Das Problem ist z.B. auch in Dresden noch nicht geklärt.
Dort wird immer noch falsch geroutet, weil es m.E nur über einen getrennten Weg richtig funktioniert oder mit lanes da wo die durchgezogen Linie beginnt oder endet.
Es geht ja nicht nur ums Ansagen, sonder auch ums Anzeigen.
Auch bei größeren Kreuzungen mit diagonaler Linksabiegerspur zeigen die Router erst bei kreuzenden Fahrbahnfahren scharf links abiegen:
Das hatten wir doch schonmal? Wenn ein Router change:lanes nicht auswertet, ist es ein Routerproblem, ist alles richtig getaggt dort, der Router ist falsch.
Das ist ein weiteres Problem. Es scheint kein extra tag für Exit lanes zu geben. Programmiertechnisch wäre das meines erachtens nur zu lösen in dem man die lanes vor und nach dem motorway_junction vergleicht. einmal hat man 2 und einmal 3, darauf kann das navi folgern, das Exit lanes getaggt sind. Anschließend muss man vom motorway_junction rückwärts prüfen wieviele Segmente diese zusätzliche lane haben.
Unterstützend könnte man dann noch den turn:lanes auswerten und feststellen, dass die zusätzliche lane auch einen anderen turn hat.
Osmand zeigt im Display tatsächlich einen Fahrspurassistent an. Aber in Verbindung mit der Entfernung ist dieser manchmal eher verwirrend als hilfreich. Die Aussage die Osmand trifft ist im Prinzip “Wenn die Entfernungsanzeige auf 0 steht, dann musst du auf dieser Spur sein”. Für Fahrer hilfreicher wäre aber die Info wann diese Spur anfängt, also wann man wechseln muss. Im Stadverkehr kann es sein, dass viele Abzweigungen nah hintereinander sind. In Osmand kommt die Anzeige in 500m die rechte Spur. Wechselt man zu früh, landet man ganz woanders, wechselt man wie von anderen Navis gewohnt bei 0 ist es schon zu spät weil man bereits auf der Spur sein müsste.
Der Vorschlag in Github stammt von mir daher möchte ich mich gern nochmal auf deutsch dazu äußern.
Programmiertechnisch ist es ein Problem festzustellen ob man geradeaus, leicht rechts, rechts, scharf rechts oder eine wende machen soll WENN keine turn angabe vorhanden ist.
Der Grund ist, dass die einzigen Informationen die das Navi in diesem Fall hat sind die Ausrichtung der Segmente und die Winkel dazwischen. Das bedeutet es muss eine Regel geben welcher Winkel welche Abbiegeart bedeutet.
0-25° = Geradeaus, 26 bis 64° leicht rechts, 65 bis 100° rechts… usw.
nun gibt es aber 1. Es liegt am Mapper wie der Winkel letzendlich aussieht. 2. solange die Hauptstrecke gerade ist, läßt es sich leicht rechnen, was aber wenn die Ausfahrt in einer Kurve liegt? Welches Segment nutzt man zur Winkelbestimmung? Oder ein Mittelwert?
In Abhängigkeit der Bauweise und des Mappers werden diese Winkel, also die Grenzwerte mal leicht über- oder unterschritten mit dem Ergebnis, dass das navi ein abbiegen oder ein geradeaus anzeigt wo keins sein sollte. Das lässt sich aber nicht beheben indem man die Grenzwerte ändert, denn dann werden einfach nur andere Stellen falsch.
Allerdings muss ich sagen, dass diese Funktion in älteren Osmand Versionen besser geklappt hat und erst in der ganz neuen falsch ist bzw. schlechter.
PS: An einer Autobahnauffahrt hab ich mal gesehen, dass jemand diese sozusagen rechtwinklig gemappet hat also so:
=======
|
mit dem Ergebnis, dass osmand sagte in 200m links abbiegen, dann sofort rechts abbiegen. Daher meine Vermutung, dass es ohne turn lanes die Winkel der Segmente bestimmt.
Auch diese Aussage kann ein Router aus den gegebenen Daten gewinnen, indem er die Lage abbiegender Knoten auswertet. Wenn ich am Knoten n abfahren muss, kann er mich auf die Abbiegespur wechseln lassen, sobald (a) ich an Knoten (n–1) vorbei bin und (b) sich an der Spurkonfiguration auf der Abbiegeseite nichts mehr ändert (also eine durchgehende rechte Spur mit turn:lanes:***|[slight_]right vorliegt).
Ich bleibe dabei: Die Daten sind alle da, die Router müssen sie nur auswerten.
Das ist ein anderes Thema, aber ich halte es auch für eine absolute Unsitte, den Way der Abbiegerampe so weit in Wegmitte zu belassen, bis er parallel zur Hauptfahrbahn läuft, und dann mit einem 45° abknickend gewinkelten Stück dort anzubinden. Das suggeriert jedem Router Kurven, die gar nicht da sind, ohne eine Chance für ihn, das zu erkennen. Wenn ich Abbiegerampen mappe, lasse ich sie „fließend“ aus dem Haupt-Way abzweigen bzw. in ihn einmünden, so wie man halt auch fährt (wobei die Form der Geometrie entscheidend ist, nicht die exakte Lage).
Das würde zumindest erklären warum man oftmals die Exit lanes einzeln sieht. Nämlich immer dann wenn der Mapper der Meinung war, dass ein “Smooth turn” nur am Anfang (oder der Mitte) der Ausfahrtspur möglich war. Aber ich denke niemand hält einen “Smooth turn” am Ende also am Punkt der baulichen Trennung für noch machbar.
Gleichzeitig ist offensichtlich warum die navis so navigieren wie sie es eben tun. Die halten sich an die englische Definition und geben dem Fahrer den Punkt des “Smooth turn”.
Schaut man sich die Versionsgeschichte an so ergibt sich folgendes:
Anfang 2013 stand da: Der letzte Punkt an dem ein legales abbiegen möglich ist. Also am Ende der gestrichelten Linie.
Und seit Ende 2013 die Definition “Smooth turn”.
Wenn man jetzt den Vorschlag von Kreuzschnabel beherzigt, dass man die Abbiegespuren fließend in die Straße einführt, sehe ich kein großes Problem, beide Punkte umzusetzen. Wenn die Abbiegespur fließend die Straße verlässt, ergibt das ziemlich genau den beschriebenen “smooth turn”. Folglich ist die junction-Node dann an dem Gemeinsamen Punkt der beiden Ways perfekt gesetzt.
Ich finde letzendlich wiedersprechen sich die beiden Definitionen, was es einerseits für Mapper und andererseits für Navi Hersteller schwierig macht. Hier mal ein Beispiel von der Stelle die ich meine:
Der wirklich letzte Punkt eines “Smooth turn” wäre bei 1, danach ist die Linie durchgezogen. Die “markierende” Trennung ist bei 2 wo auch der Punkt ist. die tatsächlich bauliche Trennung ist sogar erst bei 3.
Den Einwand von Kreuzschnabel verstehe ich durchaus, genauso wie ich das Problem verstehe, dass die Navi-Hersteller aus einer zusätzlichen lane nicht per se schließen können, dass es sich um eine Ausfahrt handelt (ein lane:types:motorway|motorway|exit gibt es ja nicht) und daher den optimalen Punkt zum Spurwechseln nur schwer bestimmen können.
Also wenn ich mir turn:lanes=through|through|slight_right ansehe, ist glaube ich ziemlich offensichtlich, welche Spur zum Abbiegen vorgesehen ist. Dieser Wert sollte bei nahezu allen gewöhnlichen Ausfahrten so oder so ähnlich auftauchen.
Wenn man sich den letzten Punkt des Ways mit diesem Tagging ansieht, kann man bei korrektem Mapping in 99% der Fällen klar auslesen, auf welchen Way eine Spur mit slight_right führt.
Ein gutes Navi sollte daher ab Beginn des turn:lanes - Taggings auf die zu verwendende Abbiegespur verweisen.
Einzige Problem ist, wenn ein komplexeres System mit mehreren parrallelen Abbiegespuren vorliegt, die alle zu einem anderen Way führen. Dieses Problem kann man aber IMO nur über Relationen einwandfrei lösen - die bisherigen Varianten eignen sich dafür nach meiner Auffassung alle nicht.
Ich hatte schon öfter den Gedanken, dass man dafür die destination-Relationen so modifizieren könnte, dass man über die Rolle angeben kann, welche Spur auf einem Way zum gewünschten Ziel führt. Das würde es auch ermöglichen, im bei komplexen Innenstadtkreuzungen schon mehrere Knotenpunkte vorher auf die korrekte Spur zu verweisen. Google verwendet übrigens ansatzweise schon ein solches Sytsem.
Eine Rolle für das oben genannte Beispiel innerhalb einer destination-Relation für die Abbiegenden Richtungen könnte bspw. so aussehen: n|n|y
Fragt sich, wie dehnbar ein smooth turn ist, bzw. was es genau meint. Ich meine, dass man am letztmöglichen Abbiegepunkt smooth abbiegen kann, somit kollidiert das egtl. mit nix.
Warum nicht?
Der Streifen wird dann als slight_right erfasst.
Evtl je nach Beschilderung nicht von Beginn an, aber ab dem Moment, wo das so ist kann der Router das auch auswerten.
Wo der Streifen im Endeffekt her kommt ist nebenrangig und kann auch durch die derzeitigen Methoden gar nicht ohne Zweifel ausgewertet werden.
Bestes Beispiel ist der Bonner Verteilerkreis am Ende der A555. Genau an der Stelle, wo der Heinrich-Böll-Ring in den Verteiler einmündet, bekommt die Kreisfahrbahn eine weitere Spur. Diese ist jedoch nicht die Spur, die vom Heinrich-Böll-Ring kommt. Die Fahrzeuge, die von dort kommen müssen sich direkt in den fließenden Verkehr einordnen.
Dort steht zwar glaube ich ein Vorfahrt-Achten Schild, aber auch da dran kann man das nicht fest machen, weil es eine ganze Reihe Beschleunigungsstreifen gibt, die ebenfalls Vorher ein Vorfahrt-Achten Schild stehen haben. Sogar Stopp-Schilder gibt es vor Beschleunigungsstreifen, vor allem in Autobahnbaustellen.
Neuer Aspekt: Es gibt auch noch die Möglichkeit der turn-Relation, die wirklich exakt aussagt, ab wann welche Spur wohin führt.
Diese Konstrukte dürften rein technisch die beste Lösung darstellen, sind aber ziemlich wartungsfeindlich (wenn so ne Kreuzung mal umgebaut wird, räumt man die Relationen am besten erstmal komplett ab und fängt beim Urschleim neu an) und für Anfänger vollkommen unzumutbar – außer es gäbe Werkzeuge, die das Ganze menschenverständlich präsentieren, z.B. als GUI mit Spurdarstellung zum Klicken, und die Relation daraus maschinell erstellen. Ich weiß nicht, ob es die gibt.
Hier ist auch die Frage aus wessen Sicht “smooth”. Je früher der Spurwechsel stattfindet umso sicherer ist es für alle Verkehrsteilnehmer.
Betrachtet man es aus der Sicht eines Fahrer der schon auf dem Verzögerungsstreifen ist und der dann beobachtet wie von links kurz vor Ende des Streifens ein weiterer kurz vor knapp rüberzieht, dann fallen demjenigen viele Begriffe dafür ein aber “smooth” dürfte nicht zur Auswahl gehören.
Ich habe übrigens eine Anfrage an die Osmand Entwickler gestellt und wenn ich die Antwort des Programmierers (der auch hier im russischen Forum ist) richtig deute, dann reicht ein turn:lanes schlicht nicht aus. https://github.com/osmandapp/Osmand/issues/5246
Openstreetmaps, Navis und Anwender können gegenseitig voneinander profitieren. Wenn die Navi App gut und zuverläßig ist, dann ist der Nutzer vllt auch mal bereit den ein oder anderen Poi oder Hausnummer einzutragen (so wars bei mir). Wenn umgekehrt die Erfahrung ist, das trotz “korrektem” mapping das Navi unzuverläßig ist, dann hat man wenig Lust etwas beizutragen.
Die turn-relation wird ich mir mal ansehen. Wäre ja intressant ob diese auch von den Navis unterstützt wird oder ob man wegen der Komplexität und der geringen Nutzung darauf verzichtet.
Du vermischt grade Spurwechsel und Abbiegevorgang. Der Spurwechsel kann und sollte natürlich so früh wie möglich angesagt werden, OSM bietet dafür auch die Instrumente (turn:lanes). Der Abbiegevorgang ist dann das tatsächliche Verlassen der Hauptfahrbahn. Dies sollte an dem Punkt angezeigt werden, wo man noch eine normale “smoothe” Lenkradbewegung macht.
Die Turn-Relation ist gegenüber der :lanes-Erweiterung nagelneu. Es gibt ein paar Tools, die das Testhalber auswerten, aber von einem Einsatz in einem Navi habe ich bisher nichts gehört.
