Markiertes, namenloses Wanderwegenetze in *wn Network abbilden

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.

Gerne: https://forum.openstreetmap.org/viewtopic.php?id=66366. In den Diskussionsseite im Wiki war es schon verlinkt, hab es dort aber prominenter dargestellt.

Ich habe kein Problem damit, die Diskussion grundsätzlich nochmal aufzumachen ob man das “de facto” der langjährigen Nutzung von network-Relationen akzeptiert und dokumentiert oder ob das alles geändert werden muss.

Wichtig ist nur, dass man Netz ohne Routensymbole und Routen voneinander trennen kann.

Das sollten wir dann aber in einem neuen Thread machen, denn der Titel von dem hier passt nicht.

Was genau widerspricht sich mit bisherigen Definitionen?

Was ist dadurch nun falsch dokumentiert?

“Neu” ist gut, es gibt das seit weit über 10 Jahren in relevanten Größenordnungen, nur hat das niemand dokumentiert.

Neu ist lediglich, der Vorschlag, wie Sammelrelationen vermieden werden können. Wobei auch das ist nicht neu ist, es entspricht dem bekannten Vorgehen bei Knotennetzwerken.

Stimmt, wahrscheinlich fällt mehr Bestand in die neue Definition als in die alte, rein formal ist die ja um Welten breiter. Ich halte das allerdings nicht unbedingt für einen Vorteil. Da ist schon mehr neu, zumindest im Wiki, als nur ein Vorschlag, wie Sammelrelationen vermieden werden können. Für meinen Geschmack ist jetzt zu viel Verschiedenes unter einem Hut. Enge Definitionen sind schneller vermittelt und machen auch das Validieren leichter. Aber das sind nur meine Bedenken, und wir sind hier eh schon so weit vom Thema, dass ein neuer Thread nicht schaden kann.