Falsche Verwendung von cycleway=shared_lane in Deutschland

Simon, wie würde das Tag dann konkret aussehen? Z.B. cycleway:markings=dashed/solid, oder wie?

Eine Unterscheidung per bicycle=designated/yes funktioniert nicht, weil es in anderen Ländern zB. in den Niederlanden “schutzstreifenähnliche” Markierungen einmal mit und auch ohne Benutzungspflicht gibt.

Das bloße herunterbrechen ob die Markierung gestrichelt oder durchgezohen ist wird den wesentlichen Unterschieden beider Wegarten bei weitem nicht gerecht. Der wesentliche Unterschied ist nicht ob der Streifen überfahrbar ist oder nicht, sondern setzt sich aus der Breite des Streifens, und vor allem auch der Breite des angrenzenden Fahrstreifens zusammen! Das sind einfache rechtliche einsatzgrenzen, die in anderen Ländern ähnlich sind wie in Deutschland.

Weil die Streifenart für Radfahrer von entscheidender Bedeutung ist, plädiere ich für die Lösung des neuen value soft_lane.
Man könnte zwar die jeweilige Breite der Streifen und der Fahrbahn taggen, aber das wird niemand so cm genau hinbekommen. Und bei track/path gibt es auch abhängig der Breite unterschiedliche values, weil es auch da einen entscheidenen Unterschied macht.

Es soll wohl schon ein Radweg sein, der Streifen geht bis zum nächsten Ort und es sind auch Schilder vorhanden, nur eben keine blauen.
https://www.mapillary.com/app/?focus=photo&pKey=9mWTylFDMXpP5ac5QrZreA&lat=49.768630979992&lng=8.478220940016854&z=19.307090262718656&menu=false&x=0.3657588864784952&y=0.6058944675492794&zoom=0.8248752079866889

Sry, aber das ist für mich kein Radweg. Zumal die Autos hier warscheinlich völlig legal parken: https://www.mapillary.com/app/?focus=photo&pKey=Tj1DV8l1ZXWtZbFQKh1agQ&lat=49.7557866&lng=8.48225544&z=17
Auch, dass die Bushaltestelle da einfach drüber gebaut wurde spricht definitiv dagegen.
Nur weil am Ende der Straße ein Radwegweiser steht heißt das noch lange nichts, die Dinger zeigen mitunter sogar auf reine Gehwege oder entgegen die Einbahnstraße ohne Fahrrad-Frei Zusatz.
Grüße

Wieso oft driftet die Diskussion weg von OSM in eine über deutsche Verkehrspolitik. Es ist nun mal vielleicht für ein Gericht massgebend ob was in Deutschland normgerecht gebaut wurde, für OSM nicht (und wir können es auch nicht entscheiden) und deshalb macht es Sinn das Hauptunterscheidungsmerkmal zu erfassen und die Deutung dem Benutzer/Router zu überlassen. Und du hast durchaus recht, die Breite des Streifens wäre tatsächlich was, dass optional erfasst hilfreich wäre zu entscheiden ob man dadurch soll oder nicht.

Simon

meine Anmerkung war ja nur, dass solche Wege oft als lane in OSM sind. Und wenn wir diese schon genauer beschreiben wollen, dann können wir uns überlegen, ob wir sowas streichen oder benennen wollen.

Simon, ich bin da total mit dir auf einer Linie, aber wie sähe denn nun das Tagging aus dass du vorschlägst?

Das Problem mit den namespaces ist das die Tags unhandlich lang werden, aber es müsste wohl

cycleway:lane:markings

oder von mir aus

cycleway:lane:road_markings

plus noch left & right Varianten sein.

Simon

PS: das ganze hat natürlich nix damit zu tun, dass cycleway:shared_lane wohl in DACH eher nicht vorkommt.

Klar gibt es neben Radfahrstreifen und Schutzstreifen tausend andere Dinge, die es eigentlich nicht geben sollte. Aber dafür eigene Schlüssel zu definieren geht m. E. zu weit. Die Kernfrage ist weiter, wie taggen wir Radfahrstreifen und Schutzstreifen, denn die gibt es laut StVO ganz offiziell und in der Praxis findet man sie fast überall.

Ich bin langsam auch dafür, eine Subkey cycleway:lane=soft_lane/hard_lane einzuführen. Die Begriffe empfinde ich zwar nicht perfekt, weil nichts weich oder hart ist, aber besser als ein nacktes soft/hard. Die Widerstände dagegen sind vermutlich geringer als dagegen, das Proposal von soft_lane als top-level-tag von 2014 nochmal aufzuwärmen.

soft_lane würde dann ein bicycle=yes und vehicle=yes implizieren
hard_lane dann bicycle=designated bzw. official und vehicle=no.
Abweichungen davon müssten per access-tags ausdrücklich angegeben werden.

Ein cycleway=lane ohne subtag wäre dann eines von beiden und impliziert keine Aussagen zu Benutzungspflicht und Befahrbarkeit durch andere Fahrzeuge.

Breiten der Radspuren und der Fahrspuren daneben können ja weiterhin angegeben werden.

Muss man für diese Subtags eigenlich wieder ein proposal machen? Mein Englisch ist dafür zu schlecht, glaube ich.

Man muss bei OSM gar nichts.
Ein akzeptiertes Proposal erhöht natürlich die Chance dass sich das Schema durchsetzt.

Der kleine Exkurs diente nur dazu, den Unterschied herauszustellen. Wie ich oben schon schrieb, gibt es beide Streifenarten auch in vielen anderen Ländern. Die Maße dort sind wohl ähnlich, weil sich Fahrzeugbreiten und physikalischen Grundlagen nicht an der Landesgrenze halt machen.

Das sind quasi Wege erster und zweiter Klasse. Daher wird ein taggen nur der Linie dem Ganzen nicht so richtig gerecht. Die Linie ist aber für jeden, der auch wenig Ahnung hat ein gutes Unterscheidungmerkmal. Mal angesehen davon, dass der Linientag eine leicht komplizierte Verkettungen ist. Es ist nur ein Zusatztag, kein anderer Value, was eigentlich schöner ist. So wie im Straßennetz auch eine Art Einteilung direkt per value gibt (primary, secondary, etc.).

Da wir - wenn überhaupt - wohl nur mappen ob der Strich durchgezogen ist oder gestrichelt, könnte man auch line und broken_line nehmen. Schwierig ist es natürlich immer wenn es noch rechts Parkplätze gibt, dann sind die eh kaum zu unterscheiden.
Sehe gerade es würde auch gehen mit line und dot, das wäre doch kurz und prägnant.

Das Problem ist, dass auch Radfahrstreifen gepunktet sein können, z. B. auf Kreuzungen, nur ist der Radfahrstreifen-Strich breit und der eines Schutzstreifens schmal. Wenn man also den Strich mappen will, müsste man auch die Breite des Striches mapppen um herauszubekommen, ob die Straße Radfahrstreifen hat oder nicht. Wer wird das machen?

Ich finde daher ein neues Tag für (durchweg) überfahrbare Streifen besser, entweder als top-level-tag oder als subtag.

Also, wir haben

cycleway:lane = soft_lane/hard_lane

vs

cycleway:lane:markings = dashed/line

Nach Jochens letzten Argumenten, finde ich auch seinen Vorschlag leicht besser als Simons. Ich fasse zusammen:

  • Key hat etwas handlicheren namespace
  • zwar ist “soft” und “hard” nicht getaggt-wie-gesehen, was der Vorteil von Simons Vorschlag ist, aber das möchte man auch nicht direkt, denn Fahrradspuren mit sonst durchgezogenen Markeriungslinien sollen nicht an Einfahrten und Kreuzungen als “soft lane” getaggt werden, nur weil die Markierungslinie dort gestrichelt ist. Ein markings-tagging würde jedoch suggerieren dass das gewünscht ist.

Die aktuelle Verwendung spricht für Vorschlag (a).
cycleway:lane = soft_lane ist 26 mal in der DB.

Simon, hat dich das Argument überzeugt? Wenn ja, was ist jetzt eigentlich der nächste Schritt um das offiziell zu dokumentieren? Wir haben den Fehler gemacht, das jetzt nur im deutschen Forum besprochen zu haben.

warum nicht cycleway=lane/soft_lane? Also so wie das proposal?
Subtags finde ich eher nicht so schön. Das Argument, dass es für Verwender der Daten schlechter geeignet ist, kann ich nicht nachvollziehen. Denn man will eher eigene Radfahrstreifen heruasfiltern, anstatt gleichzeitig die richtigen Streifen zusammen mit einem Zwischending von Linie und gemeinsamer Nutzung.
Bei anderen cycleway-values gibt es meines Wissens auch keine Unterscheidung.

Es hindert ja niemand daran, den Vorschlag des Proposals zu verwenden. Vielleicht setzt es sich schnell durch.
Laut TagInfo sind es erst 22 (Seite 2).

Äh wieso, das haben wir doch jetzt die ganzen letzten Seiten ausdiskutiert. Das bringt jetzt nichts, **ein **Argument gegen ein top-level Tag herauszuziehen und es als “nicht so signifikant” zu deklarieren und gleichzeitig als Argument gegen ein Subtag anzuführen, dass es “nicht so schön” sei. Wenn du das jetzt wirklich nochmal anstoßen musst, dann bitte auf sämtliche bisher genannten Argumente Bezug nehmen.

Naja, vielleicht sind die Hauptargumente gegen ein Top-Level-Value auch bei dem ganzen Text hier im Thread unter den Tisch gefallen:

  1. Proposal wurde abgelehnt

  2. Für mich das Killer-Argument: lane-Value gibt es schon. Man muss davon ausgehen, dass viele die bisher als lane getaggt wurden, nach Einführung eines solchen Values eigentlich soft_lanes sind. Das bedeutet, die Einführung eines top-level-values neben *lane * ändert die Definition von lane. Was ist daran so schlimm? Es macht auf einen Schlag alle bisher als lane getaggten Wege potentiell falsch. Es müsste dann also jeder so getaggte Weg überprüft werden, ob er nun “wirklich” lane ist, oder soft_lane. Es wird noch schlimmer: Wie soll ein Surveyor eine schon überprüfte korrekt getaggte lane von einer lane die noch nicht überprüft wurde und potentiell falsch ist unterscheiden? Es geht nicht!

Wem das bekannt vorkommt, der weiß um das cobblestone vs sett Problem, das ist genau die gleiche Geschichte: Erst gabs nur *cobblestone *für jegliche Art von Steinpflaster, dann hat jemand sett (=Steinpflaster aus behauenem Stein, also praktisch 99% aller Steinpflaster) hinzudefiniert. Bis heute ist es bei einer cobblestone-Straße deswegen unmöglich, herauszufinden, ob sie “wirklich” eine Straße aus unbehauenem Stein ist oder nur noch nicht “korrekt” in sett umgetaggt wurde.
Nun endlich hat sich nach langem hin- und her eine Lösung gefunden, und das ist, den expliziten Value unhewn_cobblestone einzuführen, der dazu genutzt wird, *cobblestone *langsam durch entweder *sett *oder diesen zu ersetzen.
Also, die Moral der Geschichte: Keine neuen Top-Level values definieren die zur Umdefinition bestehener Values führt! Lasst uns aus unseren Fehlern lernen.

Die Transition von farm nach *farmland *und *farmyard *ist zum Beispiel gut gelaufen, und zwar weil der alte Value, der beides beinhaltete, durch zwei speziellere ersetzt wurde. Nur einen hinzufügen und den alten so lassen, führt nur zu Problemen.

Also, wenn man einen neuen Top-Level-Value für soft_lane einführen wollen würde, müsste man gleichzeitig einen für hard_lane einführen und somit lane nach und nach ersetzen.

**Edit: **Nach GeorgFausBs Kommentar korrekt “Values” im Text benutzt, statt “Tags”.

Es wird irgendwie nicht übersichtlicher, wenn alle von Tag(s) reden - der Eine aber den key, und der Andere den value meint …