Das es sich in dem Foto um eine Abbiegespur handelt und nicht um eine normale Fahrspur, kann man an der Linie erkennen, die die Abbiegespur von der anderen Spur trennt.
Die allmächtige DB, die wir verehren, möchte nicht wissen, was es nicht ist, sondern was es ist. Da ist eine Abbiegespur on the ground und deswegen mappen wir sie. Wer das nicht, falsch oder fehlerhaft auswertet ist nicht das Problem. Eine Abbiegespur ist eine Abbiegespur und ein Hundekotbeutelspender ist ein Hundekotbeutelspender.
Derlei Sarkasmus wäre mir auch gern eingefallen.
Ich bin immer wieder verblüfft über die bestechende Logik der Argumentation einiger hier im Forum.
Wenn es um Höchstgeschwindigkeit geht, wird die StVO als Argument herangezogen, wenn ich mit der StVO argumentiere, wird das lächerlich gemacht.
Wenn eine Rechtsabbiegespur
als solche klar erkennbar ist (on the ground), warum muss da noch extra ein turn:lanes 'rangeschrieben werden? Das wird bei normalen Straßenkurven doch auch nicht gemacht.
Wenn man damit eine Hilfe für den Autofahrer über die routing software erreichen möchte, kann diese auch jetzt schon ein notwendiges Abbiegen erkennen.
Für mich ist turn:lanes ein klar ein die StVO unterstützendes “tag”, das dem Autofahrer sagt, wenn du das (rechts abbiegen) möchtest, darfst du dazu diese(n) Fahrstreifen benutzen. Wenn das egal ist, braucht er diese Information auch nicht.
Gegenfrage: Wenn der Straßenname als solcher klar erkennbar ist (on the ground), warum muss da noch extra ein name ’rangeschrieben werden?
Der Vergleich mag für dich erstmal absurd klingen, ich finde ihn passend. Generell ist Karteninformation doch dazu da, Geoinformationen zu liefern, die dem Anwender zu einem bestimmten Moment eben noch nicht bekannt, aber für die Wegführung bereits wichtig sind.
Konkret in diesem Beispiel heißt das: Ein Fahrer, der an den Beginn dieses Abbiegestreifens gelangt, sieht zwar, dass da ein Abbiegestreifen anfängt, kann aber in diesem Moment noch nicht absehen, ob dieser Abbiegestreifen der richtige für sein demnächst fälliges Abbiegevorhaben ist oder noch nicht. Der Streifen könnte ja vorher schon abbiegen oder wieder aufhören.
Die Software kann ihm jetzt sagen „nimm diesen Abbiegestreifen“, wenn wir ihr per Tagging verraten, dass er sich bis zu der Kreuzung, an der abzubiegen ist, fortsetzt. Was der Fahrer in dem Moment, wie gesagt, noch nicht unbedingt weiß.
Auch wenn dieser konkrete Fall übersichtlich aussieht: Tatsächlich kann ja eine auf dem Luftbild nicht sichtbare Kuppe dazwischen sein.
–ks
Kreuzschnabel, so sehe ich das auch. In dem vorliegenden Beispiel mag die Situation zwar übersichtlich sein. Anders sieht es aber in Ballungszentren und Städten aus, wo eine Abbiegespur auf die nächste folgt.
Übrigens sind auf Autobahnen die Abfahrten nie mit Richtungspfeilen markiert. Trotzdem sind es keine normalen Fahrspuren sondern eindeutig Abbiegespuren. Das wird deutlich ebenso wie in dem Beispielfoto in dieser Diskussion an der Fahrbahnmarkierung. Zu den normalen Fahrspuren sind solche Abbiegespuren mit einer breiten unterbrochenenen Linie abgegegrenzt. Normale Fahrspuren sind mit einer dünnen unterbrochenen Linie abgegrenzt. Dies macht deutlich, dass diese Spuren als Verzögerungs- oder Beschleunigungsstreifen im Zuge eines Abbiegevorgangs genutzt werden sollen und nicht zum geradeausfahren.
Noch was dazu. Wir kommen wahrscheinlich deshalb auf keinen Nenner, weil der eine sagt: „turn:lanes kodiert Fahrstreifenmarkierungen“ und der andere: „turn:lanes kodiert Fahrstreifenfunktionen“. Das sind zwei grundsätzlich unterschiedliche Herangehensweisen – eine dogmatisch, eine pragmatisch. (Ähnlich gelagert ist die Frage, ob maxspeed nun ein warum auch immer geltendes Tempolimit oder ein rundes Blechding mit rotem Rand und einer Zahl drin abbildet. Daher mein Vergleich oben.)
Schaut euch mal https://www.openstreetmap.org/way/322930907 an. Wer von Süden kommt und an der nächsten großen Kreuzung nach links auf den Gustav-Stresemann-Ring will, wurde bis vor einem halben Jahr vom Osmand-Spurassistenten – wohl in froher Erwartung der Linksabbiegung – auf die linke der drei Spuren geschickt. Was leider doof ist, weil die linke dann in eine Unterführung führt, die die Kreuzung geradeaus unterquert; um an der Kreuzung links abbiegen zu können, muss man deshalb eine der beiden rechten Spuren nehmen.
Da waren bereits turnlanes:turns-Relationen eingebaut (die sind nicht von mir), die das einklich darstellen sollten. Wurden aber von keinem der mir vorliegenden Navis ausgewertet. Oder so, dass erst 20 Meter vor der Trennung Bescheid gesagt wurde, wenn es für einen Fahrstreifenwechsel zu spät ist.
Deshalb habe ich da mal turn:lanes drangesetzt mit slight_left und slight_right, um die Trennung zu verdeutlichen. Und, o Wunder, seitdem leitet Osmand einen so perfekt über die rechten zwei Spuren da durch, dass kein Ortsfremder sich mehr verfranzen muss.
War das Tagging für den Router? Ja, wenn man der dogmatischen Denke folgt, denn da stehen keine Pfeile auf den Fahrstreifen. Nein, wenn man der pragmatischen Denke folgt, denn ich habe damit die vorher offenbar unklare Funktion dieser drei Streifen erfolgreich abgebildet, der Router weiß jetzt, welche der drei Spuren wohin führt. Er berücksichtigt das turn:lanes also nicht nur als Streifenkennzeichnung für die Ausgabe, sondern auch als Streifenfunktion für die Wegführung.
Deshalb bin ich so für die pragmatische Sichtweise 
–ks
Moin,
nur zum Verständnis:
Du bist also der Meinung, dass es egal ist, welchen der beiden Fahrstreifen in Jans Beispiel der Autofahrer zum rechts abbiegen (ausfahren) benutzt?
Das gleiche gilt dann ja übrigens auch für das geradeaus fahren …
Diese Frage stellt sich in dem Beispiel überhaupt nicht. Ich gehe mal davon aus, dass der Abzweig richtig gemappt ist, d.h. es gibt eine zweistreifige Straße, von der eine einstreifige Fahrbahn nach rechts abzweigt.
Die routing software informiert den Fahrer in Intervallen entsprechend der Entfernung, dass er auf der errechneten Route nach rechts abbiegen muss. Wenn die zusätzliche Abbiegespur ihre volle Breite erreicht hat, sollte sie als dritte Spur gemappt sein. Wenn das Auto diese Stelle erreicht hat, gibt die routing software die Anweisung: “Jetzt auf den rechten Abbiege-Fahrstreifen wechseln!“
Damit ist alles für den Fahrer gesagt. Die dafür notwendigen Informationen sind in diesem Fall in der DB enthalten. Irgendwelche turn:lanes tags sind dafür nicht notwendig.
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?