turn:lanes und Fahrbahnmarkierungen

Hallo,
da sich in der letzten Zeit keiner mehr zu dem Thema geäußert hat, versuche ich mal, die Diskussion zusammenzufassen und ein paar Schussfolgerungen zu ziehen.
Grundlage, um bestimmte Sachverhalte in die Datenbank aufzunehmen (zu mappen) sind
a.) dass diese Sachverhalte in irgendeiner Weise existieren
b.) dass sie für irgendeinen Zweck benutzt werden.
In diesem konkreten Fall dreht es sich um die Frage, ob an die in dem Luftbild dargestellte Abzweigung einer Straße in irgendeiner Weise turn:lanes tags notwendig sind.
Da sich die OSM-community darauf geeinigt hat, Straßen und nicht Fahrwege zu erfassen (Spuren bzw. Fahrstreifen und ihre Eigenschaften werden nicht als Vektoren gezeichnet, sondern es werden an die „hardware“ Straße die Eigenschaften geschrieben) müssen bestimmte Eigenschaften für routing software extra standardisiert gemappt werden.
Es wurden die turn:lanes tags kreiert.

Der Sinn von routing software besteht darin, einem Individuum eine Hilfe an die Hand zu geben, geführt von einem Punkt A zu einem Punkt B zu gelangen. Wenn der von der software errechnete Weg nicht nur geradeaus führt, sondern auch Verzweigungen umfasst, soll die software den Nutzer rechtzeitig darauf hinweisen, dass er sein Fahrt- bzw. Laufrichtung ändern muss, um zu seinem Ziel zu gelangen. Dazu muss die Software die in der Datenbank hinterlegten Vektoren dahingehend auswerten, wo genau die Abzweigung liegt, in welche Richtung das Verlassen des bisherigen Weges erfolgen muss und eventuell noch weitere notwendigen Informationen.

Um sich an dem im post von Lübeck verwendeten Beispiel zu orientieren:
Es führt eine zweistreifige Straße höherer Ordnung von C nach D, von der eine Rechtsabbiegespur abzweigt. Die Rechtsabbiegespur beginnt als zusätzlicher Fahrstreifen rechts von der ursprünglichen Fahrbahn. Mit den vorhandenen Mitteln (Erhöhung der Anzahl der lanes in diese Fahrtrichtung) wird der routing software dieser Fakt mitgeteilt. Damit kann sie den Nutzer (Fahrer) informieren, dass er jetzt den Fahrstreifen wechseln sollte und sogar, dass er dafür (wenn das Stück Straße konsequent mit change:lanes gemappt ist) wieviel Platz bzw. Zeit er dafür hat.

Es konnte keiner für mich glaubhaft und logisch nachvollziehbar darlegen, welchen Nutzen ein turn:lanes hier hat. Es ist hier einfach Schmuck am Nachthemd. Vielleicht liest ja ein Programmierer von routing software mit und äußert sich mal dazu.

Turn:lanes hat für mich eine Berechtigung, wenn es um Aspekte der StVO geht. Der routing software (und damit dem Fahrer) wird hier eine Hilfe an die Hand gegeben, um zu sagen: Wenn du hier nach rechts (links) abbiegen möchtest (oder auch geradeaus), dann musst du zwingend diesen Fahrstreifen benutzen (ansonsten ist es nach der durchgehenden Linie ein Rechtsverstoß). Dieser Fall tritt auf, wenn eine oder mehrere Fahrspuren mit dem Vorschriftzeichen 297 versehen sind. Man kann das akustisch oder optisch dem Nutzer präsentieren.
Ich weiß, dass es da auch viele Fälle gibt, bei denen das mapping der Pfeile sich aus den anderen Gegebenheiten der Straßengeometrie ergibt. Aber das lässt sich wohl verschmerzen.
Mein Vorschlag ist, den entsprechenden Passus im deutschen Wiki daraufhin zu ändern. Turn:lanes nur da, wo sich die entsprechenden Pfeile auf der Fahrbahn befinden, vom ersten Pfeil der aufgemalt ist, bis zur Haltelinie (Zeichen 294). Für Verkehrsschilder hat sich ja schon ein anderes tagging etabliert.
Nur im deutschen Wiki deshalb, weil die Straßenverkehrsordnungen der 193? Länder dieser Erde einfach zu verschieden sind und man diese wohl kaum alle in eine software pressen kann. Jedes Land sollte das seinen entsprechenden Gesetzgebungen anpassen. Für routing software ist es zu kompliziert, auf alle diese Befindlichkeiten(Gesetze) der Länder einzugehen, dass kann man einfacher über die Datenbank lösen.
Und ja, es ist tagging für den Router. Das ist turn:lanes immer. Mir ist keine andere Anwendung bekannt, die sich sonst um diese tags kümmert.

Meiner Meinung nach gibt es hier keine andere Lösung. Wenn jemand eine Idee hat, immer her damit.

Das ist in dem Falle für die Routing-software eben nicht eindeutig, es könnte schlicht auch oben angesprochener Picknickstreifen oder aber eine Rettungsbucht oder sonstwas sein. Aus einer Veränderung der lanes kann (bzw. imho darf(!)) eine Software nicht zweifelsfrei ableiten, dass es eine Aus- oder Auffahrt ist.

Hast du dafür ein Beispiel zur Hand? Ich habe noch nie gesehen, dass sich aus einer Rettungsbucht, einem Nothalteplatz o.ä. eine Abbiegespur entwickelt. Dazwischen liegt mindestens eine Sperrfäche. Und zwar genau aus dem Grund, dass keiner so etwas mit der Abbiegespur verwechselt.

Edith: Außerdem sind Nothaltebuchten, Picknickstreifen oder ähnliches keine Fahrstreifen.

Also zum Beispiel bei diesem Straßen-Wirrwarr in Berlin, ist es mir schon sehr lieb, wenn mein Router mir anzeigt, ob ich nun auf der/den Geradeausspur/en bleiben soll, oder demnächst/jetzt auf die rechte oder linke Abbiegespur wechseln soll. Nur anhand von Erhöhung/Verringerung von Spuranzahl erscheint mir das Routen hier nicht möglich.

Ich kann es nach wie vor nicht nachvollziehen, wieso das an den Pfeilen festgemacht wird. In dem vorliegenden Beispiel ebenso wie bei allen Autobahnabfahrten wird die Abbiegespur von den Geradeausspuren eindeutig durch die unterbrochene breite Fahrbahnmarkierung (den sogennannten Breistrich) abgegrenzt. Normale Fahrspuren werden lediglich mit unterbrochenen oder durchgezogenen Schmalstrich voneinander abgegrenzt. Es gilt ja z.B. das Rechtsfahrgebot besonders für langsam fahrende Fahrzeuge. Wäre die Abbiegespur eine normale Fahrspur, müsste z.B. ein LKW-Fahrer auf diese Spur wechseln um dann an der Stelle, wo die Abbiegespur nach rechts wechggeht, wieder eine Spur nach links zu wechseln. Eben das ist aber so nicht vorgesehen und wäre auch gefährlich. Und dafür ist es sinnvoll den betreffenden lane in der Datenbank entsprechend zu kennzeichnen, auch wenn im Fall einer Schnellstraße oder Autobahn auf Richtungspfeile verzichtet wird.

Das stimmt so nicht ganz. Denn ob der neue Fahrstreifen links oder rechts der Fahrbahn beginnt, lässt sich aus dieser Information nicht schlussfolgern. Man kann also beispielsweise nicht wissen, ob man zum Rechtsabbiegen aus der rechten Spur eine Spur nach rechts wechseln oder einfach nur durchfahren muss. Das würde man erst vor Ort sehen. Um diese Information im Voraus zu haben, braucht es transit:lanes. Wenn man mal (ggf. durch zusätzliche Sensoren) so genaue Positionsdaten hätte, dass der Router weiß, auf welcher Spur das Fahrzeug unterwegs ist, wäre diese Information dann auch nutzbar, weil beispielsweise ein Spurwechsel dann nur angesagt werden muss, wenn tatsächlich eine Änderung der Fahrspur nötig ist.

Und theoretisch dürfte das zusammen mit change:lanes sogar ausreichen, um alle für einen Spurwechselassistenten nötigen Informationen zu haben. Die Angabe von lanes selbst wäre bei gleichzeitiger Angabe von transit:lanes redundant (und höchstens für simplere Auswertemöglichkeiten nötig) und dort wo transit:lanes nicht getaggt ist, wäre lanes=x eigentlich nur eine Abkürzung für transit_lanes=xcontinue*.

Natürlich ließen sich die Fahrspurvorgaben in diesem Fall auch aus den lanes rekonstruieren (mit der oben genannten Ausnahme, ob der zusätzliche Streifen rechts oder links beginnt). Nur ist lanes allein kein Schema, welches beispielsweise an mehrspurigen Kreuzungen die Abbiegespuren richtig zuordnen kann. Dafür braucht es dort turn:lanes (wobei auch das nicht sagen kann, auf welcher Fahrbahnseite zusätzliche Spuren beginnen). Ein Router müsste also für den gleichen Umstand zwei verschiedene Schema unterstützen - lanes und turn:lanes. Das ist immer sehr ungünstig, wenn es für einen Sachverhalt parallele Logiken gibt.

Das ist trotzdem möglich. Routing erfolgt in erste Linie anhand der Knoten, an den sich Fahrbahnen teilen. Und dann schlägt dir dein Router von, welche Fahrstreifen du in Richtung deines Fahrzieles benutzen kannst. Wo ist da das Problem?

Wenn eine Fahrspur rechts (oder links) einer schon vorhandenen beginnt und danach eine Fahrbahnteilung an einem Knoten erfolgt, ist die Sache doch eindeutig. Dann ist es eine Abbiegespur. Wenn der neue Fahrstreifen hinter dem Knoten weitergeht, ist es keine reine Abbiegespur. Möglichkeiten des Fahrstreifenwechsels werden über change:lane getagged. Was ist daran nicht klar?
Und dein LKW-Fahrer hat ja auch noch Augen im Kopf und ein Gehirn, das er benutzen kann. Und er schaut (hoffentlich) aus seinem Fahrzeug nach vorn. Routing software bietet lediglich eine Anleitung zum Handeln.

Wenn ihr euch so an die turn:lanes in diesem Zusammenhang festklammert, wie ist es dann möglich, dass ihr ohne Router überhaupt fahren könnt? Richtig, weil euch Informationen vorliegen, aus denen ihr ableiten könnt, welchen Fahrstreifen ihr wählen müsst, um zu eurem Ziel zu gelangen. Der routing software liegen diese Informationen aber vor, so wie ich das geschildert habe.

Protexenus, mit dieser Argumentation könnte man auf die lanes-Angaben komplett verzichten. Sieht man ja alles vor Ort.

Die Diskussion dreht sich im Kreis. Längst sind Beispiele für den Nutzen von turn:lanes genannt worden, dennoch wird weiterhin behauptet, es gebe keine, und dann das Argument angebracht, das sehe man doch vor Ort. (Auch auf dieses bin ich bereits eingegangen.)

Ich bleibe beim pragmatischen Tagging und bezeichne eine Spur nach ihrer Funktion statt nach aufgemalten Formen. Dass der Router mir schon 1 km vor der Kreuzung mitteilen kann, ob eine separate Abbiegespur vorliegt oder ob ich aus der rechten Geradeausspur rechts abzubiegen habe, also bevor ich die Spur sehe und bevor sie überhaupt beginnt, empfinde ich mindestens als Komfort.

Ich weiß umgekehrt auch nicht, was an turn:lanes-Einträgen trotz fehlender Pfeile schädlich sein soll. Abgesehen vom Speicherplatzverbrauch.

Ich frage nochmals etwas provokativ zurück, wieso wir Straßennamen taggen. Sieht man doch vor Ort, wie die heißen, und fürs Suchen und Adressrouting genügen die addr:street-Einträge an den Fahrzielen. Also: Warum Straßennamen an die ways setzen?

–ks

+1 Ich hätte geschrieben:

Gerade das Beispiel vom Berliner Dreieck Funkturm finde ich recht gut.

Bei den vielen Dingen die sonst gemappt werden, sind die paar Byte für die turn:lanes eine gut angelegte Sache.

Sven

Mal ein Versuch, die beiden von kreuzschnabel erwähnten und scheinbar unvereinbaren unterschiedlichen Herangehensweisen doch miteinander zu vereinen:

Grundsätzlich denke ich auch, dass ein Abbiegestreifen als solcher gekennzeichnet sein muss, um ein turn:lanes=* zu erhalten. Nun wurde ja aber bereits oben (und auch im wiki) erwähnt, dass eine solche Markierung nicht zwangsläufig ein auf der Fahrbahn aufgemalter Pfeil sein muss, sondern z.B. auch ein Schild sein kannn. Warum also nicht einfach den von Galbinus erwähnten sogenannten Breistrich als eben diese erforderliche Kennzeichnung begreifen?