Relation Wanderweg - Mehrfachverwendung eines Weges in der Relation

Communities Österreich (Austria)
1

Ich habe den klassischen Nordwaldkammweg in einer Relation (relation 1133233) fertig gestellt. Dabei habe ich aber ein Problem: es wird zB auf den Punkt: Nebelstein (715847532) bei 48.6736294, 14.7788708 raufgegangen und auf dem selben Weg wieder hinunter. Das lässt sich zwar unterbrechnungsfrei in die Relation reinschieben, hat aber einen unangenehmen Nebeneffekt.
Sowohl auf https://hiking.waymarkedtrails.org als auch bei der Relationsprüfung http://ra.osmsurround.org/analyzeRelation?relationId=1133233&noCache=true&_noCache=on bekommt man nun kein Höhenprofil mehr angezeigt. Das Höhenprofil funktioniert immer nur, wenn absolut keine Doppelverwendung von Wegen drinnen ist.
Wie kann man das umgehen? Wie soll sowas eingezeichnet werden? Den doppelt verwendeten Weg auf den Berg doch nicht einzeichnen?

Danke für eure Antworten!
Klemens

2

Hi Klemens,
Ja, das Problem ist auch mir bekannt und tritt meines Wissen nach bei hiking.waymarkedtrails.org bereits auf, wenn ein Kreisverkehr Bestandteil der Relation ist. Ich würde die Relation so mappen, wie Du es bei #1133233 gemacht hast, d.h. als durchgehender Linienzug mit Mehrfachverwendung von Linien. Du könntest das Problem auf https://github.com/lonvia/waymarked-trails-site/issues melden oder bei lonvia@denofr.de melden.
Grüße
Andreas

3

Ja - das hab ich mal gemacht, mal sehen ob ich eine Antwort bekommen. Aber ich fürchte, nachdem auch die Relationsprüfung dann kein Höhenprofil mehr darstellen kann, ist das ein gröberes Problem und nicht nur im Bereich von waymarkedtrails.
danke Andreas!
Vielleicht kennt doch noch wer eine Lösung…

4

Möchte euch die Antwort nicht vorenthalten:

Und tatsächlich! waymarkedtrails zeigt nun das Höhenprofil an - obwohl ich eigentlich an der Relation nichts mehr gemacht habe (und auch sonst niemand lt. Änderungssätzen). Beim Relation Analyzer gibt’s zwar kein Profil, aber wichtiger ist es mit bei waymarkedtrails.

5

Hi Klemens,
das sind ja wirklich schöne Nachrichten und vielen Dank an lonvia@denofr.de :slight_smile:
Deine Relation #1133233 ist sauber als durchgehender Linienzug gemappt. Bis einer Änderungen bei waymarkedtrails sichtbar wird, können meiner Erfahrung nach ein paar Minuten oder manchmal ein paar Stunden oder selten Tage vergehen. Vielleicht hats nur ein wenig gedauert.
Grüße
Andreas

6

In Routenrelationen ist die Reihenfolge der Members bedeutungslos. Dass du die Members entsprechend dem Routenverlauf vom Hochstein nach Pyhrabruck geordnet hast, war ein unnötiger Arbeitsaufwand. Entsprechend gibt es auch keinen Grund, Stichwege doppelt in eine Routenrelation einzuhängen. Ein Weg ist entweder enthalten oder nicht enthalten. Ein doppelt eingehängter Weg führt höchstens zu Problemen, denn wenn der markierte Weg verlegt wird und deshalb jemand den alten Weg aus der Relation herausnehmen möchte, muss er den Weg 2x aus der Relation entfernen. Damit rechnet man als Bearbeiter nicht.

Für Anwendungen wäre es theoretisch eine Hilfe, wenn die Abschnitte sortiert sind und der Stichweg doppelt drin ist, damit die Anwendung ihn vor und wieder zurück verfolgen kann. Aber weil diese Sortierung nicht Teil der Spezifikation des Relationstyps ist, können sich die Anwendungen nicht drauf verlassen, und so sortieren sie die Members selber. Mit einem doppelten Member können sie nichts anfangen.

Es gibt gerade bei Wanderrouten alle möglichen Topologien, nämlich auch Rund- und Sternwege und Wegvarianten, die abzweigen und wieder einmünden. Das muss beim Erstellen von Höhenprofilen alles berücksichtigt werden. In solchen Fällen zeigt sich, wie sorgfältig eine Anwendung programmiert ist.

7

Hm… dem kann ich teilweise nicht zustimmen:

Ich sehe mehrere Gründe, die hier dagegen sprechen:

  • Kartenanwendungen wie zB waymarkedtrails funktionieren ohne richtige Reihenfolge nicht perfekt

Dies ‘gefällt’ mir ebenso nicht, weil die Relation in JOSM usw. nicht durchgängig wird. Außerdem widerspricht es wieder dem korrekten Ablauf von waymarkedtrails, was für mich hier die nützliche Anwendung ist, an der ich die Bearbeitung ausrichte.

Ist dir eine entsprechende Diskussion bezüglich richtig/falsch in dieser Frage bekannt?

8

Dazu kann ich nichts sagen, ich benütze JOSM nicht.

Interessant, das steht sogar schon lang drin. Zählen tut aber das englischsprachige Wiki und dort gibt es diese Seite gar nicht. Die Spezifikation befindet sich auf http://wiki.openstreetmap.org/wiki/Relation:route bzw. http://wiki.openstreetmap.org/wiki/Tag:route%3Dhiking. Auf die Reihenfolge der Members wird nur bei Haltestellen hingewiesen (Rollen stop, platform).

Wanderrelationen zu sortieren wär eine endlose, hoffnungslose Aufgabe. Schau dir mal Weitwanderwege wie Nordalpen-, Zentralalpen- und Jakobsweg an. Da gibt es über tausend Members und hunderte Versionen, d.h. alle paar Tage ändert jemand was an den Zuordnungen. Selbst wenn sich gelegentlich jemand die Mühe machen würde, diese Relationen zu sortieren, dann wär das ein Bärendienst, weil die Versionsgeschichte noch unübersichtlicher werden würde und keiner mehr nachvollziehen könnte, wer wann was geändert hat.

Das muss man sich im Detail anschauen und die Bugs ggf. den Entwicklern melden. In der Darstellung der Routen in der Karte sind mir noch in keiner Anwendung Probleme aufgefallen, und sowas wie Höhenprofile sind halt Zusatzfeatures, die keinen Anspruch auf Perfektion stellen. http://ra.osmsurround.org/analyzeRelation kommt laut Dokumentation immerhin mit Y-Verzweigungen und Unterbrechungen klar.

Nein, und angesichts der Spezifikation sehe ich keinen Diskussionsbedarf. Was dringender diskutiert gehört, ist die Frage, wie Infotafeln, Wegweiser, Kreuzwegstationen, Rastplätze usw. in die Relationen eingehängt werden sollen.

9

Im JOSM eben nicht - alle Members laden und sortieren lassen. Upload - fertig (zumindest bei Roundtrips bzw. ‘normaler’ Linienführung)

10

Hi kpalser,

Ja, in JOSM ist es einfach, aber fkv verwendet primär Merkaartor als Editor. Merkaartor war, als ich mit OSM vor einigen Jahren begonnen habe, ein recht verbreiteter Editor. Auch ich habe damit etwa 1900 Changesets erzeugt. Die Weiterentwicklung vom Merkaartor ist etwas eingeschlafen und die Möglichkeiten zur Bearbeitung von Relationen (wozu auch die Routen gehören) ist sehr eingeschränkt. Siehe folgenden Screenshot (Links vom schwarzen Balken ist Merkaartor und rechts ist Josm. Die grünen Rahmen zeigen die Relationsmember samt Reihenfolge):

Siehst Du, dass fkv in Merkaartor gar nicht sieht, ob die Wegestücke sortiert sind?

Hi fkv,

Nein, bereits bei Y-Verzweigungen ist beim “OSM Relation Analyzer” nur noch die Prüfung auf Lücken möglich. Der “OSM Relation Analyzer” kann damit nicht mehr den durchgehenden Verlauf und damit auch, z.B. die Länge nicht mehr korrekt erkennen.

Beispiel (live wäre es hier zu sehen http://ra.osmsurround.org/analyzeRelation?relationId=7544980&_noCache=on)):

Hier wäre die komplette Routenlänge um von A über B nach C nach B nach D zu kommen 120m+2x51m+70m=292m. OSMRA kommt auf 239m. Wie soll er auch auf die korrekte Länge kommen, wenn das Wegstück BC nicht doppelt (als Hin- und Rückweg) in der Route drin ist? Und eine Y-Verzweigung ist noch eine sehr einfache Form.

Neben waymarkedtrails und “OSM Relation Analyzer” gibt es noch weiter OSM-Dienste, die auf die richtige Sortierung von Routen angewiesen sind:

Ob mit vertretbarem Aufwand diese OSM-Dienste auch ohne sortierte Routen funktionieren könnten, kann ich als Nichtentwickler nicht sagen.

Und Du musst ja nicht sortieren. Es ist Dir freigestellt neue Routen zu sortieren und die aktuellen Editoren (selbst iD) sorgen beim Splitten von Wegen dafür, dass die Sortierung von bestehenden Routen nicht zerstört wird. Wer sortiert unterstützt bestimmte Funktionen dieser OSM-Dienste. Wenn nicht, halt nicht.

Grüße
Andreas

PS. Aus dem englischen Wiki, z.B. “http://wiki.openstreetmap.org/w/index.php?title=Relation”: A relation is a Data Primitive that consists of one or more tags and also an ordered list of one or more Nodes and/or Ways as members. Auch im ursprünglichen Text von http://wiki.openstreetmap.org/w/index.php?title=Relation:route stand bei den Members neben “Recurrence? one or more” auch “the ways making up the route, in sequence. The transition from one way to the next is at the common node shared by the two routes”.

11

Snip (doppelter Post)

12

@Andreas Binder
Vielen Dank für diese sehr ausführliche Stellungnahme! Interessant wie sehr sich die Betrachtungsweise mit der Verwendung des Editor-Tools ändert.
Also können wir wohl das so festhalten, dass das Reihen der Wege gewünscht ist und Wege (wenn sie später wieder verwendet werden) auch mehrfach vorkommen können bzw. gar sollen, wenn es für die Ermittlung der Weglänge und die durchgehende Route benötigt wird.
Was @fkv noch aufgeworfen hat: das Verwenden von Wegweisern, Marterln usw. in Relationen ist hier tatsächlich wiederum ein Problem, da diese anscheinend auch das ‘schöne’ Auswerten von Relationen in diversen Tools verhindert.

13

Hi kpalser,

Ja, die Sortierung von Routenwegen und die Mehrfachverwendung von Wegen um nichtlineare Routenformen darzustellen ist gängige Praxis (auf bei den großen Routen wie E1-x, Via Alpina, Jakobswege …). Diverse OSM-Dienste setzen darauf, dass es gemacht wird. Aber nicht jeder Editor ist dafür geeignet, so dass es Mapper gibt, die es machen und andere, die es nicht machen (bzw. nicht machen können).

Beides ist OK. Die OSM-Dienste müssen mit beidem rechnen und zeigen je nachdem nur einen Teil der Dienstfunktionen an.

Bezüglich “Wegweisern, Marterln usw. in Relationen” sehe ich einen gewissen Bedarf bzw. wird in geringem Umfang bereits genutzt.

Hier ein paar dokumentierte Möglichkeiten (teils route=xy bezogen):

role=start für den Startpunkt einer Route, z.B. bei kreisrunden Routen (http://wiki.openstreetmap.org/wiki/Tag:route%3Dski)
role=guidepost für Wegweiser (http://wiki.openstreetmap.org/wiki/Relation:route)
role=put_in für Booteinsetzstellen (http://wiki.openstreetmap.org/wiki/DE:WikiProject_Canoe_Maps)
role=information für Karten und Infotafeln (http://wiki.openstreetmap.org/wiki/DE:WikiProject_Canoe_Maps)
role=mark für Peilmarken (http://wiki.openstreetmap.org/wiki/DE:WikiProject_Canoe_Maps)

Verwendet wird in Praxis (https://taginfo.openstreetmap.org/relations/?rtype=route#roles) mit über 500-Vorkommen auch role=station

Ich persönlich finde aber, dass stinknormale Wegweiser nicht unbedingt in eine Route müssen (speziell, wenn die Wegweiser nicht nur für diese eine Route aufgestellt wurden). Auch würde ich auf normale POIs der Route, die nicht zwingend zur Route gehören, wie Parkplätze, Campingplätze, Restaurants als Routenmitglieder verzichten. Sinnvoll fände ich z.B. die Stationen einer Route, wenn es so was auf der Route gibt und dies so ausgeschildert ist, z.B. “Station 1 - Moor”, “Station 2 - Bahnhof”.

Von daher wurde ich in eine Route nur die POIs aufnehmen, die wirklich Bestandteil der Route sind und kein “nice to have”

Grüße
Andreas