Hallo zusammen,
ich bräuchte mal wieder etwas Hilfe. Wie tagge ich am besten einen Wanderweg der dann teilweise in Ortschaften über normale Straßen läuft?
Im Moment ist der Wanderweg wie folgt angelegt:
highway=footway, route=hiking, name=Weinwanderweg
Die Straße wie gewohnt:
highway=residental, name=strassenname
Wie tagge ich am sinnvollsten? Soll ich beide Namen erwähnen?
Vorab danke für eure Infos.
Gruß
Christian
Der Weg ist aktuell falsch gemappt. Wanderwege werden nicht direkt am way getaggt.
Richtig wäre:
name und route sollten an allen diesen Wegen entfernt und die Wege in die Relation eingehängt werden.
Mehr dazu hier: http://wiki.openstreetmap.org/wiki/DE:Hiking
bye, Nop
Mir ist nicht ganz klar, was das Tagging der Straße mit dem Wanderweg zu tun hat… Die entsprechenden Abschnitte der Straße kommen einfach mit in die Wanderweg-(Routen)-Relation, genau wie der Fußweg,
Vielleicht etwas OT:
Meine beiden Vorredner haben zwar recht mit den Routen (und mach ich auch brav so), aber man findet sehr häufig Wanderwege, die nur mit sac_scale=hiking getagged sind, dann noch die Wanderwegweiser und das war’s auch schon. Alles was nicht “path” ist, ist dann eine Lücke, weil das bei JOSM z.B. nur für “path” drin ist. Das führt dann bei Lonvias Wanderkarte zu vielen Wegweisern, die einfach so in der Gegend rumstehen. Das seh ich mehrheitlich bei Wanderwegen, vielleicht weil das Wiki das etwas provoziert. Sac_scale gibt ja eher die Wegbeschaffenheit an; dass da lieber Relationen verwendet werden sollen, kommt dann ganz am Schluss.
Ich häng Wanderwegstücken, die mir beim Mappen unter die Füsse kommen (wenn ich nur Teilstücke finde), gerne mal ein note=markierter Wanderweg dran. Das hilft mir später, den Weg wieder zu erkennen und vielleicht auch einem Mitmapper, der nicht den ganzen weg abgeht.
Also: Den von Nop verlinkten Wiki-Artikel von unten lesen 
-kuede
Es gibt sowohl sac_scale als auch Wegweiser unabhängig von Routen (hier markierte Wanderwege). Beides ist also kein sicherer Hinweis auf Wanderrouten.
Edbert (EvanE)
Nop hat völlig recht. Auf’m Navi isses dann immer wieder mal anders und die Namen sind zu lesen.
Um welchen Weg handelt es sich? Ich denke ich kenn mich dort aus 
Das habe ich mir zwischenzeitlich auch angewöhnt: Das Stück Weg oder den Wegweiser mit note=roter Punkt (und gelber Strich) … und eventuell description=von hier nach Westen roter Punkt, nord - süd= gelber Strich angewöhnt. Und vor allem sollte eine Relation z.B. Gelber Strich unterteilt werden (von Ort zu Ort oder andere POI).
Nein, sollte er nicht. Ein Wanderweg ist ein von einer Organisation zusammengestelltes und veröffentliches Ganzes. Es macht grundsätzlich keinen Sinn, dieses definierte Objekt willkürlich in Stücke zu teilen. Es erschwert lediglich die Bearbeitung, da man erst mal nachvollziehen muß, welches von mehreren Fragmenten man eigentlich braucht und alle Informationen müssen mehrfach eingetragen und gepflegt werden. Am Besten weil am Einfachsten ist eine Relation pro Wanderweg.
Einziger Grund für eine Aufteilung sind technische Restriktionen von OSM. (Annäherung an die 2000 Ways, erschwertes Handling im Editor durch zu große räumliche Ausdehnung)
Natürlich kann es in einer Region mehrere disjunkte Wege mit derselben Farbmarkierung geben. Das sind dann aber unterschiedliche Wanderwege, keine Aufteilung.
bye, Nop
Darin und in fast allen anderen Punkten stimme ich Dir ja zu, aber
beruht wohl auf einer Verwechslung. Wege sind auf 2000 Knoten beschränkt; Relationen nicht (vgl. auch Monster relations). Ungeachtet dessen sind beliebig große Relationen irgendwann nicht mehr handhabbar und belasten in unverhältnismäßigem Ausmaß Editor, API und Datenbank, sodaß eine Aufspaltung Sinn machen kann - allerdings sicher nicht in Abschnitte von einem Kaff zum nächsten.
Einspruch: Das führt bei Fernwanderwegen zu Monsterrelationen, die nicht mehr vernünftig zu handhaben sind.
Es gibt ein Proposal für das Aufteilen von Routen mit Tag segment=yes, die in die Gesamtrelation als Mitglied in der richtigen Reihenfolge aufgenommen werden. Damit hat man sowohl die Gesamtübersicht als auch die Möglichkeit, gezielt nur Teile zu bearbeiten. Wer mal eine Relation mit ein paar hundert Mitgliedern im Editor hatte, kann da vielleicht nachfühlen.
Durch Beschränkung auf Tiefe eins (also keine Segmente im Segment) kann man den Aufwand für die Werkzeuge m.E. auch gering halten.
Diese Segmente können auch Mitglied unterschiedlicher Relationen sein, wenn mehrere Routen dasselbe Teilstück verwenden. Dadurch spart man sich gerade die Mühe des Mehrfachpflegens (Redundanz), wenn mal in diesem Abschnitt ein Teilstück z.B. wegen Neubau geändert werden muss. Die für die Gesamtroute charakteristischen Attribute stehen in diesem Fall zwingend in der Elternrelation, nicht im Segment.
Dieses Verfahren kann auch auf andere Relationen mit Type=route wie Radrouten, Buslinien angewendet werden. Es muss dazu nichts grundsätzlich neu eingeführt werden, denn Relationen dürfen auch bisher schon alles enthalten, auch andere Relationen. Das Tag segment=yes macht nur deutlich, dass dies keine eigenständige Route ist, sondern noch in einer Elternrelation enthalten sein muss.
Dann sollte aber die Relation nicht die Bezeichnung des Wanderwegzeichens erhalten. Leider wird als Name mesit nur “Roter Punkt”, “Grüner Strich”, … verwendet
Z.B wurde vielfach “Gelber Strich” als Name angegeben. So ergab der “Gelbe Strich” Dippoldiswalder Heide mit “Gelber Strich” Kahleberg - Rehefeld und “Gelber Strich” Rundweg Schmiedeberg mit “Gelber Strich” Rundweg Obercarsdorf in einer Relation geführt. So wird auch alles was Grüner Punkt oder Roter Strich oder … hat in einer Relation “gesammelt”.
Des wegen finde ich es besser, die Relationen nach Ort zu Ort oder POI zu POI oder nach dem Namen (falls vorhanden) in Relationen zu erfassen. Wenn der “EB” über Thüringen, Sachsen, CZ und Ungarn führt können diese Teilstücke als einzelne (Teil-)Relation erfasst und in einer (Sammel-) Relation vereint werden - ist m.E. leichter editierbar und weniger Fehleranfällig.
Zum Beispiel der Gelber Strich unserer Gemeinde:
Rund um Schmiedeberg (teiilweise grüner Punkt vom früheren Rundweg)
Rund um Dönschten
Rund um Obercarsdorf (mit Abkürzung Kleine Runde)
Rund um Hennersdorf
Rund um Schönfeld mit (kleiner Runde: Rundweg Schönfeld )
Rund um Naundorf (mit Schlossparkrunde)
Naundorf-Sadisdorf-Hennersdorf-Ammelsdorf-Schönfeld (hier auch Bestandteil Rund um Naundorf, Rundweg Hennersdorf und Rundweg Schönfeld)
Schmiedeberg-Brand-Kipsdorf-Tellkoppe-Oberbärenburg
Obercarsdorf-Naundorf-Schmiedeberg-Döntschten
Obercarsdorf - Oberfrauendorf
Alle haben nur die Bezeichnung auf der Karte der Gemiende “Rundweg” (rote Linie) oder “Wanderweg” (violette Linie). An den Rundwegen gibt es nur Pfeil “Rundweg” mit Zeichen “Gelber Strich” oder den Pfeil mit “Ortsangabe”.
Die o.g. Bezeichnungen sind von mir zur Unterscheidung - auch der Gemeinde vorgeschlagen, aber nicht durchführbar (Auszeichnungskosten der Schilder) - was ich auch als Grund bei alles “Gelber Strich” vermute.
Da stimme ich Dir wiederum völlig zu. “Roter Punkt” ist ein Farbmarkierung und weder ein sinnvoller Name noch ein Gruppierungskriterium. Es macht überhaupt keinen Sinn, disjunkte Wege mit demselben Farbklecks in eine Relation zu packen.
Ich hab irgendwann mal hier in der Gegend gezählt und bin auf 16 Verwendungen von “grüner Punkt” gekommen. Das sind natürlich 16 Wanderwege mit 16 Relationen und sollten sinnvollerweise mit 16 unterschiedlichen Namen versehen werden. Und hier wird das zum Glück auch richtig gemacht.
Es gibt leider auch Verfechter der Theorie, einen einfacher Wanderweg müsse nach nicht nachvollziehbaren Kriterien wie Gemeindegrenzen in lauter kleine Fitzel zerhackt werden - damit hatte ich Deine Aussage verwechselt.
bye, Nop
Darum hatte ich die Ausnahme ja auch schon erwähnt. Bei extrem langen internationalen Wanderwegen macht es Sinn, bei der großen Mehrheit an regionalen und lokalen Wanderwegen nicht.
Von so einem Proposal (Link???) halte ich gar nichts. Jede Etappe eines aufgeteilten Wanderwegs sollte für sich eigenständig getaggt sein, damit nichts kaputtgeht wenn ein Mapper nur einen Abschnitt findet/sieht oder einen ganz anderen Editor verwendet als der Aufteiler, der solche Konstrukte nicht oder anders unterstützt. Derzeit rendert mein Server 19427 Beispiele dafür, daß man wunderbar ohne Superrelationen auskommt.
bye, Nop