Radverkehrsanlagen kartieren: Wann setzt man bicycle=designated?

§25 (1) “Wer zu Fuß geht, muss die Gehwege benutzen.”
Gehweg ist jede öffentliche Verkehrsfläche, die erkennbar dem Fußverkehr dienen soll.

Daraus lässt sich auch schließen, wenn die Verkehrsfläche erkennbar nur dem Radverkehr dienen soll, ist es kein Gehweg.

Dieses “erkennbar” ist nicht an Gebotsschildern festgemacht (siehe sonstige Radwege), was es den Verkehrsteilnehmer (und uns Mappern) nicht einfach macht und im Rechtsstreit wohl im Einzelfall durch Gerichte entschieden werden muss. Ich tendiere derzeit zur Rechtsauffassung von MitteloberrheinischerWaldameisenschreck.

Moin!

Hab jetzt mal mit dem ursprünglichen Verfasser des Proposals bicycle=use_sidepath gesprochen und gefragt, warum es nur für separat gemappte highways gilt. Hier ist seine Antwort:

Im Prinzip sagt er ja nur, dass kein Router mehr entlang der Straße routen würde. Erstens ist das nur der Fall, weil er die Information später explizit im Wiki hinzugefügt hat, zweitens erklärt das für mich nicht, warum das ursprünglich gar nicht Teil des Proposals war und drittens geht etwas wie cycleway:right:compulsory=yes/no eben nicht, weil es abhängig von Seite und Fahrtrichtung ist. Aber gut.

Für mich impliziert das 2 Dinge:

  1. alle mit cycleway=* erfassten Radwege sind verpflichtend oder nicht, da ein Router da nicht unterscheiden kann. Vermutlich verstehen alle Router sie momentan als benutzungspflichtig, ist jetzt aber natürlich nur geraten. Ausnahme könnte das bicycle=yes sein.
  2. will ich die Benutzungspflicht eines Radwegs entlang einer Straße erfassen, muss ich ihn derzeit separat erfassen.

Für PeeWee32 als Holländer ist das ja kein Problem, da dort fast alle Radwege als separate Wege erfasst wurden.

Mir ist nicht sicher ob Du verstanden hast dass Router bei nicht separat gemappten Radwegen immer ueber die Strasse routen…

bicycle=use_sidepath wurde als Ergaenzung zu bicycle=no erfunden, welches bis dato vorwiegend in NL verwendet wurde um Router dazu zu bringen Radfahrer nicht ueber die Strasse sondern den parallelen Radweg zu schicken.

Hier will ich auch nochmal einhaken.

Für Router ist es erstmal das Wichtigste zu erkennen, wer einen Weg (oder Straße) nutzen darf oder nicht. Wenn man das aus den realen OSM-Daten extrahieren möchte, ist das schon eine Aufgabe für sich, da sich die Information aus highway, sämtlichen access-Attributen und ggf. auch noch cycleway und sidewalk extrahieren muss und zudem lokale Default-Werte, diverse häufige Mapping-Fehler und -Eigenarten, berücksichtigen muss.
Ob man designated nun dafür verwenden sollte, Radwege zu bevorzugen, bleibt die Entscheidung des Programmierers. Es ist nicht gesagt das man auf als Radweg ausgeschilderten Wegen oder auf für den Radverkehr gedachten Flächen wirklich schneller, sicherer oder komfortabler vorankommt als auf anderen Wegen (in Holland mag das vielleicht besser funktionieren). International lässt sich das ganze vermutlich erst recht nicht übertragen.

Edit:Typo, Ergänzungen

Nur weil wir bisher (scheinbar?) ausschließlich Router haben, die sich so verhalten, heißt das aber nicht, dass das für immer so bleiben muss. Niemand hier kennt alle Router und auch die vorhandenen werden immer ausgefeilter. Nach dieser Logik wäre das grundsätzliche Erfassen von Radwegen mit cycleway=* derzeit überflüssig, weil Router ja sowieso über die Straße routen.

Wenn grundsätzlich niemand außer mir daran Interesse hat, benutzungspflichtige Radwege parallel zu Straßen von nicht benutzungspflichtigen unterscheiden zu können, dann erfasse ich sie einfach separat und gut. Halte ich sowieso für das sauberste.

gibt es eigentlich Router, die Fußgänger über highway=pedestrian routen, wenn diese als Tags einer Multipolygonrelation gesetzt sind? (über die Ränder routen, dass es mit Routing über Flächen Probleme gibt ist klar). Analog ggf. auch für andere highway=* Flächen die über MP-Relationen definiert sind.

Warum eigentlich nicht dem Vorschlag von PeeWee32 folgen und ein neues Tag “compulsory” etablieren. Damit lässt sich die Situation in Deutschland (benutzungspflichtig oder nicht) sauber abbilden und es werden nicht einfach nur andere Tags uminterpretiert.

insbesondere weil es einen Unterschied macht, ob Fahrräder grundsätzlich verboten sind oder ob es lediglich einen unter bestimmten Umständen (man will hin wo der Weg hinführt und er ist benutzbar und nicht z.B. unter Schneemassen begraben oder durch rutschiges Laub oder Müll unbenutzbar) benutzungspflichtigen, parallelen Weg gibt.

Weil die Benutzungspflicht davon abhängig ist, von welcher Richtung man kommt. Man bräuchte also Konstrukte wie cycleway:left:forward:compulsory=yes und das will vermutlich niemand erfassen müssen. Grundsätzlich wäre das aber eine Möglichkeit, ja. Dann müsste man nur noch definieren, was der “default” ist. *:compulsory=yes in Fahrtrichtung nehme ich an.

Bin mir nicht ganz sicher worauf sich dein Kommentar bezieht: Man soll nicht bicycle=no an die Straße schreiben sondern weiterhin bicycle=use_sidepath. Das hat doch mit der zusätzlichen Verwendung von compulsory am Radweg nichts zu tun.

@Nadjita
Wie auch bisher muss ich ggf. zwischen rechten und linken und zwischen vorwärts und in Gegenrichtung unterscheiden. Dazu habe ich auch jetzt schon right/left:forward/backward benötigt. Default ist eine gute Frage, vermutlich am Ende wieder Länderspezifisch.

Der Unterschied ist, dass Du jetzt beides auf einmal brauchst. Es ergebe sich also 4 Möglichkeiten. Im Prinzip kann man ja mal versuchen, wie viel Aufwand das konkret ist, und wie der Standardwert in Deutschland aussehen müsste. Da es früher fast ausschließlich benutzungspflichtige Radwege gab:


cycleway:right:forward:compulsive=yes
cycleway:right:backward:compulsive=no
cycleway:left:forward:compulsive=no
cycleway:left:backward:compulsive=yes

nehme ich an. Und in welcher Reihenfolge kommt forward/backward vs left/right? Ich finde das zum Haareraufen :roll_eyes:

Äh nein:
Wenn ich nur vorwärts fahren darf, dann brauche ich für Rückwärts kein compulsory angeben.
Wenn in beide Richtungen das gleiche gilt, dann brauche ich nicht forward und backward angeben.
Und wenn für rechts und links das gleiche gilt, dann auch kein left and right (und auch kein both)

Für dein extremes Beispiel mit zwei benutzungspflichtigen Radwegen die in die Gegenrichtung nicht benutzungspflicht frei sind könnte ich auch kurz schreiben:

cycleway:(both:)forward:compulsory=yes
cycleway:(both:)backward:compulsory=no

Mit einem Standardwert könnte dann auch noch eine der beiden Zeilen entfallen.

Das forward und backward bezieht sich auf die Richtung relativ zur Ausrichtung des Weges, nicht der Fahrtrichtung. cycleway:(both:)forward:compulsory=yes würde also bedeuten links und rechts der Straße ist ein in Wegesrichtung benutzungspflichtiger Radweg. Mein Beispiel sagt also nur: In Fahrtrichtung ist der rechtsseitige Radweg normalerweise benutzungspflichtig, der linksseitige hingegen nicht.

Hmm, das ist natürlich richtig. Das macht die Verwendung aber jetzt auch schon arg kompliziert. mal schauen wo das so vorkommt.

Und kommt dieses Beispiel wirklich oft vor: Und es wäre ja auch mit bicycle=yes/designated nicht wirklich einfacher zu modellieren.

Taginfo sagt:

cycleway:right:bicycle:forward: 34x
cycleway:right:bicycle:backward: 33x
cycleway:left:bicycle:backward: 13x
cycleway:left:bicycle:forward 9x

Wurde wohl nicht wirklich intensiv genutzt.

Es stellt sich die Frage, wann man komplizierte Konstrukte überhaupt braucht …
Per Default sind Radwege Einrichtungsradwege. Wenn das mit oneway korrekt getaggt ist und beide Seiten benutzungspflichtig sind, braucht man weder left/right, noch forward/backward, ein einfaches richtungs- und seitenunabhängiges tag reicht dann für die B-Pflicht.
Dito beim zweiten Standardfall, dem einseitigen Zweirichtungsradweg, wenn dessen Seite und oneway=no korrekt getaggt ist.
Auch bei beidseitigen Zweirichtungradwegen, wenn sich die B-Pflicht auf beiden Seiten/in beide Richtungen nicht unterscheidet. Nur Puristen mögen dann monieren, dass das “beidseitig” evtl. nicht klar würde.

Komplexer wird es nur, wenn sich die Benutzungspficht auf beiden Seiten und/oder in beide Richtungen unterscheidet.
Bei Einrichtungsradwegen beidseitig oder Zweirichtungradwegen einseitig reicht dann immer noch forward/backward

Nur bei Zweirichtungsradwegen beidseitig, wenn bspw. auf der einen Seite eine B-Pflicht beschildert ist, auf der anderen Seite nicht, müsste man notfalls xward UND l/r gleichzeitig zum Einsatz bringen.
Das gülte aber auch im Falle des Getrenntmappings, wo dann das b=use/optional_sidepath nicht mehr eindeutig wäre, wobei sich da das Problem ergäbe, dass bicycle:left=optional_sidepath eine Fahrbahnoption suggerieren würde, die mit bicycle:right=use_sidepath unterminiert würde, weil wenn man nicht links führe, müsste man rechts fahren, das führt dann in den Bereich rechtlich nicht koscherer Beschilderung … Unkoschees passt eh nicht in unser Datenmodell, also würde ich in dem Falle nur bicycle=use_sidepath mappen, der Router kann sich dank oneway=no’s die Seite aussuchen und das wäre auch die Brücke, mit der man f/b/l/r-Monster im anderen Mappingfall vermeiden könnte: Nur das relevante taggen, dass irgendwo eine B-Pflicht besteht, in solchen Fällen vmtl. auch in beide Richtungen, also alle Richtungs- und Seitenangaben weglassen …

Ich finde das Mischen von left/right und forward/backward auch extrem verwirrend. Ich würde mir da schon etwas Besseres wünschen.
Aber ich denke, wir schweifen jetzt sehr ab. Ursprünglich ging es ja nur um designated ja/nein und das wurde eigentlich hinreichend geklärt.

Auch außerorts ? :roll_eyes:

Und genau dazu gibt es bicycle:forward=use_sidepath und vice versa. Für separat erfasste Radwege ist es eindeutig geklärt.

Da gibt sich die StVO mal unerwartet klar: Linke Radwege ohne die Zeichen 237, 240 oder 241 dürfen nur benutzt werden, wenn dies durch das allein stehende Zusatzzeichen „Radverkehr frei “angezeigt ist.

Ergänzung:
Es gibt keinerlei Hinweise das innerorts und außerorts hier andere Regeln gelten. Und wer nun sagt, da geht es nur um “sonstige Radwege” - dann müsste dieser Satz auch innerorts gelten - was allen bewusst sein dürfte, dass dem nicht so ist.