An der Stelle hatte ich auch lange ueberlegt, aber ich denke doch, dass ein Tagging der fahrtrichtungsbezogenen Fortsetzung noch verwirrender ist, da man dann in EINER Liste die Angaben fuer ZWEI raeumlich getrennte Wegenden vermischt.
Die Information, dass eine Spur z.B. eine reine Linksabbiegerspur ist, sollte am Way selbst vorliegen. Es wäre unzumutbar, dazu alle Spuren aller anderen Ways einer Kreuzung prüfen zu müssen!
Laut meinem Vorschlag ist das ja auch nicht zwingend gefordert, dass man das so erfasst. Letztendlich stossen an einem Kreuzungspunkt ja mehrere Wegenden aneinander, und man muss per Tagging erfassen, wie sich die einzelnen Spuren ueber die Kreuzungen hinweg miteinander verbinden. Von der Intuition her ist es sicherlich am einfachsten, wenn man fuer jede auf die Kreuzung hinfuehrende Spur angibt, wie diese hinter der Kreuzung weiter geht. Der Vollstaendigkeit halber muss aber auch definiert sein, wie entsprechenden Tags fuer die anderen Spuren zu setzen sind. Das heisst ja aber nicht, dass man die aber auch mit angeben muss, denn letztendlich wird dadurch ja das System ueberbestimmt.
Spaetestens wenn man die Fusswege mit einbezieht, hat sich das mit der definierten Fahrtrichtung der einzelnen Spuren sowieso erledigt.
Du bist nicht der erste in diesem Thread, der lanes=* als Key nutzt. Ich halte das aber für einen unnötigen Konflikt mit der bisherigen Verwendung von lanes=* für die Anzahl der (Fahrbahn-)Spuren. Das lässt sich durch Wahl eines anderen Schlüssels - lanes:layout, lanes:type, lanes:class oder was auch immer - problemlos vermeiden.
Die Bezeichner sind mir bislang voellig egal, entscheidender ist es, erstmal eine Struktur fuer das Spurmapping auszuarbeiten.
Mit Schlüsseln wie “lanes:surface:6” wird ohne Not der Vorteil aufgegeben, nur eine feste Anzahl Schlüssel zu haben, was sich Anwender z.B. beim Import in Datenbanken oft wünschen.
Am einfachsten für die Auswertung und auch in Editoren & co fände ich, Leerstellen in der Liste zu erlauben. Als z.B.:
lanes:surface = ;;;;;unpaved
Das würde sich fast von selbst programmieren.
Im Prinzip wuerde beides gehen. Die erste Variante waere m.E. einfacher (per Hand) zu editieren und auch besser zu lesen, die zweite Variante waere vielleicht einfacher auszuwerten. Letzteres wuerde ich allerdings nicht ueberbewerten, denn ohne viel Aufwand koennte ein Praeprozessor die eine Notation in die andere umwandeln.
Wenn das wegen der Lesbarkeit nicht gefällt, würde ich subjektiv ein
lanes:surface = 6:unpaved
bevorzugen.
Das halte ich fuer die schlechteste aller moeglichen Loesungen.
Da muss klar sein, dass diese Verschönerung der Tags (der Verzicht auf ein spezielles Richtungstrennzeichen wie das | in meinem Post) dadurch erkauft wird, dass für die große Mehrheit der “normalen” Straßen ohne ungewöhnliche Verteilung der Fahrtrichtungen ein Zusatztag nötig wird. Dazu kommt noch, dass du die Information über “Linksabbiegerspur” etc. in ein Sondertag auslagerst. Das ist zwar schön aufgeräumt, aber führt insgesamt zu 3 Tags statt 1 Tag als Mindestausstattung einer so getaggten Straße.
Ist der haeufigste Fall wirklich die Linksabbiegespur? Ist nicht der Fall viel haeufiger, wo eine Strasse ohne bauliche Veraenderung fortgefuehrt wird und man einfach nur beschreiben muss, wie die Strasse aussieht? Im Normalfall braucht man sich um das Verbinden der Spuren eigentlich gar nicht kuemmern, ich wuerde mal schaetzen, dass man bei ueber 90% der Verbindungspunkte ohne weitere Angaben allein mit Default-Werten klar kommt. Die Zusatztags sind doch erst in den Sonderfaellen nötig, wo man es mit komplizierteren Kreuzungsstrukturen zu tun hat.
Gruss
Torsten