Talk:Berlin/Verkehrswende/Radwege/Archiv

From OpenStreetMap Wiki
Jump to navigation Jump to search

OSM-Daten und ihre Analyse können – bei ausreichender Qualität, Aktualität und Detailtiefe – eine ideale Grundlage sein, um den Ausbauzustand Berliner Fahrradinfrastrukturen zu bewerten, den Fortschritt der Verkehrswende zu beobachten und Infrastrukturmängel aufzuzeigen. Das gilt insbesondere für den Zustand der Fahrradwege. Das entsprechende OSM-Taggingschema ist gut geeignet, die allgemeine Verkehrssituation wiederzugeben – zur Detailkartierung vorhandener Infrastrukturen sehen wir jedoch noch Verbesserungsbedarf, insbesondere bei Daten zur Bewertung der Radinfrastrukturqualität. So gibt es beispielsweise noch kein Schema zum Tagging geschützter Radwege.

Auf dieser Seite sollen offene Fragen und Überlegungen zum Tagging von Radwegen in Berlin zusammengetragen werden, um das Schema zuverbessern, live zu testen und schließlich Tagging Guidelines für Berlin zu entwickeln. Kommentare und Anmerkungen gern ergänzen, möglichst mit Signatur: --~~~~

Tagging von Radwegen und Radinfrastruktur in OSM: Siehe https://wiki.openstreetmap.org/wiki/Key:cycleway und https://wiki.openstreetmap.org/wiki/Bicycle

Unsere Tagging-Empfehlung – WIP

Siehe auch:

Allgemein: Radwege, die durch physische Barrieren von der Fahrbahn abgegrenzt sind, können/sollen als separate Linien gemappt werden. Physische Barrieren können beispielsweise Bordsteine, parkende Fahrzeuge oder Poller sein. Lediglich die Eigenschaften von Radfahr-/Schutzstreifen, die nur durch Linien am Fahrbahnrand gekennzeichnet sind, werden an die Linie der Fahrbahn gemappt.

Tagging-Empfehlungen für separate Radwege

Die hier aufgeführten Tagging-Empfehlungen gelten für separat gemappte Radwege, also Wege, die explizit für den Radverkehr vorgesehen sind.

Tag Value Dringlichkeit Beschreibung
highway=cycleway - Pflicht Haupttag für Radwege.
width=* Zahl in Metern, z.B. "1" oder "2.2". Empfohlen Breite des Radwegs bzw. des für den Radverkehr vorgesehenen Bereichs. Gemessen einschließlich der Begrenzungslinien.

TBD:

  • Empfehlen wir est_width=*? Wie genau ist für uns gut? --Tordans (talk) 17:08, 10 January 2020 (UTC)
Du meinst für die Angabe von Schätzwerten? Würde ich auf den ersten Blick nicht empfehlen, andererseits finde ich eine Schätzung der Breite besser als wenn "width" nur mit einer Schätzung gefüllt wird oder ganz weggelassen wird... Formulierungsvorschlag: "Die Breite sollte durch Messung oder Abschreiten vor Ort oder hochaufgelöste Luftbilder möglichst genau bestimmt werden. Grobe Schätzungen von Breiten können mit est_width=* angegeben werden." --Supaplex030 (talk) 21:17, 13 January 2020 (UTC)
  • 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)
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 habe einmal "width=wide" benutzt an einer Stelle mit breitem Radweg, der nach rechts hin unbegrenzt in eine ungenutzte bzw. Busspur übergeht (https://www.openstreetmap.org/way/764003834). Weiß nicht, ob es sich für solche Fälle als Empfehlung eignet... --Supaplex030 (talk) 21:14, 16 January 2020 (UTC)
surface=* Meist surface=asphalt (Asphalt) oder surface=paving_stones (gleichmäßig geformte Beton-Pflastersteine mit geringen Zwischenräumen. Empfohlen Oberflächenbeschaffenheit/Material des Fahrbahnbelags des Radwegs.
smoothness=* todo Optional Die Oberflächenqualität/Ebenheit des Radweges.

TBD:

  • Ich finde die bestehenden Mapping-Empfehlungen aus dem Wiki, die sich an "Rollenbreiten" orientieren, eigentlich ziemlich gut und objektiv. Wir sollten nur definieren, ob es uns um "theoretisch mögliches" oder "bequemes/angenehmes" Fahren geht. Für mich ist letzteres der klare Favorit, sodass sich in etwa diese Abstufungen/Entsprechungen ergeben:
    • excellent: Glatter, unbeschädigter Asphalt mit sehr guten Rolleigenschaften (Faustregel: Hier könnte man auch gut mit Inlineskates fahren).
    • good: Asphalt (oder andere glatte versiegelte Oberfläche) mit höchstens kleineren Schäden oder Rissen, die keine spürbaren Verwerfungen hervorrufen. Insbesondere ohne Wurzelschäden o.ä. (Faustregel: Hier lässt sich gut Rennrad fahren).
    • intermediate: Im allgemeinen gut befahrbare Oberfläche, auf der aber kleinere Verwerfungen spürbar sind: Beispielsweise Pflastersteine/Kleinpflaster mit geringen Zwischenräumen, Asphalt mit kleineren, seltenen Wurzelschäden, verfestigter Boden oder sehr gut (!) versiegeltes Kopfsteinpflaster (dann auf jeden Fall mit check_date=* versehen :)(Faustregel: Hier kann ich gut mit einem Stadtrad fahren).
    • bad: Deutlich spürbare Verwerfungen oder "Rütteln", z.B. auf üblichem Kopfsteinpflaster, aufgrund zahlreicher Wurzelschäden/Schlaglöcher oder auf unbefestigten Wegen mit Pfützenlöchern o.ä., nicht mehr zum Rennradfahren geeignet, deutlicher Geschwindigkeitsverlust (Faustregel: Beim nächsten Mal kaufe ich mir ein Fahrrad mit besserer Federung - oder gleich ein Mountain Bike...)
    • very_bad: Starke Verwerfungen oder Schäden, nicht mehr zum Radfahren mit City- oder Trekkingrad geeignet bzw. nur mit erheblichem Geschwindigkeitsverlust (Faustregel: Wege, nach deren Befahrung ich dem zuständigen Baustadtrat eine Mail schreibe - und wirklich ein Mountain Bike brauche)
Darunter dürfte es in Berlin, zumindest auf formaler Radinfrastruktur, eigentlich nichts geben ^^ --Supaplex030 (talk) 21:17, 13 January 2020 (UTC)
lit=* yes / no Optional Ob der Radweg beleuchtet ist.

TBD:

  • 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)
oneway=* yes / no Pflicht "yes" bei einspurigen Radwegen in eine Richtung (default), "no" bei Radwegen, die explizit in beide Richtungen befahren werden dürfen (mit Pfeilen auf der Fahrbahn oder mit Verkehrszeichen gekennzeichnet).
incline=* Steigungsprozent oder up / down Optional Spür- und sichtbare Steigung des Radwegs. Nach Möglichkeit in Prozent durchschnittlicher Steigung auf dem Radwegabschnitt angegeben (z.B. auf Grundlage von Höhendaten oder guter Vor-Ort-Messung: 5 Meter Steigung auf 100 Meter Weglänge entspricht 5% Steigung; negative Werte für Gefälle - entsprechend der Richtung der Wegelinie). Wenn kein genauer Wert bestimmt werden kann, kann auch nur "up" (Steigung) oder "down" (für Gefälle) angegeben werden.

(Geologisch: Vor allem relevant an den Steigungen am Rand des Berliner Urstromtals hinauf zur Barnim- oder Teltow-Hochfläche)

TBD:

  • Oder nur up/down? Oder als %-Wert? --Tordans (talk) 17:08, 10 January 2020 (UTC)
Eine Gradzahl würde ich nicht empfehlen: Schwer auszurechnen und vorzustellen/de facto unbrauchbar. Wer die Möglichkeit hat, soll einen Prozentwert angeben, ansonsten nur up oder down. --Supaplex030 (talk) 21:17, 13 January 2020 (UTC)
surface:colour=* "green" (grün), "red" (rot, v.a. an Einfahrten/Gefahrenstellen), "no" (keine besondere Einfärbung), in anderen Ländern/Städten oft auch "blue" (blau) Optional Farbe des Belags. Zunehmend werden auch in Berlin Radwege farblich hervorgehoben, um die Sicherheit zu erhöhen. Hinweis: lediglich colour=* ist irreführend, da das manchmal für abstrakte Farbentsprechungen von Routen genutzt wird, siehe z.B. die "blaue" Farbe der U8

TBD:

buffer=* bzw. buffer:left=* und buffer:right=* Zahl in Metern oder yes / no Optional Abstand/Schutzpuffer nach links oder nach rechts. Ist nur "buffer" angegeben, ist der Abstand nach links zur Fahrbahn gemeint. buffer:right=* ist insbesondere als Schutzabstand neben parkenden Autos (Gefahr durch sich öffnende Autotüren) oder gegenüber dem Fußverkehr interessant.

TBD:

  • Siehe oben zu "width". Wie misst man das? --Tordans (talk) 17:08, 10 January 2020 (UTC)
  • Unter Umständen könnte man auch hier in :left und :right differenzieren: Bisweilen gibt es auch zum Fußweg einen markierten/symbolisierten Puffer (default meint aber :left). --Supaplex030 (talk) 21:17, 13 January 2020 (UTC)
Ergänzung: Ich würde auf jeden Fall eine Differenzierung in buffer:left und buffer:right empfehlen - insbesondere bei Radfahrsteifen, bei denen auch der Puffer nach rechts zu sich öffnenden Autotüren relevant ist (siehe Karl-Marx-Straße). --Supaplex030 (talk) 21:14, 16 January 2020 (UTC)
protection=* bzw. protection:left=* und protection:right=*
  • bollard (Poller)
  • kerb (Bordstein)
  • parking_lane (Parkspur), bus_lane (Busspur)
  • grass_strip (Grünstreifen), hedge (Hecke), tree_row (Baumreihe)
  • solid_line (geschlossene Linie), dashed_line (gestrichelte Linie), pictogram (Markierung mit Fahrradsymbol)
  • surface (Markierung durch verschiedene Fahrbahnoberflächen, Pflasterung o.ä.)
  • yes (unspezifiziert)
  • no (keine bauliche oder symbolische Trennung zu anderen Verkehrsteilnehmern vorhanden)
  • not_required (kein Schutz notwendig, da kein Verkehrsraum anschließt)
 Empfohlen

Beschreibt, auf welche Weise der Radweg von Verkehr auf der linken/rechten Seite geschützt ist. Links ist zumeist die Fahrbahn mit Autoverkehr, rechts zumeist Gehweg. Mehrere Values können mit Semikolon getrennt getaggt werden, wobei baulich getrennte Phänomene von links nach rechts erfasst werden sollten (z.B. "parking_lane;kerb" für einen Bordstein, von dem aus sich links noch eine Reihe parkender Autos anschließt). Eine Interpretation, welche Werte einem "hohen" und welche einem "geringen" Schutzstatus entsprechen, ist damit nicht verbunden und bleibt den Anwendern überlassen.

TBD:

  • surface - also kein Schutz?? --Tordans (talk) 17:08, 10 January 2020 (UTC)
Sozusagen, zumindest nicht im physischen Sinne. So wie verschiedene Arten von Markierungslinien. Habe dazu nochmal ergänzt, dass die "Interpretation" der Werte den Anwendern überlassen bleibt. Ich bin davon ausgegangen, dass man "automatisiert" nur ein hohes Schutzlevel annehmen würde, wenn entsprechende Values zu finden sind (z.B. "bollard"); andere Values dagegen als geringen (oder quasi nicht vorhandenen) Schutzstatus interpretieren würde (z.B. "no", "surface" oder die Markierungsarten). --Supaplex030 (talk) 21:17, 13 January 2020 (UTC)
Weiterer Hinweis dazu von einem Changeset: Auch "protection=parking_lane" kann - insbesondere bei fehlendem Buffer, als Gefahr interpretiert werden (durch sich öffnende Autotüren). --Supaplex030 (talk) 08:51, 17 January 2020 (UTC)
  • nur "protection" ohne :left oder :right würde ich dennoch erwähnen: Als default für links. --Supaplex030 (talk) 21:17, 13 January 2020 (UTC)
  • Manchmal gibt es Bereiche an Schutzstreifen, bei denen sich eine Busspur/Bushaltestellenbereich o.ä. anschließt. Ich habe in diesen Fällen erstmal "parking_lane" benutzt, obwohl es nicht ganz passt (Karl-Marx-Straße). Ob es sinnvoll ist, dafür weitere Typen von "lanes" zu differenzieren, glaube ich aber nicht, da es ja um die Funktion "Spur mit ruhendem oder langsamem Verkehr" geht... Ein weiterer Sonderfall sind querparkende Autos, bei denen es sich ja auch nicht um eine "lane" im klassischen Sinne handelt. Das erstmal nur als Beobachtung aus dem Reallife-Test. --Supaplex030 (talk) 21:14, 16 January 2020 (UTC)
Hatte den Busspur-Fall erneut auf der Werbellinstraße und könnte mir vorstellen, dass es öfter mal ähnliche Fälle gibt oder Radspuren bisweilen links von Busspuren geführt werden. Ich denke, "bus_lane" ist dafür nen guter Tag und habe ihn in der Liste ergänzt. --Supaplex030 (talk) 18:46, 19 January 2020 (UTC)
  • Empfehlen wir auch beim Tagging von Schutzstreifen, also am highway selbst, stehts alle "Richtungen" auszuschreiben, selbst bei oneways? Im konkreten Fall ging es an einer Einbahnstraße darum, ob sich das ":right" bei "cycleway:protection:right" auf cycleway oder protection bezieht. Besser könnte das Monster "cycleway:right:protection:right" sein, um auch bei beidspurig befahrbaren Straßen nicht durcheinanderzukommen (wo es je eine linke und eine rechte Seite bei einem linken und einer rechten Radspur gibt :) Siehe Diskussion an einem Changeset --Supaplex030 (talk) 08:48, 17 January 2020 (UTC)
Das betrifft dann auch buffer:left und buffer:right. --Supaplex030 (talk) 18:26, 19 January 2020 (UTC)
  • Es gab noch den Hinweis, dass sich protection=* nicht nur für Fahrradwege, sondern auch Gehwege verwenden lässt. Das sollten wir beachten, sobald wir eine Wiki-Doku dafür anlegen. --Supaplex030 (talk) 17:32, 19 January 2020 (UTC)
  • Welchen Wert für "Leitboys" (s.u., Pictures) verwenden? --!bm (talk) 13:09, 4 February 2020 (UTC)
    • 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)

Tagging-Empfehlungen Radfahr-/Radschutzstreifen

Die hier aufgeführten Tagging-Empfehlungen gelten für Radwege, die nicht separat erfasst werden können/sollten, also am Fahrbahnrand durch Markierungslinien gekennzeichnete Radfahr- und Radschutzstreifen.

Grundsätzlich sind die gleichen Eigenschaften interessant wie an separat gemappten Wegen, allerdings müssen diese – soweit sie sich von denen der (Auto-)Straße unterscheiden – durch ein Präfix als spezifisch für den Radweg gekennzeichnet werden:

Tagging-Empfehlungen für die Auto-Fahrbahn

Wir beschreiben hier nur Tags, die für den Radweg/Radverkehr relevant sind.

  • Bei separat gemappten Radwegen gibt cycleway=separate am Straßen-highway an, dass dieser als separater Way gemapped wurde. Erlaubt somit Datenkonsumenten zu erkennen, dass diese Straße zwar einen Radweg hat, die Daten dazu aber anderswo zu holen sind.
  • (Haus- und Grundstücks-)Einfahrten, die den Radweg kreuzen, können interessant für Datenanalysen sein und sollten daher erfasst werden. Dazu von der Straße ausgehend eine Linie entlang der Einfahrt mit highway=service + service=driveway mappen (bei Gebäudedurchfahrten außerdem tunnel=building_passage im Bereich der Durchfahrt - gut im WMS-Datensatz ALKIS, Gebäude erkennbar). Bei separat gemappten Radwegen auf einen gemeinsamen Punkt als Kreuzungspunkt zwischen Radweg und Einfahrt achten.
  • 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)

[gelöst] Offene Frage 1: Vorschläge zum Taggen des "Schutzstatus" eines Radweges

Zur Zeit gibt es keine Möglichkeit, die Abgrenzung eines Radweges nach links (meist zum fließenden Verkehr) oder rechts (meist zum Fußweg) zu spezifizieren, womit ein wesentliches Qualitäts- bzw. Sicherheitsmerkmal nicht erfasst wird. Mit Pollern vom Autoverkehr abgetrennte Protected Bike Lanes (PBL), wie sie in Berlin zunehemend entstehen, können beispielsweise gegenwärtig nicht adäquat in OSM abgebildet werden. Aber auch Hochboardradwege (mit Markierungen auf dem Gehweg) sind beispielsweise durch Baumreihen, parkende Fahrzeuge, Bordsteine oder andere Barrieren begrenzt. Für Fahrradschutzstreifen (mit Markierungen auf der Fahrbahn) gibt es immerhin einen Vorschlag zur Differenzierung zwischen durchgezogenen und gestrichelten Linien (Wiki, Forum).

  • Taggingvorschlag: cycleway:protection=* bzw. Differenzierung nach protection:left=* oder protection:right=*
    • mögliche Values: bollard (Poller), kerb (Bordstein), parking_lane (Parkspur), tree_row (Baumreihe), grass_strip (Grünstreifen), solid_line, dashed_line (Markierung der Fahrbahn durch durchgezogene oder gestrichelte Linie – könnte u.U. auch an cycleway=lane verwendet werden), pictogram (Markierung mit Fahrradsymbol), surface (Markierung durch verschiedene Fahrbahnoberflächen o.ä.), yes (unspezifiziert), no (keine bauliche oder symbolische Trennung zu anderen Verkehrsteilnehmern vorhanden), not_required (keine Trennung notwendig, da auf dieser Seite kein Verkehrsraum an den Radweg angrenzt)
    • Folge verschiedener Values (von links nach rechts) mit Semikolon getrennt (z.B. "parking_lane;kerb;trees")

[gelöst] Offene Frage 2: Protected Bike Lanes mit getrennten oder verbundenen Ways mappen?

Der gegenwärtige OSM-Diskurs lässt es zu, Radwege als separate Wege zu mappen, wenn eine bauliche/physische Trennung zur Fahrbahn besteht (z.B. durch einen Bordstein, parkende Autos oder einen Grünstreifen). Ob durch Poller getrennte PBL im OSM-Sinne "physisch getrennt" vom Straßenverlauf sind und daher als separate Ways getaggt werden können oder sie als herkömmliche Schutzstreifen behandelt werden und ihre Eigenschaften an den way der Straße gehören ist nicht geklärt/umstritten.

Eigenschaften der (Auto-)Fahrbahn und des Radweges getrennt zu erfassen, hat diverse Vor- und Nachteile (Siehe auch: WikiProject_Germany/Workshops/Linienbündel):

Pro way-splitting:

  • einfaches und übersichtliches Taggen vieler Detaileigenschaften (insbesondere bei schnell wechselnden oder richtungsabhängigen Eigenschaften)
  • komplexe geometrische Zusammenhänge einfacher erfassbar
  • formal genaueres Abbild der Realität
  • im Fall von PBL: Im Gegensatz zu normalen Schutzstreifen ist ein Fahrspurwechsel nicht vorgesehen (bspw. bei Lastenrädern oder Anhängern auch physisch teils kaum möglich) und Poller (insbesondere feste, z.B. Hasenheide) stellen für einige Verkehrsteilnehmer eine strengere Barriere dar als z.B. Bordsteine

Kontra way-splitting:

  • Schwierigkeiten beim Routing und Rendern von generalisierten Abbildungen (z.B. Fahrradwegekarte)
    • u.a. auch schwierige oder unmögliche Zuordnung der Straße/des Straßennamens, zu dem der Radweg gehört
    • durch (komplizierte) Relationen oder einen Hinweis am way der Straße (siehe nachfolgend) aber theoretisch vermeidbar
  • im Fall von PBL: straßenbegleitend, im engeren Sinne keine bauliche Trennung (die meisten Räder könnten zwischen den Spuren wechseln)

Wie wir hierbei in Bezug auf PBL in Berlin vorgehen wollen, müssen wir auf einem Meetup bzw. in der Community diskutieren. Radwegeigenschaften in (sowohl von der Straße als auch gegenüber dem Gehweg) getrennten Linien zu erfassen, erscheint grundsätzlich vorteilhaft. cycleway=track sollten zukünftig in separate Linien überführt werden.

Offene Frage 3: Datenbezug von Straße und Radweg bei getrennter Erfassung

  • Problem: Bei getrennter Erfassung von (Auto-)Fahrbahn und Radweg fehlen jeweils relevante (maschinenlesbare) Infos: An der Straße fehlen Information zum vorhandenen und parallel verlaufenen Radweg; am Radweg fehlen beispielsweise Infos zum Straßennamen oder andere Übertragbare Informationen wie Straßenbeleuchtung.
  • Lösungsmöglichkeiten:
    • street-Relationen wie in Lübeck sind übermäßig kompliziert und wartungsanfällig und sollten daher vermieden werden.
    • Stattdessen gibt es bereits ein cycleway=separate, um am Straßen-highway anzugeben, dass ein vorhandener Radweg separat gemappt wurde und Doppelinformationen zu vermeiden.
    • Dem Radweg eine eindeutige Straße bzw. einen Straßennamen zuzuordnen, bliebe in dieser Variante jedoch weiterhin eine Herausforderung für Data Consumer (siehe unten: Usecases).

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)

Usecases / Anwendungsfälle für das Tagging

(Nicht sortiert)

  • Sehen, ob eine Straße gesonderte Infrastruktur für Fahrrad hat – und welche. --Tordans (talk)
    • Status Quo
      • ✔️– Lane Tagging ermöglicht das
      • ⁉️ – Problem, wenn gesonderter Track, dann fehlt an Haupt-Lane der Bezug / die Information -> Siehe oben, offene Frage 3
  • Routing: Radweg-Routing hat die gleiche Qualität wie Auto-Routing; vor allem nennt Radweg-Routing auch den Straßennamen --Tordans (talk)
    • Status Quo
      • ⁉️ – Bei Radwegen als eigener Track ein Problem, da Router die Relation zur Straße nicht kennen und der Name nicht dupliziert wird. Wenn wir OSM's denormalisiertem DB-Model folgen, müssten wir die Informationen duplizieren. Relationen scheinen zu komplex hierfür.
  • Detaillierte Qualitätsangaben zum Radweg auswerten können (Schutz-Art, Oberflächen-Eigenschaften, Kreuzungen, Verschwenkungen u.a.) --Tordans (talk)
    • Status Quo
      • ⁉️ – Lane-Tagging problematisch, da Straßenabschnitte sehr kleinteilig werden und Wegeführung nur für die Hauptstraße angegeben werden (Verschwenkungen).
      • ⁉️ – Gesonderter Track auch problematisch, siehe oben. Konsens scheint zu sein, dass bauliche Trennung einen gesonderten Track rechtfertigt.
  • Detaillierte Angaben zum Schutz Richtung Autos und Fußgänger (PBL u.ä.) auswerten können --Tordans (talk)
    • Status Quo
      • ⁉️ – Tagging-Vorschläge oben. Wichtig ist mir, dass beide Richtungen erfasst sind (Autos und Fußgänger)
  • Wegeführung an Kreuzungen können ausgewerten werden für Routing und für Sicherheitsanalysen --Tordans (talk) 08:14, 23 December 2019 (UTC)
    • Status Quo
      • ⁉️ – Thema ist noch komplexer als der Rest. Siehe auch oben. Überschneidung zum Lane- und Lane-Access-Tagging.

Real live examples (Abschnitt aufräumen/aktualisieren)

Übersicht: Nach erweitertem Schema gemappte Radwege in Berlin

Test des Taggingschemas an der PBL Hasenheide

Karte iD Editor Routing-Check Mapillary ParkingLanes-Check

Hasenheide Suedseite Orthophoto.png

Visualisierung von Radwegeigenschaften der PBL Hasenheide: (QGIS auf OSM-Grundlage)

  • Breite der Linie: Radwegbreite
  • Farbe der Linie: Farbe der Oberfläche
  • rote Flächen: Parkstreifen
  • orangene Flächen: buffer
  • Punkte: Poller
  • gestrichelte und durchgezogene Linien: Fahrbahnmarkierungen (links) bzw. Bordstein (rechts)
  • hellgraue Linie (nahe Hermannplatz): Radwegmarkierung nur durch Oberflächengestaltung (protection:right = surface)

Pictures

Oranienstraße

TODO: Hochbordradweg Pannierstraße

Offene Fragen zum Tagging generell:

  • Wie setzen wir Anfang/Ende der Lane, so wie im Beispiel?
  • Wenn der Radweg durchginge an den Kreuzungen der Pannierstraße, wie würde man ihn dann mit den Fahrbahnen verbinden? Bspw. hier/Mapillary. Nur mit der kreuzenden Fahrbahn? Oder auch mit der parallelen Fahrbahn links?

TODOs für dieses konkrete Changeset / Tagging:

  • Width nachmessen

Notizen die noch sortiert werden müssen

Links

Tooling

Exkurs: Daten der Stadt Berlin

Beispiel Mittelweg, Neukölln

Overpass-Query um "cycleway=track" zu finden für mögliches Tag-Migration

Overpass Query um alle Radwege vom Typ "track" zu finden, die bisher als Attribut der Straße gemapped sind. 

  [out:json][timeout:25];
  (
    node["cycleway"="track"]({{bbox}});
    way["cycleway"="track"]({{bbox}});
    node["cycleway:left"="track"]({{bbox}});
    way["cycleway:left"="track"]({{bbox}});
    node["cycleway:right"="track"]({{bbox}});
    way["cycleway:right"="track"]({{bbox}});
    node["cycleway:both"="track"]({{bbox}});
    way["cycleway:both"="track"]({{bbox}});
    node["cycleway"="opposite_track"]({{bbox}});
    way["cycleway"="opposite_track"]({{bbox}});
  );
  out body;
  >;
  out skel qt;

weitere Overpass-Abfragen

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Talk:Berlin/Verkehrswende/Radwege/Archiv&oldid=1967556"