Falsche Verwendung von cycleway=shared_lane in Deutschland

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.

Okay, also um nochmal den Wikipedia Artikel mit der Übericht rauszukramen:

Hier ist interessant zu lesen, dass die Amerikaner diese soft_lanes tatsächlich dashed bicycle lanes nennen (und nicht etwa umständlicher bicycle lanes with dashed road markings). Quelle.

Daher, denke ich, dass ein guter Kompromiss doch wäre, statt *hard *und soft:

cycleway:lane = dashed / solid

zu nehmen. Was denkt ihr?

Ich finde die Idee, es über subkeys zu machen zunehmend schlechter. Dann haben die beste und die schlechteste Radverkehrsführung den gleichen top-level-value! Das Unterscheiden beider wird auch künftig nur zu Teilen gelingen, weil eine recht große Anzahl der Mapper sich auch künftig nicht den Aufwand macht, subkeys zu mappen.

Es ist ja gerade das Hauptanliegen, dass man Schutzstreifen erkennbar macht, damit man sie z. B. für seine Fahrradtour meiden und Radfahrstreifen und Piktorgrammspuren dagagen bevorzugt auswählen kann.

Grundsätzlich gebe ich dir Recht. In diesem Fall sehe ich das aber genau umgekehrt.

Versetz dich in jemanden, der Schutzstreifen meiden will. Nach Einführen des Subkeys ‘cycleway:lane=soft_lane’ sind alle bislang mit ‘cycleway=lane’ markierten Schutzstreifen falsch bzw. wertlos, da nicht unterscheidbar von Radfahrstreifen.

Auch nach dem Einführen eines top-level-values ‘cycleway=soft_lane’ sind die bislang als ‘lane’ getaggten Schutzstreife2n für ihn falsch.

Es ist also erstmal kein Unterschied, ob man ‘soft_lane’ als top-level-value oder sub-value einführt. Längerfristig wird sich aber ein top-level-tag schneller durchsetzen. Ein sub-level tag wird aufgrund der menschlichen Faulheit dazu führen, dass das Problem größer bleibt als bei top-level-tags.

Der Vergleich von ‘lane’/‘soft_lane’ mit ‘cobblestone’/‘sett’ hinkt etwas, denn für Schutzstreifen wird heute - zumindest dort wo ich unterwegs - bin meist nicht ‘lane’ getaggt sondern ‘shared_lane’. Das ist so als hätte man behauene Pflastersteine vor Einführen von ‘sett’ als etwas ganz anderes als ‘cobblestone’ gemappt.

Grüße,
Jochen

Finde ich keine so gute Idee, denn auch Radfahrstreifen haben über große Längen unterbrochene Linien. Da viele Mapper Luftbilder abzeichnen wirst du viele Radfahrstreifen mit cycleway:lane = dashed bekommen. Die eigentlich gewünschte Unterscheidung Schutzstreifen (schlechteste Radverkehrsführung) zu Radfahrstreifen (nahezu beste Radverkehrsführung) wird so nicht möglich sein. Du müsstest auch die Dicke der Linie mitmappen, das wird aber nur ein Bruchteil der Mapper machen.

Drum finde ich soft_lane/lane schon besser, auch wenn ich als Deutscher da eher an Softeis denke, also an etwas weiches. :slight_smile:

So wie ich der Diskussion gefolgt bin, wird eine Unterscheidung zwischen einem echten Fahrradweg gesucht und einem Streifen, der nur so tut. Hart und weich kann ich darin nicht erkennen, nicht mal den Gedanken dahinter, bzw. ob das in englisch Sinn macht. Wie wäre es mit true und like?

edit: wobei lane=true ist auch doof, vielleicht wirklich einfach beschreiben was es ist.
lane=declared (um das designated zu umgehen) und lane=shared