User:JochenB/Wegweisungsnetz-Alternativen

From OpenStreetMap Wiki
Jump to navigation Jump to search

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(im Forum als (1) ) ... ü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
  • 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"(im Forum als (2) ) ... ü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"(im Forum als (3) ) ... ü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"(im Forum als (4) ) ... 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"(im Forum als (5) ) ... 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

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=User:JochenB/Wegweisungsnetz-Alternativen&oldid=2716869"