Ich stelle mal ein paar der diskutierten Varianten gegenüber: Meine Favoriten: 1b + 2b
Radschnellwege (Infrastruktur)
Variante 1a: Kein eigenes Tag, sondern Beschreibung der Wegbeschaffenheit nur auf Basis der Eigenschaften
highway=cycleway + surface + smoothness + width + incline + Router erkennen die Abwesenheit von Ampeln und Vorrang an Kreuzungen + …
Vorteile:
• Kein neues tag, das gelernt werden muss.
Nachteile:
• Alle relevanten Informationen zu mappen ist sehr aufwändig.
.
Variante 1b: Zusätzlich zu Variante 1 ein eigenes Tag. Z.B.
• cycleway=expressway
• cycle_expressway=yes
• cycleway:expressway=yes
Vorteile:
• In der Datenbank leicht zu erkennen, zu filtern und zu rendern.
• Es erlaubt Mappern, die Qualität zum Radfahren schnell einzutragen, ohne alle Details des Weges aufwändig erfassen zu müssen. (Es ist ein gewissermaßen vergleichbar mit tracktype).
Nachteile:
• Wenn es kein Verkehrszeichen dafür gibt, ist es schwierig, objektiv zu beurteilen, ob die Qualitätskriterien erfüllt sind. Aber es ist nicht unmöglich.
• Es kann schnell einmal ein Politiker einen normalen Radweg als „Radschnellweg“ vermarkten, der viele Qualitätskriterien nicht erfüllt, und dann wird OSM nicht konsistent werden.
.
Radschnellverbindungen (Routen)
Variante 2a: kein highway=cycleway, sondern ein neuer highway-tag auf dem way (keine Relation), zB
• highway=cycle_expressway
Vorteile:
• ??
Nachteile:
• Diese Variante kann nicht gleichzeitig die Bedeutung für den Autoverkehr und den Radverkehr darstellen. Radschnellverbindungen führen aber nicht nur auf eigenen Radwegen, sondern auch durch Siedlungsstraße (zB als Fahrradstraße).
.
Variante 2b: Zusätzlich zum bestehenden highway-Tag (der üblicherweise die Bedeutung der Straße für den Autoverkehr darstellt) ein zusätzlicher Tag auf dem way (keine Relation), der die Bedeutung der Straße für den Radverkehr darstellt. zB
• cycle_highway=primary/secondary/… oder
• highway:bicycle=primary/secondary/… oder
• ncn=yes (für nationale Alltagsradrouten, sollte es die mal geben), rcn=yes (für regionale Alltagsradrouten), lcn (für lokale Alltagsradrouten) oder
Vorteile:
• Bietet nicht nur ein Tagging für Radschnellverbindungen, sondern erlaubt es, herkömmliche Alltagsradrouten von touristischen Radrouten zu unterscheiden (was ein Manko des derzeitigen Taggingschemas ist).
• „Gleichberechtigung“ von Rad und Auto in OSM, indem beides einen Top Level Tag zur Beschreibung der Netzfunktion bekommt.
Nachteile:
• Viele Radverkehrsnetze sind (noch) nicht oder nur teilweise ausgeschildert. Die Überprüfbarkeit vor Ort wird oft schwierig werden.
• Es könnte passieren, dass jede kleine Siedlungsstraße einen zusätzlichen Tag bekommt (zB cycle_highway=residential) was unübersichtlich ist und unnötig aufwändig erscheint.
.
Variante 2c: kein Zusätzliches tagging am way, sondern Sammlung der einzelnen ways in einer Relation. Darstellung der Netzfunktion der Route für den Alltagsradverkehr durch ein geeignetes tagging in der Relation. zB.
• type=route, route=bicycle, route:bicycle=expressway/…
Vorteile:
• Eigenschaften, die entlang der Route gleich, werden nur einmal (in der Relation) erfasst und können leicht gesammelt bearbeitet werden.
Nachteile:
• Ungleichbehandlung von Autos und Rädern in OSM. Die Netzfunktion für den Autoverkehr ist im highway-Tag, die Netzfunktion für den Radverkehr nur in einer Relation versteckt.
.
Variante 2d: Der highway-Tag einer Straße ist nicht aufs Auto fixiert, sondern jeweils der höchste für irgendeine Verkehrsart. zB Radschnellverbindung durch Siedlungsstraße wird zu highway=secondary
Vorteile:
• Wirkliche Gleichberechtigung
Nachteile:
• Missverständlich,
• Chaos bei Routern (für Auto und Rad),
• Die Info für welches Verkehrsmittel die Straße wichtig ist, muss sowieso irgendwie ergänzt werden, womit wir wieder bei 2a bis 2c ankommen).