Funktioniert so zwar nicht gut international, aber die Zahl der Staaten für die das implementiert werden muss dürfte auch nicht allzu groß sein.
Zurück zum Thema:
Ich halte diesen Vorschlag für richtig. Auch im Hinblick auf KISS. Mich hast Du überzeugt.
Tja, wenn das tag so zu interpretieren ist wie beschrieben, dann ist es in der Tat unsinnig, weil es zwei Informationen miteinander vermischt und den Fall dass der Radweg als tag an der Straße gemappt ist überhaupt nicht abdeckt.
traffic_sign ist zwar eindeutig, aber jeder Datennutzer der an dieser Information interessiert ist, müsste eine Liste führen, welche Schilder in welchen Ländern eine benutzungspflicht bedeuten. Das wäre sehr umständlich.
Man könnte sich natürlich auch fragen, welcher Datennutzer denn wirklich international daran interessiert ist. Der darf sich gerne melden und einen Tagging-Vorschlag machen. In vielen Ländern dürfte sich Benutzungspflicht auch implizit durch das Vorhandensein eines Seitenweges ergeben oder auch überhaupt nicht existieren.
1 Like
Das ganze stammte ja wenn ich mich recht erinnere aus den Niederlanden, wo es absolut unüblich war/ist, Radwege als Attribut und nicht separat zu mappen.
Wie wäre es mit cycleway:track=optional und cycleway:track=compulsory? Natürlich nur zusammen mit cycleway=track.
Edit: Kann nicht abstimmen, da ich der Meinung bin, dass ein Tag sinnvoll wäre, aber eben nicht bicycle=* und die Auswahlmöglickeit “Unterscheidung ist wichtig, aber Tag ist falsch” fehlt.
Der Punkt ist doch, dass alles was jetzt durch bicycle=optional_sidepath ausgedrückt wird auch durch cycleway=separated und bicycle=yes ausgedrückt werden kann (siehe Brauchen wir bicycle=optional_sidepath? - #27 by Langlaeufer. Alles weitere benötigt eh ein weiteres Tag. Oder was hab ich übersehen?
Edit: War der Annahme, dass sich optional_sidepath allgemein verwendet werden kann und nicht zwingend ein cycleway=separate benötigt:
Unter falscher Annahme
Es sollte zwischen den zwei Varianten, alles an einer Linie und als eigenständig eingetragener Seitenweg unterschieden werden. Ich dachte, das ist aus den vorangegangenen Kommentaren klar.
- Bei separat eingetragenem Seitenweg braucht es keinen zusätzlichen Tag, da
cycleway=separateundbicycle=use_sidpath(bzw. das Weglassen letzteres) alles aussagen. - Bei nur einer Linie für alles fehlt aber die Option und der Fahrradweg (
cycleway=track) braucht eine genauere Definition.
Oh, ich sehe gerade, dass bicycle=optional_sidepath nur bei cycleway=separate verwendet werden soll. Dann ist es durchaus unnötig.
Das stimmt, aber hier geht es nur um bicycle=optional_sidepath und somit um separat erfasste Radwege.
Stimmt schon, aber ich sehe dann auch leider wieder irgendwen das bicycle=yes löschen, weil es ja sowieso impliziert ist durch die highway=*-Art. Selbst wenn wir uns jetzt darauf einigen würden, dass man statt bicycle=optional_sidepath einfach bicycle=yes schreiben kann, funktioniert diese Lösung insgesamt immer noch nur für getrennt erfasste Radwege und es wäre nur eine Frage der Zeit, bis wir uns wiedersehen und zur Zweiten Runde übergehen müssten. Selbst das clevere bicycle=use_sidepath geht ja nicht bei nicht separat erfassten Radwegen.
Ich sehe da zwei mögliche Tagging-Wege an der Fahrbahn:
- z.B.
cycleway:<side>:compulsory=yes/no- das spricht eigentlich für sich - z.B.
carriageway:bicycle=yes/use_sidepath- das ist etwas, was vielleicht auch Router irgendwann auswerten könnten.
Wir sollten im Übrigen auch nich die Fußgänger vergessen, die haben ja auch das gleiche Problem. Bei nicht getrennt erfassten Gehwegen, weiß der Router nicht, dass sie nicht auf der Fahrbahn gehen dürfen. carriageway:foot=use_sidepath oder sidewalk:<side>:compulsor=yes/no würden danalog funktioieren.
Ja, wir können das (zumindest für Fahrräder) alles auch indirekt durch traffic_sign abbilden, aber ich halte das eher für eine Krücke, bis ein richtiges Tagging gefunden wurde. Es ändert aber nichts daran, dass optional_sidepath zumindest als Übergangslösung einfach durch yes ersetzt werden kann.
2 Likes
Die Information wäre auch ohne bicycle=yes noch richtig nur eben nicht mehr nachvollziehbar ob das bewusst erfasst worden ist. Aber das ist ja ein generelles Problem auch bei anderen Tags (oneway=no, cycleway=no, …) dieser Art.
Ein carriageway-Namensraum für die Fahrbahneigenschaften wäre tatsächlich sinnvoll genauso wie ein (cycleway/footway/sidewalk:)compulsory für die Benutzungspflicht für Radfahrer und/oder Fußgänger.
Auf taginfo findet sich cycleway:(side:)mandatory=yes/no. Allerdings wie auch andere Varianten in vernachlässigbarer Anzahl. Ich erwähne es nur als Vorschlag:
https://taginfo.openstreetmap.org/search?q=mandatory#keys
1 Like
Ich kann mir diese Lösung / “Definition” auch gut vorstellen. Der Vollständigkeit halber: Damit geht für mich eine Bedeutungsänderung von bicycle=yes einher. Bisher verstehe ich den Tag so, dass er auf nahezu allen Straßen implizit ist. Es ist bisher also kein Problem den Tag zu ignorieren oder gar zu löschen, da er keine Zusatzinformation liefert. Das ändert sich dann jetzt, denn in bestimmten Kombinationen (der fett hervorgehobenen), liefert das yes in Kombination mit separat eine relevante Zusatzinformation. Seht ihr das als Problem an?
(Update: Und wir müssten noch eine Definition haben, wie man das gleiche aussagt, wenn es an der centerline getaggt wurde (Westnordosts Hinweis). Ich habe aber nicht alle Posts dazu im Detail verfolgt.)
Ich möchte die Unterhaltung nicht ablenken, aber wenn dich meine Antwort interessiert, lass uns gerne dazu sprechen. Vielleicht auch mal in einem der online Meetups Berlin/Verkehrswende - OpenStreetMap Wiki?
Aus meiner Sicht ändert sich gar nichts, aber das habe ich vorher schon geschrieben. Die “Meta”-information ergibt sich nur aus dem expliziten setzen eines impliziten Wertes, so wie das bei oneway=no auch der Fall ist.
Zu Benutzungspflicht gab es ja schon zwei Vorschläge:
- mandatory
- compulsory
Das könnte so aussehen:
Bei Tagging nur an der Hauptline
cycleway:right:=track
cycleway:right:mandatory=yes/no
Oder an der Nebenlinie
highway=cycleway
mandatory=yes/no
Aber das können wir gerne mal Brainstormen
Aus Zeitgründen nur kurz dazu:
Bei use_s. wurde diese Einschränkung, wie bereits geschrieben, später reingeflickt, weil es m.E.n. als Begründung zu Inkompatibilitäten mit Routern käme, da sie das als “no” interpretieren und den am gleichen Weg als Eigenschaft gebabbten Radweg nicht erkennen mögen, also eigentlich wegen technischen Unzulänglichkeiten. Die Interpretation als no ist eh falsch, vor allem dann, wo bspw. eine direkte Verbindung zu einer abzweigenden Straße fehlt (ob nicht vorhanden oder nicht gemappt, sei dahingestellt). Behalten wir die Beschränkung auf separate Wege bei, fixieren wir auch die Unzulänglicheiten der Router, weil kein Bedarf zur Weiterentwicklung …
optional_s. hat die Einschränkung bei der Definition und die Begründung dagegen nicht.
Natürlich kann man ein eigenes Tag am separaten Radweg und für nicht separat gemappte Radwege erfinden, das wäre dann aber Doppeltagging bei benutzungspflichtigen separat gemappten Radwegen, da dann eine B-Pflicht am Radweg selbst UND eine B-Pflicht an der Fahrbahn hängt, denn use_s. wäre weiterhin nicht obsolet. Das sollte man beim angeblichen Doppeltagging c=s + b=o bedenken, wobei ich anderswo schon gesagt habe, dass es da Unterschiede zwischen den beiden gibt und zwischen yes und o_s.
Ich habe optional_sidepath aus der Wikiseite getilgt.
https://wiki.openstreetmap.org/w/index.php?title=DE:Bicycle/Radverkehrsanlagen_kartieren&diff=2522292&oldid=2521729
Ich denke die Diskussion zeigt, das es für eine Empfehlung eine Mehrheit fehlt.
1 Like
optional_sidepath löst keinerlei Probleme!
BTW:
Zudem finde ich es absolut unpassend ohne Proposal ein access-Tag einzuführen, dass so viele Datennutzer betrifft. Hier können die Nutzer nur froh sein, das Router unbekannte Accesswerte wohl als yes und nicht als no interpretieren.
4 Likes
Na ja, per Definition gelten access-tags für die ganze Straße, also auch für die cycleway=*- und sidewalk=*-Wege. Wir können das Tagging-Problem nicht auf die Router schieben, sie werten die Tags nur korrekt aus.
1 Like
Das erscheint logisch, aber führt zu möglichen Missverständnissen für Wege wie etwa das populäre
highway=path
foot=designated
bicycle=designated
(segregated=yes/no)
, also wenn Fuß und Radwege trotz (oder ohne) Trennung als ein Weg gemappt werden. mandatory=yes/no scheint sich dann auf den gesamten Weg statt auf den Radfahr-Teil des Weges zu beziehen. Vielleicht bicycle:mandatory=yes? Hmm… aber ähnliches tagging findet man auf taginfo nicht. Vielleicht gibt es eine Idee die konsistenter zu bisherigem Tagging wäre.