Cycleway:right:width oder width:lanes:forward?

Mir ist beim Radeln eine Stelle aufgefallen, wo es bei Kfz-Verkehr schwer bis gefährlich ist dort Rad zu fahren, weil der Schutzstreifen so eng ist und Fahrzeuge über den Schutzstreifen fahren (was “bei Bedarf” erlaubt ist) und vor der Ampel auch darauf halten (was wohl leider auch erlaubt ist).

Nun wollte ich das eintragen und habe gesehen es ist schon erfasst. Als

cycleway:both=lane
cycleway:both:lane=advisory
bicycle:lanes:backward=|designated
bicycle:lanes:forward=|designated
lanes=2 (da werden nämlich Radspuren nicht mitgezählt)
width:lanes:backward=|1.2
width:lanes:forward=|1.2

Ein Erfassen der Breite einzelner Spuren mit width:lanes ist nicht dokumentiert.
(allenfalls am Rande im Englischen Wiki: “width:lanes:start/end can be used to mark that a lane gradually gets narrower.”)

Dokumentiert ist allerdings cycleway:right/left:width (wenn auch mit der Anmerkung, dass das zurzeit wohl kein Router auswertet)

Fragen:

  1. Ist überhaupt eindeutig, ob bei width:lanes Radspuren mitgezählt werden?
  2. Meiner Meinung nach ist cycleway:right:width deutlich besser auswertbar. Aber gibt es (bisher) eine praktische Relevanz, wenn es scheinbar leider bisher so oder so nicht ausgewertet wird?
  3. Gibt es eine Alternative aktuelle Router auf diese Gefahr / Einschränkung hinzuweisen?

Mapillary (hier stehen gerade alle Autofahrer günstig)
Mapillary (Begegnungsverkehr ein paar Meter vorher)
Mapillary (Öfter beobachtetes Fahrverhalten)

Zunächst mal folgendes: Ich würde die Breite des Schutzstreifens nicht erfassen, weil sie faktisch nichts zur Sache tut. Warum? Der Radfahrer muss sowieso rechts fahren, da macht es keinen Unterschied, ob der Schutzstreifen 1m oder 2,5m breit ist. Die geforderten 1,5m Mindestabstand zum Autofahrer ist ja unabhängig davon, wie breit der Schutzstreifen ist. Das einzige, was helfen würde, wäre die Straße komplett zu meiden.

Wenn Du es trotzdem erfassen willst, halte ich :lanes tatsächlich für das „korrektere“ Mittel, es steht auch „In principle every tag used to describe properties of a road can be extended by the :lanes suffix when its value depends on the lane“. Prinzipiell kann man also jedes Attribut in:lanes packen. Allerdings wäre das, wenn ich das Wiki hier richtig verstehe, in Deinem Fall sehr kompliziert, weil nicht so ganz definiert ist, wie sich das Lanes-Tagging bei nicht-Einbahnstraßen verhält, weswegen man künstlich welche über :forward und :backward erzeugt:

bicycle:backward:lanes=no|designated
bicycle:forward:lanes=no|designated
cycleway:both=lane
cycleway:both:lane=advisory
cycleway:backward:lanes=no|lane
cycleway:forward:lanes=no|lane
lanes=2
lanes:backward=1
lanes:forward=1
vehicle:backward:lanes=yes|no
vehicle:forward:lanes=yes|no
width:lanes:backward=|1.2
width:lanes:forward=|1.2

Mag sein, dass das sogar immer noch falsch ist, aber klar ist: Das ist unsinnig kompliziert für das, was Du ausdrücken willst. Wie das ganze :lanes-Tagging insgesamt bei leider vielen Fällen :wink:

Also konkret zu Deinen Fragen:

Ja, Du musst sie allerdings über cycleway:lanes=* definieren. Nur bei lanes=* werden sie nicht mitgezählt.

Das wäre besser auswertbar für Router, ja. Ich vermute auch, dass abseits von turn:lanes die Lanes momentan einfach viel zu kompliziert sind, um ausgewertet zu werden, aber ich hab den Quälcode noch nicht studiert. In Deinem konkreten Fall könnte zumindest für einen Fahrradrouter ein cycleway:both:width=1.2 wesentlich vorteilhafter sein als :lanes. Ich wüsste allerdings nicht, was ein Router mit der Breite eines Schutzstreifens anfangen sollte. Soll er vermeiden, auf der Fahrbahn zu fahren? Warum ich das für einen Trugschluss halte, habe ich bereits ganz zu anfangs geschrieben. Bei einem physisch getrennten Weg wäre das etwas anderes, weil manche Fahrräder dann dort unter Umständen gar nicht fahren können, weil sie zu breit sind. Auf der Fahrbahn gibt es dieses Problem allerdings nicht.

Du kannst mit class:bicycle arbeiten, um grundsätzlich Strecken unattraktiv zu machen. Manchmal ist das tatsächlich die einzig sinnvolle Lösung. Und eben auch eine der großen Stärken von OSM: Ein(e) Ortskundige(r) rät von der Benutzung einer objektiv guten Straße ab, weil sie/er weiß, dass sie für Fahrradfahrende schlecht/riskant ist. Das kann man sogar zeitlich steuern über :conditional, wenn man nur den Berufsverkehr ausnehmen will.

Ich hoffe, ich habe nicht noch weiter verwirrt. Und nur zur Klarstellung: nur weil ich die Breite eines Schutzstreifens für uninteressant halte, heißt das nicht, dass Andere das genauso sehen. Und ich wäre mir auch nicht sicher, ob das noch als lanes=2 zählt, weil die Markierung entweder entfernt wurde, oder zu stark abgefahren ist. In diesem Fall würde ich das mit dem Lanes-Tagging besser ganz vergessen.

Mmh, der fehlende Mittelstreifen macht es um einiges komplizierter und birgt die Gefahr vom Thema abzuschweifen. Ist hier lanes=2 angebracht und was setzte ich für lane_markings=*

Meine folgenden Worte vernachlässigen den fehlenden Mittelstreifen:

Halte ich soweit für komplett richtig und ausreichend. @mueschel’s Visualisierung, OSM Lane Visualizer, stellt das auch richtig dar.

Wie schon erwähnt ist das :lanes-Tagging mit fast allen Schlüsseln anwendbar. Also access:lanes, maxspeed:lanes, surface:lanes, smoothness:lanes, … und eben auch width:lanes. Ist so auch in der Tabelle aufgelistet

Von den Suffixen :start und :end würde ich abraten. (Wird das überhaupt von Editor-Software beim Teilen der Linie bzw. drehen der Richtung unterstützt?). Ist aber ein anderes Thema.

Ja, :lanes beinhaltet alle “Spuren”.
Ist mal wieder die Frage, wie viele gleichbedeutende bzw. überlappenden Tagging-Schemata brauchen wir. width und width:lanes oder auch surface und surface:lanes deckt die gesamte Straße (von Bordstein zu Bordstein) ab während cycleway:* sich ausschließlich mit Fahrradinfrastruktur befasst. Ich finde den allgemeineren Ansatz besser.

Doch es ist definiert, eben mit :forward und :backward bei Straßen mit jeweils Spuren in Richtungen. So kompliziert ist es auch wieder nicht. :right und :left wäre noch verwirrender und zudem abhängig von Links- bzw Rechtsverkehr.

Bei einem Schutzstreifen ist aber der Wert no sowohl bei bicycle:lanes als auch vehicle:lanes falsch. Auf letzteres kann mMn. hier ganz verzichtet werden.

MMn ist das komplizierteste die fehlende Unterstützung in der Editor-Software. Mit anständiger Visualisierung, z.B. Styles/Lane_and_Road_Attributes – JOSM, sollte es nachvollziehbar sein und es kann ja auch lokal, offline auf dem eigenen Rechner, mit den Tags rumgespielt und ausprobiert werden.

Da bin ich dann überfragt, ob es das überhaupt braucht. Eigentlich nur bei komplizierten Fällen mit der Fahrradspur zwischen allgemeinen Spuren und auch da sollten die allgemeinen cycleway=* zusammen mit bicycle:lanes schon ausreichen.

Vielen Dank. Ja ich denke die Mittellinie würde absichtlich entfernt und das lanes tagging müsste ggf angepasst werden.
Ich werde mir den lane Visualisierer mal anschauen.

Danke für den Hinweis zu class:bicycle, das kannte ich noch nicht. Weißt du welche router das auswerten?

Bezüglich Breite von Schutzstreifen ist ein schmaler wohl eher so etwas wie ein “Möchtegern-Schutzstreifen”, der in der Praxis nicht so viel Schutz bietet. Ich gehe davon aus, dass Router Schutzstreifen vor keiner Markierung bevorzugen. Dem folgend könnten Router ggf Straßen mit schmalem Schutzstreifen abwerten.

Siehe:

2 Likes