Sorry, Sven, ich hätte den Weg verlinken sollen: Saar-Radweg/Vallée de la Sarre, auch problematisch, da ab der Schleuse Serrig zwei Varianten auf beiden Seiten der Saar existieren.
Bitte nicht mit dem Saarland-Radweg verwechseln, der ein Rundweg ist - und aus welchen Gründen auch immer noch einen beschilderten Zipfel in Richtung Sarreguemines-Centre aufweist, wie Du richtig erkannt hast.
@Vinzenz_Mai Auch an der Stelle sind wir wieder beim Thema… ist die Datenbasis nicht technisch und geometrisch sauber, dann können keine sauber auswertbaren Daten ala gpx bei rauskommen, auch nicht, wenn der Datenauswerter das ganze gpx-Format unterstützen würde…
Hier bei diesen Themenradwegen ermangelt es an einer konsistenten Fehlerprüfung:vor allem: Wegevollständigheit und bidirektionale Routingfähigkeit (access-Tags im weiteren Sinne!) !
In Waymarkedtrails kann man auch die Sectionen sehen, und sie separat als gpx exportieren.
Waymarkedtrails benutzt dieselbe gpx-Exportengine wie Overpass-turbo, ohne eigene Extras.
Nur wenn die Relationen im Superroute in OSM gut sind und richtig geordnet, sind das Hohenprofil und die gpx-Export kontinu.
Wenn alles gut geordnet ist und anschliesst, hat die gpx-Datei 1 Track. Wenn die Subrelationen niecht ein kontinuer Track formieren, gibt es mehrere Tracks in der gpx-Datei, gemäß den Spezifikationen des gpx-Formats.
Apps und Programme entscheiden selbst, wie sie damit umgehen.
Dies gilt auch für POIs, die als Wegpunkte in eine gpx-Datei aufgenommen werden können. Ich weiß nicht, ob Overpass-turbo/Waymarkedtrails das auch tut.
Aber nur weil in der Voreinstellung die Segmente einzeln gemalt werden. Erst wenn man das Verbinden der Segmente aktiviert, wird der eigentliche Track in seinem Verlauf angezeigt. Der ist zwar formal korrekt aber trotzdem inhaltlich unsinnig.
Das ist auch kein größerer Aufwand, als in Osmand sinnvolle Tracks per Hand zusammen zu bauen.
Die vernünftigere Lösung ist aber sowieso, beim Export sinnvolle Tracks zu bilden, die auch universell verwendbar sind und keine Sonderbehandlung erfordern. Dann braucht ein Nutzer wie der Eingangsposter sich nicht über unbrauchbare Tracks beschweren und sich auf die Suche nach einer geigneten Anwendung für Nachbearbeitung machen.
… und diese Voraussetzung wird nicht von allen Relationen des Inntalwegs erfüllt:
Inntalweg West weist zwei Verbindungen zum Inntalweg Ost auf: Griesstätt und Wasserburg, beim Inntalweg Bayern sind es die Schleifen in Mühldorf am Inn.
Das sieht man, wie von @ToniE schon erwähnt, wenn man sich das Höhenprofil anzeigen lässt.
NMM: Die Superroute enthält einige Alternativen, ist also nicht vollkontinu. Die gpx-Datei wird also mehrere Tracks enthalten. Die separate sectionen sehen gut aus.
Es gibt keine einzige Hauptroute ohne Varianten, daher ist es nicht möglich, eine vollständig durchgehende gpx-Datei für ein Garmin zu exportieren.
Wenn du das willst, könntest du eine Hauptrouten-relation erstellen.
OSM ist aus meiner Sicht nicht der richtige Ort, wenn man eine Route haben will. Dann eher mit so was wie brouter die Strecke nachbauen. Das führt aus meiner Sicht zu besseren Resultaten
Woran erkennt man denn die Hauptroute? Oder rätst du gerade dazu, jeder solle sich seine Hauptroute des Innradwegs in OSM anlegen?
Waymarkedtrails-Maintainer hier. Nehmen wir das mal auseinander. Das Grundproblem hier ist, dass Fahrrad/Wanderrouten in OSM ziemlich oft nicht linear sind. Alternative Routenführungen wurden schon genannt, die gerne mit entsprechender Rolle in die Routen-Relation gepackt werden. Aber schon der einfache Fall, dass die Route in die beiden Richtungen durch verschiedene Einbahnstrassen oder über einen Kreisverkehr geführt wird, sorgt dafür, dass es keine lineare Route mehr ist. Das ganze Problem ist ziemlich unabhängig von Superrouten, das gibt es auch schon mit einfachen Relationen.
Waymarkedtrails versteht gerade weder die speziellen Rollen noch Forward/Backward-Führungen. Das ist schon lange auf meiner Todo-Liste. Wird aber auf absehbare Zeit nichts werden. Falls jemand Interesse hat, sich damit zu beschäftigen, PM an mich. Das wäre nicht nur für GPX-Download wichtig, sondern auch für das Höhenprofil.
Das ist aber nur das technische Problem. Es gibt da noch ein Benutzungsproblem. Denn sobald eine Route nicht mehr linear ist, stellt sich die Frage: welchen Teil der Route will der Nutzer denn eigentlich haben. Man braucht also nicht mehr einen einfachen ‘Download der Route’, sondern müsste sich individuell zusammenklicken, ob man vorwärts oder rückwärts oder via Alternative A oder B fahren will.
Und an diesem Punkt schliesse ich mich der Empfehlung anderer Nutzer an: lieber brouter oder Graphhopper oder Osmand nehmen, sich die tatsächliche Route zusammenklicken und dann das GPX davon benutzen. Der GPX-Download von Waymarktrails ist da einfach das falsche Tool.
Völlig richtig, das forward/backward-Problem ließe sich im Exporter lösen.
Das Thema mit den Alternativen in der Theorie per dezidierten Relationen. Wenn es zwischen den Punkten A und B auf der Route zwei Möglichkeiten gibt, könnte man für jede Variante eine Unterrelation erstellen. Dann könnte ein Exporter wieder einen linearen GPX-Track erzeugen. Ob das jetzt aus OSM-Sicht gewollt ist, lasse ich mal ebenso dahingestellt wie ob das ein Exporter unterstützen wollen würde… Technisch wäre das zumindest umsetzbar. Aktuell erfolgt die Trennung der Unter-Relationen meiner Erfahrung nach eher nach Region und weniger nach Routenabschnitten
Meistens map ich Wanderwege, die nichts mit forward- und backwardrollen zu tun haben. Fast alle langen Wanderwege haben eine ausgeschilderte Hauptroute, ich teile sie in überschaubare Stücke, oft so wie es der Operator macht. Alternative Routen erhalten eine eigene Relation. Manchmal, aber nicht immer, kombiniere ich die Hauptroute und die Alternative mit den entsprechenden Rollen zu einer Superroute, die dann kein voll durchgängiger single trail ist.
So kan ich alles, was ich brauch, in Teilen oder komplett exportieren. Eine Nachbearbeitung der gpx-Dateien ist oft notwendig, ich verwende dazu afstandmeten.nl, aber dafür gibt es viele online und offline Tools.
OSM kennt die ausgeschilderten Routen, plant aber keine Touren. Deshalb kann man nicht verlangen, dass OSM immer genau das gpx gibt, das man braucht. Aber ich kann via die Relationen nette Sections zur verfügung stellen.
Most OSM-based bicycle routers can handle the backward/forward roles so typical for bicycle routes. In fact this is a mechanisme to pack two routes in one relation, which poses a problem when exporting a bicycle route as one gpx. If you use an OSM-aware router to recreate the route according to the OSM-relation, it will create a single track according to the direction the user chooses.
Ja, ließe sich… Andererseits sehe ich hier auch den Importer in der Pfllicht, der das gpx-Format in Gänze zu unterstützen hat und nicht nur die Teile dessen, die einem genehm sind…
Das gpx-Format ist ein Datenaustauschformat, welches verschiedenste Varianten aus Punkt- und Linieninformationen beinhaltet/ beinhalten kann, und nicht nur das, was Maren Gilzer im Glücksrad gedreht hat, oder sich jeder aussuchen kann!
Eine gpx-Datei mit mehreren Tracks die nur jeweils ein Segment haben ist genauso zugelassen wie gpx-Dateien, deren Tracks jeweils aus mehreren Segmenten bestehen; incl. einer Kombination aus beiden! Letzteres wird vielfach nicht unterstützt, ist aber das, was hier in Frage steht. Daher entstehen diese “Pseudo-Artefakt-Routen”, die aufgrund dieser mangelhaften Unterstützung des Datenformates entstehen… diese langen, geraden Verbindungen deines Beispiels… Das ist das Grundproblem!
@lonvia Für mich ist hier bezogen auf die OSM-Datenbasis datentechnisch alles richtig und sauber!
Aber wie? Wie kann der Exporter wissen welche Richtung zu exportieren, wenn die Relation zwei Richtungen hat, also zwei Routen? Die gleiche Frage für Alternativen die mit Rollen in einer Relation enthalten sind: wie kann der Exporter wissen welche du haben möchtest?
Ganz richtig! forward/backward bezieht sich nämlich nicht auf die Richtung, in der die Route abgefahren wird, sondern auf die Richtung der OSM-Wege. Welcher Weg nun genommen wird, wenn die Route von A nach B, bzw. wenn die Route von B nach A gefahren wird, das ergibt sich erst daraus, dass die Fahrtrichtung und die Richtung der OSM-Wege zur Übereinstimmung gebracht wird.
Nicht einmal der JOSM Routen Editor bekommt das hin, dass die Superroute als durchgängig erscheint. Man sieht das beim Innradweg in Martina, wo Abschnitt 2 unmittelbar bei so einer FW/BW Stelle an Abschnitt 3 grenzt.
PS: Ich pflege ab und an der Innradweg im Inntal (Tirol) und hab erst vor wenigen Tagen die “alternative” Rolle erstmals auf die Alternativerouten gesetzt. Meine Erfahrung mit der Sache, und auch damit, dass Editoren, auch welche die von ganz vielen Leuten verwendet werden, mit Routen-Relationen überfordert sind. Geht das einfacher?
Sicher? Wenn ich einen Innradweg haben mochte und dann 36 Segmente bekomme, die ich dann irgendwie selber/manuell verbinden muss ist das “gut”? Für mich ist beides unbrauchbar.
Unser Routendatenmodell ist für verzweigte Routen nicht gemacht. Das ist das Grundproblem. Zumindest aus meiner Sicht.
