Verwirrung und widerspr. Wiki-Angaben bei Radstreifen/lanes [solved]

Liebe Community,

ich hatte vor einiger Zeit hier begonnen, um die Ecke die Radfahrerführung detaillierter darzustellen. Dabei geht es um die Radwege von und zur Universität, die für außenstehende manchmal doch sehr verwirrend sein können, daher will ich die Radführung in der OpenCycleMap abbilden.

Völlig klar ist: Radwege auf einer Fahrbahn sind Teil einer Fahrbahn und werden nicht getrennt gezeichnet (kein Spurmapping, das hab ich schon gelernt). Getrennt gezeichnet werden darf nur, was baulich auch getrennt ist. Getrennt gezeichnet werden muss nicht zwingend, es kann auch über bicycle=use_sidepath gekennzeichnet werden.

Zum Thema, wie solche Streifen, die u.a. überfahrbar sein können, wurde meine erste Frage hier zu überfahrbaren Radfahrstreifen von kreuzschnabel u.a. wie folgt beantwortet:

Diesen Abschnitt habe ich dann wie auf folgendem Screenshot zu sehen kaum verändert - es passte ja zur Beschreibung, lediglich die Position und Länge angepasst.

Es ist allerdings auch zu sehen, dass JOSM hier beine Warnung ausgibt, dass die lanes=3-Angabe nicht zu den 4 Fahrspuren passt. Diese Warnung habe ich nach Hinweis in der ersten Frage dann gekonnt ignoriert, was mir erst einmal nicht gefällt.

Jetzt wirds aber erst witzig, es finden sich nun im Wiki widersprüchliche Angaben.

Der deutsche Eintrag zum Lanes-Schlüssel besagt:

Der englische Eintrag hierzu sagt allerdings

Das zieht sich auch bis zum Beispieleintrag zum Erfassen überfahrbarer Radstreifen. Im deutschen Artikel ist hier von 3 Fahrspuren die Rede, im englischen Artikel hingegen steht lanes=4.

Auch hier wird das lanes-Attribut für Radverkehrsanlagen vorgeschlagen, was wiederum dem deutschen lanes-Eintrag widerspricht.

Eine andere Unklarheit, die sich daraus ergibt, ist die folgende:

Hier habe ich bisher nur cycleway=lane durch cycleway:right=lane ersetzt und die Richtung markiert, allerdings kämpfe ich auch hier mit dem lanes=1-Attribut. Dies widerspricht eventuell dem englischen Wiki-Artikel, denn es müsste dann lanes=2 heißen, was man aber einfach so gar nicht eintragen darf (siehe Beispiel weiter unten, was dann passiert). Für mich ergeben sich nun drei Möglichkeiten, wie das lanes-Attribut verwendet werden kann:
**a) Gar nicht. **highway=trunk_link und cycleway:right=lane zusammen sagen aus, dass es sich um eine Straße mit einem Radfahrstreifen handelt. Würde auch hierzu passen.
b) Man erfasst beide Fahrspuren mit lanes=2, dann aber konsequent zusammen mit vehicle:lanes=yes|no und bicycle:lanes=no|designated, wie auch der überfahrbare Radstreifen im Beispiel im englischen Wiki gekennzeichnet wurde.
c) Exakt so, wie es gemacht wurde, dann könnte man zusätzlich bicycle=no setzen, denn die Beschilderung sagt, dass auf dem eigentlichen highway=trunk_link nicht radgefahren werden darf, sondern nur auf dem cycleway=lane.

An anderer Stelle ist ein Radstreifen wie folgt erfasst:

Was ich hier vermisse, ist das unter b) erwähnte access-Tag, welches festlegt, dass die dritte Fahrspur nicht mit Fahrzeugen befahren werden darf, also vehicle:lanes=yes|yes|no. Das hat zur Folge, dass OSMAND hier beim Fahren drei Fahrspuren anzeigt, da ja lanes=3 gesetzt ist und keine Beschränkung für vehicle vorhanden ist:

Tatsächlich gibt es aber hier, wie auf dem JOSM-Screenshot zu sehen, nur zwei Fahrspuren für Autos, die falsche Anzeige bei OSMAND hat also einen Grund.

Ich finde das relativ schlecht, wenn sich solche widersprüchlichen Angaben im Wiki finden. Sehr gerne würde ich diese nun einfach ändern, aber ohne Rücksprache mit euch wollte ich da nicht einfach rumradieren. Ich erkenne nun drei sinnvolle Methoden, einen Radstreifen zu erfassen:

a) Als Zusatzangabe zu highway=… mit cycleway=lane oder detaillierter; ohne Angabe von lanes - dies steht so bereits als Beispiel im Wiki
b) Als eigene Fahrspur, die zu lanes dazugezählt wird, konsequent mit vehicle:lanes=yes|yes|no und bicycle:lanes=no|no|yes und zusätzlich der Angabe cycleway=lane wie im Englischen Wiki beschrieben. Dies ermöglicht auch, die irrsinnigsten Radführungen auf Straßen in Großstätten abzubilden und wird zum Teil schon so gemacht.
c) Eine Mischung aus a) und c), bei der der Radstreifen nicht zu lanes dazugezählt wird, zusätzlich aber durch cycleway(:right)=lane als “vorhanden” bekannt ist.

Nach meinem Verständnis widersprechen sich b) und c) etwas, vielleicht kann ja noch jemand etwas dazu sagen. Die Möglichkeit b) wird gelegentlich verwendet, c) in dieser Form auch. Bei b) könnte dann, wenn cycleway=right auch verwendet wird, cycleway=right auch bedeuten, dass sich zusätzlich zu den in b) erfassten Radspuren noch eine weitere Radspur am Fahrbahnrand befindet. “Könnte”, muss aber nicht.

Gemäß dieser Aufzählung würde ich gerne, nachdem das hier diskutiert wurde und keine Einwände herrschen, das Wiki anpassen:

  • Den deutschen Key:Lanes-Eintrag dem englischen anpassen
  • Das Fahrspuren-Tagging-Beispiel ebenfalls dem englischen anpassen
  • Hier bei den Beispielen unter “Radfahrstreifen” die drei oben genannten Möglichkeiten aufzählen, auch einen Hinweis zum Spurmapping an dieser Stelle ich für sinnvoll.

Hmm, langer Post. Hier mal meine Meinung dazu mit Argumenten.

Fahrradspur-Tagging nicht mit (Auto-)spur-Tagging vermischen!

Meiner Ansicht nach darf das cycleway=lane tagging-Schema auf keinen Fall vermischt werden mit dem lanes-Schema (für Autos). Das kann nur zu Inkonsistenzen führen. Gründe:

  1. Für cycleway-lanes gibt es bereits ein eigenes Namespace - cycleway(:left/right):lanes=x. Sowohl das, als auch *lanes *zu nutzen, wäre eine Dopplung der Information. Konkret würde ich das Tagging aus dem ersten Beispiel interpretieren als “es gibt eine Fahrradspur und zusätzlich dazu gibt es auf der Straße eine Spur, auf der nur Fahrradfahrer fahren dürfen”

  2. Vom gesunden Menschenverstand aus betrachtet, hat eine Fahrradspur praktisch nichts gemein mit einer normalen Auto-Spur, außer dass sie auf der gleichen Straße ist. Sie ist viel schmaler, d.h. die Befahrbarkeit ist keine Frage der Verkehrsregeln (wie etwa bei Busspuren), es ist eine getrennte Verkehrsführung. Oder wollen wir auch anfangen, Fußwege die nicht durch eine Bordsteinkante von der Straße getrennt sind, als *lanes *zu taggen? Ich hoffe nicht!

  3. Applikationen die sich nur für Autos interessieren, müssten in einem Schema in dem die lanes auch reine Fahrradspuren beinhalten können, beides interpretieren können, wenn die Schemas miteinander vermischt werden. Ich glaube nicht, dass irgendein Programm das momentan richtig interpretieren würde

  4. Folgend daraus, wäre eine Hineinmischung von Fahrradstreifen in das normale lanes-Tagging praktisch eine Erweiterung/Umdeutung des lanes-Tags. Bestehende Tags umzudefinieren ist aufjedenfall zu vermeiden, denn dadurch werden bestehende Tags plötzlich obsolet bzw. falsch (siehe surface=cobblestone Diskussion, daraus sollten wir lernen)

Ich sehe in dem ersten Beispiel bist du versucht, die Fahrradspur per lanes zu taggen, um abzubilden, dass die Fahrradspur in der Mitte verläuft. Aber man sollte sich die Frage stellen, wozu muss man diese Information überhaupt erfassen (können)?

Mein Hauptpunkt ist, dass man cycleway(:)=*-Tagging nicht mit lanes= mischen sollte, entweder das erste oder das zweite. Das zweite wie gesagt sollte nur genutzt werden, wenn daraus wirklich ein Mehrwert entsteht, denn dieses Tagging fordert mehr Komplexität für Data-Consumer (Applikationen, Editoren) und mehr (Wartungs-)Aufwand, das heißt auch mehr Fehlerquellen, für Mapper.
(Diesen Mehrwert sehe ich grad nicht, aber ich will nicht ausschließen dass es irgendwo Situationen gibt, wo das doch Sinn macht.)

Folglich ist die englische Wiki meiner Ansicht falsch bzw. zumindest aus den angesprochenen Gründen sehr problematisch. Interessant wäre zu erfahren, ob die angesprochene Dokumentation aus einer vorhergehenden Diskussion (Talk-Page etc) entstanden ist, oder ob das ein einzelner sich dazugedacht hat.

Im englischen Wiki steht das aber noch nichtmal seit zwei Wochen so:
https://wiki.openstreetmap.org/w/index.php?title=Key%3Alanes&type=revision&diff=1507052&oldid=1475860

Solch eine Umdefinition vorhandener Tags ist natürlich immer problematisch. In diesem speziellen Fall habe ich den allerdings den Eindruck, dass eine Umdefinition des lanes-Keys mit Anpassung an die Spurdefinition des :lanes Suffixes wohl langfristig das kleinere Übel ist, als die unterschiedlichen Definitionen, was eine Spur ist, beizubehalten. Letzteres ist für die meisten Benutzer völlig verwirrend und wird somit niemals zu konsistenten Daten führen.

Die vorgenommene Änderung im Wiki ist allerdings auch noch keine vollständige Anpassung der Spur-Definition.

Das Proposal zum :lanes Suffix hat aus gutem Grund eine andere Spurdefinition gewählt. Konsequent wäre es jedoch gewesen, den lanes-Key abzuschaffen.

Wenn das in Vorbereitung befindliche Fahrspurtagging von iD tatsächlich irgendwann mal fertig werden sollte, dürfte es die Definitionsunterschiede missachten. Ich hatte auf Github zwar frühzeitig auf den Definitionsunterschied hingewiesen, dennoch hat man einen Anzatz gewählt, der konzeptionell von gleicher Spuranzahl bei lanes=* und :lanes ausgeht und damit auch von der Äquivalenz der Spurdefinitionen. Da stellt sich die Frage, ob die OSM-Community die abweichende
Spurdefinition von lanes=
gegen iD verteidigen will und kann.

Ich werde lanes weiterhin wie gewohnt eintragen, dazu zählen keine Fahrradstreifen, wenn es keine vollständigen (Auto)Spuren sind.

Das Wiki ist ja mehr zur Orientierung :slight_smile: Les ich in der Regel nur, wenn ich mich in ein Thema einarbeiten, die Änderung im englischen wäre mir also nicht mal aufgefallen.
Etablierte und weit genutzte Tags sollten nicht nachträglich umdefiniert werden. Das funktioniert einfach nicht.

Genau. Nun muss man raten, welche der 7.000.000 lanes Angaben in OSM welcher Definition entspricht. :confused:
Mit anderen Worten: Das Tag ist “verbrannt”, wenn man die Definition nicht schnellstens wieder zurück ändert.

Oh da gibts wohl Klärungsbedarf :slight_smile:

Den Ansatz für das getrennte Erfassen von getrennten Verkehrswegen (Auto und Rad) kann ich gut nachvollziehen, das ergibt auch in vielerlei Hinsicht Sinn.

Genau das ist das Problem, welches auch ich damit habe. Diese Interpretation ist durchaus möglich und entspricht dann nicht der Realität.

Situationen, in denen das sinnvoll sein kann, die cycleways in lanes zu erfassen, sind überfahrbahre Radfahrstreifen, oder eine Radfahrerführung zwischen den Fahrstreifen der Autos.
In anderen Fällen, wie bei einem einzelnen Streifen an der Seite, finde ich das lanes-Schema dazu überflüssig und unnötig, da es ja mit cycleway:etc:etc sehr genau mit extrem vielen Details beschrieben werden kann.

Exakt. Zum Kartieren lese ich (wahrscheinlich viele andere) das Wiki, wie Dinge erfasst werden sollen und mache das dann genau so wie es da steht. Denke dass ich nicht der einzige bin, der so arbeitet :roll_eyes:

Wenn es konsistente Daten ergeben soll, wäre das durchaus von Interesse.

Ist mir auch nur aufgefallen, weil es an unterschiedlichen Orten unterschiedlich erfasst wurde. In Wikipedia wechsle ich öfter die Sprache, da die Artikel oft nach Land sehr unterschiedlich mit Informationen gefüllt sind.

Den auf diesem Screenshot zu sehenden Radweg habe ich nun wie folgt erfasst:

cycleway:right=lane
cycleway:right:bicycle=designated
cycleway:right:oneway=yes
highway=secondary
lanes=2
und so weiter...

Mit cycleway:right=lane sollte dann alles gesagt sein, also alles wie gehabt.

Ich muss gestehen: Mit dem lanes-Zeugs habe ich mich noch nicht wirklich beschäftigt …
Mir fällt es nur gelegentlich auf, wenn ich irgendwo Kleinigkeiten, insbesondere bei Radverkehr, ändern will und lasse meist die Finger weg bisher … Aber werde wohl nicht drumrum kommen, mich mal einzulesen …
Aufgefallen ist es mir kürzlich an diesem Knoten, wo es bei lanes=3 ominöse Angaben mit 4 Spuren gab incl. Radspur … Ist das ein konformes Tagging?

Nur noch noch ein kleiner Einwurf:

Da muss man unterscheiden zwischen

  • baulichen und
  • rechtlichen Aspekten.
    Rein baulich sind alle Spuren auf der “Fahrbahn”, was baulich die asphaltierte Fläche zwischen den Bordsteinen bezeichnet …
    Rechtlich sind aber
  • nur die Schutzstreifen (schmale gestrichelte Linie, nur Piktogramme, meist schmaler) Teil der Fahrbahn
  • während die “richtigen” Radfahrstreifen (breite durchgezogene *) Linie, benutzungspflichtig nur mit Blechschild **) ) rechtlich NICHT Teil der Fahrbahn sind, weil die endet an der durchgezogenen Fahrbahnbegrenzungslinie.

Deswegen darf man als Autofahrer letztere nicht befahren, erstere bei Bedarf aber durchaus. Bei Schutzstreifen liegt rechtlich ein Überholvorgang vor, man muss die mind. 1,5 m Abstand aus der Rechtssprechung einhalten, was gerne vergessen wird, weil ja jeder auf den (zu engen) Spuren bleibt/bleiben sollte. Bei Radfahrstreifen ist es rechtlich ein Vorbeifahren, kein Überholen, aber aus anderen §§ raus kommt man eigentlich zu ähnlichen Abständen, wurde gerade in der letzten ADFC-Radwelt vorgerechnet …

*) zum Queren zum Abbiegen sind sie auf Kreuzungen gerne gestrichelt, ändert aber nix am Status.
**) Ohne Blechschild nur mit “Straßenmalkunst” ist es eigentlich nur ein Seitenstreifen, der nicht benutzungspflichtig ist. Hamburg hat da eine andere Rechtsauffassung, für Restdeutschland gilt dagegen die StVO :wink:

Nach der alten und wohl richtigen Definition von “lanes”: Ja. Es sind 4 Spuren, davon 3 “Fahrspuren für Motorisierten Verkehr” oder wie man das auch immer nennen will. Es ergibt auch keinen Sinn, die Anzahl von lanes immer zusätzlich anzugeben, wenn diese nur wiedergibt, wie viele lanes erfasst sind, denn das ergibt sich aus der Anzahl der |||| in den Werten und wäre dann überbestimmt.

Ich beziehe mich rein auf das bauliche, hätte man dazu schreiben sollen. Auf der Karte möchte ich sehen, ob ich auf der gleichen Fahrbahn fahren muss oder nicht. Getrennt gezeichnete Wege sollten in der Realität auch getrennt sein. Hier gibt es z.B. auch Radwege neben einer Straße mit Radstreifen - der Irrsinn wäre dann deutlich, da man auf der Karte bei getrenntem Zeichnen nicht wüsste, welcher Weg nun auf der Straße ist und welcher nicht. Dazu bräuchte es eine Relation und das wäre völlig über das Ziel hinausgeschossen.

Wenn ich auf einer 2-spurigen Straße mit begleitendem Radweg fahre möchte ich keine 3 Spuren im Navi angezeigt bekommen.

Ich habe nun im englischen Wiki eine Diskussionseintrag darüber erzeugt mit Bitte um Klärung.

Ich werde dann, wenn niemand etwas dagegen hat, im Wiki ergänzen, dass also die Radfahrstreifen ausschließlich durch cycleway=lane dargestellt werden und nicht mit lanes am Highway, etwa so:

highway=secondary Die eigentliche Straße
lanes=3 Lanes dieses “highways”, der Lanes-Key bezieht sich auf highway=secondary
cycleway:right=lane Der gezeichnete Way hat ebenfalls noch Radfahrstreifen, hier nur auf der rechten Seite
cycleway:lanes=2 Der Radfahrstreifen hat zwei Fahrspuren für Radfahrer, so könnte man lanes für cycleway nutzen

Nicht zulässig ist, dass die Radfahrspur mittels lanes zum Highway zusammengefasst wird, wenn es sich nicht um erwähnte Kreuzungen und überfahrbare Radstreifen handelt.

Überfahrbare Radstreifen für gemische Verkehrsführung werden so erfasst, wie im Wiki beschrieben mit der lanes-Anzahl strikt für die Fahrspuren der Verkehrsmittel, die auch auf dem eigentlichen highway fahren. Dies ist dann logisch, wenn man sagt, dass Radstreifen dem motorisierten Verkehr nicht zur Verfügung stehen.

Könntest du in deinem Wiki-Diskussionsbeitrag noch das Datum ergänzen? Dann ist es besser zeitlich einzuordnen.
Die Änderung wurde von User Paul Johnson gemacht, siehe https://wiki.openstreetmap.org/w/index.php?title=Key:lanes&action=history. Hast du ihn bzgl. vorausgegangener Diskussion mal gefragt?
Auch die französische Wikiseite hat den bisherigen Stand, d.h. bicycle lanes sind ausgeschlossen.

Erledigt

Hab ihm eben mal eine Nachricht geschickt, mal schauen was dabei raus kommt.

Die Definition von westnorost in #2 deckt sich ja auch damit, ich habe, denke ich, genug Beispiele aufgezählt warum es so sinnvoll war wie es war.

So, ich habe eine Antwort bekommen: Fahrräder sind Fahrzeuge und damit gehörts dazu und dann weitere Ausführungen dazu, denn Radstreifen sind nicht immer hinter dem Bordstein. Falsche Anzeige bei Osmand ist das Problem von Osmand.

Das hilft mir jetzt nicht wirklich weiter. Vor allem bringt das absolut inkonsistente Daten hervor.

Wer ist den für das Wiki zuständig? Falls ein Revert sinnvoll ist?
Ohne Diskussion ein primäres Tag zu ändern ist ja wohl auch nicht ganz konform, oder?

Und wenn Osmand bei inkonsistenten Daten die Hälfte „falsch“ darstellt, ist das eben nicht das Problem von Osmand. Woher soll Osmand wissen, dass das da so und das da anders gemeint ist? Konsistentes Tagging ist die erste Voraussetzung für richtige Darstellung.

–ks

So, ich hoffe ich hab hier nicht zuviel Staub aufgewirbelt, aber das (eigentlich nie vorhandene) Problem scheint gelöst. Jemand hat die Änderungen im Englischen Wiki jetzt revertiert.

Ich war so frei (oder frech?) und habe nun im Wiki die einleitenden Sätze beim rein deutschen Artikel Radverkehrsanlagen kartieren etwas ergänzt um die klare Trennung vom lanes-Schema des highways herauszustellen. Dies ergibt sich zwar, wenn man die lanes-Definition genau liest, war mir aber bis dahin unklar und wurde so nicht erwähnt. Es war wohl auch anderen nicht klar, sonst hätte ich das im einleitenden Posting gezeigten Beispiel so nicht vorgefunden.

Weiter habe ich im englischen und deutschen Wiki bei der Erklärung des lanes-Schema (hier und hier) jeweils einen einzelnen, erklärenden Satz hinzugefügt, warum in diesem Beispiel lanes=3 gesetzt ist, der auch nochmal auf die Lanes-Definition verweist.

Würde mich freuen wenn da nochmal jemand drüberschaut ob das so okay ist. Ich persönlich finde es wesentlich verständlicher so.

Letzte Unklarheit: Hier wird nun vorgeschlagen, den lanes-Key für die Beschreibung von Fahrradwegen zu nutzen fals nötig. Das widerspricht zwar augenscheinlich der Definition von lanes, allerdings nicht beim genauen lesen: Es ist die Rede von “sollen” bzw. “should”. Damit wären folgende beide Beispiele legal, denn der lanes-Schlüssel wird entweder im Namensraum von cycleway oder direkt auf highway=cycleway bezogen verwendet, um Fahrspuranzahl von Radspuren zu beschreiben:

Beispiel 1: Eine Einbahnstraße mit einer Fahrspur und einer Radspur rechts mit zwei Fahrspuren in beide Richtungen

highway=service (oder sonstwas)
oneway=yes
lanes=1
cycleway:right=lane
cycleway:right:oneway=no

Beispiel 2: Eine Einbahnstraße mit einer Fahrspur, baulich getrennt davon ein Radweg mit zwei Fahrspuren:
Linie A (Straße)

highway=service (oder sonstwas)
oneway=yes
lanes=1

Linie B (Radweg)

highway=cycleway
lanes=2

Ist das zulässig? Wenn ja, wird aus allem ein Schuh, wenn nicht, wird es schwer, Fahrspuranzahl von Radwegen zu beschreiben und der Wiki-Eintrag dazu müsste noch angepasst werden.

Edit: Beispiel 1 war an sich schon falsch, angepasst.

Ich halte das cycleway(:left/right):lanes=x Schema in vielen Fällen für völlig unzureichend um die Realität adäquat abzubilden. In der Innenstadt sind die Fahrradstreifen oft nicht am Rand sondern auch in der Mitte oder es verläuft noch eine Busspur oder Abbiegespur außen. Manchmal teilen sich auch Radfahrer und Busse eine Fahrspur. Manchmal gibt es auch eine zusätzliche Abbiegespur und dazwischen verlaufen Autospuren. manchmal wechseln die radstreifen auch plötzlich von links in die Mitte. Wie will man das damit abbilden? Kann mir das jemand erklären? Als Radfahrer will ich genauso, dass der Spurassistent mir rechtzeitig mitteilt, wie ich mich einzuordnen habe. Auch wäre es sicherlich wünschenswert, wenn Autofahrer vom Navi gewarnt werden würden, wenn sie eine Fahrradspur überqueren müssen. Ich fand das lanes-Schema gerade deshalb gut, weil es so universell ist und man nicht für alle Fälle andere Schemata mit völlig unterschiedlicher Syntax anwenden muss. Ich verstehe auch nicht, was an einer fahrradspur vom Grundsatz her anders sein soll als bei anderen Sonderspuren. Der vergleich mit Fuwegen ist völlig daneben, da baulich nicht getrennte Fußwege immer außen verlaufen. Ich habe den Eindruck, dass die Diskussion in erster Linie von Autofahrern und deren Sichtweisen und Bedürfnissen geprägt ist.

I asked the guy on Telegram to revert that change (after he announced his wiki edit). I explained the difference between lanes= and :lanes.
He does not believe me.

Edit: I’ve contacted the mapper via email

Ja, das kann ich nun gern erklären. In den allermeisten Fällen ist es völlig ausreichend, die Radwege seitlich der Fahrbahn zu beschreiben, weil es so viele solcher komplexen Kreuzungen nun doch nicht gibt. Das erspart weiter auch viel Arbeit, da so unter Umständen auf den :lanes-Suffix beim highway durchgehend verzichtet werden kann.

Die von dir eben erwähnten Beispiele hingegen können nur über den :lanes-Suffix am highway erfasst werden, das Funktioniert über den Stil Fahrspur- und Straßenattribute von JOSM übrigens auch sehr gut und übersichtlich. Die Radspuren werden dann nicht beim Hauptschlüssel lanes=* gezählt, aber mit dem Suffix :lanes am Highway erfasst. Damit kann man eigentlich das schlimmste Labyrinth abbilden. Genau das habe ich nun im Wiki ergänzt, da es vorher relativ schwierig zu erkennen war (mMn).

Das lanes-Schema wird ja genau für das von dir erwähnte Beispiel, aber eben auch nur dafür verwendet. Damit sind die Informationen, die Navisoftware benötigt, um das angesprochene anzuzeigen, vorhanden.

Na da möchte ich als Allwetterradfahrer oder “Immerkurbler”, der die Diskussion ja angefangen hat, widersprechen. Ich verstehe auch die Definition und Erklärung, die hier dankenswerterweise in #2 ausführlich erläutert wurde und sehe diese nicht im Widerspruch zu den Bedürfnissen von Radfahrern, die Radverkehrsführung in OSM abzubilden.

Ich habe mal [solved] an den Thementitel angehängt, da die eigentlichen Fragen geklärt sind und auch die Wiki-Einträge revertiert sind.