User:JochenB/Wegweisungsnetz-Alternativen

Hier möchte ich Alternativen zum Taggen von mit Wegweisung versehenen Fahrrad- oder Wanderwegnetzen gegenüberstellen. Ziel ist es, sich für eine Version zu entscheiden, die Grundlage eines Proposals mit einem einheitliches Vorgehen für beide Netze wird.

Motivation ist, eine Unterscheidungsmöglichkeit zu bekommen zwischen

• den Wander- bzw. Fahrradrouten mit Name und
• den restlichen Verbindungen im Netz mit Wegweisung aber ohne Symbol und Name

Heute ist diese Unterscheidung oft nicht möglich, da beides oft als route-Relationen mit route=bicycle bzw. route=hiking gemappt wird. Benannte Routen können daher nicht gegenüber dem restlichen Netz hervorgehoben werden. So gehen z. B. in dem oft engmaschigen Radverkehrsnetz von NRW die Themenradwege unter, da sie gleich dargestellt werden müssen.

Bitte diskutiert im Forum über Vor- und Nachteile und gebt euer Voting ab, welche Variante aus eurer Sicht die beste ist!:

Forumsdiskussion: Proposal: Wander-/Radweg ggü. anderen Wege mit Wegweisern hervorheben?

Hinweis: Im deutschen Wiki ist bereits ein Taggingschema beschrieben, siehe DE:Bicycle/Radverkehrsnetze kartieren (Verwenden von network-Relationen für Netzverbindungen). Diese basiert auf einer Diskussion von 2019. Wichtige Annahmen dafür haben sich jedoch als falsch herausgestellt, zudem suchen wir nach einer einheitlichen Lösung für Fahrrad- und Wandernetzwerke, so dass diese Lösung nochmal zur Diskussion gestellt wird.

Gegenüberstellung Tagging-Ideen für Netz-Verbindungen

Ein Radverkehrsnetz bzw. Wandernetz ist gekennzeichnet durch einheitliche Fahrrad- bzw. Wanderwegweiser. Es besteht aus den mit Wegweisung versehenden Wegen sowie aus den Knoten, an denen sich diese Wege kreuzen, verzweigen oder enden. Die Wege zwischen diesen Knoten sind die Verbindungen.

Unterschied zu ausgeschilderten und bennanten Radrouten oder markierten Wanderwegen: Verbindungen haben keinen eigenen Namen und kein eigenes Symbol (z. B. kein Symbol-Einschub am Fahrrad-Wegweiser).

Für jede Verbindung wird eine eigene Relation erstellt. Diese Relationen erhalten alle Wegelinien und Wegweiser der Verbindung. Sie enden an Knoten, an denen andere Verbindungen kreuzen, verzweigen oder enden. Die Wegelinien einer Relation bilden eine durchgehende, lückenlose Wegekette. Abzweigende Verbindungen erhalten eine eigene Relation (analog zu Verbindungen in Knotenpunktnetzwerken).

In der folgenden Tabelle sind Möglichkeiten aufgelistet, mit welchen Tags diese Verbindungs-Relationen von herkömmlichen Rad- und Wanderrouten unterschieden werden können. Die aus meiner Sicht entscheidenden Nachteile habe ich rot markiert.

Tabelle alternativer Ideen für ein Taggingschema von Verbindungen im Grundnetz:

	Erklärung der Idee: Abgrenzung der Verbindungen des Grundnetzes ggü. benannten Routen ...	Tagging der Verbindung	andere relevante Werte des Tags	Vorteile	Nachteile
(a) Verwenden von network-Relationen	... über den Relationstyp "network" Netzverbindung: network-Relation (zusätzlich zur übergeordneten Master-network-Relation) benannte Route: route-Relation Verwenden einer eingeführten Praxis aber aber Kleinschneiden der bislang entstandenen Riesen-Relationen (teilweise > 3.000 Mitglieder!) in viele handliche Netzverbindungs-Relationen.	Relation mit >> type=network << route=bicycle/hiking	type=route benannte Routen type=network (ohne route=bicycle/hiking) übergeordnete Master-network-Relationen	gelebte Praxis seit ca. 2011 wenn auch wegen der Unhandlichkeit entstandener Riesen-Relationen mitunter eingeschlafen. Verfahren bereits dokumentiert im deutschen Wiki (seit Dezember 2020 nach Diskussion von 2019). keine Einführungsprobleme aufgrund fehlender Darstellung im Render: Die Relationen werden weiter durch Renderer dargestellt, die Darstellung ändert sich erstmal nicht. (Erkenntnis 2021: keine Unterstützung durch bekannte Tile-Renderer mehr)	Untypische Verwendung von network-Relationen für ausgeschilderte Strecken. Üblicherweise werden Streckenverläufe mit route-Relationen abgebildet. network-Relationen sollen gleichartige Objekte eines Netzwerks zusammenfassen. Die Verbindungen des Grundnetzes erfüllen die Bedingungen für route-Relationen, die von network-Relationen eher nicht. Doppelte Bedeutung von network-Relationen im Kontext Radverkehr kann verwirren: type=network mit route=bicycle/hiking: Verbindungen im Netz, enthalten die Weglinien und Wegweiser type=network ohne route=bicycle/hiking: "Sammelrelation", enthalten alle Verbindungs-Relationen des Netzes Abweichende Lösung von den sehr ähnlichen Knotenpunktnetzwerken wirkt inkonsistent: Netz mit Knotenpunktnummern: type=route mit network:type=node_network Netz ohne Knotenpunktnummern: type=network ohne network:type=* Fehlende Unterstützung durch übliche Tile-Renderer, daher Akzeptanzprobleme: Das Anwenden des neuen Schemas lässt die Relationen aus populären Karten verschwinden. Folge: Diskussionen (z. B. in diesem Changesetkommentar). Lösbar, indem man z. B. Thunderforest überzeugt, diese Lösung zu rendern.
(b) neuer Wert "basic_network" für "network:type"	... über den Netzwerktyp "basic_network" Anlehnung an die Knotenpunktnetzwerke, deren Taggingschema sehr ähnlich und weit verbreitet ist ("Radeln / Wandern nach Zahlen") Wert "basic-network", weil das mit Wegweisung versehene Netz als Grundnetz betrachtet werden kann, über das konkrete Themenwege gelegt werden können. alternativer Wert: "destination_network" da die Wegweiser Ziele ausweisen	Relation mit type=route route=bicycle/hiking network=*cn/*wn >> network:type=basic_network <<	network:type=node_network Verbindungen in Knotenpunktnetzwerken ("Radeln / Wandern nach Zahlen") ohne network:type=* benannte Routen	keine Änderung der Beutung bestehender Tags da zusätzliche Information keine Einführungsprobleme aufgrund fehlender Darstellung im Render: Die Relationen werden weiter durch Renderer dargestellt, die Darstellung ändert sich erstmal nicht.	Semantisch unlogisch: Das Grundnetz erhält ein eigenes Tag, bei den darüber verlaufenden Themenrouten entfällt das Tag. Logischer wäre es anders herum. Zu harte Abgrenzung zu Knotenpunktnetzwerken: Es wird vermittelt, dass ein Netz entweder ein Wegeweisungsnetz oder ein Knotenpunktnetz sein kann. In der Praxis ist das Knotenpunktnetzwerk (Routensymbol mit Knotenpunktnummern) oft mit den klassischen Wegweisern kombiniert (Wegweiser mit Ortsnamen).
(c) neuer Wert "bcn/lcn" für "network"	... über eine neue Klassifizierungsstufe "bcn/bwn" Annahme: Verbindungen des Grundnetzes sind als "Bausteine" für Fahrten / Wanderungen unabhängig davon, ob die Fahrten / Wanderungen lokal, regional, national oder international sind. Sie werden daher keiner räumlichen Klassifizierung "lokal / regional / national / international" zugeordnet. Erklärung "bcn/bwn": "basic cycling network" bzw. "basic hiking network" alternativer Vorschlag: "ocn/own" statt "bcn/bwn" für "Betreibernetz", also ein Wegweisungsnetz, dass einen einheitlichen Betreiber hat ("o" für "operator").	Relation mit type=route route=bicycle/hiking >> network=bcn/bwn << (oder network=ocn/own)	für benannte Routen mit ... network=lcn/lwn ... lokaler Bedeutung network=rcn/rwn ... überregionaler Bedeutung network=ncn/nwn ... nationaler Bedeutung network=icn/iwn ... Internationaler Bedeutung	Auflösung des Widerspruchs, dass die einzelnen Netz-Verbindungen von der Länge eher lokal sind (lcn) während das gesamte Netz oft überregionale Bedeutung hat (rcn) einfache Handhabung, da bekannter Schlüssel nur um einen neuen Wert erweitert wird	Keine Klassifizierung möglich, daher Akzeptanzprobleme: Durch Verwenden von "b*n" ist das gleichzeitige Verwenden von "l*n/r*n" usw. ausgeschlossen. Mitunter wurde in OSM bereits das Grundnetz klassifiziert, z. B. anhand der Strukturebene des Radverkehrsnetzes in der Länder-Radverkehrskonzeption. network=rcn steht dort für als Landesnetz ausgewiesene Radverbindungen, network=lcn für ergänzende Routen der Kommunen und Landkreise (z. B. in NRW). Umdeutung der vorhandenen Werte "r*n/l*n": Verbindungen des "Grundnetzes" sind bislang network=r*n/l*n. Nach der Änderung nicht mehr. Über lange Zeit wird unklar bleiben, ob eine Route mit lcn nun ein Radweg mit Symbol oder nur eine Netzverbindung ohne Symbol ist. (Dies ist aber nahezu ohne Auswirkung, da das heute auch schon unklar ist). Notwendigkeit des Umtaggens bestehender Relationen: die bisher mit network=r*n/l*n getaggt wurden Einführungsprobleme aufgrund teilweise fehlender Darstellung im Render: Die Relationen werden nicht durch alle populären Renderer dargestellt: "network=bcn" wird in cyclOSM wie "lcn" gerendert in thunderforest derzeit nicht dargestellt in waymarkedtrails wie "lcn" gerendert "network=bwn" wird in waymarkedtrails wie "lwn" gerendert in wanderreitkarte.de derzeit nicht dargestellt Zusätzlicher Nachteil von network=ocn/own: Einheitliche Netzwerke haben oft verschiedene Betreiber: So liegt die Radwegweisung eines Kreises oft in der Hand der Kommunen, auch wenn die Wegweisung dem selben Schema entspricht. Definiert man das Netz nur anhand des Betreibers, müsste man das Kreisnetz demnach in viele kleine Netze aufteilen, ohne dass dies Belang für den Nutzer hat oder die Definition ist unsauber mit der Gefahr von unterschiedlichen Auslegungen.
(d) allgemeinerer Wert "bicycle/hiking" für "network"	... durch Weglassen der Klassifizierung Annahme: wie links Netzverbindung: allgemeine Netzwerk-Angabe ohne Klassifizierung: network=bicycle/hiking benannte Routen: Klassifizierung in der Netzwerk-Angabe:	Relation mit type=route route=bicycle/hiking >> network=bicycle/hiking <<	für benannte Routen mit ... network=lcn/lwn ... lokaler Bedeutung network=rcn/rwn ... überregionaler Bedeutung network=ncn/nwn ... nationaler Bedeutung network=icn/iwn ... Internationaler Bedeutung	Auflösung des Widerspruchs, dass die einzelnen Netz-Verbindungen von der Länge eher lokal sind (lcn) während das gesamte Netz oft überregionale Bedeutung hat (rcn) einfache Handhabung, da bestehender Schlüssel mit bestehendem Wert kombiniert wird	Keine Klassifizierung möglich, daher Akzeptanzprobleme: identisch zu "network=bcn/bwn" (siehe links) Umdeutung der vorhandenen Werte "r*n/l*n": identisch zu "network=bcn/bwn" (siehe links) Notwendigkeit des Umtaggens bestehender Relationen: identisch zu "network=bcn/bwn" (siehe links) Risiko des versehentlichen Umtaggens: network=bicycle/hiking ist ein allgemeiner Wert als z. B. network=rcn/rwn, es besteht die Gefahr, dass Mapper wieder 'rcn/rwn' entsprechend der bisherigen Praxis taggen, da sie annehmen, damit die Angaben zu detaillieren. Einführungsprobleme aufgrund nur teilweiser Darstellung im Render: Die Relationen werden weiter durch Renderer dargestellt, die Darstellung ändert sich erstmal nicht. "network=bicycle" wird in cyclOSM wie "lcn" gerendert in thunderforest derzeit nicht dargestellt in waymarkedtrails wie "lcn" gerendert "network=hiking" wird in waymarkedtrails wie "lwn" gerendert in wanderreitkarte.de derzeit nicht dargestellt
(e) kein "ref" und "name" dafür "noname =yes"	... Weglassen von "ref" und "name" Da sich Netzverbindungen im Grundetz von den Routen nur darin unterscheiden, dass sie kein Symbol und kein Name haben, werden nur name, ref und symbol weggelassen und dafür ein noname=yes hinzugefügt. Eine weitere Unterscheidung zwischen Netzverbindung und benannter Route gibt es nicht.	Relation mit type=route route=bicycle/hiking network=*cn/*wn >> ohne name, ref und symbol <<	mit name, ref und symbol benannte Routen	sehr einfach: keine neuen Tags nahe an der Realität: Unterscheidung ausschließlich anhand der Merkmale, anhand derer Netz und benannte Route auch in der Realität unterschieden werden. keine Einführungsprobleme aufgrund fehlender Darstellung im Render: Die Relationen werden weiter durch Renderer dargestellt, die Darstellung ändert sich erstmal nicht.	Notwendigkeit des Umtaggens bestehender Relationen und Inkompatibilität zur bisherigen Taggingpraxis, daher Akzeptanzprobleme: Bisher wurden Verbindungen des Grundnetzes mitunter mit ref und name versehen, z. B. "ref=NRW" für die Grundetz-Verbindungen des Landesnetz NRW (Verweis auf die Netzdefinition in der Radverkehrskonzeption von NRW). ref, name und symbol müssten entfernt werden. Risiko des versehentlichen Umtaggens: Information durch das Fehlen von Tags auszudrücken ist ungünstig, da nicht erkennbar ist, ob der Tag bewusst nicht gesetzt wurde oder ob er noch nicht gesetzt wurde. Letzteres erfolgt, wenn dem Mapper Informationen fehlten oder er sie nicht so detalliert erfassen wollte. Somit ist das Risiko groß, dass ein anderer Mapper diese Tags wieder mappt, ohne dass ihm dabei bewusst wird, dass er die Verbinung damit "umklassifiziert". Das Problem wird insbesondere deshalb auftreten, da in der bisher übliche Taggingpraxis die Tags ref und name auch am Grundnetz vorkamen. Mitunter hat auch das Grundnetz ein Symbol: Bei Wandernetzwerken gibt es mitunter Symbole für "alle sonstigen Strecken". Fahrradnetzwerke haben mitunter eigene Symbole, so hatten in Sachsen zeitweise alle neuen Radwegweiser das sächsische Staatswappen.
(f) Tag am Weg statt Relation	... durch einen Tag an den Wegekanten, z.B. "lcn/lwn=basic_network" Wegeverbindungen mit Wegweisung werden nicht als klassische Routen mit Beginn und Ende gesehen, da sich Beginn und Ende nur aus der Netzgeometrie ableiten. Es reicht daher ein Tag an den Wegelinien der Verbindung	Tagging von lcn=basic_network bzw. lwn=basic_network an den Wegekanten oder einer der links beschriebenen Tags. Keine Relation für die Wegeverbindung, auch kein name, ref oder symbol.	lcn=yes bzw. lwn=yes für eine unspezifische Zuordnung einer Wegekante zu Radverkehrs- oder Wanderwegnetzen	sehr einfach: allem für ungeübte Mapper durch Verzicht auf Relationen Zwischenlösung wenn nur einen Teil der Verbindung gemappt werden kann	Fehlende Unterstützung durch übliche Tile-Renderer, daher Akzeptanzprobleme: lcn=basic_network wird von den üblichen Renderern nicht dargestellt. Vorteile von Relationen können nicht genutzt werden: z. B. zentrales Vorhalten von Informationen in einem Objekt, leichtes Überprüfen der Durchgängigkeit und Vollständigkeit der Wegekette, Zuordnung der Wegweiser zur Verbindung.
...

Hintergründe

Bisherige Diskussionen im Forum

• Ist eine Zielwegweisung eine Route im OSM-Sinne? ab 27.05.2019
  Ergebnisse:
  • Bedarf der Unterscheidung zwischen Routen mit Symbol und Name und dem restlichen Netz mit Wegweisung.
  • Im Wiki soll die bestehende Praxis mit network-Relationen dokumentiert werden (ist hier erfolgt: DE:Bicycle/Radverkehrsnetze kartieren)
• Markiertes, namenloses Wanderwegenetze in *wn Network abbilden ab 24. Dez 2020
  Ergebnis: Bedarf der Unterscheidung auch bei Wanderwegnetzen. Einheitliches Vorgehen zu Radverkehrsnetze wünschenswert. Die Verwendung von network-Relationen sollte nochmal diskutiert werden (erfolgt hier).
• Keine Rendererunterstützung für Radverkehrsnetze mehr, was tun? ab 7. Jan 2021
  Ergebnis: Die Renderer stellen network-Relationen nicht (mehr?) dar. Könnte man aber durch Gespräche mit den Betreibern/Programmierern lösen.