Talk:Berlin/Verkehrswende/Radwege

From OpenStreetMap Wiki
Jump to navigation Jump to search

Filing cabinet icon.svg 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#valuesTordans (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 [1]
Frankfurter Allee stadteinwärts Samariterstr. Proskauer Straße Friedrichshain-Kreuzberg 400 [1]
Gitschiner Straße / Skalitzer Straße beidseitig Hallesches Tor Kottbusser Tor Friedrichshain-Kreuzberg 3500 [1]
Hallesches Ufer einseitig Hallesches Tor Köthener Str. Friedrichshain-Kreuzberg 1300 [1]
Kottbusser Damm / Kottbusser Straße beidseitig Kottbusser Tor Hermannplatz Friedrichshain-Kreuzberg 2430 [1]
Lichtenberger Straße beidseitig Holzmarktstr. Strausberger Platz Friedrichshain-Kreuzberg 960 [1]
Petersburger Straße beidseitig Bersarinplatz Landsberger Allee Friedrichshain-Kreuzberg 1750 [1]
Tempelhofer Ufer / Waterloo-Ufer einseitig Schöneberger Str. Zossener Str. Friedrichshain-Kreuzberg 1650 [1]
Schöneberger Ufer einseitig Potsdamer Brücke Köthener Str. Mitte 580 [1]
Danziger Straße beidseitig PrenzlauerAllee Danziger Straße 144 Pankow 1800 [1]
Attilastraße Röblingstraße/Gersdorfstraße Ringstraße Tempelhof-Schönberg [1] zuletzt noch nicht umgesetzt
Steglitzer Damm Bismarckstraße Munsterdamm Steglitz-Zehlendorf [1] zuletzt noch nicht umgesetzt
Adlergestell Rudower Chaussee Fennstraße Treptow-Köpenick [1] zunächst bis zum 31. Dezember geplant
Blaschkoallee Britzer Damm Buschkrugallee Neukölln [1]
Zossener Straße Zossener Brücke Blücherstraße Friedrichshain-Kreuzberg Friedrichshain-Kreuzberg [1]

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

In OSM? Straße Bezirk Quelle Anmerkungen
Körte-/Grimm-/Mariannenstraße Friedrichshain-Kreuzberg [2]
Palisadenstraße Friedrichshain-Kreuzberg [3] 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)