DE talk:Key:cycleway:right

From OpenStreetMap Wiki
Jump to navigation Jump to search

opposite ist nicht inkompatibel!

Ich widerspreche das opposite_lane/track hier inkompatibel ist. Es ist sogar notwendig, wenn der Radweg entgegen der Einbahnstraße laufen soll. Es hebt die Richtung der Einbahnstraße für Radfahrer auf enthält aber keine Aussage zur Richtung des Radweges --Langläufer (talk) 17:48, 17 April 2023 (UTC)

Erstens ist cycleway:right=* kein Tag, das nur auf Einbahnstraßen Verwendung findet, womit der Terminus opposite an sich schon nicht selbsterklärend ist. Ganz konkret könnte ein Neuling z.B. davon ausgehen, dass mit opposite die andere Straßenseite gemeint ist und nicht die vorgesehene Fahrrichtung. Zweitens ist die Interpretation und Auswertung sehr viel schwieriger, gerade bei Einbahnstraßen, denn es ist nicht, d.h. nicht ohne weitere Definition, klar, ob sich opposite als fahrrichtungsbestimmender Wert auf die Vektorrichtung des osm-ways oder aber auf die mittels oneway=* festgelegte Richtung der Einbahnstraße bezieht. Dein Argument der Aufhebung der Einbahnstraßenrichtung deutet darauf hin, dass du letztgenannten Bezug präferierst, womit sich die vorgsehene Fahrrichtung auf der Fahrradspur nur unter Zuhilfename aller drei Werte, d.h. der Vektorrichtung, den sich darauf beziehenden oneway=* der Straße zur Bestimmung der Einbahnstraßenrichtung und letztlich den sich wiederum darauf beziehenden opposite_lane/track-Wert für die Bestimmung der vorgesehenen Fahrrichtung auf der Fahrradspur.
Die Bestimmung der Fahrradspurrichtung ist sehr viel einfacher (für Mensch und Maschine), wenn man (in Ländern mit Rechtsverkehr) bei Abwesenheit des cycleway:right:oneway=* dieselbe Fahrrichtung annimmt, die für die Straße bzw. Einbahnstraße gegeben ist, d.h. bei:
  • oneway=1 Fahrradspurrichtung == Einbahnstraßenrichtung == Vektorrichtung des osm-ways
  • oneway=-1 Fahrradspurrichtung == Einbahnstraßenrichtung == entgegengesetzte Vektorrichtung des osm-ways
.. und bei gesetztem cycleway:right:oneway=*
Die Tag-Ökonomie ist so angelegt, dass für die häufiger anzutreffenden Fälle der implizit gegebene Wert zutreffend ist, also cycleway:right:oneway=* überwiegend gar nicht gesetzt werden muss, während die Setzung und Auswertung bei den selteneren, exotischen Fällen unmittelbar und intuitiv erfolgen kann, denn die Semantik gleicht exakt jener, die historisch durch oneway=* bereits lange gegeben ist. (Wie üblich kann das Tag auch explizit gesetzt sein, wenn es dem implizit ermittelbaren Wert nicht widerpricht, so wie z.B. auf manchen Zweirichtungsbahnstraßen explizit oneway=no gesetzt ist, um zu verdeutlichen, dass dies "wirklich" keine Einbahnstraße ist; in diesem Fall dient eine Setzung eher der Kommunikation an Mitmapper)
Summa summarum sind opposite_lane/track Werte nicht notwendig. Selbst wenn man zu dem Schluss kommt, dass sie nicht inkompatibel sind und schlüssig auswertbar sind, dann doch auf missverständlicherem, weniger intuitivem Weg, womit von einer Verwendung abzuraten ist. Hinzu kommt, dass cycleway:right=* historisch nach cycleway=* entstanden ist und man absichtlich diese Werte nicht mit in das (damals) neue Schema übernommen hat, um nicht dieselbe Verwirrung zu stiften, die aus oben genannten Gründen bestand. --Cmuelle8 (talk) 23:37, 17 April 2023 (UTC)
Danke für den Erklärungsversuch, die Verwendung von cycleway:oneway ist mir jedoch sehr wohl geläufig. Es bereitet aus meiner Sicht den Leute viel mehr probleme left und right zu verstehen als opposite. Ich wüsste auch nicht, dass die Verwendung von opposite_* deprecated wurde. Aber ja, oneway:bicycle ist auch aus meiner Sicht das bessere Schema. Es wird aber immer noch auf etliche Seiten empfohlen beide Varianten zu setzen. Ich muss allerdings zugeben, dass die Verwendungszahlen zeigen, dass sich das neue Schema mittlerweile durchgesetzt hat.
Ich würde das dennoch nicht als inkompatibel bezeichnen, sondern eher veraltet oder nicht empfohlen. --Langläufer (talk) 18:43, 18 April 2023 (UTC)
Das eigentliche Problem bleibt, dass es derzeit bei Einbahnstraßen nicht möglich anzuzeigen ob die auch Fahrbahn oder nur die Radwege in Gegenrichtung zu verwenden sind weil man um das Setzen oneway:bicycle=no nicht herum kommt. Die Router werten cycleway:*:oneway nicht aus sondern achten nur auf oneway und oneway:bicycle bzw cycleway=opposite_*. Das ganze cycleway:oneway ist derzeit nur in wenigen Karten sichtbar. --Langläufer (talk) 18:43, 18 April 2023 (UTC)
Ich habe nicht gesagt, dass opposite_* deprecated wurde, sondern nur verdeutlicht, warum es von Anfang an nicht in Zshg. mit cycleway:right bzw. cycleway:left Verwendung finden sollte (das es einige entgegen der Wiki-Dokumentation doch taten ist/war ein Sport und ein anderes Thema..). cycleway:right und cycleway:left wurden eingeführt, um Mehrdeutigkeiten auszuräumen, die mit dem früheren Schema bestanden. Es ist nur folgerichtig, die Ursache dieser Mehrdeutigkeiten nicht in ein Folgeschema übernommen zu haben. Es gibt aber sehr viele Anwendungen, die mit diesen Mehrdeutigkeiten leben können und die es nicht präziser brauchen, weswegen cycleway:right und cycleway:left auch nicht von allen Anwendungen ausgewertet wird, nach wie vor nicht, und anfänglich von keinerlei Anwendungen (!).
Router, die cycleway:right bzw. cycleway:left auswerten, bekommen in Sonderfällen Probleme, wenn sie sich ausschließlich auf das nicht selektive oneway:bicycle=* stützen: Falls sich die vorgesehene Fahrrichtung zwischen den Fahrradspuren am linken und rechten Wegrand vom Standardfall unterscheidet, ist eine Abbildung von Vor-Ort-Situationen damit unmöglich. Beispiele:
Rechts der Kraftfahrbahn(en) befindet sich ein baulich abgesetzter Fahrradweg, der in beide Richtungen befahren werden darf und links jener eine Fahrraspur, die in Verkehrsrichtung der linken (oder einzigen) Kraftfahrbahnspur läuft. osm-übersetzt:
  • das ist nicht ersetzbar oder auszudrücken mittels cycleway:right=track + cycleway:left=lane + oneway:bicycle=no
  • falls in Kombination mit Einbahnstraße gegeben, gleicht die implizit ermittelte Fahrrichtung der linksseitigen Fahrradspur der Einbahnstraßenrichtung (d.h. Abwesenheit des tags cycleway:left:oneway)
  • ohne Einbahnstraßenattribut (d.h. Abwesenheit des tags oneway) wäre der implizite Wert für die Fahrrichtung der Fahrradspur durch die Fahrrichtung der linken Kraftverkehrsspur gegeben
Rechts der Kraftfahrbahn einer Einbahnstraße befindet sich eine Fahrradspur mit derselben Flussrichtung wie der Kraftverkehr, links davon eine entgegen dieser Richtung. osm-übersetzt:
  • das wäre wiederum nicht ersetzbar oder auszudrücken mittels cycleway:right=lane + cycleway:left=lane + oneway:bicycle=1 (bzw. -1)
  • die Kombination cycleway=lane + cycleway:left:oneway=-1 ist weniger intuitiv und würde sich auf eine implizite Annahme stützen, dass der Standardfall bei Verwendung mit Einbahnstraßen stets eine linke und rechte Spur annimmt, tatsächlich kann man aber m.E. bzw. de facto bei ausschließler Anwesenheit des Tags cycleway=lane nur darauf schließen, dass es eine Fahrradspur gibt (nicht wie viele, d.h. es ist dann mehrdeutig, ob eine oder zwei vorhanden sind; und falls eine zudem offen, ob sie links oder rechts des Weges liegt. (Genau diesem Umstand ist es zu verdanken, dass cycleway=* häufig nur noch aus dem Wertevorrat { right, left, both, (none) } bestückt wird und die Art { lane, track } als Werte der später geschaffenen Tags cycleway:right bzw. cycleway:left in Erscheinung treten; bitte aber in diesem Zshg. die bereits bestehenden Wiki-Hilfeseiten konsultieren - die Diskussionsseiten sind für Taggingzwecke z.B. nicht maßgeblich)
Im Zshg. mit dem Henne-Ei-Problem ist also ein Argument gegen cycleway:*:oneway nicht ratsam: Falls man die Router z.B. im Zukunft präziser einstellen/programmieren möchte, dann braucht man auch diese präzisere Datenlage; und umgekehrt, falls diese Datenlage nicht existiert, wird auch niemand beginnen können das Routing in der Software algorithmisch zu verbessern.
Also ja, es ist richtig, dass Datenkonsumenten von cycleway:*:oneway derzeit dünn sind (einen genauen Überblick hat man wegen der Vielzahl der Software ohnehin nicht). Es wäre aber falsch zu glauben, dass allein deswegen die Tags keinen Nutzen hätten und dieser derzeitige Umstand in Zukunft gleich bleibt. Viele der Tags, die heute datenkonsumententechnisch ausgewertet werden, etwa um gerenderte Karten oder Statistiken zu erstellen, waren irgendwann mal in dem gleichen Stadium verhaftet.
Bitte bei dieser Argumentation nicht vergessen, dass es in der Vielzahl der Fälle eben nicht nötig ist cycleway:*:oneway zu setzen: Wenn man dafür einen Auswerter programmiert, dann geht es i.d.R. schon um die Auswertung und Analyse von Spezialfällen, nicht Regelfällen. Das wird/kann schnell vergessen/werden. --Cmuelle8 (talk) 01:34, 19 April 2023 (UTC)
Ich argumentiere auch nicht gegen cycleway:*:oneway und halte es auch nicht für entbehrlich und fänd es sogar auch die saubere Lösung. Ich argumentiere lediglich für gegen die Formulierung, dass opposite_track/lane nicht mit left/right/both kompatibel sei. Falls das jedoch im Proposel von cycleway:left/right stehen sollte, dann gebe ich mich geschlagen. --Langläufer (talk) 06:06, 19 April 2023 (UTC)
Schon verstanden, evtl. ist die Formulierung übersteuert, damit aber unmissverständlich. Aus den bereits genannten Argumenten, oben, und dem Wunsch zum Zeitpunkt der Dokumentation von cycleway:right bzw cycleway:left explizit opposite_* auszuschließen ergab sich diese Formulierung. Vielleicht wird es eher verständlich wenn man es als Inkompatibilität per Definition und nicht strikt als technische Inkompatibilität versteht. Prinzipiell hätte ich auch kein Problem damit, es exakter zu formulieren, indem man schreibt "unerwünscht" oder "abgeraten" oder "nicht empfohlen"; aber wozu den Aufwand - die Doku ist Jahre alt und funktioniert einigermaßen und das Resultat, auf das es ankommt, nämlich opposite_* auszusparen wäre das gleiche. Ich fürchte, mit einem Edit daran neue Wege der Interpretation zu eröffnen und einige könnten es als Einladung verstehen, wieder mit diesen Werten herumzuexperimentieren, obwohl sie von Anfang an in Kombination mit cycleway:left bzw cycleway:right nicht gewollt waren. Die harschere Formulierung ist evtl. rein logisch nicht zu 100% exakt, aber sie kürzt die oben genannten Argumente auf ein Minimum ab und sorgt für die gewollte Separation. Oder anders gesagt, die Dokumentation so wie sie besteht ist alltagstauglich - diese Diskussion hier jedermann zuzumuten hingegen eher nicht. --Cmuelle8 (talk) 03:10, 20 April 2023 (UTC)

Beispiele

Beispiel 1

Dann mach ich mal ein Beispiel mit einer Einbahnstraße, die einen beidseitig befahrbaren Radweg hat.

Option 1: Erweckt den Eindruck das auch die Fahrbahn entgegen der Einbahnstraße befahren werden kann.
highway=<road> Irgendein Straßentyp
oneway=yes
oneway:bicycle=no (Irgendein Teil der Straße ist gegen die Einbahnstraße befahrbar!)
cycleway:right=track
cycleway:right:oneway=no

oneway:bicycle=* schreibt derzeit, dass sobald es möglich ist mit dem Fahrrad einen Weg/Straße in beide Richtungen zu befahren oneway:bicycle=no setzbar ist. Auf Nicht-Einbahnstraßen ist das der Standardfall und für Einbahnstraßen wäre dies explizit setzbar, sobald eine Fahrradspur, ein abgesetzter Fahrradweg oder eine Kraftverkehrfahrbahn besteht auf dem der Radverkehr entgegen der Einbahnstraße erlaubt ist. Dies sei deshalb elaborierend ausgeführt, weil die Klammerbemerkung oben Template:" auch so interpretierbar werden kann, dass ein Weg neben der Straße für die Bewertung nebensächlich wäre (was er laut oneway:bicycle=* nicht ist).
Deine Beobachtung ist m. E. sehr richtig, dass mit Option 1 nicht klar ist, ob oneway:bicycle=no ausschließlich aufgrund des beidseitg befahrbaren Radwegs am rechten Straßenrand gesetzt wurde, oder etwa, weil sowohl auf diesem Radweg als auch auf der Kraftverkehrfahrbahn Radverkehr in entgegengesetzter Richtung erlaubt ist. Diese Mehrdeutigkeit beeinträchtigt aber nicht, dass für den Radweg am rechten Straßenrand exakte Aussagen anhand der cycleway:right* Tags getroffen werden können.
Das bedeutet auch, dass nicht in allen möglichen Fällen oneway:bicycle=no nutzbar ist, um die Befahrbarkeit einer Kraftverkehrfahrbahn für Radverkehr in entgegengesetzter Richtung auszudrücken bzw. abzuleiten. Es gibt sowohl Fälle, wo dieser Tag eindeutig ist, d.h. ausschließlich die Kraftverkehrfahrbahn adressiert (etwa onway=yes + oneway:bicycle=no + cycleway=no), aber auch Fälle, wo dieser Tag nur wiedergibt, dass mindestens eine Möglichkeit für Radfahrer besteht, den Weg/Straße in entgegengesetzter Richtung zu benutzen (Beispiel dafür mit Option 1 gegeben). In solchen Fällen ist oneway:bicycle=no fuzzy. --Cmuelle8 (talk) 03:10, 20 April 2023 (UTC)

Option 2: Das Gleiche mit opposite ausgedrückt - hier wird klar, dass nur der Radweg entgegen der Einbahnstraßenrichtung befahrbar ist.
highway=<road>
oneway=yes
cycleway:right=opposite_track
cycleway:right:oneway=no (auch hier nicht verzichtbar!)

Diese Option 2 ist völlig ohne opposite_* und der bestehenden Dokumentation für den Tag abbildbar, sie ist semantisch äquivalent zu
highway=<road>
oneway=yes
cycleway:right=track
cycleway:right:oneway=no
Womit gesagt ist, dass lediglich oneway:bicycle=no aus dem Satz der Tags in Option 1 zu entfernen ist, um Unklarheiten über den Radbefahrbarkeitsstatus der Kraftverkehrbahn auszuräumen.
Eine gute Frage in diesem Zusammenhang ist aber, wie eine Einbahnstraße mittels Tags eindeutig abgebildet werden kann, auf der zusätzlich zu der in Option 2 gegebenen Situation auch auf der Kraftverkehrbahn Radverkehr in entgegengesetzter Richtung stattfinden darf. Option 1 ist, wie zu sehen war, polymorph: Radverkehr in entgegengesetzter Richtung auf der Kraftverkehrsbahn könnte erlaubt sein, oder nicht (der Tagsatz erlaubt, laut der vorliegenden Dokumentation zumindest, keine genauere Aussage). --Cmuelle8 (talk) 03:10, 20 April 2023 (UTC)

Beispiel 2

Und dann noch eine normale Einbahnstraße mit linkseitigen Radweg.

Option 1: Erweckt den Eindruck das auch die Fahrbahn entgegen der Einbahnstraße befahren werden kann.
highway=<road> Irgendein Straßentyp
oneway=yes
oneway:bicycle=no (Irgendein Teil der Straße ist gegen die Einbahnstraße befahrbar!)
cycleway:left=lane
(cycleway:left:oneway=-1 ist Defaultwert und damit nicht notwendig)

Option 2: Das Gleiche mit opposite ausgedrückt - hier wird klar, dass nur der Radweg entgegen der Einbahnstraßenrichtung befahrbar ist.
highway=<road>
oneway=yes
cycleway:left=opposite_lane
(cycleway:left:oneway=-1 ist Defaultwert und damit nicht notwendig)

Wäre das gleiche wie
highway=<road>
oneway=yes
cycleway:left=lane
cycleway:left:oneway=-1
.. und man muss nicht überlegen, ob opposite_ sich nun auf die durch oneway= gegebene Richtung oder die Vektorrichtung des osm-ways bezieht. Es bleibt dabei, opposite_* Werte sind und waren nie für die Verwendung mit cycleway:left bzw. cycleway:right vorgesehen, siehe oben. --Cmuelle8 (talk) 03:20, 20 April 2023 (UTC)


Das eigentlich Problem ist natürlich das die Router zwar cycleway:*=opposite_* auswerten aber nicht cycleway:*:oneway=*. --Langläufer (talk) 06:29, 19 April 2023 (UTC)

Siehe Abschnitt Henne-Ei-Problem. Das Router cycleway:*=opposite_* auswerten läuft entgegen der Dokumentation. Sie sollten das nicht tun. --Cmuelle8 (talk) 03:20, 20 April 2023 (UTC)
Es gibt noch einen weiteren Grund, warum es keine gute Idee ist, Werte wie opposite_lane oder opposite_track zu benutzen. Diese Werte mischen Aussagen zu zwei semantisch voneinander strikt getrennten Klassen. Die eine Klasse ist die physische Art des Weges { Spur, baulich getrennter Weg }, die andere die administrativ vergebene erlaubte Nutzungsrichtung des Weges.
Zudem ist es beobachtbar so, dass mittlerweile eine Vielzahl der baulich getrennten Radwege an Straßen geometrisch separat erfasst sind. Das kann man als Indiz auffassen, dass die bisherigen Abstraktionen, die für die Erfassung von Situationen vor Ort mittels einer einzigen Geometrie (Linienbündel vs. ein Linienzug + Tags) geschaffen worden waren, nicht ausreichend praxisfreundlich oder mapper/menschenfreundlich waren. Das ist weder ein Plädoyer für oder gegen Linienbündel (früher wurde mal der Versuch unternommen jede Spur mittels eigener Geometrie/Linienzug abzubilden), zeigt aber, dass gute Tag-Dokumentation und einfache Verständlichkeit wichtig für den Erfolg von abstrakten Abbildungen der Situation vor Ort sind. Wenn eine Tag-Abstraktion langfristig z.B. nicht ausreichend zu einem der OSM-Grundsätze wie DE:Ein_Objekt,_ein_OSM-Element passt, besteht die Gefahr, dass die Abstraktion an sich verworfen wird, zugunsten von weniger eleganten Lösungen mit mehr Geometrie bzw. mehr OSM-Elementen. --Cmuelle8 (talk) 03:45, 20 April 2023 (UTC)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=DE_talk:Key:cycleway:right&oldid=2506585"