Es gibt insgesamt vier Tags für die Zahl der Spuren: lanes, :forward, :backward und :both_ways. Wobei lanes die Summe der anderen drei ist. Da lanes:both_ways eher die Ausnahme ist, sollte man immer davon ausgehen, das lanes:both_ways=0 wenn nichts anderes angegeben ist.
Bleiben noch die üblichen lanes, lanes:forward und lanes:backward. Hier reicht es zwei der drei anzugeben, da die dritte immer berechnet werden kann. Ist nur lanes angegeben, dann werden die lanes gleichmäßig für beide Richtungen verteilt (z.B. lanes=4 → zwei in jede Richtung)
Mehr Infos wie durchgezogene Linien ist nicht enthalten. Die gibt es mit overtaking=no (wenn Überholverbot) und mit change:lanes (wenn durchgezogene Linie). Bedenkt, dass eine durchgezogene Linie nicht bedeutet, dass nicht überholt werden darf!
Eine durchgezogene Linie wird durch change(:lanes)(:backward/forward)=* angezeigt.
… aber ohne die Linie zu überfahren - auch nur teilweise (Radstärke) - z.B. Radfahrer überholen mit seitlichen Abstand:
http://www.bussgeldrechner.org/fahrstreifenbegrenzung.html
Das Schild Überholverbot heißt in D ja “nur”: “Verbietet den Führern von Kraftfahrzeugen aller Art, mehrspurige Kraftfahrzeuge und Krafträder mit Beiwagen zu überholen.”
Ich denke das ist im Wiki und in den Köpfen noch nicht genügend herausgearbeitet.
Ich habe mir das so gedacht, dass man immer wenn eine Trennung der Spuren, also auch nur eine gestrichelte Linie vorhanden ist, dann könnte man das in OSM sichtbar machen, indem man beide Richtungsspuren angibt. bedeutet also, es gibt für jeder Richtung eine abgegrenzte Spur.
Fehlt diese Trennung, also wie auf den meisten residentals aber auch tertiär und unklassifiziert, dann wird nur lanes=2 geschrieben. Bedeutet also, man muss sich mit dem Gegenverkehr vor Ort einigen, wo man fahren kann.
Man könnte natürlich auch argumentieren, dass durch lanes:r+l=1 mitgeteilt wird, dass die Gegenspur nicht benutzt werden darf, man je Richtung also nur eine hat. Das wäre dann die durchgezogene Linie, die wird ja aber schon andersweitig beschrieben.
Also ich sehe hier durch die impliziten Standardannahmen auch keinen großen Bedarf. Klar, für die Navigation wird es immer wichtiger, spezifisch zu taggen, und das mache ich auch immer, wenn es nötig ist. Aber das “nötig” ist hier das Schlüsselwort. Ich stelle mir immer die Frage, ob einer Navigation (sei es Mensch oder Maschine) wirklich eine Information fehlt, wenn ich ein “Minimal-Tagging” verwende. Wenn nicht, ist alles gut, dann brauche ich auch keine zusätzlichen Tags. Diese würden nämlich im Sinne von
lediglich für mehr Bytes in der Datenbank sorgen.
Ein anderer Aspekt ist natürlich die Darstellung in den Karten. Es gibt den Grundsatz “Wir taggen nicht für den Renderer”. Das stimmt in meinen Augen allerdings nur so weit, dass man keine Eigenschaften “erfinden” oder “verbiegen” soll, nur, damit es besser aussieht. Wenn ich aber gerne die reale Anzahl von Fahrstreifen mit den richtigen Linien und vielleicht sogar Breiten sehen möchte (soweit es vom entsprechenden Renderer unterstützt wird), dann kann ich sicherlich die entsprechenden Tags vergeben, auch wenn diese nicht zwingend für eine Navigation erforderlich sind. Die Instrumente dafür wurden oben ja schon teils genannt.
Mein Grundsatz:
-lanes=* wird erfasst, wenn entsprechende Markierungen vorhanden sind.
-lanes=* sagt nichts über Straßenbreite oder die Fahrtrichtungsmöglichkeit aus.
-Für Breite gibt es die width=
-Für Fahrtrichtungsmöglichkeite gibt es oneway=*
Die Idee von wegavision muss nicht umgesetzt werden, weil die vorhandenen taggings ausreichen. Und bloß, weil Gegenverkehr möglich ist, hat eine Straße noch lande keine zwei Spuren.
Genau das versucht er doch damit deutlich zu machen. Bei vielen Straßen mit Gegenverkehr existiert keine optische Trennung der Fahrspuren. D.h., die voreingestellte Annahme “lanes=2” bedeutet nur, dass sich hier zwei Fahrzeuge begegnen können.
Es gibt Straßen mit einer optischen Trennung durch eine gestrichelte oder geschlossene Linie (sog. Mittelstrich). Zur Verdeutlichung, dass hier tatsächlich zwei “getrennte” Fahrspuren existieren möchte er lanes:forward=* und lanes:backward:* hinzufügen.
Der Renderer hat dann die Möglichkeit, an diesen Straßen eine Fahrspurtrennung anhand des sog. Mittelstrichs optisch zu untermalen. Bei Straßen ohne diese Trennung gibt es die Anzeige des Mittelstriches dann nicht.
Jedenfalls habe ich es so verstanden (ohne jetzt eine Wertung über eine Sinnhaftigkeit abzugeben).
Abgesehen davon, dass ein Mittelstrich auf den Straßen in den Karten optisch ganz nett aussieht, aber nur da, wo er auch wirklich existiert, sollte aber folgendes bedacht werden:
Die Breite der Straße mit Mittelstrich ist in der Regel (jedenfalls hier bei uns) größer als die ohne.
Eine Angabe der Breite mit width=* halte ich für notwendig aber nicht ausreichend, denn die Fahrspuren können unterschiedliche Breite haben. Müssten wir dann nicht auch einen Tag wie “width:lanes:forward”, einführen, und dies sogar “fahrspurengenau” wie
“lanes:forward=2” + “width:lanes:forward=3.5|2.4” ?
Die Angabe wird zu einer weiteren Zersplitterung von Straßenabschnitten führen, da es durchaus Straßen gibt, die immer nur in Teilstücken eine optische Kennzeichnung haben.
Es muss festgelegt werden, ob width dann einschl. Randstreifen/Bürgersteig angegeben werden muss, oder ob man bei Randstreifen sagt: width=, und width:lanes: bei Fahrspuren und ein widht:sidewalk=* immer zusätzlich angeben muss.
Das macht zumindest eine Menge Arbeit, aber was macht bei OSM keine Arbeit…
Thoschi
Dieses Tagging wird bereits verwendet.
Meines Wissens ist die Breite der Straße die Breite der Fahrstraße.
Jo, das deckt sich auch mit meinen Erfahrungen mit der StVO.
Wollte mal vor einiger Zeit dort herausfinden, was eigentlich einen “Bürgersteig” ausmacht, und dessen Definition in der StVO finden: nada. Die schreibt nur (sinngemäß): Die Straße beginnt und endet an den Bordsteinkanten, …
Gruss
walter
Gut zu wissen… das sollte man dann mal im Wiki dokumentieren (oder bin ich mal wieder blind?)
Moin,
damit wäre ich vorsichtig, denn
ich lese da einen anderen Sinn heraus:
Wie kann eine Straßenverkehrsordnung denn dann überhaupt Regeln und Verkehrszeichen definieren, die nicht den Bereich zwischen den Bordsteinen betreffen?
Fazit:
Die Fahrbahn beginnt und endet an den Bordsteinen (in der Regel, bei Seitenstreifen u. ä. Ausnahme).
Siehe auch
Grüße, Georg
Kurz gesagt: Man muss zwischen Straße und Fahrbahn (Teil davon) unterscheiden.
“lanes” (Fahrstreifen) bezieht sich mMn auf Fahrbahn.
Die Fahrbahn kann aber auch schon an der Fahrbahnbegrenzungslinie enden, deswegen heißt sie ja so …
Deswegen sind Radspuren auch nicht Teil der Fahrbahn im Gegensatz zu Schutzstreifen.
Und Seitenstreifen sind auch ohne gemalte Linie nicht Teil der Fahrbahn nach § 2.
Stellt man ein Gehwegschild neben die Fahrbahnbegrenzungslinie, dann ist rechts der Linie sogar ein Gehweg …
Man kann es sogar noch weiter treiben:
Ist ein Radstreifen zwischen zwei Normalfahrstreifen Teil der Fahrbahn oder nicht?
(Anm.: Ich verzichte auf eine juristisch fundierte Antwort 
)
Für solche Spitzfindigkeiten empfehle ich das verkehrsportal.de
Am besten mit einem Packen Bilder unterm Arm 
Es geht aber doch darum, festzulegen auf was sich der Tag “width=*” in OSM bezieht. Und dafür hilft das Straßengesetz nur wenig weiter. Ich lese daraus, grds. wird gesetzlich eine Straße in Fahrbahn, Gehweg und ggf. Seitenstreifen, Gräben unterteilt, das sind für uns aber doch nur Begriffsdefinitionen. Aber das Gesetz kann nicht vorgeben, wie der Tag “width” an dem Tag “highway” zu werten ist. Wird mit width die Breite der Straße einschl. der Entwässerungsgräben rechts und links genommen, wird nur die Breite des befestigten Bereichs genommen oder nur der für ein Fahrzeug befahrbare Teil (das wäre bei spurgetrennten Wegen wie Autobahnen sinnvoll, denn lt. Gesetz gehört der Mittelstreifen ja zur Straße).
Wambacher schlägt vor, das width nur für die Fahrbahn genutzt wird. Das bedeutet für den Bürgersteig und Radweg müssen andere Tags her:
width:sidewalk
width:footway
width:path
width:cycleway
Eben für alle, die mit highway=* zusätzlich an einem way vergeben werden.
In Nepal habe ich schon
width=4
width:carriage=5
width:shoulder=0.5
gesehen.
Wurde im Rahmen eines ILO-Projektes zusammen mit etlichen weiteren undokumentierten Tags vor Ort erfasst.
Wambachers Vorschlag halte ich jetzt schon für “best practice”.
Im Übrigen hat sich zum Angeben der Breite von Geh-/Radwegen als Attribut der “Straße”
sidewalk:width=*
cycleway:width=*
etabliert.