Talk:Berlin/Verkehrswende/Radwege

Archiv

Messen von Radwegbreiten: Auch die Linie?

Was genau gehört zur Breite? Auch die Linie? Das wurde an der Oberbaumbrücke ja viel diskutiert. --Tordans (talk) 17:08, 10 January 2020 (UTC) [ >> betrifft auch buffer:*]

Ich dachte, in OSM wird immer von der Mitte der Linie aus gemessen. Finde aber gerade keinen Wikibeleg dazu. Dementsprechend würde ich auch "von der Mitte der Begrenzungslinie" aus messen. --Supaplex030 (talk) 21:17, 13 January 2020 (UTC)

Ich hatte bisher zwischen den Linien gemessen, die Linie darf ja eigentlich nicht befahren werden. Die durchgezogenen sind bei uns ca 25 cm breit und bilden damit den minimalen Puffer ab. Andererseits kommt es ja auch nicht auf ein paar cm an und in der Verwaltungsvorschrift zur StVO finde ich dann sogar Radfahrstreifen (einschließlich Breite des Zeichens 295) möglichst 1,85 m mindestens 1,5 m. Ich überlege zur Zeit ob ich in die Vorlage nicht mit einer Combobox feste Stufen angebe, damit da auch geschätzt werden kann. -- Gisbert (Gmbo) (talk) 08:50, 30 October 2020 (UTC)

Beleuchtung von Radwegen

Gilt ein Radweg auch als beleuchtet, wenn die Straßenlaternen auf der gegenüberliegenden Seite stehen? Beispiel: Thomasstraße zwischen Mittelweg und Selkestraße. Oder anders: Wie dunkel muss es werden, um nicht mehr als beleuchtet zu gelten? Ich tendiere dazu, "yes" nur dann zu verwenden, wenn es auch wirklich Laternen auf der Seite des Radwegs gibt (es sei denn, es ist trotzdem wirklich hell). --Supaplex030 (talk) 21:17, 13 January 2020 (UTC)

protection: Value für Leitboys?

Welchen Wert für "Leitboys" (s.u., Pictures) verwenden? --!bm (talk) 13:09, 4 February 2020 (UTC)

hier noch mal die Bilder: #1 & #2

• Wie wäre es mit "cone" - das könnte dann auch z.B. für Verkehrskegel oder ähnliche "kleinere" und "flexiblere" Arten des Schutzes verwendet werden. Also nicht zu spezifisch, aber klar ein anderer Klassenbegriff als feste, massive, hohe Poller. --Supaplex030 (talk) 16:22, 6 February 2020 (UTC)
  • cone meint doch Kegel, die Leitboys sind ja flach, bestenfalls ein Kegelstumpfschnitt --!bm (talk) 22:11, 1 April 2020 (UTC)

Ich hab schon vergeblich versucht herauszufinden, wie man "Leitboy" (bzw. diese Art Verkehrsbake(?)) auf englisch bezeichnen würde... Hast du noch ne Idee oder Kontakte zur englischsprachigen Verkehrscommunity? :) --Supaplex030 (talk) 09:16, 2 April 2020 (UTC)

cycleway=opposite ist ungünstig und sollte nicht mehr verwendet werden

Wir sollten von cycleway=opposite abraten und die entsprechende Wikiseite (insbesondere die deutsche, aber evtl. auch die englische) aktualisieren. cycleway=opposite ist überflüssig, da die gegenseitige Befahrbarkeit durch Fahrräder besser durch oneway:bicycle=no gekennzeichnet werden sollte. Das ist auch im englischen Wiki so vermerkt. cycleway=* kann dann genutzt werden, um die tatsächliche Infrastruktur zu kennzeichnen (z.B. cycleway:both=no, wenn es keine gibt). (Siehe auch Talk:Tag:cycleway=opposite.) --Supaplex030 (talk) 19:29, 19 January 2020 (UTC)

Mappen von Gefahrenstellen?

Vielleicht in dem wir objektivere Einträge wie hazard=tree_root mappen? Beispiel https://www.openstreetmap.org/node/983512225 / https://taginfo.openstreetmap.org/keys/hazard#values —Tordans (talk) 08:16, 7 July 2019 (UTC)

• Finde ich ne gute Idee! Neben Wurzeln und Schlaglöchern wäre das auch ideal, um baulich gefährliche Stellen zu markieren, beispielsweise wenn Objekte die Sicht auf potentiell in den Radweg laufende Passanten versperren. Mir fällt spontan diese Stelle ein. --Supaplex030 (talk) 21:27, 13 January 2020 (UTC)
  • Sehe gerade: hazard:bicycle=* ist dafür bereits in Gebrauch! Bisher nur wenige "brauchbare" Einträge... U.a. "door_zone", "busy_road" (für gefährliche, radweglose Straßen?) oder "tracks" (für die Überqueerung von Schienen?). Dazu könnten wir ja mal Vorschläge für klassische Gefahrenquellen sammeln und dokumentieren. --Supaplex030 (talk) 19:12, 23 January 2020 (UTC)
    • Vorschlag: Weitere hazard:bicycle=* Einträge:
      door_zone (Radwege/Radschutzstreifen ohne aussreichenden Sicherheitsabstand zu parkenden KFZ)
      diversion (Für Radwege, welche abrupt verschwenkt werden)
      cycleway_end (Baulicher Radweg endet im Nichts)
      public_transport_platform (Radwege, die durch den Wartebereich bzw. Ein- und Ausstiegbereich einer Haltestelle geführt werden.)
      pothole (Schlagloch)
      --Mlvln (talk) 12:33, 3 February 2020 (UTC)

Weitere Taggingfragen

• Wo werden die seperaten Radwege an Kreuzungen angeschlossen wenn ein Übergang zu Radwegen auf der Fahrbahnlinie stattfindet? Direkt am Kreuzungspunkt der beiden Fahrbahnlinien? --Mlvln (talk) 15:05, 7 February 2020 (UTC)
• Wie werden Ampeln, bzw Radfahrampeln und die Überquerungsmöglichkeiten bei seperaten Radwegen erfasst? Macht es sinn Tags wie highway:crossing, crossing=island, crossing:island=yes, traffic_calming=table zu übernehmen? --Mlvln (talk) 15:05, 7 February 2020 (UTC)

Dafür sollten wir bei Gelegenheit mal das Mapping einer Kreuzung anhand einer schematischen Darstellung demonstrieren... Separate Radwege sollten dabei die Straßenlinie nicht in der Mitte, sondern dort, wo sie tatsächlich die Straße überqueren, kreuzen (siehe https://www.openstreetmap.org/way/778654436). Ampeln, Verkehrsinseln etc. am besten auch taggen, soweit sie Teil des Radwegs sind. Statt highway=crossing würde ich Linien mit cycleway=crossing (vgl. auch Abbildungen in footway=crossing) empfehlen... --Supaplex030 (talk) 09:28, 2 April 2020 (UTC)

Zu diesem Thema habe ich begonnen, Kreuzungsbeispiele unter crossing-Beispiele-Berlin zu sammeln - leider nicht unbedingt mit der einfachsten Kreuzung angefangen ;) Ich versuche noch andere Beispiele zu skizzieren. --Supaplex030 (talk) 16:33, 17 April 2020 (UTC)

Assoziation zwischen separaten Radwegen und zugehöriger Straße

Bei separat gemappten Rad- wie auch Gehwegen werden in der bisherigen Mapping-Praxis meist keine Bezüge zwischen diesen Wegen und der zugehörigen Straße hergestellt. Für Routing-Algorithmen ergibt sich daraus das Problem, dass Straßeneigenschaften, insbesondere Straßennamen oder Straßentyp (z.B. Anwendungsfall "meiden von Hauptstraßen"), diesen Wegen nur schwer oder gar nicht zugeordnet werden können. Hier eine Sammlung von Möglichkeiten, um separaten Radwegen die zugehörige Straße (oder zumindest deren Namen) zuzuordnen:

	Vorteile	Nachteile
street-Relation, die Straße und alle begleitenden Wege enthält (z.B. umgesetzt in Lübeck)	alle Objekte entlang der Straße sind dieser klar zugeordnet aus den Tags der Relation lassen sich Eigenschaften der Straße einfach abfragen, die für den gesamten Straßenverlauf gelten (z.B. Straßentyp)	keine eindeutige Zuordnung von Radwegabschnitten zu Straßenabschnitten möglich, daher algorithmisch kaum auswertbar schwer zu handhaben und aufwendig zu pflegen daher schwer für Neulinge zu bearbeiten
zusätzliches einfaches Tag wie associated_street=* am separaten Weg (umgesetzt an Gehwegen in Tampa, Florida: siehe Overpass)	einfach	keine eindeutige Zuordnung von Radwegabschnitten zu Straßenabschnitten möglich, daher algorithmisch kaum auswertbar (andere Straßeneigenschaften wie Straßentyp müssten über räumliche Nähe "gleichnamiger" Linien hergeleitet werden) wenig verbreiteter Tag müsste sich weiter etablieren
name=* am separaten Weg verwenden	einfach	Unterscheidung zwischen Wegen mit wirklichem Namen und "assoziiertem" Namen schwierig daraus resultierend Probleme beim Renderung keine eindeutige Zuordnung von Radwegabschnitten zu Straßenabschnitten möglich, daher algorithmisch kaum auswertbar (andere Straßeneigenschaften wie Straßentyp müssten über räumliche Nähe "gleichnamiger" Linien hergeleitet werden)
Wege geometrisch über zugrunde liegende Flächen verknüpfen (area:highway=*)	andere Straßeneigenschaften können evtl. aus geometrischen Bezügen abgeleitet werden Straßenraumaufteilung wird sehr präzise abgebildet abstraktes OSM-Modell der Linien kann parallel weiter bestehen bleiben (i. d. R. eine Linie pro Straße)	eine Straße "vollständig" zu mappen ist aufwendig Flächentagging wahrscheinlich noch nicht verbreitet genug, als dass Routing-Algorithmen diese bei Berechnungen berücksichtigen würden Informationen ggf. redundant im abstrakten Modell (Straßen-Linien) und exakten Modell (Straßen-Flächen) mit doppeltem Pflegeaufwand und Risiko von Widersprüchen.
keine Verbindung herstellen, sondern Router oder andere Anwendungen sollen diese bei Bedarf selbst aus Nähe und Parallelität ermitteln	keine weiteren Veränderungen beim Mappen erforderlich	Bezüge kompliziert oder gar nicht zu berechnen, unpräzise und fehleranfällig

Habe ich Möglichkeiten übersehen? Gibt es weitere Vor- oder Nachteile? --Supaplex030 (talk) 21:15, 19 April 2020 (UTC) / edit --Supaplex030 (talk) 19:21, 20 April 2020 (UTC)

Die Diskussion um das Thema hat bereits eine lange Geschichte hinter sich. Im Wiki hat man dazu gute Formulierungen gefunden, siehe unten. Die Empfehlungen hier stehen meiner Meinung nach im Widerspruch dazu. Ich würde vorschlagen und anraten, die Formulierungen aus dem Wiki zu verwenden.

Ich sehe 2 wesentliche Nachteile des Getrennt-Mappings:

• Router empfehlen Umwege, weil das Queren der Straße nicht abgebildet wird.
• Auf Karten wird ebenso dieser Eindruck erweckt, da getrennte Wege ja nur dort angewendet werden sollen, wo es keine/begrenzte Übergänge zur Fahrbahn gibt.
• Wenn Radwege an Kreuzungen verschwenkt werden und andere straßenbegleitende Radwege/Pfade einmünden/kreuzen/ausfädeln geben Router mitunter sehr viele Hinweise "links halten"/"rechts halten", "Abbiegen", in extrem kurzen Abständen - das obwohl man einfach einer geradeaus führenden Straße folgt. Das ist extrem nervend und verwirrend.

Ich würde vorschlagen und anraten, die Formulierungen aus dem Wiki zu verwenden:

"Im OSM-Sinne gilt als bauliche Trennung, wenn man nicht überall zwischen dem Radweg und der Fahrbahn wechseln kann (z. B. Grünstreifen oder Leitplanke)."

"Generell sind getrennte Linien zu verwenden, wenn es baulich nicht möglich ist zu wenden, den Weg zu überqueren oder unmittelbar vom Bürgersteig bzw. Radweg auf die Fahrbahn zu wechseln. ... Ist ein solcher Wechsel kontinuierlich möglich, sollte eher keine separate Linie gezeichnet werden." (https://wiki.openstreetmap.org/wiki/DE:Bicycle/Radverkehrsanlagen_kartieren#Erfassen_der_Linie)

Ich verstehe den Wunsch, die räumlichen Gegebenheiten möglichst nahe zu kommen und Geh- und Radwege genau dort zu mappen, wo sie langgehen. Das sollte aber besser per Flächenmapping erfolgen und nicht indem man parallele, direkt nebeneinander liegende Fahrspuren und Wege als einzelne Linien taggt. Zudem können Angaben der Fahrbahn- und Fahrspurbreiten mit width:lanes=*zusammen mit placement=* am highway helfen, die Geh- und Radwege genauer zu platzieren - ohne eigene Ways (siehe JOSM-Kartenstil Lane_and_Road_Attributes).

Viele Grüße,

--Jo (talk) 20:46, 26 April 2020 (UTC)

Hallo Jo,

besser spät eine Antwort als nie ;) Die Diskussion darum wird zunehmend geführt, wobei dieses Schema hier bewusst zum separaten Mapping motiviert. OSM hat insbesondere in vielen Großstädten, auch außerhalb Deutschlands, ein Niveau erreicht, bei dem separates Mapping meiner Meinung nach deutlich mehr Vorteile als Nachteile entfaltet und Haltungen gegen separates Mappen eine Fortentwicklung bremsen. Statt einen Zustand der Datenbank zu bewahren, der mit diesen Ansprüchen bzw. dieser Detaillierung nicht Schritt halten kann, sollte es mMn darum gehen, Lösungen für die von dir zurecht aufgeworfenen Fragen zu finden (die auch dieses Schema seit seinem ersten Tag begleiten). Einen meiner Meinung nach vielversprechenden Ansatz habe ich gerade in das Schema integriert, siehe hier. Das wir darum in Zukunft nicht herumkommen, zeigt meiner Ansicht nach eine aktuelle Diskussion auf der Tagging ML.

Du hast noch ein "neues" Gegenargument aufgeworfen, was ich ehrlichgesagt nicht als Gegenargument gelten lassen würde: "Wenn Radwege an Kreuzungen verschwenkt werden und andere straßenbegleitende Radwege/Pfade einmünden/kreuzen/ausfädeln geben Router mitunter sehr viele Hinweise "links halten"/"rechts halten", "Abbiegen", in extrem kurzen Abständen". Genau dieses präzise Routing durch komplexe, unübersichtliche, am Besten noch mit speziellen Radwegumführungen ausgestatteten Kreuzungssituationen (in denen solche Ansagen zu erwarten wären) ist mMn ein Vorteil der separaten Variante. Wenn ich dafür häufige Ansagen bekomme, ist es eben so - besser als zu wenige oder ungenaue. Ein Standardfall sind solche Kreuzungen außerdem nicht.

Beste Grüße,

--Supaplex030 (talk) 20:58, 23 September 2020 (UTC)

Hallo Supaplex030,

ich habe Deine Antwort erst jetzt gesehen.

Bei den oben geschriebenen "vielversprechenden" Versuchen der Zuordnung von separat gemappten Radwegen zur Straße fehlt ein entscheidender Nachteil: Es funktioniert nicht. Ich habe das in der Tabelle oben als Nachteile ergänzt.

Zum Micro-Routing:

Verschwenkte Radwege sind kein Ausnahmefall sondern in vielen Städten die Regelbauform an größeren Kreuzungen ("starre Schiene"). Um geradeaus zu fahren biegt man dort innerhalb weniger Meter erst halbrechts ab, danach wieder links. Richtig ist, dass nicht an allen solchen Kreuzungen die Ansagen missverständlich werden. Das hängt von den örtlichen Verhältnissen ab und der Art, wie es gemappt wurde (in Summe: vom Zufall).

Mit einem Fahrrad ist man mit ca. 15-25 km/h unterwegs, dort sollte pro Kreuzung eine, maximal zwei Ansagen kommen (Folgen Sie der "xxx-Straße geradeaus"). Wenn hier Ansagen im 10m-Abstand kommen, sehe ich den von dir genannten Vorteil nicht. Ganz im Gegenteil, es macht dass das Navigieren per Ansagen oft schlichtweg unbrauchbar. Für die optische Darstellung dagegen ist das Micro-Routing durchaus hilfreich, das stimmt.

Die meisten von dir genannten Lösungsansätze verfolgen die Idee, dass der Router das selber lösen kann durch Angabe von Verweisen zwischen Straße und Radweg. Es wäre echt schön, wenn der Router für die Ansagen einfach entlang der Straßenkante routet, sich aber die Informationen aus den seperat erfassten Wegen nimmt. Das ist m. E. aber eine Scheinlösung, die nicht funktionieren wird:

Radwege sind - genau wie die eigentliche Straße - oft in viele einzelne Kanten unterteilt, die nicht anhand des Namens unterschieden werden können. Wenn sich dabei wesentliche Eigenschaften der Radwege ändern, so muss der Router diese Änderung auf die richtige Stelle der Straßenkanten übertragen. Er muss also eindeutig die Änderungen der Radwegeigenschaften auf die Abschnitte der Straße verorten.

Erstes Problem: Straßenkante und seperate Radwegkante sind i. d. R. nicht an den gleichen Stellen geteilt, eine ein-eindeutige Zuordnung zwischen beiden ist daher nicht möglich. Damit der Router die Kanten selber teilt fehlt ihn die Information, wo genau er teilen soll.

Zweites Problem: Der Router kann nicht per Algorithmus ein-eindeutig den richtigen separat gemappten Radwegabschnitt zum zugehörigen Abschnitt der Straße zuordnen, da alle Straßenabschnitte den gleichen Namen haben und ggf. alles in einer Relation liegt.

Ebenso fehlt eine Lösung für die im Getrenntmapping fehlenden Verbindungen des Radweges zur Straße, wo man vom Radweg die Fahrspur wechseln kann, z.B. zum Linksabbiegen oder man aber auf die andere Seite wechseln kann.

Die angebotenen Lösungen funktionieren also alle nicht und sind zum Teil aufwendig und fehleranfällig im Mappen. In all den Diskussionen habe ich bislang keine brauchbare Lösung gesehen.

Trotzdem tut man so, als wären alle Probleme gelöst und wundert sich über die Emotionen, die hochkommen, wenn Mapper anfangen, Spuren oder Radwege getrennt zu mappen. Auch von dir, du erwähnst zwar die Probleme, kannst aber keine praktikablen Lösungen anbieten, empfiehlst aber trotzdemn das Seperat-Mapping. Du bist damit leider nicht alleine.

Das frustriert mich ehrlich gesagt. Leider ist durch die Seperat-Mapping-Community das fehlerfreie Fahren nach Ansagen mit dem Fahrrad schon in vielen Städten kaum noch möglich, meine Hauptanwendung von OSM geht durch dieses Vorgehen nach und nach kaputt.

Du lässt im Beitragsvorschlag deine persönliche Meinung stark durchblicken. Unter "Berlin/Verkehrswende/Radwege", würde ich erwarten, dass hier der Konsens oder kleinste gemeinsame Nenner dargestellt wird.

Exkurs: Das Grundproblem liegt im Widerspruch zwischen zwei gegenläufigen grundsätzlichen Datenmodellen:

• abstraktes Modell mit Linientagging (Abstraktion der Fläche als i.d.R. eine Linie je Straße in OSM)
• topographisch genaue Abbildung mit Flächentagging (jede Straße ist eine in Wirklichkeit und in OSM eine Fläche)

Das erste Modell ist nicht "alt" sondern "anders". Das zweite ist nicht die moderne Ablösung des erstens sondern eine Ergänzung.

Das Getrennt-Mapping von Fahrspuren, Rad- oder Gehwegen ist der Versuch, dass erste Modell "zu vergewaltigen", um es in Richtung zweites Modell zu biegen, ohne sich die Mühe zu machen, Flächen und deren Verbidnungen zu zeichnen. Das hat sicher Mehrwerte, macht aber die algorithmischen Anwendungsfälle des ersten Modells kapputt, weil wichtige Informationen verloren gehen.

Die einzige Lösung ist m. E. das Nebeneinander von Linien- und Flächentagging. Das Linientagging als abstrakte Form (ohne Seperatmapping), das Flächentagging für die exakte Darstellung. Dann kann sich ein Router entscheiden, ob er über die Flächen geht (optische Darstellung) und/oder das abstrakte Modell nutzt (Audio-Naviagation). Dann aber bitte das abstrakte Modell nicht kaputtmachen.

--Jo (talk) 23:52, 16 December 2020 (UTC)

Hallo Jo,

ich bin mir nicht sicher, ob wir aneinander vorbeidiskutieren oder du die "Radikalität" des hier vertretenen Separat-Mappings überschätzt. Tatsächlich kam das Thema Radwegverschwenkung neulich mal auf, aber ich kenne keine Fälle, in denen diese separat gemappt wurden (auch wenn dies – nebenbei angemerkt – immerhin den kleinen Vorteil hätte, das das Routing die zweite Ampel beim Linksabbiegen mit einbezieht, die derzeit meistens verlorengeht). Das lanes-Schema wäre wohl eher ein Ansatzpunkt, um dieses Detail abzubilden.

Hast du mal ein Beispiel für eine Kreuzung, bei der es zu so einer Vielzahl von Anweisungen kommt wie von dir geschildert? Für meinen Geschmack gibt es manchmal sogar zu wenige Anweisungen – siehe z.B. dieses Routing über den Hermannplatz, bei dem der gesamte Platz und die anschließende große Kreuzung mit einer einzigen Anweisung überfahren wird (nebenbei bemerkt: Die einzige überflüssige Anweisung kommt hier gleich am Anfang, wenn sich die Straße aufteilt – wird bei anderen Routern aber ignoriert).

Wie du ja selbst bemerkt hast, haben wir hier nichts Neues erfunden. Im Gegenteil versuchen wir Lösungen/Ergänzungen zu finden, um eine gängige OSM-Praxis zu verbessern, nämlich straßenbegleitenden Wegen (das betrifft Gehwege gleichermaßen) relevante Straßeneigenschaften zuzuordnen – in erster Linie Straßenname und Straßenklassifikation. Alle anderen Straßeneigenschaften sind für den Rad-/Gehweg ohnehin nicht interessant, da sie dort entweder nicht zutreffen oder anders sein können und daher separat erfasst sind. Bei dem hier am Ende des Abschnitts skizzierten Vorschlag muss man dafür keine Kanten zuordnen, denn die beiden genannten Eigenschaften werden einfach übertragen, Router könnten sie direkt auslesen.

Du hast noch das Argument "Straßenseitenwechsel" aufgeführt, was ich oft höre, aber persönlich – zumindest im urbanen Bereich – für irrelevant halte. Von einem Router erwarte ich, dass er mich auf dafür vorgesehenen Wegen zum Ziel leitet, für alles andere habe ich mein Gehirn. Wenn ich dafür einen Umweg bis zur 100 Meter entfernten Kreuzung in Kauf nehmen muss und dann wieder zurück, dann ist das gut so (und wenn ich mit Kindern unterwegs bin oder im Rollstuhl, dann ist das sogar meine zwingende Erwartung an den Router).

Dieses "Problem" wird also erst an sehr langen Straßen ohne Querverbindungen relevant. Möglicherweise ist Separat-Mapping in diesen Fällen ohnehin nicht sinnvoll, hängt halt von den Bedinungen vor Ort ab und welchen Mehrwert man sich dann konkret versprechen würde. Man muss Nutzern aber unabhängig davon zutrauen, dass sie in solchen Situationen in Zielnähe ihren eigenen Kopf benutzen, denn auch ohne Separat-Mapping wird aus den OSM-Daten nicht unbedingt ableitbar, ob es angebracht ist, die Straße direkt zu überqueren oder nicht. Warst du z.B. schonmal in Moskau? Hier könnte sowas potentiell tödlich enden. Auch "künstliche" Querverbindungen habe ich in solchen Fällen schon gesehen (könnte man mit proposed footway=link sogar spezifizieren), finde ich aber höchstens eine Notlösung. Ggf. könnten Router auch auf der gegenüberliegenden Straßenseite enden/einen Zielhinweis ausgeben, wenn der Umweg außergewöhnlich lang berechnet wird (weiß nicht ob es das in der Praxis schon gibt – bei nicht separat erfassten Wegen ist das ja vermutlich der übliche Fall). --Supaplex030 (talk) 13:26, 17 December 2020 (UTC)

Hallo Supaplex,

(ich beginne bei den Einrückungen mal wieder bei 0)

sorry für die Emotionen, war gestern spät.

Ein Beispiel für eine seperat gemappte "starre Schiene" gibt es hier in Darmstadt, wo das Getrenntmapping Standard ist: https://www.openstreetmap.org/directions?engine=fossgis_osrm_bike&route=49.88326%2C8.65891%3B49.88387%2C8.65623#map=18/49.88356/8.65757&layers=C

Das lanes-Schema finde ich eine sehr gute Erfindung. In Verbindung mit den lanes-Style im JOSM macht das auch richtig Spaß und kann jeder z. B. beim Navigieren mit OSMAND nutzen. Problem ist nur, dass das Verlangen nicht befriedigt wird, vom Luftbild exakt abzuzeichnen.

Was das Straßequeren betrifft, so scheinst du v. a. an hoch belastete Hauptverkehrsstraßen zu denken, wo man wirklich nur dort queren sollte, wo es ausgewiesen ist. Das betrifft aber vielleicht 10% des Straßennetzes. Gehwege werden aber selbst an schmalsten Gassen des Nebennetzes seperat gezeichnet. Aber auch bei den normalen klassischen, mittel belasteten innerstädtischen Hauptstraßen ist Queren an jeder Stelle der Normalfall.

Ich kenne jemanden, der läuft tatsächlich zum Queren immer bis zur nächsten Kreuzung - der einzige bisher in meinem Leben. 100-200m Umweg sind für einen Fußgänger schon recht viel, das kommt auch in der Stadt leicht zusammen. Dass OSM durch eine bestimmte Taggingpraxis dort Fehler macht, die Mensch durch Hirn beseitigen muss, ist für mich nicht zufriedenstellend, zumal es eben auch anders geht. Aber ja, oftmals findet der Router einen anderen Weg mit weniger Umwegen, nur halt nicht der beste Weg. Das Problem ist sicher keins von Leben und Tod.

Dass ein Fahrbahnqueren nicht zu empfehlen ist, könnte man beim Linientagging mit einem zusätzlichen Tag leicht kennzeichnen. Umgekehrt ist es beim Seperat-Mapping nahezu nicht möglich, zwischen verschiedene Abschnitten von verschiednenen Kanten anzugeben, dass man dort beliebig queren kann.

Um den seperaten Wegen Name und Klassifizierung mitzuteilen sind die genannten Vorschläge durchaus geeignet, nur wenn die Klassifizierung wechselt, wird es wieder schwierig.

Was nicht geht, ist per Algorithmen aus dem "Getrenntmapping" ein "Zusammenmapping" zu erzeugen, dort trete die von mir genannten Probleme auf. Das wäre aber z. B. für Navigation per Ansage sehr hilfreich, um die Anzahl der Ansagen zu begrenzen.

Viele Grüße, --Jo (talk) 23:40, 17 December 2020 (UTC)

Ich habe nach diversen Diskussionen im Forum Vor und Nachteile gegenübergestellt und im Text verlinkt. Bitte dort auf der Diskussionsseite Hnweise hinterlassen, wenn Vor- oder Nachteile fehlen. Generell halte ich weiterhin für ungünstig, eine der beiden Lösungen zu propagandieren. Jede hat so seine Vor- und Nachteile.

--Jo (talk) 21:54, 24 June 2021 (UTC)

Eigenschaften mehrerer gleichzeitiger Radstreifen an Kreuzungen erfassen

Eine offene Frage: Wie lassen sich verschiedene Eigenschaften von mehreren (nicht separat gemappten) Radstreifen an einer Straße erfassen? Ein Beispiel für diesen Fall ist hier (Mapillary) zu finden: Ganz rechts ein Radstreifen zum Rechtsabbiegen, links davon eine Autospur und dann ein weiterer Radstreifen zum Geradeaus fahren. --Supaplex030 (talk) 13:55, 8 July 2020 (UTC)

Übersicht Pop-Up-Radwege

Hier mal eine Übersicht angeordneter Pop-Up-Radwege und deren Kartierungsstand in OSM (zum Tagging von Pop-up-Radwegen siehe hier):

In OSM?	Straßenzug	Richtung	von	bis	Bezirk	Länge (m)	Quelle	Anmerkungen
✓	Kantstraße / Neue Kantstraße	beidseitig	Messedamm	Budapester Str.	Charlottenburg-Wilmersdorf	7200
✓	Frankfurter Allee	stadteinwärts	Samariterstr.	Proskauer Straße	Friedrichshain-Kreuzberg	400
✓	Gitschiner Straße / Skalitzer Straße	beidseitig	Hallesches Tor	Kottbusser Tor	Friedrichshain-Kreuzberg	3500
✓	Hallesches Ufer	einseitig	Hallesches Tor	Köthener Str.	Friedrichshain-Kreuzberg	1300
✓	Kottbusser Damm / Kottbusser Straße	beidseitig	Kottbusser Tor	Hermannplatz	Friedrichshain-Kreuzberg	2430
✓	Lichtenberger Straße	beidseitig	Holzmarktstr.	Strausberger Platz	Friedrichshain-Kreuzberg	960
✓	Petersburger Straße	beidseitig	Bersarinplatz	Landsberger Allee	Friedrichshain-Kreuzberg	1750
✓	Tempelhofer Ufer / Waterloo-Ufer	einseitig	Schöneberger Str.	Zossener Str.	Friedrichshain-Kreuzberg	1650
✓	Schöneberger Ufer	einseitig	Potsdamer Brücke	Köthener Str.	Mitte	580
✓	Danziger Straße	beidseitig	PrenzlauerAllee	Danziger Straße 144	Pankow	1800
	Attilastraße		Röblingstraße/Gersdorfstraße	Ringstraße	Tempelhof-Schönberg			zuletzt noch nicht umgesetzt
	Steglitzer Damm		Bismarckstraße	Munsterdamm	Steglitz-Zehlendorf			zuletzt noch nicht umgesetzt
✓	Adlergestell		Rudower Chaussee	Fennstraße	Treptow-Köpenick			zunächst bis zum 31. Dezember geplant
✓	Blaschkoallee		Britzer Damm	Buschkrugallee	Neukölln
✓	Zossener Straße		Zossener Brücke	Blücherstraße	Friedrichshain-Kreuzberg	Friedrichshain-Kreuzberg

Darüber hinaus eine Übersicht über Pop-up-Fahrradstraßen:

In OSM?	Straße	Bezirk	Quelle	Anmerkungen
✓	Körte-/Grimm-/Mariannenstraße	Friedrichshain-Kreuzberg
	Palisadenstraße	Friedrichshain-Kreuzberg		vorerst nur Planung

---

Missverständlichkeit in Bildunterschrift

Im Beispiel der "Fahrradschleuse/Fahrradweichen" war die Bildunterschrift "Geradeaus- und Linksabbiegespur (im vorderen Bereich!) für Radfahrende." für mich missverständlich.

Bei mir hat es die Aufmerksamkeit auf den für mich "vorderen Abschnitt" gelenkt, wo es eine gemeinsame Linksabbiegerspur gibt und noch keine Rad-Linksabbiegerspur. Dort ist ist die Linksabbiegerspur für Radfahrer erlaubt. Erst auf den "hinteren Abschnitt" im Hintergrund kommt diese Trennung.

Sprich: Was "vorne" und "hinten" ist, ist je nach Person genau umgekehrt.

Vorschlag: "... (erst kurz vor der Kreuzung)"

Guter Punkt, habe ich gleich so angepasst! --Supaplex030 (talk) 08:41, 17 December 2020 (UTC)

Breitere Diskussion / global verständliche Dokumentation in Englisch

In diesem Taggingschema steckt inzwischen sehr viel Arbeit, und für mich sieht alles sehr gut ausgearbeitet aus. Allerdings steht das alles ziemlich versteckt auf einer eigenen Seite und ist auch nur in Deutsch verfügbar. Auch in anderen Städten gibt es zaghafte Versuche ähnliches zu mappen, allerdings oft mit völlig anderem Tagging. Ich denke daher, dass inzwischen ein guter Zeitpunkt ist, hier in eine größere Diskussion einzusteigen und zumindest die grundlegenden Tags für alle Mapper auffindbar zu machen. --Mueschel (talk) 19:56, 16 March 2021 (UTC)

Da gebe ich dir absolut Recht – wenn es nicht immer so viele Baustellen gleichzeitig gäbe, hätte ich damit vermutlich auch schon begonnen... Meiner Meinung nach wäre es dabei sinnvoll, die Seite in zwei getrennte Aspekte zu trennen: Einmal die Vorschläge zum detaillierteren Mappen von Radwegen an sich, andererseits eine Sammlung diverser fahrradbezogener Infrastrukturen. Allerdings weiß ich nicht, wie und wo man die Diskussion am Besten führen/starten könnte – zumal es sich um eine Mischung aus einer Sammlung bestehender/akzeptierter Tags und Neuvorschlägen/Erweiterungen handelt.--Supaplex030 (talk) 23:00, 16 March 2021 (UTC)

Passierbarkeit von Barrieren/Engstellen (für Lastenräder/Sonderbauformen)

Die Frage, wie man diese – auch in komplizierteren Fällen wie zB bei barrier=cycle_barrier – sinnvoll erfassen könnte, wurde in einzelnen Verkehrswende-Sessions (zuletzt 2021-03-16) zumindest angeschnitten. Bei einfachen Pollern bietet sich hierzu maxwidth:physical=* an. --!bm (talk) 18:38, 27 March 2021 (UTC)

Zur Dokumentation an dieser Stelle auch der Hinweis auf den Vorschlag width:separation, um insbesondere bei Drängelgittern den Abstand zwischen den Stangen anzugeben. Aus diesem Abstand und der "Einfahrtsbreite" des Gitters kann man dann theoretisch für jede individuelle Fahrzeugabmessung (Länge x Breite) berechnen, ob es durchpasst oder nicht – und muss nicht auf eine allgemeine unspezifische Breitenangabe vertrauen, die z.B. für ein schmales, aber sehr langes Gefährt unbrauchbar sein kann. --Supaplex030 (talk) 19:29, 27 March 2021 (UTC)

Breite von Radwegen messen

Hallo zusammen, da ich derzeit die cycleway:width=* der Radfahrstreifen in meiner Umgebung erfassen möchte, stellte sich mir die Frage wie denn die Breite überhaupt für OSM-Zwecke definiert ist. Laut VwV-StVO ist die Breite als "lichte Breite (befestigter Verkehrsraum mit Sicherheitsraum)" definiert, wobei dies insbesondere die durchgezogenen Trennlinien Zeichen 295 (scheinbar auch, soweit vorhanden, die rechte) beinhaltet; ob die Gosse auch dazu zählt, kann ich nicht feststellen. Zumindest von der hiesigen Stadtverwaltung wird sie scheinbar miteinbezogen, da ansonsten nahezu alle, vor allem auch neu angelegte, Radfahrstreifen unter der Mindestbreite von 1,50m lägen.
Was habt ihr in Berlin alles als zur Breite gehörend gezählt? Falls die Gosse nicht dazugehört, könnte es sinnvoll sein, diese in einem separaten Tag zu erfassen? Besten Dank für eure Antwort. --Nw520 (talk) 23:29, 16 May 2021 (UTC)

Radwegbreite

Also zumindest in der Verkehrswendegruppe haben wir darüber mal diskutiert und fanden es sinnvoll, nur die effektiv nutzbare Breite mit cycleway:width=*/width=* zu erfassen. Das heißt, nur die Breite zwischen den Linien etc. (ich kenne auch keine gegenteiligen Diskussionen in der OSM-Community – wobei dieser Präzisionsgrad für die meisten Mapper vermutlich irrelevant ist). Aus Perspektive der Nutzenden dieser Infrastruktur, also Radfahrenden, ist alles andere ja im Prinzip uninteressant (und könnte bei Bedarf höchstens über andere Tags erfasst werden).

Im Kapitel Tagging-Beispiele sind ein paar dementsprechend beschriftete Beispiel-Bilder, z.B. das nebenstehende.

Das mit der Gosse ist ein interessanter Punkt, den wir – wenn ich mich richtig erinnere – noch nicht so explizit diskutiert haben. Wenn sich der Bereich wirklich nicht zum Radfahren eignet (kommt zumindest hier in Berlin eher selten vor), würde ich ihn bei der Breite eher herauslassen. So hab ich es z.B. schon bei Gehwegbreiten gemacht: Wenn da in regelmäßigen Abständen eine Baumscheibe o.ä. ohne Gehwegpflasterung in den Gehweg reinragt, dann hab ich immer nur die Breite bis zur Baumscheibe genommen.

Die OSM-Datenbank kennt schon fast 20.000 mal gutter=*, was vermutlich beschreibt, ob es eine Gosse gibt oder nicht... Vielleicht bietet sich gutter:width=* an, um deren Breite anzugeben..? --Supaplex030 (talk) 13:11, 17 May 2021 (UTC)

Perfekt, vielen Dank. Bisher hatte auch nur die "Hauptbreite" erfasst und die Gosse — die ja nicht selten Straßenabläufe hat, welche für schmale Reifen problematisch sein könnten — ausgelassen. Tagging-Interesse an dieser besteht bei mir nur wegen der scheinbar rechtlichen Relevanz; da ich sie ohnehin von der Radfahrstreifenbreite abziehen muss, kann ich sie auch gleich mit in OSM erfassen. --Nw520 (talk) 13:21, 17 May 2021 (UTC)

Wenn auf einem Radweg eine ernsthafte Sturzgefahr durch Abflussgitter besteht, könnte man auch über einen eigenen Value dafür für hazard:bicycle / Gefahrenstellen nachdenken... --Supaplex030 (talk) 13:27, 17 May 2021 (UTC)

turn:bicycle:lanes

re https://wiki.openstreetmap.org/wiki/Berlin/Verkehrswende/Radwege#Radfahrstreifen_in_Mittellage_.2F_Fahrradschleuse_.2F_Fahrradweichen

re https://wiki.openstreetmap.org/wiki/Talk:Key:turn:bicycle:lanes

What about cases where multiple vehicles can use one lane, and allowed turn direction depends on a vehicle? See case where cyclists and buses can go straight and other vehicles only turn right Note also turn:bus:lanes=* and File:Special turn lane rule for bus.jpg example Mateusz Konieczny (talk) 07:43, 10 October 2021 (UTC)

(Note for other wiki readers: see herefor the follow-up to the discussion.) --Supaplex030 (talk) 08:10, 10 October 2021 (UTC)

turn:lanes für Fahrradspuren OHNE explizite Richtungspfeile – wie angeben?

Erst Mal: ich finde besonders die Beispiele unter unter „Radfahrstreifen in Mittellage / Fahrradschleuse / Fahrradweichen“ sehr wertvoll! In den sechs Beispiel zeigt sich aber etwas, das mir schon öfters Kopfzerbrechen bereitet hat beim Mapping (wie man es angeben soll): es geht darum, dass den Fotos der Beispiele 1, 3 und 5 auf den roten Fahrradspuren keine Markierungspfeile für die Richtung zu sehen sind (soweit das auf den Fotos erkennbar ist). Und trotzdem ist hier bei den Radspuren für turn=* nicht none angegeben ...

Beispiel 3 ist noch ein Sonderfall – und auch ein etwas unglückliches Beispiel, wie ich finde, weil nicht klar ist, ob das Tagging sich auf den Teil der Straße vor der Ampel bezieht (3 :lanes-Spuren in backward-Richtung) oder auf den auf dem Foto am unteren Rand zu sehenden Abschnitt (streng genommen 4 :lanes-Spuren in backward-Richtung). Zudem sieht man Markierungspfeile auf den Radspuren erst, wenn man auf Mapillary-Bilder in der Sequenz ein Bild zurück geht – da sollte das Foto vielleicht geändert werden – ich würde zur Vereinfachung und der Klarheit halber eher das nächste Mapillary-Bild nehmen. Und falls sich das Tagging sich auf diesen Teil der Straße vor der Ampel beziehen soll, wäre bei turn:lanes:backward ein "|" zuviel (statt turn:lanes:backward=through|through||right müsste es dann turn:lanes:backward=through|through|right heißen). So wie das Tagging jetzt ist, gibt es auch eine inkonsistente Anzahl von :lanes-Spuren (3 bei vehicle:lanes:backward, bicycle:lanes:backward und cycleway:lanes:backward, 4 bei turn:lanes:backward) – das würde ich beim Mappen auf jeden Fall vermeiden, und es führt – soweit ich weiß – auch bei manchen Editoren zu einem Validierungsfehler, wie ich denke zurecht. Ich würde immer darauf achten, dass über alle Tags hinweg die Anzahl der :lanes-Spuren an einem Wegabschnitt gleich ist. Und vielleicht sollte man das auch im Wiki noch betonen oder zumindest empfehlen ...

Ich beschränke mich nun aber auf die für meine eigentliche Frage relevanten Beispiele 1 und 5 ...

Obwohl dort also auf den Fahrradspuren keine Markierungspfeile für die Richtung zu sehen sind, ist bei diesen Beispiel bei turn:lanes nicht der dafür eigentlich vorgesehene Wert none angegeben, sondern jeweils die Richtung(en), in die ein Radfahrer auf diesen Spuren fahren darf. Soweit ich den turn=* Tag verstehe, wird damit aber doch wirklich nur die angezeigte Folgerichtung eines Weges oder einer Spur angegeben (so besagt es die deutsche Wiki-Seite; auf der englischen Seite heißt es: „The turn=* key can be used to specify the indicated turn or merge direction for a way or lane.“). Und eben gerade nicht die Richtung(en), in die man fahren darf. turn=* gibt nach meine Verständnis keine Richtungs-Regel an, sondern nur eine Richtungs-Anzeige (auf der Fahrbahn, durch Schilder oder Sonstiges). Oder sehe ich das falsch? Oder will man es hier so taggen, wie eine Richtungsmarkierung eigentlich sein müsste, wenn sie da wäre? Oder weil es sich durch sonstige Fahrbahnmarkierungen (gestrichelte Linie in Vorwärtsrichtung – aber eben ein Stück weiter, vielleicht auf einem separaten Weg-Segment?) ergibt – bzw. zählt das auch als Markierung im Sinne von turn=*? (Auf der englischen Seite heißt es z.B. auch noch: „(...) the turn=* key can be used in any situation where a manoeuvre is signed, marked or otherwise implied by road markings“. Sind das hier also "otherwise implied" Fälle? Und der turn=* Tag soll ja laut Wiki-Seite auch nicht für das Routing relevant sein – ich habe es immer so verstanden, dass er für realistische visuelle Spuranzeigen (oder Ansagen) in einer Routing-Software/einem Navi benutzt werden kann (und für viel mehr nicht), und die tatsächlichen Abbiegebeschränkungen/-Möglichkeiten, die für das Routing zählen, ergeben sich durch Tags an den Anschlussstraßen bzw. durch turn restrictions (Relationen). Somit würde beim jetzigen Tagging eine visuelle Anzeige in einer Routingsoftware/einem Navi nicht mit der Situation vor Ort übereinstimmen, wohl aber klar zeigen, wie man als Radfahrer abbiegen darf – also wie es eigentlich auch als Pfeil-Markierung auf der Straße wünschenswert wäre (und wohl auch in solch einer visuellen Darstellung – und bei einer Sprachausgabe sowieso)! Oder ist das Haarspalterei bzw. so ein dummer Graubereich? Mir ist nicht ganz klar, ob es da eine übliche Art des Taggings gibt (eine stille Übereinkunft? oder wurde das schon mal irgendwo ausdiskutiert?). Vielleicht sollte man da ja auch mal das Wording auf der Wiki-Seite von turn=* überdenken ...

Mein Frage ist also konkret: ist das Tagging für turn:lanes bei den Beispielen 1 und 5 OK und wünschenswert so? Oder müsste es doch nach strenger Auslegung heißen:

• Beispiel 1: turn:lanes=left|none|right
• Beispiel 5: turn:lanes= left|none|through|none|right

Falls es so OK und wünschenswert ist, wie es jetzt ist, sollte man das vielleicht bei den Beispielen noch als Anmerkung vermerken ... vielleicht mit kurzer Begründung ... wäre mein Vorschlag.

--Goodidea (talk) 04:51, 12 November 2021 (UTC)

Interessanter Aspekt – ist mir noch nie bewusst aufgefallen, dass manche Streifen mit Pfeilen markiert sind, aber viele nicht... Andererseits ist die Verkehrsführung auf diesen Streifen implizit, also ergibt sich aus den benachbarten Kfz-Fahrstreifen bzw. ggf. weiteren vorhandenen Radfahrstreifen. Das wäre dann also genau die von dir genannte turn-"Definition" "...otherwise implied by road markings...". Das Ziel hinter diesem Tagging ist ja – wie die englischsprachige Beschreibung gut zusammenfasst – eine Aussage darüber treffen zu können, "wohin man auf dieser Spur geführt wird", und das ist bei diesen Fahrstreifen ja meist deutlich. Das tatsächliche Vorhandensein von bestimmten Markierungen (z.B. auf den Boden gemalten Pfeilen) geht damit nicht einher. Wer das wirklich genau erfassen will, müsste dann wohl über ein spezielles Symbol-Tagging dafür nachdenken, z.B. angelehnt an road_marking=* – ist für so gut wie alle Anwendungen aber mehr oder weniger irrelevant, denke ich.

Zwei der gezeigten Beispiele sind übrigens auch im Bereich der "Neuköllner Straßenraumkarte", einer sehr detaillierten Karte auf OSM-Basis von mir bzw. hier aus der lokalen OSM-Community, die u.a. auch Radfahrstreifen in Mittellage rendert – Pfeile gibt es dort generell bisher nur auf den Kfz-Spuren: Beispiel 1 Beispiel 3

Danke für den Hinweis auf den Fehler in Beispiel 3 – das war aus Versehen und den habe ich korrigiert! Unter den Beispielen gibt es Hinweise, die ich etwas ausführlicher formuliert habe und die nun auch nochmal explizit auf die Anzahl der Fahrspuren eingehen.

--Supaplex030 (talk) 15:54, 12 November 2021 (UTC) P.S. ich werde das Thema mal hier in der Community bei unserem nächsten Verkehrswende-Treffen ansprechen und dann ggf. noch einen Hinweis ergänzen, dass turn:lanes auch ohne Pfeile ok ist oder wie auch immer das Fazit der Diskussion dann ist...

horse ist nicht enthalten in vehicle:lanes

Auf exklusiven Fahrradstreifen sind auch keine Pferde erlaubt, daher verwende ich in meiner Gegend anstatt vehicle:lanes=* lieber access:lanes=*. Was spricht dagegen? --Skyper (talk) 00:49, 1 February 2023 (UTC)

Das ist eine gute Frage - vermutlich wie so oft wurden die armen Pferde bei der ersten Dokumentation (vor immerhin 8 Jahren) einfach vergessen. An sich sehe ich auch nichts, was dagegen sprechen sollte. Wenn du magst, reg doch mal auf der Lanes-Seite (dem Ursprung dieses Schemas) eine Änderung an. --Supaplex030 (talk) 09:25, 1 February 2023 (UTC)

Mal sehen was dabei rauskommt: Talk:Lanes#Were_horses_forgotten_in_vehicle:lanes. --Skyper (talk) 13:50, 2 February 2023 (UTC)

"no" bei bicycle:lanes ist zu restriktiv

Bei Fahrradstreifen wird empfohlen die allgemeine Spur direkt links daneben mit no bei bicycle:lanes=* zu setzten. Dies halte ich für zu restriktiv, da es einige Gegebenheiten und Gründe gibt, wo diese Spur sehr wohl benutzt werden darf. Z.B. wenn der Fahrradstreifen zugeparkt oder nicht von Schnee (Silverstermüll) geräumt ist, aber auch beim Überholen von langsameren Fahrradfahrenden. Analog zu use_sidepath fehlt uns leider bisher einentsprechender Wert (use_sidelane). Daher verwende ich in meiner Gegend lieber yes bzw. einen leeren Wert. --Skyper (talk) 00:49, 1 February 2023 (UTC)

Die access-Values drücken die allgemeine Nutzungsbeschränkung aus, die besagen, dass du in dieser Situation im Allgemeinen auf dem Radstreifen bleiben musst. Wenn der Radstreifen blockiert ist, kannst du ihn natürlich nicht nutzen und musst ggf. ausweichen - das ist aber kein Fall für access-Tags. Auch Überholen ist davon unberührt (ich bin mir nicht sicher wie das Überholen dort geregelt ist, zumindest bei unterbrochenen Linien. Bei durchgezogenen Linien müsste ja sowieso ein Spurwechsel- und Überholverbot gelten. change=* und overtaking=* sind Tags die sowas bei Bedarf genauer ausdrücken können - aber dafür müssten wohl erst die geltenden Regeln "studiert" werden ;) --Supaplex030 (talk) 09:25, 1 February 2023 (UTC)

Schwierig. Nicht umsonst verwenden wir ja auch bicycle=use_sidepath und foot=use_sidepath bei separat eingetragenen Seitenwegen und nicht etwa no. Auch das mit den Spurwechseln bei durchgezogenen Linien ist nicht eindeutig. An Busspuren und Bushaltestellen gibt es häufig nur durchgezogene Linien und trotzdem dürfen Busse da die Spur wechseln. change=* verwende ich natürlich schon, allerdings lasse ich da die Werte bei Spuren mit Nutzungsbeschränkung leer. overtaking=* sollte nur da verwendet werden, wo es auch mit entsprechendem Verkehrsschildern ausgeschildert ist und nicht aufgrund von Fahrbahnmarkierungen. --Skyper (talk) 13:06, 2 February 2023 (UTC)

Wie mehrere Radwege taggen?

An vielen Straßen in Berlin können Radfahrende sowohl die Busspur nutzen als auch einen (meist veralteten) Hochbordradweg. Wie taggt man das korrekt? Meine Idee wäre:

cycleway=share_busway;track (wenn der Hochbordradweg nicht separat gemappt ist), oder
cyleway=share_busway;separate (wenn der Hochbordradweg separat gemappt ist).

Ist das so richtig? --Thom bike bln (talk) 11:47, 6 August 2023 (UTC)

Semikolon-getrennte Werte sind in diesem Fall ungünstig, da sie hier von nahezu keiner Software ausgewertet werden (da diese Schreibweise kein Konsens in der Community ist bzw. nicht dokumentiert ist) und die Daten damit praktisch verloren gehen würden. Meiner Meinung nach sollte einfach cycleway=share_busway an der Straßenlinie und eine separate Radwegelinie für den Hochbordradweg verwendet werden. Auch aus Perspektive vieler Datenauswertungen ist das ausreichend – ein Router kann beispielsweise den "besseren" beider Wege nutzen und der Hinweis auf eine "separate" Geometrie ist ebenfalls verzichtbar, wenn die Straßenlinie selbst auch zum Radfahren genutzt werden kann.--Supaplex030 (talk) 19:57, 11 August 2023 (UTC)