Hallo,
heute bin ich auf Relationen mit type=turnlanes:turns gestoßen, die JOSM-Prüfung zeigte sie an.
Beispiel: https://www.openstreetmap.org/relation/3078719 .
Sowas kannte ich noch nicht. Es gibt eine Wikiseite dazu https://wiki.openstreetmap.org/wiki/Relations/Proposed/turn_lanes, ein Vorschlag aus dem Jahre 2011 (RFC startete am 18.3. 2011). Ist das veraltet? Wie ist damit umzugehen?
Es werden damit wohl erlaubte Abbiege- bzw. Geradeausrelationen dargestellt im Gegensatz zu den Abbiegebeschränkungen, die ich bisher für den Standard gehalten habe.
Auch. Vor allem werden damit Spurführungen an Kreuzungen sehr exakt dargestellt, also welche Spuren einer hinführenden Straße auf welche Spuren einer wegführenden Straße führen. In der Praxis funktioniert das nicht ganz so wasserdichte turn:lanes=* (das zwar die Anzahl der Richtungsfahrstreifen, aber nicht die genaue Zuordnung abbildet) aber meist auch gut genug. Abgesehen davon, dass man für jeden Fahrstreifen jeder hinführenden Straße eine separate Relation braucht.
Ist eine ältere Methode zum Mappen von Abbiegespuren. Bevor sich turn:lanes=* durchgesetzt hat gab es diverse relationsbasierte Ansätze fürs Spurmapping. (Ich hatte so um 2008 rum auch mal einen, inkl. zugehörigem Tool. Damals hatte ich noch etwas seltsame Vorstellungen vom OSM-Datenmodell. ;))
Dieser Relationstyp dürfte seine im Vergleich zu ähnlichen Ansätzen größere Popularität auch vor allem dem schicken zugehörigen JOSM-Plugin verdanken. Wie Kreuzschnabel sagt ist es theoretisch nicht komplett durch turn:lanes=* ersetzbar, weil es das Ziel einer Spur explizit macht. In der Praxis ist das aber meist auch mit den turn-Werten eindeutig.
Interessant werden so Relationen bei Situationen, wo schon Abbiegespuren für spätere Kreuzungen vorgeschrieben sind. Zum Beispiel:Linke Spur biegt an der kommenden Kreuzung links ab, zweite Spur von links biegt an der darauffolgenden Kreuzung links ab, daneben die Spur fährt diese und nächste Kreuzung geradeaus und von der rechten Spur darfst du diese und nächste Kreuzung rechts abbiegen (zwischen der kommenden und der darauffolgenden Kreuzung ist kein Spurwechsel mehr erlaubt).
Nun habe ich das kapiert; in der Relation gibt lanes=* die durchnumerierte Fahrspur, nicht die Anzahl an. Aber im Grunde definiert doch turn:lanes, ggf. mit forward|backward, welche Spuren für welche Richtungen sind. Für jede Abbiegemöglichkeit eine Relation ist eine Menge Zeug.
Vielleicht war das anfangs verlinkte Beispiel auch unglücklich, um den Sinn und Zweck dieser Relationen zu verstehen, denn da hat nur die Äußere Bayreuther Straße von Süden her zwei Abbiegespuren (left|through;right), ansonsten ist das eine simple 2-Straßen-kreuzen-sich-und-man-darf-von-jeder-in-jede-andere-einbiegen-Kreuzung. Nun wird diese Tatsache mit 12 Relationen abgebildet, wofür mit turnrestrictions 0 notwendig wären. Das erscheint mir unnötig komplex.
Daher war für mich auch die Frage, ob das veraltet ist und eher umgebaut werden sollte oder zwar einem alten Proposal entspringt, aber nicht falsch ist und nicht stört, also bleiben kann.
Ich hab’s ja nur bemerkt, weil JOSM es als unbekannten Relationstyp angezeigt hat.
Wäre das nicht ein Fall für destination:lanes ?
Ein interessantes anderes Detail an dem Proposal ist die Angabe, ob zusätzliche Abbiegespuren links oder rechts angeflanscht sind oder geht das auch mit turn:lanes irgendwie? Sowas wäre zur Orientierung für eine Routerdarstellung der Abbiegespuren nützlich. Kommt für die Linksabbieger vor der Kreuzung noch eine Linksabbiegespur links dazu oder wird die linke Spur, auf der ich gerade fahre, zur Linksabbiegerspur und sollte ich besser rechtzeitig eine Spur nach rechts wechseln?
Das ist für Angabe der Beschilderung der Spur hilfreich. Der Router weiß aber trotzdem nicht, welche Spur der Fahrer nehmen muss. Bei normalen Kreuzungen kann der Router ganz gut raten, aber bei komplizierten eher nicht.
Es fehlt derzeit eine saubere Möglichkeit zur Spezifikation, wie die Spuren von zwei verbundenen Wegen miteinander verbunden sind.
Der Key transit hatte diese Spezifikation mit gewissen funktionalen Einschränkungen ermöglicht.
Dieser wurde aber von den Editorentwicklern strikt abgelehnt. Meines Erachtens war das transit-Proposal auch wenig ausgereift. Es wurde dabei zuviel Wert auf hübsche Tags in Standdardfällen gelegt, was man sich aber mit einem unnötig komplizierten Regelwerk und funktionalen Einschränkungen erkauft hat.
In einigen Fällen kann eine Heuristik auf Basis der placements Tags helfen. Allerdings geht das bei den Proposal-Beispielen auch meist besser als in Realität, z.B. auf Straßen ohne bauliche Trennung der Fahrtrichtungen scheitert dies fast komplett.
Die Relationen vom Typ turnlanes:turns helfen da auch nicht weiter, weil zwar die zu verwendende Zugangsspur spezifiziert wird, aber abgangsseitig nur der Weg spezifiziert wird, aber nicht die zu nutzende Spur.
Das Plugin zu turnlanes könnte eine fast ideale Basis sein, um Verbindungen von Spuren zu spezifizieren.
Dazu wäre es so zu ergänzen, dass man abgangsseitig auch einzelne Spuren auswählen kann.
Die Unterstütung der Extraspuren wäre zu entfernen, da diese inkompatibel zum :lanes-Schema sind.
Abzulegen wären die Daten dann in einem überarbeiteten turnlanes:turns Relationstyp oder in einem komplett neuen Relationstyp.
