Ich sage nein! Warum?
Es ist unsaubere Modellierung, denn es vermischt zwei Dinge:
a) (access) dass man auf einer Straße Radfahren darf und
b) dass es eine separat erfasste Radinfrastruktur gibt.
Es gibt dafür eine saubere alternative Lösung
a) bicycle=yes (i.d.R. nicht notwendig, aber zur Klarstellung erlaubt) dafür, dass man auf der Fahrbahn fahren darf
b) cycleway=separate für den Hinweis auf die separat erfasste Infrastruktur
Router benötigen diese Information außerdem nicht, sie können Radwege auch so bevorzugen.
d.h.
kein Radweg → cycleway=no
nicht benutzungsflichtig → cycleway=separate (nur Verweis auf den separaten Weg)
benutzungspflichtig → cycleway=separate + bicycle=use_sidepath (um die Straße zu sperren)
cycleway=separate ist mittlerweile gängige Praxis (75 000 x)
bicycle=optional_sidepath kennt bisher nur 3300 Verwendungen
Wir benötigen bicycle=optional_sidepath
Wir benötigen kein bicycle=optional_sidepath
0voters
Warum ist bicycle=use_sidepath hingegen keine unsaubere Modellierung?
Weil es tatsächlich eine andere (weichere) Einschränkung als bicycle=no ist.
Falls der benutzungspflichtige Radweg nicht nutzbar ist oder das Fahrziel über ihn nicht erreichbar ist, kann z.B. trotzdem die Fahrbahn verwendet werden. Leider wird es von vielen Router noch als hartes no implementiert.
Welche negativen Folgen hat das taggen von bicycle=optional_sidepath?
Ich sehe einen (potenziell großen/wichtigen) Vorteil: Es zeigt, dass ein anderer Wert nicht fehlt.
Ich werde kein bicycle=yes an alle Straßen taggen, da das impliziert ist und unnötig.
An allen Straßen wo ein Radweg daneben ist und diese notwendigerweise mit cycleway:<seite>=separate auf dessen parallel verlaufende Existenz verweisen, genauso nicht (obwohl es sicherlich keinen Unterschied macht), mit derselben Begründung über die Redundanz.
bicycle=optional_sidepath hingegen beschreibt, dass der Radweg daneben tatsächlich parallel und zum selben Ziel verläuft. Außerdem beschreibt das weiterhin, dass kein anderer Wert dort wie bicycle=no oder bicycle=use_sidepath, oder die Existenz irgendeines bicycle-tags dort fehlt.
Für die Datenprozessierung und Analyse der Datenqualität – vor allem Vollständigkeit – sind alle Tagging-Definition, die keine Unterscheidung erlauben zwischen “Tag ist nicht da und das ist Absicht und soll etwas aussagen” und “Tag ist nicht da, weil er bisher noch nicht getaggt wurde” ein großes Problem. Apps wie StreetComplete und andere Projekte, die darauf hinarbeiten die Datenqualität zu standardisieren und erhöhen, brauchen explizite values.
Das streitet auch keiner ab, aber optional_sidepath hat mit “access” nichts zu tun. Ich habe nichts dagegen, dass man Benutzungspflicht am Radweg taggt, mit eigenen Tags wie bicycle:compulsory=yes/no oder meinetwegen auch an der Fahrbahn mit einem entsprechenden Tag (z.B. cycleway:compulsory=yes/no). Aber eben nicht mit einem Access-Tag, denn es hat dort die exakt selbe Bedeutung wie yes: dort darfst Du fahren.
Wenn man die Vollständigkeit der Daten feststellen möchte, dann lässt sich das durch setzen von bicycle=yes und cycleway=separate ebenso lösen. Dafür brauch es kein optional_sidepath.
cycleway=
bicycle=
Bedeutung
no
no
auf/entlang der Straße darf man gar nicht radfahren
no
yes
kein Radweg man darf auf der Straße fahren
separate
yes
es gibt einen separat erfassten nicht-benutzungspflichtigen Radweg (das entspricht genau bicycle=optional_sidepath)
separate
no
Man darf auf der Straße zu keiner Zeit fahren, ein separat erfasster Radweg ist aber vorhanden
separate
use_sidepath
es gibt einen separat erfassten benutzungspflichtigen Radweg
no
use_sidepath
Fehler
Vorsicht!
track/lane
no/use_sidepath
Fehler: Für Router ist die gesamte Kante (der way) inklusive Radwege gesperrt, die schauen nicht auf cycleway:bicycle!
OT: Und mal ehrlich, dass mit der nicht überprüfbaren Vollständigkeit ist ein ganz grundlegendes Problem von Karten. Alle Objekte die noch nicht eingezeichnet sind, kann man auch nicht auf Vollständigkeit überprüfen. Oder wollt ihr demnächst überall ranschreiben dass dort keine Haus / Keine Straße ist?
Über die Richtigkeit und Aktualität sagt das übrigens auch nichts aus.
Es ist genau das gleiche Ja, nicht mehr und nicht weniger! Ich darf da fahren und der Router wird mir den optimalen Weg suchen egal ob auf der Straße oder IRGENDWO anders lang.
Was für Tags soll man denn (dann) setzen wenn der Fahrradweg auf der Straße gemappt ist?
Also mit cycleway=track. Wie unterscheiden zwischen “der Fahrradweg an dieser Straße ist benutzungspflichtig” und “der Fahrradweg an dieser STraße ist nicht benutzungspflichtig”?
Soweit ich weiß sagt bicycle=*_sidepath nichts darüber aus ob der Fahrradweg als separater Weg erfasst ist oder als Tag an der Straße klebt.
Zumindest würde es keinen Sinn machen wenn er dies aussagen würde. Denn dann könnte man den Unterschied zwischen benutzungspflichtig und nicht benutzungspflichtig ja garnicht taggen wenn der Fahrradweg als tag an der Straße gemappt ist.
Man kann derzeit nicht taggen ob ein Weg benutzungspfichtig ist, egal ob separat oder an der Linie.
Dazu bräuchte es ein weiteres Tag womit man die Benutzungspflicht erfasst. (Edit: oder indirekt über traffic_sign)
Das ist auch schon Thema einer anderen Diskussion.
Man kann lediglich erfassen ob bei separat erfassten Radwegen die Fahrbahn der Straße nicht befahren werden darf.
bicycle=*_sidepath darf nur an Straßen mit separat erfassten Radwegen benutzt werden.
Selbstverständlich kann man das! bicycle=use_sidepath ist genau dafür da. Und gehört an den Straßen-way, da es sich effektiv um ein Fahrbahn-Benutzungsverbot handelt.
Das ist aber explizit nur die separate Radwege! Bei cycleway=track müsste man das aus den hoffentlich erfassten Schildern ableiten, aber die sind ja eher für Mapper als für Router.
Ja? Ist das so? @westnordost behauptet das Gegenteil.
Im wiki steht zwar seit 2015 (leider ohne Änderungskommentar):
Please do not use bicycle=use_sidepath in combination with cycleway=track on the main highway, if there is no separate cycleway drawn on the map. This is confusing for routing engines because bicycle=use_sidepath indicates not to route on the main highway (use the separate cycleway) and this conflicts with the tag cycleway=track, which indicates that bicycles are allowed to route on (bike lanes connected to) the main highway.
siehe oben den Abschnitt aus dem Wiki. Im ursprünglichen Proposal wurde das nicht so explizit erwähnt, es wurde aber nur auf Fälle mit separatem cycleway eingegangen und der Verfasser des Proposals schreibt auch auf der Diskussionsseite:
Danke für den Hinweis. Tja, ist die Frage, ob das auch alle so gesehen haben, die abgestimmt haben.
Ich halte es jedenfalls für sinnvoll, dass der Tag nur bei separat erfassten Radwegen verwendet werden sollte. Ziel ist es dem Router den Hinweis zu geben, dass er ein Alternativweg finden muss. Dass das seit 2015 bereits unverändert im Wiki steht spricht auch dafür, dass dies Konsens ist.
Das Thema hatten wir doch schon. Ja, das Routing braucht es nicht. Manch ein Datenanwender möchte es aber vielleicht dennoch wissen um z.b. entsprechende Karten rendern zu können.
Die Accesstags (inkl. bicycle) und auch oneway beziehen sich auf den gesamten OSM-way inklusive daran getaggter Rad und Fußwege.
Ich kann Access und Oneway für Nebenwege durch namensräume cycleway:/sidepath: seperat erfassen - es wird jedoch von den meisten Routern vollkommen ignoriert.
Eigenschaft nur für die Fahrbahn lassen sich derzeit nur über lanes erfassen.
Ist hier wohl auch OT, aber ich halte traffic_sign nach wie vor für das Mittel der Wahl, damit eine Anwendung ein Radweg mit Zeichen 237/240/241 eindeutig identifizieren und rendern kann.
