[Talk-de] Fahrspuren die 315.

[Martin Simon]

Am 9. März 2012 13:53 schrieb Christian Müller <cmue81 at gmx.de>:

> Ich würde Dich bitten, Dich eingehend mit dem proposal zu beschäftigen.  Was Du hier schreibst stimmt wrt TR einfach nicht.  Du hast TR entweder gar nicht verstanden oder beschränkst Dich nur auf einen Teilaspekt, den Du glaubst verstanden zu haben.  Also nochmal:
[...]

Das hat sich als Mißverständnis herausgestellt: ich hatte deine
Restrictions in JOSM als way-node-way interpretiert, deren via-node an
der Haltlinie liegt (was auch aus meinem Text hervorgehen dürfte) -
sorry dafür.

Technisch sind die restrictions also in Ordnung, ich kenne aber
ehrlich gesagt keinen Router, der via-ways auswertet. Kennst du einen?
Für manche nach derzeitigem Konsens gemappte Kreuzungssituationen
kommt man ja auch nicht drum herum (links abbiegen erlaubt, u-turn
verboten bei baulich getrennten Richtungsfahrbahnen als separate
Ways).

Sei also versichert: ich verstehe TRs - ich war sogar schon vor ihnen hier. ;-)

Was auf jeden Fall bleibt, ist die total verhagelte Geometrie.

> Du hast Recht, wenn Du argumentierst, dass GPS u.U. nicht spurgenau positioniert.  Dafür können die Daten aber nichts und ein paar Galileo Sats sind ja auch schon oben..

Naja, aller Voraussicht nach wird das auch nicht den großen Vorteil in
"Standardsituationen" bringen, eher in solchen, in denen man heute zu
wenig Satelliten überhaupt empfangen kann.

Das Problem ist auch nicht nur die Genauigkeit der Positionierung,
sondern auch die Trennung von _einer_ Verkehrsfläche mit verschiedenen
Spuren in verschiedene Wege, die keine Verbindung besitzen - das macht
korrektes Routing im Falle einer (Neu)berechnung im Bereich vor einer
Kreuzung auch dann zur Glückssache, wenn du deine Position im
Submeter-Bereich bestimmen könntest. (einzige Chance: du bist zufällig
auf der Spur, die zur korrekten Route gehören würde)

Natürlich kommt jetzt, man könne per Relation das soeben auseinander
gefledderte wieder zusammen kleben... das macht die ganze Konstruktion
nicht unbedingt leichter handhabbar.

> Das stimmt nur dann, wenn die routing engine die TR nicht nutzt.

> Eines noch, wenn mkgmap Abbiegeanweisungen aus der Geometrie errechnet, ist das toll, es entspricht aber nicht der Definition von TR - dort ist die Anweisung, die ein TR-kompatibler Router zu nutzen hat, klar in _*_* kodiert, während also e.g. in no_left_turn das "no" für den Routinggraph relevant ist, ist der gesamte String Nutzeranweisung.  Aus der Geometrie sollten Anweisungen nur dann erzeugt werden, wenn keine TR vorhanden sind.

Nö, der ist eher Mapperhilfe und war von anfang an nicht als
Routerhinweis gedacht - ein "no_lean_right" oder "no_sharp_right_turn"
haben wir ja beispielsweise nicht.
Im Zweifel könnte man natürlich darauf zurückgreifen.

> Das ist auch so herum sinnvoll, da es aufwendiger ist, aus der Geometrie eine Anweisung zu errechnen, als wenn schon eine in der Relation verfügbar ist.

Das muß man eh mindestens für alle Kreuzungen ohne TR (Millionen!) tun
und es funktioniert zuverlässig.

Mit deinem Ansatz wird für jede Kreuzung, an der auch nur eine
Abbiegespur oder auf einer Fahrbahn mehr als eine Spur pro Richtung
existiert ein großer Haufen ways und Relationen fällig - plus
virtuelle Hilfswege zum leidlichen Wechsel der Spuren bei komplexeren
Kreuzungen.

Daß dabei ein paar Hinweise für den Router anfallen, wie eine Aktion
angekündigt werden könnte, vermag ich da nicht als großen Vorteil zu
erkennen...

Noch eine Bemerkung zum Schluss:
Auch highway=*_link ist nicht für "Spuren derselben Fahrbahn" gedacht,
sondern für Verbindungen, die baulich von der Hauptfahrbahn (so es sie
gibt) getrennt sind.

Gruß,

Martin (der erst vorgestern vom Garmin einmal um den Block gelotst
wurde, weil jemand die Straße fälschlich als "baulich getrennt"
gemappt hat und das Ziel auf der anderen Straßenseite lag. ;-) )