Idee:
“lanes:forward=1 + lanes:backward=1” wird immer dann benutzt, wenn die beiden Fahrstreifen durch eine Mittellinie getrennt sind.
Begründung:
Die übliche Straße bei uns hat ja zwei Spuren, eine in jede Richtung, auch wenn zwei Autos nicht immer nebeneinander passen. Kartiert wird also lanes=2. Einbahnstraßen üblicherweise nur eine Spur, auch wenn es sich um eine ehemalige normale Straße handelt, also lanes=1.
Die Frage ist nun, wann soll man lanes:forward=* und lanes:backward=* verwenden, die Wiki sagt nur, wenn es eine unterschiedliche Anzahl ist. Könnte man nicht durch die grundsätzliche Verwendung der Richtungen eine weitere Größe in OSM bringen?
Scheinbar werden die lanes für die Navigation immer wichtiger, da könnten wir auch etwas genauer sein.
Wenn ich wegavision richtig verstehe, will er/sie auf diese Weise eine durchgehende Mittellinie reintaggen (also keine bauliche Trennung, daher keine separaten Ways, aber eine verkehrsrechtliche Trennung).
Also bei 3 Spuren ohne Richtungszuweisung einfach lanes=3, bei 2 Spuren in forward- und 1 Spur in backward-Richtung lanes:forward=2 und lanes:backward=1 taggen. Der Vorschlag zielt darauf ab, daß im zweiten Fall klar ist, dass die Spuren den Fahrtrichtungen fest zugeordnet sind.
Schlecht ist die Idee nicht. Dann besteht aber viel Nachholbedarf bei allen Straßen mit durchgehenden Mittellinien, die schon mit der Summe getaggt sind.
lanes:forward=1 + lanes:backward=1 bei jeder “normalen” straße ist schon vollständighalber richtig, aber nicht notwendig bzw. ist doch der defaultwert i.V.m. mit lanes=2 oder?. ich fange mit diesen tags erst bei lanes=3 und mehr an. bei durchgezoger linie gibt es das tag overtaking=no.
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!
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
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, …
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).