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.
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:
Ä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:
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.
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.
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.
Links und rechts bezieht sich in der StVO auf deine Fahrtrichtung. Es gibt keine Ausnahmen für nur einseitige Radwege, weder in der Benutzungspflicht (wenn blaues in meine Fahrtrichtung dann nicht auf der Straße), noch im Benutzungsrecht (nur rechts, es sei denn links steht ein Schild).
Es könnte rechts weiß auf blau und links schwarz auf weiß stehen oder umgekehrt, das brächte dann OSM-Mapper, die es genau nehmen wollen, zur Verzweiflung … Aber richtig, es ist dann “egal wohl, bloß nicht auf der ‘Autostraße’, die gehört 'richtigen” Verkehrsteilnehmern!!1" gemeint …
Beim Getrenntmappng reicht ein einfaches b=use_… an der Fahrbahn, um das auszudrücken.
Beim Nichtgetrenntmapping mit compulsory für die Nebenwegtags oder wenn man beim Getrenntmapping die B-Pflicht am Nebenweg mappen wollen würden täterä, käme man ins Schwimmen, weil der eine nicht b-pfl. ist und das zu Fehlschlüssen für die Fahrbahn führen könnte … Hmmm …
