Meinst du beim ersten Punkt in der Regel jetzt “Wegrichtung” oder “Fahrtrichtung”?
Das Problem bei der Fahrtrichtung ist halt die vollstaendige Listendarstellung lanes:continutaion:forward=left|straight|straight|right
Bei den Spuren mit lanes:direction=forward wird hier die Kreuzung an dem einen Ende des Weges beschrieben, bei den Spuren mit lanes:direction=backward wird hier eine ganz andere Kreuzung am anderen Ende des Weges beschrieben.
Diese Vermischung halte ich fuer ziemlich verwirrend. Mir schient es da sinnvoller zu sein, dass man unter EINEM Schluessel die Verbindungen der Spuren an EINEM Ende des Weges sammelt.
Vielleicht waere als Schluessel lanes:connection passender, da dieser Begriff bezgl. der Richtung neutraler ist. Es wird einfach angegeben, wie eine Spur an diesem Kreuzungspunkt mit den anderen Richtungen verbunden ist.
Ich muss gestehen, dass ich weder deinen Zusatz noch das Beispiel in deinem Link wirklich verstehe.
Nach meinem Konzept sollte in einem Schlüssel erfasst werden, wie die jewielige Spur an einem Knotenpunkt mit den angrenzenden Wegen verbunden ist. Das wird ueber den entsprechenden Wert abgebildet, wobei auch eine Liste von Werten moeglich ist.
Die gaengigsten Werte duerften straight, left und right sein dazu kommt sicherlich noch ein Wert fürs Wenden u_turn oder backward vielleicht sowie Zwischenwerte fuer kompliziertere Kreuzungstopologien wie slight_left oder sharp_right und vielleicht braucht man auch noch ein up oder down, wobei solche vertikalen Wegtrennungen eigentlich immer auch in der Ebene beschrieben werden koennen.
Bei naeheren ueberlegen habe ich deine Frage jetzt, glaube ich, doch verstanden. Meinst du: Wie wuerde mein Konzept es abbilden, wenn die Verbindungen zwischen den Spuren nicht symmetrisch sind? D.h. solche Faelle, wo eine Spur in beide Richtungen befahrbar ist, sie ueber die Kreuzung aber mit Spuren verbunden ist, die nur in eine Richtung befahren werden darf.
Bei meinem Konzept wuerde sich daraus ergeben, dass lanes:connection:forward des eines Weges nicht genau dem lanes:connection:backward entspricht. Da hatte ich bisher noch nicht drueber nachgedacht, scheint mir aber letztendlich kein Problem zu sein, denn am Ende sollte sich ja trotzdem ein widerspruchsfreies Gesamtbild ergeben.
Das ist die von mir noch offen gelassene Frage, ob man bei der Bezeichnung der einzelnen Spuren zwischen Abbiegespur und “normaler” Fahrspur unterscheiden muss oder nicht. Fuer das Routing (im Sinne von: Bestimmung der optimalen Spur) oder für eine schoene Kartendarstellung braucht man das eigentlich nicht. Aber fuer die Sprachausgabe koennte das hilfreich sein. Oder verwirrt diese Zusatzinformation eher? Ich habe weiss es nicht. Ab wann ist eine “normale” Fahrspur eine Abbiegespur? Sobald da Pfeile aufgemalt sind, schaetze ich mal.
Weil dabei Schluessel und Wert vermischt werden. Bei dieser Loesung muss man auch die rechte Seite der Gleichung auswerten, ehe man entscheiden kann, ob das Tag fuer einen von Belang ist oder nicht.
Bezueglich der Zahlen in Schluesseln sehe ich nicht so das grosse Problem. Klar, die Auswerteprogramme muessen eine Nummer schlauer werden, wenn sie diese Informationen auswerten wollen. Das gilt aber auch fuer die angedachte Listendarstellung auf der rechten Seite des Gleichheitszeichens. Das Spurmapping stellt nun mal hoehere Anforderungen an die Auswertung, liefert aber dafuer zusaetzliche Informationen, die bislang nicht erfasst werden koennen.
Mit dem lanes=* stimme ich mit fkv ueberein. Es besteht keine Gefahr, dass lanes=* und lanes= bei der Auswertung verwechselt werden. Und ich sehe keinen Sinn darin, fuer einen Weg die Beschreibung von lanes= und lanes:layout=* parallel vorzusehen/zuzulassen. Das wuerde nur zusaetzliche Komplikationen mit sich bringen.
@fkv: Ja, ich sollte wohl mein Konzept auch als Variante in die Uebersicht mit aufnehmen. Allerdings habe ich damit zwei Probleme: Zum einen legt das fuer meinen Geschmack den Schwerpunkt zu sehr auf die Syntax, welche ich als eher zweitrangig ansehe. Zum anderen sind die Beispiele so unvollstaendig, dass die konzeptionellen Unterschiede zwischen den einzelnen Varianten gar nicht klar werden. Solange z.B. nicht der OSM-Weg-Graph fuer die Beispiele mit angegeben wird, kann man einen Unterschied zwischen einer Erfassung enstprechend der Wegrichtung und einer Erfassung entsprechend der Fahrtrichung gar nicht erkennen.
Gruss
Torsten