Am 9. März 2012 13:53 schrieb Christian Müller <cmu...@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. ;-) ) _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de