Mal ne Frage zu lanes

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 :wink: )

Für solche Spitzfindigkeiten empfehle ich das verkehrsportal.de
Am besten mit einem Packen Bilder unterm Arm :wink:

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.

Ich halte es mit Hubert87: Das etablierte sidewalk(:left|:right):width für die Breite der Bürgersteige. Es ist üblich, zuerst das Objekt und dann die Eigenschaft zu nennen, z.B. gibt es roof:height aber nicht height:roof.

width=* vermeide ich lieber, sobald nicht mehr ganz klar ist welche Breite gemeint ist (Fahrbahn, mit Radstreifen, mit Parkstreifen, mit Bürgersteig etc.). Dann kommt width:lanes zum Einsatz, was ja ohnehin mehr Informationen enthält.

Mach OSM-Definition sollte width an sich die Gesamtbreite des Objekts angeben, also inklusive aller zusätzlich getaggten Nebenobjekte (Wege und Parkstreifen). Die StVO interessiert in diesem Zusammenhang nicht, da es sich um ein Tag handelt das an beliebigen Objekten vorhanden sein kann und selbstverständlich auch weltweit eigesetzt wird.

Nichts gegen einzuwenden, habe die Tagkombination im Wiki halt nicht gefunden.

Moin,

ehrlich gesagt grinse ich mir Einen, wie hier der Zusammenhang zu Walters sinngemäß ‘fehlerhafter’ Behauptung und Thoschis darauf beruhendem Umdefinitionswunsch von width beim highway zerrissen wird. :wink:

Aber solange wir den gleichen Konsens haben:

  • width bezieht sich auf das OSM-Objekt
  • und da nicht klar ist, was genau das Objekt highway nun darstellt / darstellen soll, ist eben auch width unklar
  • width jetzt auf die Fahrbahn zu definieren ist eben eine Umdefinition des früheren Verständnis
    solls mir egal sein.

Eine bestehende Definition in einem laufenden Prozess (*), von dem noch nicht einmal klar ist, ob er je abgeschlossen wird, zu ändern, ist selten sinnvoll.
Eine klare Definition bringt zwar unzweifelhaft Vorteile für die Zukunft - aber eine Umdefinition verfälscht nach Murphy alle bereits vorhandenen Daten.

Vorschlag:
Nehmt für den Straßenteil Fahrbahn wie für die anderen Straßenteile lieber einen eindeutigen tag (vielleicht carriageway:width) und lasst ihn von Muttersprachlern absegnen.

Grüße, Georg

(*) highway-tags oder getrennt mappen

Mein Ziel ist keine Umdefinition sondern eine eindeutige Klarstellung und Beschreibung. Wenn bisher niemandem wirklich klar ist, wie width genau anzuwenden ist, dann sind die Daten jetzt schon chaotisch. Folglich sollte man Eindeutigkeit herstellen (und beschreiben). Die Alternative ist wie bisher, jeder mappt so, wie er es verstanden hat.
Das bei einer Klarstellung bereits gemappte Daten dadurch “fehlerhaft” sein /werden, versteht sich von selbst unter der Prämisse, dass der gleiche Tag schon jetzt mit unterschiedlicher Bedeutung getaggt ist.

Dein implizierter Vorschlag, alles so zu lassen wie es ist, ist somit eine Festschreibung des Chaos und die Tatsache dass diese Daten unauswertbar und damit überflüssig sind.
Dein Vorschlag einen neuen Tag zu verwenden beseitigt das Chaos und die Verwirrung beim jetztigen immer noch nicht, sondern schafft im Zweifel reduntante Daten.