StreetComplete: Oneway auf Radwegen

Aber genau darum geht es doch: Ein 240er ist ja nur nicht in beide Richtungen befahrbar, wenn er straßenbegleitend ist. Das trifft ja auf Waldwege oder 240er mit „Anlieger frei“ nicht zu, die sind ja nicht straßenbegleitend.

In Deutsch, oder Englisch? Du fragst im Deutschen Bereich, aber das Beispiel ist auf Englisch. Ich bin nicht gut in so etwas, aber hier ist mein Versuch:

„Ist der Radweg in beide Richtungen freigegeben (mit ↑↓ beschildert, oder nicht entlang einer Straße verlaufend)?“

Und dann als Folgefrage bei „nein“, wie von @Discostu36 vorgeschlagen die Richtung erfragen.

Ich würde es erstmal auch weglassen.

Etwas schade finde ich, dass die Tausenden von nicht straßenbegleitenden Radwegen dann generisch oneway=no erhalten, obwohl diese Anhabe dort eig. nicht nötig wäre (da die Wege ja eben nicht straßenbegleitend sind). Aber na ja, das kann man dann wohl nicht ändern.

Rein theoretisch müsste man nur bei straßenbegleitenden Radwegen nach dem oneway fragen, bzw. nur für diese Grupppe von Radwegen lohnt sich die Quest so richtig.

Aber da man diese Klasse von Radwegen offenbar nicht (sicher) heraufiltern kann, da es für straßenbegleitende Radwege kein extra Tag gibt, muss dann für alle Radwege gefragt werden. Das ust das, was ich ehrlich gesagt ein bisschen unnötig finde, aber gut, was will man machen…

Zusätzlich würde ich vorschlagen, in der Quest einzubauen, dass Wege ignoriert werden, die (warum auch immer…) bereits ein ‘oneway:bicycle’-Tag tragen.

Na ja, es gibt ja ein proposal dazu, is_sidepath=yes für straßenbegleitende Fuß und/oder Radwege zu nehmen. Bei über 17000 Verwendungen auf Wegen würde man wohl fast schon als “de facto” sprechen, auch wenn die Details des Konzeptes viel Gegenwind bekommen haben.
Man könnte die Quest also auch zweistufig gestalten und zuerst fragen, ob der Weg straßenbegleitend ist (dann entsprechend is_sidepath=yes/no setzen und bei yes fragen, ob der Weg in beide Richtungen befahrbar ist (↑↓-Beschilderung vorhanden oder auf dem Boden aufgemalt). Wäre jetzt nicht dumm, würde dann aber is_sidepath=yes/no sehr schnell durchsetzen.

Ich denke, das ist zu spezifisch. Der Radweg könnte in Gegenrichtung auch

🚲
frei

haben.

Das habe ich auf GitHub auch schon vorgeschlagen.

1 Like

Ja, wenn die Städte alle korrekt beschildern würden, dann stünde da „↑↓“ in Fahrtrichtung und „:bike: frei“ oder „240+↑↓“ in Gegenrichtung. Wie würde man danach fragen?

Frage 1: Ist dies ein straßenbegleitender Fahrradweg?
Frage 2: Ist der Fahrradweg in Gegenrichtung freigegeben (↑↓ in Fahrt- oder Gegenrichtung, bzw. :bike: frei in Gegenrichtung)?

Klingt wieder ein wenig zu lang.

Nein, wie oben schon geschrieben, ist das nur für Fälle gedacht, wenn das oneway für Fahrräder vom Wert für alle abweicht (als Ersatz für cycleway=opposite & Co.), nicht für die alleinige Verwendung.
Den Fehler habe ich auch eine Weile gemacht.

Da gehört das “:bicycle” dann weg …

Das wäre das Schwierige an diese Aufgabe: Sie ist erst im Rückblick zu klären …

Ich hab hier in den letzten Jahren einiges an falschen Radwegebeschilderungen gesehen, wo wie oben erläutert, gerne mal Zeichen 240 nebst Zusatzzeichen an asphaltierten Waldwegen gesetzt war… unterm Strich dann ohnehin strittige highway-Verwendung…

Sven

Wenn ein 237/239/240/241 den Fuß- und Radverkehr als Hauptnutzer mit Vorrang vor anderen festlegt, halte ich path (oder foot-/cycleway) für gerechtfertigt trotz Freigaben, so ist es ja auch bei Fußgängerzonen, wo es auch nur eher wenige ohne Freigaben für bspw. Lieferverkehr zu gewissen Zeiten gibt.

Den Zusammenhang mit oneway verstehe ich aber nicht, denn wenn die Freigaben an bspw. straßenbegleitenden einseitigen Radwegen symmetrisch an beiden Enden erfolgt, gilt das oneway=no für alle. Sollte eine Freigabe nicht symmetrisch erfolgen (dazu gerne Bsp., mein Versuch von gestern, mit overpass path/c. + motor_v.=agr. mit Mapillary zu korrelieren, brachte nur Symmetrien und mind. ein Fehltagging ohne Freigabe), wäre das was für klassisches o=yes + o:b=no dort, aber kein Grund, anderswo nur o:b statt o zu verwenden.

Genau. Bei isolierten Radwegen (is_sidepath=no) sollte SC nicht die Richtung abfragen.
Da diese meist bidirektional sind und ein fälschlich gesetztes oneway schwere Folgen hätte, da der Router nicht auf die Straße ausweichen könnte.

2 Likes

100% Zustimmung,
wie gesagt, fände ich das auch absolut unnötig und in keinster Weise erforderlich (aka der “no spam”-Regel bei SC)

Ob sich diese Sichtweise allerdings durchsetzen kann, na ja. Ich habe da so meine Zweifel.

StreetComplete “sollte” so vieles nicht fragen :joy:

Es bleibt dennoch eine Abwägung, wo es sinnvoll ist, die Werte explizit zu erfassen und diese fällt individuell unterschiedlich aus, aber ich nehme an, du wirst das oder das auch nicht für sinnvoll halten (ok in letzterem Fall ist es einfach falsch und die trail_visibility müsste bei der nötigen Beschilderung deutlich eingeschränkt sein)

1 Like

Ich habe das im GitHub-Issue ergänzt.

Hm, um effektiv zu vermeiden dass an quasi jedem Radweg oneway=* dran steht, müsste es einen tag geben, der aussagt ob, ein Radweg straßenbegleitend ist oder nicht. Dieser tag würde dann quasi an jedem Radweg getaggt sein.

Ein solcher tag hat sich bisher nicht etabliert, noch wurde einer approved.

Vielleicht gibt es noch mehr ähnliche Ansätze. Der erste ist der bisher meistgenutzte, allerdings ist er inkonsistent / orthogonal zu dem mit Abstand am häufigsten genutzten tag dieser Art: footway=sidewalk mit 3,6 Millionen Nutzungen.

Wie dem auch sei, sollte sich einer dieser tags deutlich etablieren oder approved werden, dann ist damit zu rechnen dass dieser tag dann optimalerweise irgendwann an jedem Radweg klebt.

Freunde der tag-Sparsamkeit kommen also so oder so nicht auf ihre Kosten.

1 Like

is_sidepath ist vorwiegend für Radwege gedacht und hat den Vorteil dass man damit einen Weg auch als NICHT-straßenbegleitend attributieren kann.

3 Likes

Stimmt, das ist ein klarer Vorteil. Ein weiterer Vorteil ist, dass das tag unabhängig vom highway=*-Wert ist, so dass nichts dagegen spricht, es für footway, path, steps und cycleway (und bridleway) zu nutzen.

Another option is 38 683 footway=sidewalk bicycle=designated ( overpass turbo - on highway=path I guess )

another option is asking only for places marked as sidewalks, without exhaustive coverage of separately mapped sidewalks unmarked as sidewalks (possibly combined with elaborate detection of separately marked sidewalks, not tagged as sidewalks, along roads that would catch some additional cases).

Die Identifikation straßenbegleitender Wege, z.B. über das is_sidepath-Schema, habe ich auch auf die Agenda für den OSM-Samstag nächste Woche im Anschluss an die FOSSGIS gesetzt – ich hoffe, dass wir hier weiterkommen und würde ggf. auch den Proposal-Prozess in angepasster Form weiterführen. Spannend, auch hier wieder zu sehen, wie nützlich das sein kann.

4 Likes