Manchmal muss man ein Proposal erst zur Abstimmung bringen, damit sich die Leute damit beschäftigen. Das ist aktuell bestens gelungen. Die Ereignisse überschlagen sich, immer mehr Vorschläge werden veröffentlicht. Ich hab auch welche.
Den Ansatz für width und maxspeed finde ich gut.
Die starre Trennung nach Fahrtrichtungen ist aber nicht flexibel genug. In den USA gibt es angeblich Abbiegespuren, die in beiden Fahrtrichtungen befahren werden dürfen. Außerdem sind Bus- und Radstreifen auf der “linken” Seite denkbar möglich.
Ich habe in der Mailingliste Talk-AT ein Konzept vorgestellt, das ich hier noch genauer ausführen möchte.
Anforderungen:
- Es sollen alle Spuren, Trennstreifen usw. abgebildet werden.
- Es soll Routing in allen Fällen und für alle Verkehrsteilnehmer funktionieren. (Außer Fußgänger, die klammere ich mal aus.)
- Auf vielfachen Wunsch sollen Spurassistenten möglich sein, d.h. ein Navi soll ansagen können, welche Spur die richtige ist, um mehrere Kreuzungen später richtig abbiegen zu können.
- Das ganze soll mit möglichst wenig Relationen und möglichst wenig + verständlichen Tags gehen.
Ich bin zur Ansicht gelangt, dass man die Spurendefinition von den Routinginformationen trennen muss. Bisher wurde das oft in einen Topf geworfen, darum waren die Taggingschemas wirr und deckten nicht alle Fälle ab.
1.) lanes=* - Spuren- und Spurentrennerdefinition, für beide Fahrtrichtungen
2.) lane_matching=* - Von welcher Spur kommt man auf welche Anschlussspur auf welchem anschließenden Way. In diesem Tag werden nur die in Fahrtrichtung zu benutzenden Spuren berücksichtigt.
3.) Spureigenschaften:
lanes:maxspeed=*
lanes:width=*
lanes:surface=*
usw.
Wie von Walter vorgeschlagen, aber mit lauter Kommas, keine Strichpunkte. Strichpunkte sind nicht nötig, weil die Fahrtrichtung schon in lanes=* definiert wird. Außerdem werden Strichpunkte üblicherweise benutzt um unabhängige Werte aneinanderzureihen. Hier sind sie nicht unabhängig, sondern sie stehen in einer definierten Reihenfolge.
Die Spuren werden immer von links nach rechts angegeben (in Way-Richtung schauend).
ad 1:
Die Syntax ist von http://wiki.openstreetmap.org/wiki/Proposed_features/Lanes_ex abgeleitet, aber viel ist davon nicht mehr über.
lanes=<Spuren von links nach rechts, jeweils mit mind. 1 Trenner dazwischen>
= [“+” …]
= l | sl | s | sr | r | c | b | t | w … left/slightleft/streight/slightright/right/(bi)cycle/bus/taxi/railway(oder tramway)
- kann auch uppercase sein, heißt dann engegen der Wayrichtung.
Beispiele: w+l … Linksabbiegespur mit Schienen; b+c … Bus und Fahrrad; L+l … in beiden Richtungen befahrbare Abbiegespur (s.o.)
= folgende:
, … Leitl- oder Warnlinie, Spurwechsel/Überholen erlaubt
| … Sperrlinie
,| … Sperrlinie, Überholen von linker Seite erlaubt
|, … Sperrlinie, Überholen von rechter Seite erlaubt
|| … doppelte Sperrlinie
<> … undefinierte bauliche Trennung
… durch Grasfläche baulich getrennt, die Klammern sind hier Literale, statt grass sind auch alle anderen Werte von barrier=* und surface=* erlaubt
ad 2:
lane_matching=<Spuren von links nach rechts, durch je 1 Komma getrennt>
= [][“.” [“+” …]]
… 0=umkehren, 1=linkester Anschlussway, 2=zweitlinkester usw., Default ist 1
… 1=linkeste Spur, 2=zweitlinkeste usw., Default ist alle
lane_matching:backward=* … genauso, aber Blick entgegen der Wayrichtung, für die Anschlüsse am rückwärtigen Ende des Ways
Beispiel 1:
lanes=R,C,S,SLsl,s,c,r für beidseitig Linksabbiegeundgradaus-Spur, Gradausspur, Radfahrstreifen und Rechtsabbiegespur, in der Mitte eine bauliche Trennung mit Hecke.
dazu zusätzlich:
lane_matching=0+1+2.1, 2.2, 2.3, 3
- d.h. von der linkesten Spur darf man umkehren (0), links abbiegen auf beliebige Spur (1) und geradeaus fahren auf linke Spur (2.1);
von der zweitlinkesten Spur darf man geradeaus auf die zweitlinkeste fahren (2.2);
von der drittlinkesten auf die drittlinkeste (d.h. auf den Radfahrstreifen bleiben);
von der rechten darf man rechts abbiegen auf eine beliebige Spur (3).
Beispiel 2:
3 Spuren, mittlere teilt sich:
lane_matching=.1, .2+3, .4
Beispiel 3:
3 Spuren, linke hört auf:
lane_matching=.1, .1, .2
Zusammenfassung: Die Syntaxbeschreibung wirkt ein bisschen kompliziert, aber wie die Beispiele zeigen, ist das Tagging sehr kurz und halb so wild. Relationen sind keine nötig, die Abbiegerelationen erübrigen sich auch. Bei Way-Splits muss man aufpassen, aber das gilt für die alternativen Proposals genauso.