Das kann ich mir nicht vorstellen. Diese Informationen stehen nicht in der GPX Datei und wo soll Osmand sie sonst hernehmen?. Du hast doch nicht etwa die Abschnitte des Gurkenwegs einzeln heruntergeladen und in Osmand importiert?
Als was werden Sie dargestellt? Als Tracks? Und wie werden Sie benannt?
Hier muß ich mich revidieren… Sorry. Da hat mich Osmand ausgetrixt… Ich hatte zu dem Test extra alles was mit solchen zusätzlichen Informationen zusammenhängt, ausgeschaltet. Ich habe 3-4mal geschaut und keine Stelle gesehen, wo ich weitere Radgeschichten ausblenden kann… da war nähmlich noch was zu sehen und aktiv… 
Aber es bleibt dabei: Osmand zeigt die Original-gpx (superroute!) korrekt an, immer (ich vermute) an einem Startpunkt des Segments ist die kleine Schaltfläche und ich kann alle 11 Tracksegmente auswählen und zum Routing verwenden, so wie ich das sehe.
Je mehr man das betrachtet, wertet hier jeder diese gpx-Dateien etwas anders aus und behandelt das unterschiedlich. Bei BaseCamp und anderen muß ich bei meinem genannten Beispiel aufwendig den Track splitten.
Bei meinem o.g. Verarbeitungsweg von einem Esri-Shape über gpx hin zu einer Garmin-img-Datei nutze ich u.a. auch GPS Trackmaker um aus shp die gpx zu erstellen. Wenn ich damit mein Beispiel öffne, kann ich die da auch entstehenden falschen Artefakt-Verbindungen einfach anklicken und gleich löschen… eine Sache von höchstens 4-5 Sekunden… Danach zeigt es auch BaseCamp korrekt an…
Ungeachtet dessen ist sowas über gpx und track eh immer mit Vorsicht zu genießen, da in der gpx auch keine oneway-Geschichten stehen… Von daher kann das eh nur als etwas bessere Information genutzt werden und diverse GPS-Karten sollten eh direkt bereits die Radweginformationen haben…
Fazit für mich: gpx als Container-Dateiformat bietet wesentlich mehr Möglichkeiten die darin verpackten Daten zu nutzen, als es diverse Verarbeiter solcher Daten können und wollen.
Sven
In komoot sieht es ähnlich aus wie in Basecamp (das ich nicht habe), demonstriert am Beispiel des Saar-Radwegs (hier Vallée de la Sarre):
Korrigiert durch Vertauschen zweier Elemente der Relation zwischen den Punkten 4 und 5. Im exportierten GPX war die Richtung des Track-Segmentes umgekehrt zu den benachbarten Tracksegmenten, warum auch immer. Jetzt sind die ersten drei Segmente zu einem zusammengefasst.
Vinzenz
Ok… nächstes Beispiel…
Da gehen die Inkonsistenten los…
Frage: wie soll ein Datenexport mit einem validen Ergebnis funktionieren, wenn die verwendete Datenbasis bereits Fehler enthält?
Na?
Richtig! Geht nicht!
Da sind wir wieder bei der von mir erkannten nötigen Validitätsprüfung vergleichbar mit den Knotenpunktnetzen (hier angepasst an die Situation)
Sven
Das liegt daran, dass jOSM diese langen Rueckspruenge nicht darstellt, bzw. allgemein Segmente, die laenger als x sind. Kannst du in den Einstellungen rausnehmen oder auf einen sehr hohen Wert setzen, dann sieht das auch in jOSM nicht mehr “gut” aus.
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.
Siehe auch den noch nicht kartierten Wegweiser auf meinem Bild von gestern: Neue Organised Editing Activities für das Radnetz Deutschland (D-Routen) - #6 by Vinzenz_Mai : Richtung Saarbrücken noch mit dem Saarland-Radweg (gelbes Saarland-Symbol rechts von EV5), Richtung Sarralbe ohne …
@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!) !
Sven
Was muss man da wo einstellen?
Ist mir schon aufgefallen, habe grad aber keine Zeit, das genauer anzuschauen.
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.
Ist dann deiner Meinung z.B. beim Innradweg alles gut geordnet und der eine eportierte Track sinnvoll und brauchbar?
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.
ich hab mir da mal ein tool geschrieben damit ich eine Relation in z.B. graphhopper packen kann.
erster Schritt… Relation zu einem GPX machen…
https://greymiche.lima-city.de/bus-relation/relation2rte/
Zweiter Schritt aus diesem GPX… Routing-Link bauen:
https://greymiche.lima-city.de/bus-relation/GPX2Routing-request/linien/test3.4.html
Waymarkedtrails:
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
