Bitte beachten: ‘designated’ bedeutet offizielle Widmung
eines Wegs.
Das Aufstellen von Bänken, prompte Beseitigung v. Schäden, Pflege trifft auch auf den innerstädt. 20m-Parkweg im Kreis zu. Die Eindeutigkeit fehlt mir hier bei deinen zunächst aufgezählten Kriterien. Eine Widmung hingegen mit Ausschilderung hat einen Namen, Markierungszeichen etc. und man erkennt eindeutig: das ist ein Wanderweg, selbst wenn er miserabel gepflegt sein sollte.
OSM hatte schon immer Lücken, die gerade deshalb neue Mapper zum Schließen animiert hat und OSM weiterbrachten. Wenn die Schweiz auf dem Gebiet recht vorbildlich ist, dann kann mit den vorhanden tags ein Wanderweg wohl ausreichend eindeutig dargestellt werden. Das Problem liegt dann vielleicht eher im unpraktischen Handling durch die Editoren.
Gruß, Cepesko
Ich weiß nicht, wo manche hier unterwegs sind, aber hierzulande ist OSM für ortsfremde Wanderer, im Sinn von Leuten auf ausgedehnten Spaziergängen, meines Erachtens, sagen wir einmal, ein wenig heikel - und ich meine damit nicht nur mapnik - weil da in den Wäldern soviel path herumhängt, von dem sich herzlich wenig ableiten lässt, was einen erwartet (was durchaus seinen Reiz haben kann, wenn man drauf aus ist). Natürlich können die Leute auch einfach den Wegweisern folgen und aufs Navi verzichten, aber wozu machen wir das dann?
PS: foot=yes am path finde ich redundant, das ist implizit, wenn nicht extra verneint; scheint mir eindeutig ein access-tag. Ein von der Gemeinde oder dem TVB aufgestellter Wegweiser (die gelben, wer die kennt) erfüllt in meinen Augen das “designated”. Solche Wege werden gepflegt, sie haben deswegen noch lange keinen Namen, kein Symbol, keine Homepage etc. Für eine Relation müsste man das alles erfinden. Oder eine Relation bilden “Wanderwege Ortsname” und alles hineinpacken?
Wenn es darum geht, ausgeschilderte Wege zu markieren ohne gleich Relationen zu verwenden, scheint tatsächlich ‘lwn/rwn=yes’ das Beste zu sein, ‘sac_scale=hiking’ sagt ja nichts über die Wegweisung aus.
Bei Wanderwegen ist ‘lwn/rwn=yes’ direkt am Weg vielleicht selten. Beim Radnetz war das mit ‘lcn/rcn=yes’ zumindest mal regional gängige Praxis an Stellen, wo zwar eine Radwegweisung da ist, aber keine markierten Themenrouten o. ä. darauf verlaufen.
Vermutlich werden die Renderer mit ‘lwn/rwn=yes’ am Weg gut klar kommen, denn ob das Tag aus einer Relation kommt oder direkt vom Weg, solllte dem Renderer egal sein.
Wenn man das Wge mit Wegweisung abr ohne Route mit Relationen abbilden will, sind beim Radverkehrsnetz auch network-Relationen üblich, als Unterscheidung zu den route-Relationen der Themenradwege. Könnte man bei Wanderwegen ebenso machen, wenn es nicht sogar schon so gemacht wird.
Wie kommst du zu der Aussage dass in niedrigen Lagen alles “gleich” aussieht? Ausgeschilderte Wanderwege können als Relation erfasst werden.
Zudem gibt es z.B. die Keys surface=*, smoothness=* und trail_visibility=*, die den Wegzustand beschreiben. Hast du mal versucht, diese Keys in deiner App darzustellen?
Ich sehe hier eher das Problem, dass es in manchen Regionen einfach zu wenige/keine Mapper gibt, die sich um die Erfassung von Wanderwegen kümmern. Daran wird auch die Einführung eines neuen Keys “hiking=yes” nichts ändern.
Für die Erfassung des Wegszustands gibt es die Keys surface=, smoothness= und trail_visibility=*, daraus lässt sich glaube ich ganz gut ableiten, was einen erwartet, und ob man den Weg z.B. mit einem Kinderwagen benutzen kann.
Zusammenfassend:
Für die Erfassung des Wegzustands gibt es die Keys surface=, smoothness= und trail_visibility=*
Für die Erfassung von markierten Wanderwegen gibt es die Relation route=hiking/foot
Für die Erfassung von Zugangsregeln gibt es die Keys access=* bzw. foot=*
Mir erschließt sich nicht, was darüber hinaus mit einem Key hiking=yes abgebildet werden soll.
Nu wenn jetzt jemand “network=Bismarktürmeroute” wie auf Deiner Wikiseite beschrieben verwendet, ist das aber schon wieder hinfällig. Und leider haben wir mal wieder keinen Standart, denn im Grunde baut ihr mit dieser Interpretation darauf, dass redudante Informationen in der Datenbank gepflegt werden.
eigentlich bräuchte man fuer die gesamte “baugruppe” die gleichen Keys wie fuer inlineskating Tja und bei Schneemobilen, Wintercrosscountryrouten (“Wandern mit Hilfsmitteln bei Schnee” - teils ueber geforene Seen) existiert scheinbar ueberhaupt keine Einigkeit.
Den Einwand verstehe ich nicht. Es gibt keine Bismarcktürmeroute. Das auf der Wikiseite erwähnte Tag network=Bismarcktürme wird direkt an die Türme getaggt. Es handelt sich also überhaupt nicht um Wege.
Das verstehe ich noch weniger. Wen meinst du mit “ihr”? Soweit ich sehe, sind hier die meisten Beitragenden der Ansicht, dass die Information “Dieser Way ist Teil einer markierten Wanderroute” am sinnvollsten dadurch abgebildet wird, dass er member einer Relation mit route=hiking ist. Das ist dann doch gerade KEINE redundante Information. Wenn man zusätzlich noch hiking=yes dranpappen würde, DAS wäre redundante Information. (Und ich will gar nicht wissen, wie oft dieses Tag versehentlich stehenbleibt, wenn eine Wanderroute verschwindet, und dann als falsche Information in der Datenbank steht.)
Nun, die meisten. Allerdings sind Relationen leider nicht fuer alle Mapper zugänglich und scheinbar braucht es einfacherer Wege, die ja hier vertreten werden. In dem Beitrag geht es ja gerade darum ob ein tag hiking=yes an den Weg und nicht in eine Relation gepackt wird. Die meinte ich mit “ihr”.
Weiß nicht, ob wirklich eine Alternative zur Relation gebraucht wird. Wir können auch die Ansicht vertreten, dass mann es lassen sollte, wenn es einem zu kompliziert ist.
Wenn doch: Hauptsinn von Relationen ist m. E., dass Tags, die für alle Mitglieder gelten, an einer Stelle zusammengefasst werden. Zudem bekommt man zusätzliche Struktur-Ebene, z.B. mit einem eigenen ‘name’-Tag und die Möglichkeit, Elementen bestimmte Rollen zu geben.
Die Alternative zu Relation ist damit, die Tags anstatt an die Relation direkt an den Weg zu taggen. Also nicht ‘hiking=yes’ sondern *'network=wn’. Wobei die bereits definierten Standardwerte von ‘network’ verwendet werden sollten.
Der Nebennutzen, also zusätzliche Strukturebenen und Rollen sind dann freilich nicht möglich.
Dann gibts noch die Fälle, wo gar keine route-Relation angebracht wäre, also wo gar keine Route langgeht und auch keine sonstige Wanderwegweisung vorhanden ist. Dort reicht ja bereits ‘sac_scale’.
Also kein Bedarf nach einem neuem, zusätzlichen und missverständlichen Tag.
Wenn man die bisherig gesetzten ‘hiking=yes’-Tags als Access-Tags interpretiert, sind sie aber auch nicht schädlich.
“hiking=yes” kann ich als Hinweis an nachfolgende Mapper akzeptieren, dass sie mal prüfen sollten, ob dort nicht ein relationswürdiger Wanderweg langführt. Ich bin auch schon “symbol=red_bar” begegnet - so etwas kann hilfreich sein, wenn man selbst später weitere Markierungsfragmente findet und versucht, eine Relation zusammenzustöpseln.
Ansonsten ist hiking=yes aus meiner Sicht eher überflüssig. Zum Glück ist es aber auch unschädlich.
Vielen Dank allen, die konstruktiv beigetragen haben, nicht wenige sogar aus unmittelbarer Teilnahme an der Sache selbst, nämlich der Kartierung von Wanderwegen.
Der Tenor ist allerdings auch nicht zu überhören, dass es die Wanderrelationen gibt und die das primäre Mittel sind für Renderer/Router/Apps zu erkennen, ob es sich bei einem Weg um einen Wanderweg handelt.
Einerseits finde ich das schade, weil Relationen das Mappen aufwendiger machen und für Einsteiger die Schwelle höher. Und wenn ich mir die Schweiz ansehe, die als Musterbeispiel zitiert wurde, dann beeindruckt mich das Ergebnis auch ganz und gar nicht. Es gibt dort jede Menge ein-Mitglied-Relationen, was bei Multipolygonen zB als schlechter Stil gilt. Nicht wenig wundert mich auch, wie viele Orte “fixme” es in der Schweiz gibt.
Ein paar alternative Tag-Vorschläge hab ich mir näher angesehen und festgestellt, dass es gar alles schon gibt, manches mehr, manches zB https://overpass-turbo.eu/s/11dT weniger. Nebenbei tun sich da wahre Kuriosenkabinette auf.
Der mir persönlich liebste Tag “hiking=designated” wäre allerdings erst einzuführen. Der könnte auch nicht mit einem access-tag verwechselt werden. Einem proposal das dann zu accepted wird gebe ich freilich null Chance. Warum einfach, wenn es kompliziert auch geht. Deshalb werde ich im Wiki das hiking=yes auf Wegen nicht dokumentieren um nicht Salz in offene OSM-Wunden zu streuen, und auch weil ich selbst es nicht präzise genug empfinde. Genau so wenig wie ich nun damit anfangen werde, Wanderrelationen anzulegen. Aber das ist eine andere Geschichte.
PS: Dass es für Wegbeschaffenheit usw. Tags gibt, das steht seit ein paar Tagen schon im Wandern Artikel im Wiki, das hab ich hier nicht zum ersten Mal gelesen Wie kann ich den Topic auf [Erledigt] stellen?
Das wollte ich auch als Argument anführen, quasi eine Art, wie Wanderer/innen mit Couchmappern kommunizieren, du hast das besser auf den Punkt gebracht. Nicht vergessen dabei, die Wegweiser fotografieren, kartieren und die “destination” eintragen, damit die Relationen auch halbwegs sinnvolle Namen bekommen können. Vielleicht überleg ich mir das mit dem Dokumentieren noch einmal
Deine Ausgangsfrage in dem Thread ist: Sollte das dokumentiert werden - oder nicht?
Nun wenn man die Diskussion liest, merkt man ja, dass es sehr sinnvoll ist, das tag zu dokumentieren. Es wird oft verwendet - auch wenn es garnicht empfehlenswert ist und im Zweifelsfall Fragezeichen hervorruft, wozu es eigentlich gut ist.
Aber: Auch Tags gegen deren Verwendung einigs spricht, sollten doch dokumentiert werden, damit klar und nachlesbar ist, was gegen die Verwendung spricht und welche Alternativen es gibt.
jein, sie schaden nicht direkt, aber weil sie auch keinerlei Nutzen bringen (wie es zumindest bisher scheint), schaden sie weil sie unnötig Platz belegen (nicht nur in der db sondern auch im Editor, jeder Mapper der das anfasst muss es lesen und sich überlegen was er damit macht), und weil neue Mapper davon verwirrt werden könnten und evtl. diesen vermutlich unnötigen tag weiterverbreiten würden, d.h. er führt unnötig zu Fragmentierung des Modells
Naja, dokumentiert ist es ja, seit 2009 sogar - https://wiki.openstreetmap.org/w/index.php?title=DE:Key:access&oldid=350490#Gesetze_vs._Eignung - Davor war es tatsächlich als Wert für access geführt. Ich seh das ähnlich wie dieterdreist. Schlafende Hunde braucht man nicht wecken, die Warnung davor ist im Talk zum Schlüssel inzwischen auch gut auffindbar. Ich werde am Artikel nichts ändern. Dummerweise fällt mir nichts ein, wie man schnell und unkompliziert Wanderwege ausweisen kann, was auch die Relationsfanatiker zufriedenstellt.
Hierzulande verblassen an vielen lwn Wegen die Markierungen, es werden nur mehr die Gelben Tafeln aufgestellt auf denen Ziele draufstehen ohne Wegnummern/namen. Wohl billiger so, die Wege sieht man problemlos am Boden. Hie und da entstehen “Themenwanderwege”, es genügt eben nicht mehr, einen Weg von A nach B auszuweisen, sondern es muss mindestens noch dabeistehen, was es dabei zu Erleben gibt; die bekommen dann Namen, Symbole usw. Alles was eine Relation so braucht…
Im Schwarzwald ist es ähnlich. Neben den ausgewiesenen Wanderrouten, die als eigene Relation erfasst sind und im lwn etc erfasst sind, gibt es noch die einfach markierten Wanderwege. Der Schwarzwaldverein ist davon abgekommen, für jeden Weg einen eigenen Markierungstyp zu verwenden, sondern verwendet für alle Wanderwege übergreifend die gelbe Raute (schafft also ein echtes Wanderwegnetz). Wenn der Weg zusätzlich noch in einer übergeordneten Route drin ist, kommt noch das entsprechende Routenschild dazu.
Soweit ich das sehe, kann ich z.B. zum lwn nur in Relationen erfasste Wanderwege aufnehmen. Den ganzen Rest kann ich, soweit ich das verstehe, nicht in das lwn aufnehmen, außer ich schaffe eine Relation z.B. “nicht in anderen Relationen erfasste Wege” und nehme sie darin auf. Bitte korrigiert mich, wenn ich da falsch liege, so ganz durchschaue ich das nicht.
Wäre es nicht sinnvoll, alle markierten Wanderwege im Netzwerk zu erfassen? Nicht jetzt über hiking=yes, sondern über eine Zugehörigkeit zum lwn?
Ich möchte den Vorschlag etwas konkretisieren:
Das Beschilderungssystem mit einheitlichem Netzwerkcharakter (anstatt einzelne separat beschilderte Wanderwege) kenne ich vom Schwarzwald (Schwarzwaldverein), Schweiz (SAC), Österreich (Hungerburgs gelbe Schilder, ÖAV?), Allgäu (DAV). Ein System mit vornehmlich einzeln markierten Wegen gibt es zum Beispiel in den Vogesen.
Von daher:
Das lwn sollte so bleiben wie es ist und 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
PS: Da ich, wie auch Hungerburg, schon lange in erster Linie Wanderwege mappe, ist das eine Sache, die mir auch schon länger am Herzen liegt.
Tja und bei Schneemobilen, Wintercrosscountryrouten (“Wandern mit Hilfsmitteln bei Schnee” - teils ueber geforene Seen) existiert scheinbar ueberhaupt keine Einigkeit.
Wie kann ich den Topic auf [Erledigt] stellen?