Markiertes, namenloses Wanderwegenetze in *wn Network abbilden

In Anbindung an Hungerburgs Thread über den Tag hiking=yes möchte ich folgenden Vorschlag machen:

Im Schwarzwald (Schwarzwaldverein), Schweiz (SAC), Österreich (Hungerburgs gelbe Schilder, ÖAV?), Allgäu (DAV) und sicher auch anderen Regionen gibt es bei dem Wanderwegen ein Beschilderungssystem mit einheitlichem Netzwerkcharakter (anstatt einzelne separat beschilderte Wanderwege). Hierbei haben die Wanderwege keine Namen oder Nummern, sondern werden einfach über ein fixes System beschildert. Z.B. Schwarzwaldverein mit gelber Raute, SAC mit gelb/rot/blau System, Österreich die von Hungerburg beschriebenen gelben Schiler. Ein System mit vornehmlich einzeln markierten Wegen gibt es zum Beispiel in den Vogesen.

Um auch diese Wege als markierte Wanderwege abzubilden und in Karten einfach sichtbar machen zu können, könnte man so vorgehen:

  • Das lwn so belassen wie es ist und darin nur die lokalen, in Relationen erfassten Wanderrouten erfassen. Somit können die auch von den Kartenprogrammen separat erfasst werden, was sinnvoll ist.

  • Wir schaffen eine weitere Stufe im *wn System. Eine Möglichkeit wäre, darin die kompletten Wegenetze der jeweiligen Betreiber (wie oben) in getrennten Relationen zu erfassen. Also gewissermaßen ein Netz der operator, “own”, mit Relationen Schwarzwaldverein, SAC, DAV, ÖAV, aber auch gerne Gegenden, Gemeinden, die nicht an ein großräumigeres Beschilderungssystem angeschlossen sind und eine eigene Beschilderung haben. Jeder Weg der von als Wanderweg beschildert ist, wird in die entsprechende Relation aufgenommen. Dieses Netzwerk ist sozusagen das Basinetzwerk.

Damit ist die Zuordnung jeweils klar und es gibt die Möglichkeit die beschilderten und somit ausgewiesenen Wanderwege zu erfassen (mit klarem Kriterium). Die Kartenprogramme können dann die lwn, rwn etc. Netzwerke anzeigen oder die kompletten Netzwerke in diesem Basisnetzwerk.

Was meint ihr dazu?

VG Reiner

Ich halte das für eine sehr schlechte Idee.

Für solche Wanderwegnetzwerke ist es seit vielen Jahren etabliert, eine Netzwerkroute anzulegen. D.h. alle diese Wege kommen in eine Routenrelation, die dann halt keinen Richtungscharakter hat, aber alle anderen Informationen wie lwn/rwn, Betreiber, Markierung, Bezeichnung des Netzwerks ganz normal abbildet, wie bei allen anderen Wanderrouten auch. Ein Beispiel dafür sind die Wanderwegnetze mit dem Gelben Diamanten in der Schweiz.

Es ist nicht notwendig noch was neues daneben zu erfinden bzw. etwas altes und schlechteres wieder aus der Mottenkiste zu holen.

Auf der anderen Seite habe ich die lwn usw. Tags direkt an Wegen für Radwege immer als Altlast empfunden, aus der Zeit bevor es Relationen gab um Routen vernünftig als übergreifende Route abzubilden. Ich bin sehr froh, daß es bereits bessere Möglichkeiten gab, als das Taggen von Wanderrouten aufkam. Das xwn-Modell mit allen seinen Nachteilen sollte man eher auslaufen lassen anstatt es auf weitere Themen auszudehnen.

Zum einen ist es grundsätzlich schädlich, zwei verschiedene Möglichkeiten für dieselbe Sache aufzubauen - vor allem wenn man ausnahmsweise schon ein einheitliches Schema etabliert hat. Das eröffnet dann jede Menge neue Probleme, z.B. die Möglichkeit für widersprüchliches Tagging, die Notwendigkeit für doppelte Arbeit bei Änderungen und Uneinigkeiten zwischen direkten Wegtaggern und Routentaggern.

Zum anderen führt es gleich noch zu der Frage, wie man bei Tags direkt am Weg die übrigen Informationen wie Namen oder Markierungsschema abbilden will. Auch hundertfach redundant direkt an den Weg pappen? Das wird ganz schnell uferlos bzw. auch technisch nicht mehr möglich bei Wegen die zu mehreren Routen oder Netzwegen gehören. Für Routen ist das alles schon gelöst, warum neue Probleme schaffen?

Hallo Nop,
wenn Du dann aber Wanderrouten aus den verschiedenen Netzwerken in einem Kartenprogramm darstellen möchtest, hast du neben den “echten” benamten Wanderrouten auch immer diese Netzwerke mit dabei. Das macht die Darstellung in einer Karte sehr unübersichtlich.

In meiner Region im Südschwarzwald ist das zum Beispiel beim *CN der Fall, da sind bei Darstellung des lcn “echte” Fahrradrouten mit dem Basisnetzwerk gemischt.

Das ist ja auch der Grund für meinen Vorschlag.

VG Reiner

Moin,

Hinter der Lösung mit den network-Relationen steht ja genau die Idee, das “Grundnetz” aus ausgeschilderten Rad-/Wanderwegen von den speziell markierten Rad-/Wanderrouten unterscheidbar zu machen. Der Renderer hat somit die Möglichkeit das lcn-Grundnetz ggü. den markierten lcn-Routen schwächer hervorzuheben (Grundnetz: network-Relationen, Routen: route-Relationen, beide mit ‘route=bicycle/hiking’).

Aufpassen muss man dabei, dass es keine riesigen Sammelrelationen* werden. Daher im Wiki die Empfehlung, für jede Verbindung zwischen zwei Verknüpfungspunkten jeweils eine eigene Relation zu erstellen, ähnlich dem Knptenpunktnetzwerken, nur eben, dass die Knoten und Wegeverbindungen keine Nummern haben.

edit: Beispiel hinzugefügt

Wenn mit “Netzwerkroute” nicht network-Relation sondern route-Relationen gemeint sind, dann ist es nicht möglich, die durchgehenden Wege mit Namen vom restlichen Netz zu unterschieden. Genau darum geht es Reiner meines Erachtens.

Bei Fahrradnetzen wird daher zwischen network- und route-Relation unterschieden, siehe die neue Wiki-Seite DE:Relation:network.

Ich vermute, du meinst etwas anderes. Wanderrouten haben Beginn oder Anfang und sind durchgehend einheitlich markiert, häufig haben sie einen Namen (z. B. ‘Jakobsweg’). Hierfür sind alles andere als route-Relationen nicht zielführend.

Dann gibt es aber noch Wege, die zwar Wanderwegweiser haben, sonst aber nichts. Maximal vielleicht ein Symbol für “sonstiger Wanderweg”, dass in der Region immer für kurze Zubringer- oder Verbindungsstrecken steht, aber nicht für längere durchgehende Strecken verwendet wird.

Hier sollte es eine Abgrenzung geben. Elegant wären network-Relationen wie bei Fahrradnetzen. Elegant aber nur, wenn eine network-Relationn nur eine duchgehende Verbindung beschreibt, keine Sammelrelationen.

Aber ob Relationen wiklich angemessen sind, hängt auch davon ab, was der Mapper damit erreichen will.

Relationen können m. E. folgende Zwecke haben:

  1. Informationen an einer Stelle speichern und pflegen statt an jeder Kante

  2. ggf. Beziehungen zu anderen Relationen setzen (Eltern-/Kinderrelationen)

  3. ggf. Elementen Rollen geben

  4. ggf. Elemente in eine Reihenfolge bringen

  5. ggf. im Editor in einer Reihenfolge Lücken erkennen

Wenn ein Mapper ledglich markiern möchte, dass der Weg eine Wanderwegweisung hat, dann hat er eine einzelne Zusatzinformation. Es ist also nur ein einzelner Tag im Anwendungsfall 1) (‘lwn=yes’ “Weg gehört zum lokalen Wanderwegnetz”). Hier Relationen zu verwenden ist aufwendiger und komplizierter und ein wenig wie “mit Kanonen auf Spatzen schießen”.

Mir wäre es lieber, der Mapper setzt ein ‘lwn/lcn=yes’ an den Weg, als dass er den Aufwand scheut, dafür eine Relation zu erzeugen, die ‘network=lwn/lcn’ als einzige Information hat. Die Renderer müssten dann das ‘lwn/lcn=yes’ genauso darstellen wie eine network-Relation mit ‘network=lwn/lcn’, was sie vermutlich bereits tun.

Wenn ein anderre Mapper dann weitere Informationen und Anwendungsälle erstellen will, dann kann und sollte er daraus eine Relation erstellen. Er sollte dann aber das ‘lwn/lcn=yes’ an den Wegen löschen, um Redundnazen und Risiko von Widersprüchen zu vermeiden.

Eine weitere Ebene im ‘network=in/mn/rn/ln’ finde ich nicht notwendig. Wenn route-Relationen die durchgängig markierten Wege darstellen, network-Relationen und ‘lwn/lcn=yes’ dagegen das restliche Grundnetz, so ist die Unterscheidung dadurch möglich.

edit: falsch zitiert

Wenn es Dir um die Unterscheidungsmöglichkeit geht, dann ist es völlig ausreichend, die Route-Relations so zu taggen, daß man den Unterschied zwischen einem Wanderweg und einem Wandernetzwerk erkennen kann, am besten mit einem neuen Tag. Das wäre sehr einfach zu mappen und sehr einfach auszuwerten

Genau darum geht es mir. Wie wäre sowas möglich? Kannst Du mal ein Beispiel machen?

Ich bin in den Relationen, sobald es über das Anlegen einer einfachen Relation hinausgeht, relativ unbewandert. Ich bin mir auch nicht sicher, ob wir sprachlich beide genau dasselbe meinen. Ziel wäre für mich, markierte Wege, die nicht Teil einer als Relation erfassten Wanderroute sind, zum lwn hinzuzufügen, aber von diesen Wanderrouten unterscheidbar zu halten.

VG Reiner

Begriff Netzwerke: Weil vorgeschlagen wurde, sich ein Beispiel an der Erfassung von Radfahrnetzen zu nehmen, probehalber einen kurzen Radweg “Zentrum→Badeteich” in den Editor geladen und den Typ der Relation von Route auf Network umgestellt - siehe da, der Validator meckert. Im Wiki nachgeschaut, rechtens so: Relationen vom Typ Network können nur aus Knoten und Relationen bestehen; Linien sind nicht vorgesehen. Im ersten Satz vom Artikel https://wiki.openstreetmap.org/wiki/DE:Bicycle/Radverkehrsnetze_kartieren ist von Wegen die Rede (ich lese das im Sinn von Way/Linie/Kante), gemeint sind Routen (Relationen). Wird das auch hier immer korrekt verwendet? Ich bin nicht ganz sicher.

Wanderkarten: Hier wie im andren Thread, geht es darum, wie man die Datengrundlage erweitert/verbessert, aus der sich anwendungsfreundliche Wanderkarten ableiten lassen. Meine naive Idee, dass sich das Füllen von Lücken eventuell per Tag beschleunigen ließe hab ich inzwischen begraben bzw. historische Ansätze dazu begraben lassen. Zu einem Wander- oder Spazierweg und damit für Hervorhebung auf einer Wanderkarte geeignet wird ein Weg in der OSM dadurch, dass er in einer Relation vom Typ Route und einer Route vom Typ Hiking oder Foot gefasst ist.

So, und jetzt den Thread noch einmal von vorne lesen, vielleicht gibt es hier etwas das neu ist!

So schwierig war das Neue nun gar nicht zu finden: Das Bilden jeder Menge Routen Relationen für diesen Flickenteppich, aka Wanderwegnetz, namloser, hierzulande von Gemeinden, Forstämtern, Tourismusverbänden, Alpenvereinssektionen ausgeschilderter Spazier- und Wanderwege, so gerne man diese auch auf Karten oder in Apps hervorgehoben haben will, müllt letztendlich die Karten zu! Betroffen sehe ich da vor allem den Bereich lwn. Deshalb vielleicht der Vorschlag eingangs, jene Routen stattdessen mit network=own anzuschreiben – was nicht als Sammelrelation für vom selben Operator betreute Wege missverstanden werden darf, und schon gar nicht als Relation vom Typ Network, sondern eben als eine Art, jene Routen von denen des “lwn” unterscheidbar zu machen/halten.

Gehe ich da richtig? Und, so verstanden, was spricht gegen die Einführung eines vierten Network für Routen? Der Name own scheint allerdings missverständlich: wäre “cwn” wie “communal” besser, könnte auch wie “club” gelesen werden… Vom Gedanken eines “Basisnetzwerkes” würde ich absehen, was schon “lwn/rwn” ist, braucht nicht doppelt erfasst werden.

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