StreetComplete: Oneway auf Radwegen

Das ist voll und ganz mein Standpunkt.

Man könnte ja auch bei Defaultwerten ein ”checked” tagning einführen, nur macht das die Datenbank ja auch nicht schlank und allés noch mehr kompliziert

1 Like

Ich halte den Quest für sehr wertvoll, da ich durch die fehlende Richtungsvorgabe bei Radwegen von meinem Fahrrad-Navi very british auf die linke Seite der Straße gelenkt werde. Also bitte ändern, wie bei Autostraßen üblich.

btw. darf man als Radfahrer nicht gegen die Richtung auf Radwegen fahren, wenn auf beiden Seiten der Autostraße ein Radweg existiert. Das sieht die Polizei gar nicht gern, wenn man diese Regel ignoriert… hatte schon Diskussionen mit der Polizei vor Ort.

Wie die Oberfläche genau aussehen soll, wurde noch nicht entschieden. Ich könnte mir z.B. vorstellen, dass ein Bild des Radwegs zu sehen ist und man dann entsprechende Pfeile antippt:

==========================
⇐         ⇆            ⇒
1 Like

Ähnlich wie bei Treppen (welche Richtung führt nach oben) nur eben " in welche Richtung darf gefahren werden"

3 Likes

Wie bereits geschrieben, würde ich bicycle=yes weglassen, weil ich die Gefahr sehe, dass hier in überproportional vielen Fällen in beide Richtungen gefahren werden darf. Ich muss bei Gelegenheit mal gucken, ob die Zahlen in der Datenbank diese Vermutung bestätigen.

Wir reden hier aber nicht über ID, sondern über SC. Und das Umdrehen eines Weges kann viele Nebenwirkungen haben, z.B. können dadurch Relationen kaputtgehen, Tags mit :left, :right, :forward und :backward stimmen evtl. nicht mehr etc. Es ist natürlich sinnvoll, Wege mit oneway=-1 später mit einem dafür geeigneten Editor zu überarbeiten.

2 Likes

Ich brauchte eine Weile, um mir meine Meinung zu bilden…

Grundsätzlich würde ich das begrüßen, aber…

…aber ich würde eher oneway:bicycle=yes|no als besser erachten. Das ergibt sich für mich alleine schon wegen der völlig unterschiedlich vor Ort sichtbaren Verwendungen der Radwegeinfrastruktur. Ich habe hier vor Ort auch asphaltierte und in Radwegeinfrastukturen eingebundene Wege, die z.B. mit Zeichen 240 ausgeschildert sind, aspaltiert sind und durch Wald verlaufen, also asphaltierte tracks forstwirtschaftlicher Nutzung sind… (woraus andere wiederum ein hw=unclassified machen wollen… Ein Schelm, wer Böses dabei denkt…)

Sven

3 Likes

highway=path & bicycle=designated (243.530 features)

Tag Anzahl Prozent Value Prozent gesamt
oneway 37.936 15,6%
= no 20.114 53,0% 8,3%
= yes 17.804 46,9% 7,3%

highway=path & bicycle=yes (119.642 features)

Tag Anzahl Prozent Value Prozent gesamt
oneway 3.049 2,5%
= yes 1.602 52,5% 1,3%
= no 1.447 47,5% 1,2%

Man kann die Zahlen natürlich auf unterschiedliche Weise interpretieren, insbesondere, da die Dunkelziffer so hoch ist. Da allerdings im Routing ein fehlender oneway-Tag gleichbedeutend ist mit oneway=no, ist praktisch bicycle=designated 5x häufiger in nur eine Fahrtrichtung freigegeben als bicycle=yes. Das bestärkt mich also in meiner Einschätzung.

Ich kann dir nicht ganz folgen. Du würdest Radwege mit oneway:bicycle taggen wollen, weil sie illegal von Kraftfahrzeugen in beide Richtungen befahren werden?

Nicht illegal, sondern weil z,B, Zeichen 240 nebst etwaiger Zusatzzeichen wie insbesondere Zeichen 1020-30, 1026-36 oder 1026-38 nicht selten anzutreffen sind… Ja, das mag ein Beschilderungsfehler sein, ich habe aber da die Flinte in Korn geworfen, um bei sowas nachzurecherchieren…

Sven

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.