Falsche Verwendung von cycleway=shared_lane in Deutschland

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 …

Nein.

Ich bin nicht grundsätzlich dagegen, die rechtliche Ausprägung der Nutzung der Streifen zu mappen, nur braucht das

a) bessere Werte: hard und soft gehen gar nicht (es käme überhaupt nur in Deutschland jemand in den Sinn einen aufgemalten Strich auf der Strasse als “hard” zu bezeichnen weil das Gesetz sagt das man da nicht mit dem Auto fahren sollte). Es würde auch sofort zu Missverständnissen führen da “hard” eine physische Barriere impliziert, und nicht einen Gestzesparagraphen.

b) man wenigsten eine grobe Klassifikation der verschiedenen (globalen) rechtlichen Situationen macht, zum sehen wieviele substantiell verschiedene Varianten es gibt und ob man mit 2 Hauptwerten überhaupt das genügend gut abbilden kann (shared_lane gibt es ja bereits und muss ev. nicht ersetzt werden).

Simon

Da niemand wei0, wieviele Schutzstreifen bisher statt mit lane mit shared_lane getaggt wurden, haben wir den Kuddelmuddel jetzt schon.

Und hier ist immer die Rede von der Unterscheidung der ZWEI Streifenarten in .de, aber in der schon verlinkten Liste gibt es tw. DREI Arten. Wenn man was macht, sollte man es doch mal richtig machen, mit dem man alle Varianten dieser Liste abbilden kann … Sonst verschieben wir den Kuddelmuddel nur ins Ausland …

Ja ok, “Killer-Argument 2” hat mich jetzt auch überzeugt. :slight_smile:
Und man bräuchte nicht für Einbahnstraßen ebenfalls neue Tags (values) cycleway=opposite_lane/opposite_soft_lane/opposite_buffered_lane/opposite_protected_lane/etc.

Habe wie Simon auch bedenken, ob “hard” und “soft” die richtigen Wörter sind. Bin aber kein Englisch-Crack, der das angemessen beurteieln kann.

Die Auflistung aus Wikipedia die hier schon mal gepostet wurde kann ja schon mal für einen Anfang einer Klassifikation der verschiedenen lane-Arten dienen.

Ich weiß nicht, wie es in anderen Ländern ist, aber die beiden Einbahnstraßenschilder 220 und 267 gelten in unserer StVO explizit nur für die Fahrbahn.

Bevor die Freigabe von Einbahsntr. Eingang in die StVO fand, behalf man sich mit “hard_lanes”, weil die wegen der Fahrbahnbegrenzungslinie den Radstreifen rechtlich aus der Einbahnstr. rausnahmen, denn sie liegen ja so nicht mehr auf der Fahrbahn … Winkelzüge des deutschen Straßenverkehrsrechts … :roll_eyes:
Mit Einführung der Freigabemöglichkeit eigentlich überflüssig geworden.

“soft_lanes” darf es dagegen als Gegenrichtungsfreigabe eigentlich nicht geben, denn bei der implizierten Mischnutzung kämen einem ja Autos auf der Spur entgegen … Ich kenne das nur an den (vom Auto aus gesehen) Ende von Einbahnstr. quasi als Hinweis, dass sich Linksabbieger nicht nach ganz links einordnen mögen, wie es § 9 eigentlich vorschriebe, weil es ja doch Gegenverkehr in die Einbahnstr. rein gibt. da haben die Streifen eher die Funktion einer etwas verschobenen Mittellinie, nicht unbedingt mapwürdig …

In Einbahnstraßenrichtung mag es dagegen durchgehende Schutzsreifen geben. In glaub Soest erlangte mal eine Berühmtheit, weil dieser Radler zu mehr Abstand zu Parkern animieren sollte und gegen enges Überholen, weswegen er in der Einbahnstr. quasi mittig drin lag. Wurde irgendwann von einer übergeordneten Behörde entdeckt und untersagt. Aktueller Stand unbekannt.