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.
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.
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.