Eine Sache die mich beim regelmäßigen Navigieren stört, sind die ungenauen Anzeigen des Navis, auf welcher Spur ich mich bevorzugt aufhalten soll, bzw. oft ist gar keine Empfehlung vorhanden.
OSM hat ein wesentliches Problem: Jedes Mal wenn sich die lane-Anzahl erhöht, kann ein Router nicht wissen, an welcher Stelle die neue Spur entsteht. Zu diesem Zweck könnte man folgendes Schema nutzen:
following_lanes=* gibt an, wie sich die Fahrspuren auf dem nächsten Way-Segment in Fahrtrichtung ändern. Das Tagging-Prinzip ist ähnlich zu turn:lanes=*, sodass für jede Fahrspur ein Value angegeben wird:
*remain => Lane bleibt bestehen
*new_to_left => zusätzlich zur bestehenden Fahrspur entsteht links davon eine neue Fahrspur
*new_to_right => zusätzlich zur bestehenden Fahrspur entsteht rechts davon eine neue Fahrspur
*split => aus 1 Lane werden gleichberechtigt 2
*merge_to_right => nach rechts einordnen
*merge_to_left => nach links einordnen
*merge_with_left => mit linker Spur vereinigen
*merge_with_right => mit rechter Spur vereinigen
*no => Lane endet (wg. Kreuzung; wird benötigt falls gleichzeitig eine Spur wegfällt und woanders eine neue enststeht)
Beispiele:
*new_to_right;new_to_right => 2 neue Fahrspuren rechts
*new_to_left;new_to_right => rechts wie links eine neue Fahrspur
*following_lanes=remain|new_to_right => aus einer 2spurigen Straße entsteht rechts eine neue Spur, sodass die Straße 3 spurig wird.
*split;split => aus 1 Lane werden 3
Nun kann man sich natürlich die Frage stellen, warum hier merge_to_right und merge_to_left mit auftaucht, obwohl das schon in turn:lanes drin ist. Die Antwort ist recht leicht: turn:lanes bezieht sich auf das Abbiegen an der nächsten Kreuzung. merge_to_* bezieht sich aber nur auf Spurveränderungen im nächsten way-Segment und hat mit einer Kreuzung nichts zu tun. Demzufolge sollte es unter following_lanes geführt werden.
Das Proposal für den Key transit halte ich allerdings noch nicht für ausgereift. Leider wird im Wiki sehr wenig disskutiert, solange es kein Voting gibt.
Das Proposal und der obige Vorschlag haben gewisse Ähnlichkeit und auch ähnliche Probleme. Für beide gilt, dass sie in komplexen Fällen nicht die nötige Information für die Verbindung von Spuren definieren können, und in vielen Fällen, wo diese prinzipiell funktionieren, eigentlich nicht gebraucht werden.
Ein konzeptioneller Fehler ist auch, dass beide die Beschreibung der Geometrie des Folgeweges teilweise in den vorangegangenen Weg verlagert wird. Wenn eine neue Spur im Folgeweg hinzukommt, indem sie mit einer Breite von Null am Anfang des Folgeweges beginnt, ist dies aussschließlich eine Eigenschaft des Folgeweges. Ebenso ist die Erreichbarkeit der neuen Spur ausschließlich eine Eigenschaft des Folgeweges, die mit dem Key change:lanes definiert werden kann.
Ebenso sind innerhalb eines Weges endende Spuren (Endbreite 0) ausschließlich eine Eigenschaft dieses Weges und wie diese verlassen werden können, kann auch durch den Key change:lanes definiert werden.
Wenn wir die Geometrie der Spuren des einzelnen Weges dadurch hinreichend definieren, dass wir bei Bedarf die Keys width:lanes:start und width:lanes:end verwenden, um die Spurbreiten am Anfang und Ende des Weges festzulegen, so ist eine zusätzliche Beschreibung der konnektivität der Spuren in der Regel entbehrlich. Ich sehe zwei Ausnahmefälle:
Kreuzende Spuren in unverzweigten Straßenverlauf, z.B. eine Bus- oder Radspur wechselt die Lage.
Verzweigungen oder Kreuzungen des Straßenverlaufs
Ein System zur Beschreibung der Konnektivität von Spuren sollte daher drauf ausgelegt sein, gerade diese beiden Ausnahmefälle abzudecken, wobei im zweiten Fall teilweise auch die Konnektivitätsbeschreibung zu mehr als einem Folgeweg benötigt wird.
Weder das Proposal noch obiger der Vorschlag von Manatar können kreuzende Spuren oder Konnektivität zu mehreren Folgewegen abdecken, und scheitern damit insbesondere dort, wo sie wirklich gebraucht werden.
Mehrere Folgewege unterstützt das Proposal mithilfe der Relationen. Relationen sind zwar ein ziemlicher Aufwand, aber ohne kommt man bei komplizierten Beziehungen einfach nicht aus.
Für kreuzende Spuren musst du mir mal ein Beispiel zeigen, da habe ich kein Bild im Kopf wie sowas aussehen kann.
Für ein direktes Überkreuzen der Spuren im Straßenverlauf habe ich leider kein Beispiel zur Hand, aber ich kenne Beispiele, die dem schon so nahe kommen, dass ich davon ausgehe, dass bestimmt irgendwo derartige direkte Kreuzungen gibt. Zum Beispiel gibt es in Hamburg zwischen Nedderfeld und Stapelstraße im Straßenverlauf der Kollaustraße Richtung Süden eine Ampel, die wechselweise die Busspur und den übrigen Verkehr freigibt, damit die Busspur gefahrlos gekreuzt werden kann um die Rechtsabbiegespur am Siemersplatz zu erreichen. Wenn die rechte Spur vor der Ampel nur diesen Rechtsabbiegern vorbehalten wäre, hätten wir eine reine Kreuzung der Spuren. Die Bing-Bilder sind dort übrigens schon zu alt, aber bei Mapillary kann man die Situation erkennen.
Ein theoretisches Beispiel für eine Spurkreuzung im Kreuzungsbereich wären zwei kreuzende Straßen, von denen eine Busspuren in Mittellage und eine Busspuren in Außenlage hat. Abbiegende Busse bräuchten dann wohl eine eigene Ampelphase um den sonstigen abbiegenden Verkehr zu kreuzen.
Ein weiteres Beispiel, wo zumindest der Verkehr eine Spur kreuzt, wäre eine Straße mit Radfahrstreifen auf der rechten Seite, wo dann eine Rechtsabbiegespur rechts des Radfahrstreifens hinzukommt. Ggf. kann es vor Beginn der Rechtsabbiegespur auch ein Radweg statt eines Radfahrstreifens sein. Auch für solche Fälle sollten wir die Konnektivität korrekt beschreiben können, und zwar nicht nur für den Autoverkehr, sondern auch für den Radverkehr.
Hamburg Siemersplatz: Was zum Geier… Ampel, Lichtzeichen, variable Schilder… und das bei einer so einfachen Verflechtung von Spuren? Vom Tagging her sehe ich dort kein Problem, das ganze ist ja langgezogen und normales Spur-Tagging sollte reichen.
Für die beiden anderen Beispiele: Das lässt sich relativ gut über Placement erledigen, danach bleibt nicht mehr viel für zusätzliches Tagging übrig, das nicht durch das Proposal erschlagen wird.
Zum letzten Beispiel habe ich hier ohnehin eine Kreuzung die ich mal ordentlich mappen wollte, vielleicht mache ich das mal.
Siemersplatz: Auch wenn man das Tagging in diesem Spezialfall funktionieren mag, heißt dies natürlich nicht, dass dies auch in ähnlichen aber doch etwas anderen Fällen funktioniert. Ein Problem scheint mir bei normalem Spur-Tagging zu sein, wie man angeben soll, dass der Wechsel über eine Spur, die ansonsten nicht benutzt werden darf, hinweg erfolgen darf. Hätte der Key change positive Werte ohne “only” oder “not”, so hätte man einfach einen zusätzlichen Wert für den Wechsel zur übernächsten Spur definieren können. Die variablen Schilder haben übrigens den Sinn, dass hinter der Ampel nur außerhalb der Hauptverkehrszeit eine Busspur ist, denn in der HVZ wird diese Spur ja vom MIV benötigt.
Wie in den anderen Beispielen der key placement helfen soll, kann ich nicht nachvollziehen.
Da man für den Key placement ohnehin schon eine Numerierung für die Spuren eingeführt hat, könnte man einfach die Nummer der Zielspur (ggf. mehrere mit Semikolon getrennt) im Wert des Tags angeben. Das ist meines Erachtens einfacher verständlich, einfacher zu beschreiben, kürzer und flexibler. Irgendwelchen kreuzende Spuren wären auch damit abzudecken.
Für dieses Beispiel von monotar http://www.openstreetmap.org/way/326302344
wäre es dann einfach:
transit:lanes=2|3|4;5|6
Ich dachte an so eine Straße (keine echten Daten, sondern schnell zusammengestellt): Lane Visualizer
Das komplette Tagging wird angezeigt wenn du links mit der Maus über “Way” gehst.
Placement hilft bei der Zuordnung der Spuren - was hier grafisch die Spuren richtig nebeneinanderlegt geht auch um die Spuren logisch miteinander zu verknüpfen.
Das Wechseln über eine verbotene Spur hinweg ist kein Problem: Ich darf dann wechseln, wenn kein change=no im Weg ist (siehe unterschiedliche Linien am 2./3. Wegstück), unabhängig davon, ob ich die überquerte Spur nutzen darf oder nicht. Sonst dürfte man streng genommen auch nicht links abbiegen, schließlich darf ich nicht auf der Gegenfahrbahn fahren.
Geometrisch ginge das Tagging hier auch, da sich eine Spur ja aufweitet:
Da dort aber noch eine Seitenstraße einmündet, wäre dies im allgemeinen Fall aber zur Definition der Konnektivität nicht hinreichend, da ja z.B. eine Spur in die Seitenstraße abzweigen und eine neue Spur aus dieser hinzukommen könnte.
Da Endbreite mit der Startbreite übereinstimmt und die Seitenstraße Einbahnstraße ist, ist dies jedoch nicht möglich und somit wäre dies dann zur Definition der Konnektivität tatsächlich hinreichend.
Diese Interpretation halte ich für problematisch. Wenn sich zwischen anderen Fahrspuren ein Sonderweg befindet, kann es prinzipiell folgende Situationen geben:
Ein Wechsel zwischen Fahrspur und Sonderweg ist nicht zulässig.
Ein Wechsel zwischen Fahrspur und Sonderweg ist nur den für den Sonderweg berechtigten Fahrzeugen gestattet.
Der Sonderweg darf zusätzlich auch von anderen Fahrzeugen überquert werden.
Ob diese Fälle bei der deutschen Rechtslage alle auftreten können, ist eigentlich belanglos. Ein Taggingschema muss weltweit funktionieren und da kann man kaum davon ausgehen, dass eine potentiell denkbare Regelung nicht irgendwo auch so existiert. Also müssen wir alle drei Fälle auch unterscheiden können.
In Deutschland scheint mir die Situation schon sehr undurchsichtig zu sein. Viele Busspuren sind komplett von durchgezogenen Linien (Fahrstreifen/Fahrbahnbegrenzung) umgeben.
Folgt man der StVO, so dürften die Busse nicht in diese einfahren und aus diesen ausfahren, da das Überfahren der Linie verboten und keine passende Ausnahmeregelung definiert ist. Da stellt sich dann die Frage, ob die Verkehrsbetriebe eine Ausnahmegenehmigung von der StVO erhalten und wo sie damit die durchgezogenen Linien überqueren dürfen.
Es ist schon klar, dass Placement für eine gewisse Heuristik zur Spurzuordnung eingesetzt werden kann. Insbesondere funktioniert dies aber dort, wo man auch über die Beschreibung der Spuranfangs- und endbreiten zum Ziel kommt. In beiden Fällen muss man gewisse einschränkende Annahmen treffen, wie das Fehlen von überkreuzten oder bei Verzweigungen übersprungenen Spuren. Diese einschränkenden Annahmen sind aber kein Problem, da man in Sonderfällen die Konnektivität ja explizit definieren kann.
Spurzuordnungen über Placement werden allerdings so gut wie unmöglich, wenn es sich nicht um einen Oneway handelt.
Wo Placement absolut nicht hilft, ist mein obiges Beispiel mit zwei kreuzenden Straßen mit Busspuren in Innen- sowie Außenlage wobei beide Straßen weder Einbahnstraße noch baulich getrennt sind. Sofern dort eine Buslinie abbiegt und auch der MIV in gleicher Richtung abbiegen darf, kommt es unvermeidbar zu einer Kreuzung von MIV und Busspur beim Abbiegen, die wir in der transit-Relation beschreiben müssen.
