Markiertes, namenloses Wanderwegenetze in *wn Network abbilden

Du hast im falschen Abschnitt gelesen!

Network-Relationen haben bez. Radverkehr 2 Anwendungen:

  1. Erfassen einer Wegeverbindung im Radverkehrsnetz (Grundnetz)

  2. Zusammenfassen von Wegeverbindungen und Routen in Master-network-Relationen

Du hast den Anwendungsball b) zitiert. Dort enthält eine network-Relation tatsächlich nur Knoten und andere Relationen.

Hier geht es aber um Anwendungsfall a). Dort beschreibt die network-Relation eine Wegeverbindung. Dazu werden alle Wegeelemente in die Relation aufgenommen. Unter “Kartierung der Wegeverbindundungen im Radverkehrsnetz” steht im Wiki:

“Die Wegeverbindungen im Radverkehrsnetz können durch network-Relationen abgebildet werden, die alle Wege der Wegeverbindung enthalten. Details dazu siehe unter Relation:network..

Ja, mit “Wege” sind “Ways/Linien/Kanten” gemeint, die Wege beschreiben. Also Kanten mit dem Tag 'higway='*.

Wenn der JOSM-Validator da einen Fehler meldet, so sollten wir ihn anpassen. Er darf den Fehler nur ausgeben, wenn kein ‘route=bicycle’ in der network-Relation angegeben ist, denn nur dann ist es eine Master-Relation.

Die Praxis, network-Relationen mit ‘route=bicycle’ für Wegeverbindungen zu verwenden ist uralt, man schaue sich nur die 50 rcn-Netze in NRW an, die in folgender Masterrelation aufgelistet sind: relation/33216. Klicke dort auf “Mitglieder” und schau dir die 2. bis zur 51. Relation an, alles netzwork-Relationen, die Wege enthalten. Das einzig Unangenehme an diesen Relationen ist, dass man alles in eine Relation gepackt hat mit bis zu 2.700 Mitgliedern (Sammelrelationen). Besser wäre es, das sinnvoll aufzuteilen. Das Wiki schlägt eine entsprechende Aufteilung vor, das ist recht neu und das war die Hauptmotivation, die Praxis im Wiki zu dokumentieren.

Das Eine hatte ich schon genannt: Es gibt eine bereits bei Radfahrnetzen etablierte Möglichkeit, zwischen markierten Routen und Grundnetz zu unterscheiden, sowohl mit network/route-Relationen als auch mit Tagging von ‘lcn/lwn=yes’ am Weg. Man sollte nichts Neues einführen, wenn eine Konkretisierung der Anwendung vorhandener Werkzeuge ausreicht.

Das Andere ist, dass eine neue Netzkategorie ‘network=ocn/own’ eine Teilmenge der bislang vorhandenen Netzkategorie ‘network=lwn’ wäre. ‘network=lwn’ beinhaltet ja bereits kommunale Wege, siehe DE:Key:network: “Lokale Fahrradrouten und -netze befinden sich innerhalb eines Landkreises oder einer Gemeinde” . Der neue Wert ‘ocn/own’ würde damit die Bedeutung des bisherigen Wertes ‘lcn/lwn’ verändern.

Das sollte man unbedingt vermeiden. Niemand wüsste mehr, ob eine Route/Wegeverbindung mit ‘network=lcn/lwn’ nun eine Kommunale Verbindung sein kann oder nicht.

Das Chaos um ‘sett’ und ‘cobblestone’ sollte uns eine Lehre sein. Bis heute weiß man nicht, ob eine Straße mit ‘surface=cobblestone’ nun Katzenkopfpflaster hat oder gehauene Pflastersteine, weil ‘cobblestone’ ursprünglich mal für Beides stand, seit der Einführung von ‘sett’ aber nur noch für Katzenkopfpflaster. Wer mit einem Fahrrad unterwegs ist wird mir sicher bestätigen, dass der Unterschied zwischen beiden enorm ist.

Noch einmal ganz oben angeknüpft, wie ich verstehe, was abq anspricht; Hier ein paar Radwege:

rcn Südschwarzwald-Radweg 273 km https://cycling.waymarkedtrails.org/#route?id=317448

rcn Dinkelberg Höhenradweg 10km https://cycling.waymarkedtrails.org/#route?id=9758139

lcn Wiesentalradweg 25 km / 45 km https://cycling.waymarkedtrails.org/#route?id=9494332

lcn Wehr - Schwörstadt 5 km https://cycling.waymarkedtrails.org/#route?id=9904791

Der erste Weg soll als Umriss der Region gelten. Da drin finden sich - unter vielen anderen natürlich - zwei anscheinend amtlich benannte Radwege und ein anscheinend vom Mapper benannter Radweg. Warum der kurze Dinkelberg regional ist und der viel längere Wiesental nur lokal erschließt sich aus den mir verfügbaren Daten nicht. Es wird schon seine Richtigkeit haben.

Dass es als störend empfunden werden kann, wenn der quasi erfundene Wehr-Schwör Radweg gleich wie der quasi echte Wiesental Radweg dargestellt wird ist mir auf Anhieb nachvollziehbar. Auf die namlosen Wanderwege umlegt, von denen eingangs die Rede war: Eine solche Durchmischung würde ich mir hierzulande auch nicht wünschen.

Eine andere Möglichkeit, das zu Umschiffen als ein fünfter Wert für den Schlüssel “network” an der Route fällt mir momentan nicht ein. Die Kategorie sollte weniger strenge Anforderungen an Vollständigkeit stellen, damit beim Mappen nicht zu viel erfunden werden muss… Ein neuer Wert für einen bestehenden Schlüssel ist meines Wissens verträglicher mit bestehenden Renderern/Apps als ein neuer Schlüssel.

PS: Bei Wanderwegen könnte eventuell mit “hiking” kontra “foot” etwas gemacht werden?

Wenn das so geht, und das auch von Renderern unterschieden werden kann, wäre das wunderbar.
Für lcn=yes gibt es eine Dokumentation, für lwn=yes jedoch nicht.

VG Reiner

Lcn-Network-Relationen werden meines Wissens dargestellt, bei ‘lcn=yes’ an den Wegen weiß ich es nicht. Wie es bei Wanderwegen ist, wäre auszuprobieren, ich vermute genau so. Eine Unterscheidung in der Darstellung zwischen Netzwerk und Route habe ich noch nicht gesehen, die Dokumentation ist aber noch recht frisch.

Dokumentiert sind die Fahrrad-Tags seit Kurzem bei DE:Bicycle/Radverkehrsnetzwerke_kartieren sowohl als network-Relation als auch mit ‘rcn/lcn=yes’ an den Wegen. Wenn wir hier eine Lösung mit bestehenden Tags finden, sollten wir die auch für Wanderwege dokumentieren. Wenn neue Tags eingeführt werden, dann wäre ein Proposal nicht schlecht.

Wenn es was Dokumentiertes gibt, das vorher diskutiert wurde und wir den Bedarf der unterschiedlichen Darstellung gut begründen können, werden die Programmierer der Renderer das sicher ins Backlog aufnehmen.

Das ist eine ausreichende und saubere Lösung. Erfindet einfach noch ein weiteres Tag für die Routen.

Es gibt keinen Unterschied in der Bedeutung zwischen hiking und foot, sie existieren nur aus historischen Gründen.

Es wäre eine extrem schlechte Idee, bei mehreren Hunderttausend Wanderrouten mit hiking oder foot da nachträglich eine Bedeutung hineindeuten zu wollen.

Es wäre schlichtweg falsch, ein Tagging am Weg, das nur für Radwege aus historischen Gründen existiert und daß es für Wanderwege niemals gab, mal eben für Wanderwege zu dokumentieren.

Es gibt eine einfache und kompatible Lösung mit einem Tag an der Route, siehe letzter Post.

Es wäre eine lausige Idee, die Altlast mit Tags am Weg für Wanderwege einzuführen, siehe Post #2.

Hmm, jetzt ist mir nop dazwischengekommen, beim taginfo schauen:

Wege Tag

Dafür dass es so viele mit lcn=yes getaggte Wege gibt ist der Support bei Renderern wie - nicht zu vergessen - Editoren minimal. Für lwn=yes lässt das nichts gutes ahnen.

Wie wäre es mit einem Beispiel einer editierfreundlichen Network Relation, die keine ungewünschte Sammelrelation ist und in den gebräuchlichen Renderen ordentlich aufscheint?

PS: Die Hälfte der Wege lwn=yes befinden sich - wie passend - im Schwarzwald.

PPS: Nachdem ich ja im Thread aus dem dieser herausgelöst wurde von hiking=yes geheilt wurde und es nicht dokumentiert hab, klingt mir nop’s Post fast wie eine Lanze für network=cwn (club/communal) an anonymen Routen. Damit könnten vielleicht sogar die Schweizer etwas anfangen und Lonvia müsste für die nicht mehr eine Extrawurst braten.

PPPS: Das mit den Schweizern vergessen wir gleich wieder, die haben ein network=nwn (Knotennetzwerk) - momentan wird das auf waymarked-trails durch Auswertung vom OSMC-Symbol erkannt…

Das sollte kein Kriterium sein, sondern das, was in der Datenstruktur am saubersten und einfachsten ist. Wenn dem so ist und bei den Anwendern der Bedarf da ist, so wird das in den Renderern schon dargestellt werden.

Von mir ist’s nicht, ich schwör’s! :slight_smile:

Aber vielleicht spiegelt das die Situation ganz gut wieder mit einer großen Zahl ausgeschilderter Wege, von denen nur ein Bruchteil in Wanderrouten erfasst ist.

VG Reiner

Bei den Openandromaps Karten mit Elevate werden lcn Network Relationen und lcn=yes identisch dargestellt. Wäre meiner Meinung nach kein Ziel bei den Wanderwegen.

@Nop: Kannst Du genauer schreiben, wie du dir das meinst mit der Erfassung der namenlosen Wegen in Netzwerk-Relationen? Einfach eine Relation z.B. SAC-Netzwerk, DAV-Netzwerk, etc. im lwn, in die alle namenlosen Wege reingesteckt werden?

VG Reiner

Ganz im Gegenteil, das ist eine sehr geringe Anzahl von Wegen. Du mußt berücksichtigen daß es sich durch das Taggen direkt am Way normalerweise nur um Wegabschnitte handelt, nicht um komplette Wege im Sinne des Wortes. Oft von einer Kreuzung/Abzweige zur Nächsten, je nachdem wie beim Mappen durchgezeichnet oder neu angesetzt wurde, und falls auch markierte Routen oder andere Relationen darüber laufen häufig kleinräumig zerschnitten.

Nein, das wäre viel zu groß und in Richtung Sammelrelation.

Zunächst wäre ich immer bemüht, erst mal die Wege in einer normalen Routenrelation abzubilden. Nur weil ein Weg keinen hübschen offiziellen Namen hat, ist es kein Grund in fallen zu lassen. Eine Nummer zusammen mit dem Netzwerknamen reicht auch. Oder er hat immer noch einen Beginn und ein Ziel, das man als hilreiche Info verwenden kann.

Wenn es in einer Gegend System ist, viele kurze Wege ohne durchgehende Zielführung oder Richtung zu haben, dann würde ich pro Gegend und System eine Netzwerk-Routenrelation einrichten und alle entsprechenden Wege dort reintun. Nachdem alle markierten Wege einen operator haben, der sie markiert hat und pflegt oder zumindest ausweist, sollte sich immer ein Kriterium nach Betreiber, System und Gegend finden. Wenn Du sagst “hier im Schwarzwald…” hast Du ja schon einen Ansatz dafür genannt. Diese Netzwerkrouten würde ich aus praktischen Gründen möglichst klein und regional halten.
Wie das neue network Tag dann heißt, ist Geschmackssache, solange es eindeutig ist. :slight_smile:

Hmm, ich hätte ja gedacht, das mit den Netzwerkrelationen hätte JochenB aufgebracht, scheints blicke ich da nicht ganz durch:

ZB sind hierzulande einige Wege, die offiziell der OEAV selbst ausschildert als Route-Relationen gefasst, die mit den dreistelligen Nummern (es gibt da kein offizielles Verzeichnis, aber vor Ort sind sie nummermarkiert, oder wie immer das heißt), nicht alle, aber viele.

Die einzelnen Sektionen das Vereins betreuen darüber hinaus eine Menge Steige in den Bergen, die zwar ausgeschildert sind, aber weder Nummer noch Name noch eigenes Markierungsschema haben. Sie erfüllen also nicht die Ansprüche an eine Relation Typ=Route. Würde ich die nun alle in eine Relation Type=Network packen (aka Sammelrelation, “alle von der Sektion Hall das ÖAV betreuten Wege”), wäre das nicht widersinnig?

PS: Ich warte immer noch auf ein Beispiel einer Netzwerkrelation, die aus OSM ways besteht und nicht aus Relationen vom Typ=Route, als openstreetmap.org/Link bitte.

Aus meiner Sicht handelt es sich bei den Wanderwegnetzen, um die es hier geht, um das Äquivalent zu den Radverkehrsnetzen mit Zielwegweisung. Ich denke da jedenfalls z.B. an die gelben Wanderschilde in Tirol, die mir gut bekannt sind. Diese zeigen ein Ziel an, aber nur selten eine Routenbezeichnung (Zahl). Bisher gehe ich davon aus, dass man diese Wanderwegnetze genau nach der gleichen Methode erfassen könnte wie die Radverkehrsnetze.

Die Definition und das Tagging der Radverkehrsnetze hat JochenB im Laufe des Jahres hier beschrieben:

https://wiki.openstreetmap.org/wiki/DE:Bicycle/Radverkehrsnetze_kartieren

https://wiki.openstreetmap.org/wiki/DE:Relation:network

Ein Beispiel für solch eine Netzwerkrelation ist hier (Ich habe nur 1 Minute gesucht, evtl. gibt es bessere?):

https://www.openstreetmap.org/relation/1771415

Im Wiki steht nun abweichend zu diesem Beispiel, dass man bei großen Netzwerken die einzelnen Wegeverbindungen in eigenen Network-Relationen erfassen sollte, um große Sammelrelationen zu vermeiden. Die einzelnen Wegeverbindungs-Relationen werden dann in einer Netzwerk-Relation zusammengefasst.

Ich verstehe das folgendermaßen: Die Rad-/Wanderwege sind an allen relevanten Kreuzungen ausgeschildert. Dabei gibt es zwei Fälle:

  1. Der Weg führt nur in eine Richtung (“vor” und “zurück” sind ausgeschildert) (Zwischenwegweiser bei Radverkehrsnetzen)

  2. An der Kreuzung verzweigen sich mehrere ausgeschilderte Wege des gleichen Netzwerkes (Schilder in mehr als 2 Richtungen) (Pfeilwegweiser bei Radverkehrsnetzen)

Eine Wegeverbindung ist nun die Strecke zwischen zwei Kreuzungen der 2. Art. Das bedeutet, alle Linienelemente dieser Strecke kommen in eine network-Relation. Die Gesamtheit dieser Relationen bildet dann das vollständige Netz. Voraussetzung für solch eine separate Erfassung der Wegeverbindungen ist meiner Meinung nach, dass der Abstand zwischen zwei Kreuzungen der 2. Art ausreichend groß ist, damit die Wegeverbindungs-Relationen nicht nur aus 1-2 Linienelementen bestehen. (Evtl. wäre selbst das ok, ich kann die Nachteile einer großen Anzahl an (kleinen) Relationen bisher nicht abschätzen.)

Im Prinzip handelt es sich dabei um die gleiche Methode, die in den Niederlanden für die Knotenpunktnetzwerke (Beispiel: https://www.openstreetmap.org/relation/3119030)) entwickelt wurde. Mit dem Unterschied, dass Knotenpunktrouten eben eine eindeutige Bezeichnung sowie einen festen Beginn / Ende habe und daher mit type=route statt type=network getaggt werden.

In den letzten Tagen habe ich angefangen, dieses Netzwerk nach dieser Methode zu erfassen.

Meiner Meinung nach ist dieses Methode zumindest auf die Wanderwegenetze, die ich kenne (v.a. Tirol), gut anwendbar.

Ja, Insider tun sich leichter :slight_smile: Das Beispiel viel weiter oben ist mehrstufig geschachtelt, am untern Ende fand ich dann wieder nur Routen, nicht Wege. Diese dagegen enthält tatsächlich Wege. Beim Klick auf den Link hab ich mich zuerst gefragt, ist OSM down? so lang hat das Monster geladen.

Dokumentiert ist hier https://wiki.openstreetmap.org/wiki/DE:Relation:network - das gibt es laut Protokoll erst seit zwei Wochen, kann das sein? Es weicht auch sehr stark von der englischen Seite ab, die es zwei Jahre schon gibt. Es gibt dort auch einen Link auf ein archiviertes Proposal aus 2009, das immerhin den Jakobsweg als Beispiel anführt.

Ich nehme an, dass für solche Sammelrelationen entscheidend ist, dass sie ein Netzwerk bilden, d.h. dass alle Kanten im Graphen zueinander in Verbindung stehen. Bei einer kleinen Sammelrelation wie “Von der AV Sektion Matrei betreute Wanderwege” wäre das allerdings nicht der Fall. Vielleicht ist das im Südschwarzwald anders?

Ob die Relationen vom ‘type=network’ oder ‘type=route’ sind macht keinen Unterschied in der Handhabbarkeit, sie unterschieden sich nur durch den einen Wert.

Schöne Beispiele sind die zahlreichen Fahrradknotenpunktnetzwerke. Sehr gut handhabbar, da die Relationen übersichtlich kurz sind. Ein Blick in die Mitgliederliste einer Relation und man erkennt Lücken. Ein Blick in die MasterRelation und man hat alle enthaltenen Verbindungen und Knotenpunkte und kann die Strecken ins Nachbarnetz anhand der rolle ‘connection’ erkennen (Diese Verbindungen werden im Nachbarnetz ebenso in dessen Master-Relation aufgenommen). (Beispiel Relation 7801259 - Knotenpunktnetzwerk Ostprignitz-Ruppin)

Genauso kann man das restliche Radverkehrs/Wander-Netz mappen, dann halt ohne ‘network:type=node_network’ und 'rcn_ref='*. Ein zusätzliches Tag zur Unterscheidung Netz/Route braucht es dann nicht, das wäre unnötig redundant.

Fahrradnetze wurden bislang als network-Sammelrelation getaggt (Beispiel) oder als Routen. Beides ist nicht gut. Sammelrelationen mit über 2.000 Mitgliedern sind kaum noch pflegbar. Bei Tagging der Netzwerke als Routen ist kein Unterschied zwischen dem Fahrradnetz mit Wegweisung und den touristisch vermarkteten Themenrouten mehr möglich.

Ich habe als Beispiel eine der großen Fahrradnetz-route-Sammelrelationen in einzelne Netzverbindungen aufgeteilt: Relation 55602 - Radverkehrsnetz NRW, Kreis Mettmann. Bei Wegen mit Wanderwegweisung dann halt mit ‘network=lwn/rwn’ statt ‘lcn/rcn’.

Womöglich werde ich die Verbindungen vorerst wieder in route-Relationen zurücktaggen, weil wir noch die Diskussion führen müssen, ob man mit dem Erfassen wartet, bis Renderer das darstellen, oder ob die Rendererprogrammierer warten, bis entsprechende Daten massenhaft vorhanden sind.

Ja, ist erst sehr frisch. Im Englischen fehlt der Abschnitt Radverkehrsnetz. Dieser Abschnitt ist Ergebnis von anderen Diskussionen hier im deutschen Forum. Mein Englisch ist zu schlecht, um dass international zu diskutieren.

Sammelrelationen mit Wegen sollte man grundsätzlich vermeiden.

Ich hab das in Radnetz Mettmann gesehen, dass die Pflege sehr mühsam wird. Die Wege haben ja üblicherweise eine Reihenfolge, so dass man in JOSM Lücken/Fehler sofort erkennt. Wenn aber mehrere Verbindungen und Stichstrecken in eine Relation aufgenommen werden, hat man sofort Lücken, die keine Fehler sind. Wenn die Relationen dann groß werden, ist mit vertretbaren Aufwand nicht mehr machbar, die Lücken zu überprüfen ob das Fehler sind oder ob da eine neue Verbindung beginnt. Problem ist, dass sich die Wege beliebig in der langen Liste der Relations-Members verteilen und der benachbarte Wegabschnitt garantiert am snderen Ende der Liste ist. Man wird fast wahnsinnig dabei! Die Sortierfunktion von JOSM hilft dabei kaum.

Wenn man nur eine Relation für eine durchgehende Verbindung verwendet, ist es egal, ob sie Teil eines größeren Netzes ist und ob rechts und links andere Verbindungen anschließen. Wie Duvodas es gut beschrieben hat, kann man diese Verbindungen ja in eine Master-Relation aufnehmen, falls es sowas für die Region gibt. Muss man aber nicht.

Was mir bei dieser Seite fehlt ist der Quellennachweis zu den Diskussionen. Das wäre schon sehr wichtig, wenn man nur ins Wiki schaut, sieht es momentan so aus, als hättest Du Dir das im Alleingang ausgedacht.

Kannst Du den Verweis auf die Diskussionen dahinter auf der Seite ergänzen und hier auch nochmal posten?

Meiner Ansicht nach hätte dieses Neue Ding einen neuen Namen wählen sollen. Da wurde sehr großzügig Geschichte gestrichen. Der JOSM Preset für Netzerke baut auf das hier auf https://wiki.openstreetmap.org/w/index.php?title=Relations/Proposed/Network&oldid=1640636 und es gibt auch jede Menge Relationen derart in OSM die nun ganz plötzlich falsch dokumentiert sind, weil das Tag gekapert worden ist. Im taginfo macht sich so was natürlich gut.

Nachsatz: Es gibt freilich auch Relationen, die mit der vorherigen Fassung genausowenig übereinstimmen und trotzdem aktiv gepflegt werden. Nicht unüblich übrigens: Gestern erst teilte mir ein Kontakt in Australien mit, dass dort Wanderwege von highway=path auf highway=footway umgetaggt werden, weil sie ja durch die Ausschilderung “designated” sind.