.gpx Dateien von wichtigen Radwegen in DE auf waymarkedtrails.org sind teilweise unbrauchbar

Ich benutze gerne waymarkedtrails.org zum Planen meiner Radtouren, da dort ohne unnützes Drumherum praktisch alle irgendwie “offiziellen” Radwege in Deutschland verzeichnet sind, von den großen europäischen Fernradwegen bin hin zu kleinsten Landkreistouren. Die Seite bietet auch die Möglichkeit, eine fertige .gpx Datei zu jeder der Touren herunterzuladen.

Leider habe ich bei meinen letzten Touren beim Import der Dateien in Komoot feststellen müssen, dass viele .gpx-Dateien komplett unbrauchbar sind - Abschnitte fehlen, sind falsch nummeriert, etc etc. Man versuche nur mal, die “Innradweg” oder “Via Claudia Augusta” Datei in Komoot zu öffnen, ein heilloses Kuddelmuddel.

Wer ist denn für sowas zuständig? Könnt ihr da was machen? Wie kann man helfen? Ich kann gern .gpx-Dateien auf komoot erstellen und zur Verfügng stellen, ich habe aber leider nicht die Zeit, mich jetzt in OSM einzuarbeiten.

1 Like

Hallo und willkommen im Forum!

OSM ist die Basis für (fast) alles. Auch für die Seite Waymarkedtrails. Insofern mutmaße ich, dass die problematischen Routenrelationen evtl. in OSM defekt sind. Das kommt öfter gerade bei längeren Routen mal vor, kann aber repariert werden.

Du kannst in Waymarkedtrails die Route auswählen und dann rechts oben auf “Relation xxxxxxx” klicken. Dadurch öffnest du die Route auf osm.org. Den Link könntest du dann hier posten und Leute können sich die Dinger mal ansehen und ggf reparieren. Danach sollte dann auch die GPX-Datei wieder ganz sein.

Der Innradweg hat keine Auffälligkeiten in OSM, die Via Augusta (r3811891) habe ich soeben sortiert, nun sehe ich, dass die nur Teil der Route ist. Ich schau mir das mal noch weiter an

…ergänzend von mir: grundsätzlich ist zur Planung auch cycle.travel ein gutes Tool. Datenaktualisierung dauer aber immer etwas. In Bereichen reiner Knotenpunktnetze kann man sich auch knooppuntnet anschauen.

Appropos Knotenpunktnetze… da findet eine Validitätsprüfung der Routen statt und wenn da Themenradwege drüberlaufen, profitieren diese auch davon. (hier mal ein versteckter Aufruf, sich hier die Fehler anzuschauen und abzuarbeiten) Ergänzend würde ich mir eine vergleichbare Fehlerprüfung von Themenradwegen außerhalb der Knotenpunktnetze wünschen, denn damit hätte man das Ausgangsproblem erledigt.

Sven

Das mit der automatischen Validierung ist bei Knotenpunktnetzwerken etwas einfacher, weil es ja einige klare Vorgaben gibt. Also z.B.

  • roundtrip=no
  • Befahrbarkeit in beide Richtungen muss möglch bzw. erfasst sein
  • Start und Ende Knoten sind im Namen (oder was sonst? ) kodiert
  • keine Schleifen oder Exkursionen oder sonstige Sonderfälle, die Prüfungen sonst so schwer machen

Zum Teil kann man es beheben, indem die Reihenfolge der Elemente korrigiert wird. Es gibt bei Radrouten aber auch oft mehrere alternative Varianten, wie bspw. an beiden Uferseiten. Diese Teile gehören dann zwar zum selben Radweg aber ergeben zusammen keine durchgehende Route mehr, die man als ganzes direkt importieren könnte.

Habe gerade mal den Innradweg von waymarkedtrails runtergeladen und in Basecamp betrachtet. Der ist dort nicht komplett in einer Linie sondern hat Rücksprünge.
Die Darstellung in osm ist jedoch ok. Innradweg
Hier noch ein Screenshot von Basecamp

Das liegt wohl daran, dass es egal ist ob man die Wege einer Route

  • A-B + B-C + C-D + D-E + E-F

oder als

  • A-B + D-E + C-D + B-C + E-F

‘malt’

Letztendlich kommt ene durchgehend rote gemalte Linie dabei raus.

Das Problem ist doch, dass man in Basecamp keinen durchgehenden Track bekommt.
Da habe ich leider noch keine Lösung. Ich muss mir dann den erhaltenen Track teilen und wieder passend zusammensetzen.

Für mich ist das ein Problem von Basecamp.

Ich hab mir meinen heimischen Gurkenradweg mal angeschaut. Der hat einen Ostring und und einen Nord/Westring mit einer Verbindungsroute und forward/backward-Rollen. Download von https://cycling.waymarkedtrails.org in Ordnung. Darstellung in JOSM in Ordnung. Basecamp will hier einen durchgehenden Ring erzwingen. BaseCamp verhaspelt sich an den Stellen, wo forward/backward erfasst ist.

…so mein Eindruck.

Sven

Basecamp kann hier nichts dafür. Es stellt nur das dar, was Waymarked Trails aus der superroute beim gpx-Export macht, nämlich einen einzigen Track aus all den Abschnitten einschließlich der allternativen Verläufe. Da kann gar kein sinnvoller linearer Track herauskommen.

Der Export der einzelnen Abschnitte ergibt hier je nach der Struktur der Routen vermutlich sinnvollere Ergebnisse.

Gibt es denn eine Lösung für das Problem. Ich möchte den von waymarkedtrails heruntergeladenen Track dann zur Track-Navigation auf einem Garmin-GPS nutzen. Da müssen die Trackpunkte in der richtigen Reihenfolge stehen. Ein Track, der nur schön aussieht, hilft mir da nicht weiter.

Hmm, nach allem, was hier erwähnt wurde: auf waymarkedtrails für die einzelnen Routen das Höhenprofil anzeigen lassen

  • Gut ist’s bei dieser, da ohne Lücken
  • Eher nicht brauchbar bei dieser und dieser, sind krasse Beispiele

Da bin ich mir nicht so sicher… Ich habe jetzt auf meinem Dienstrechner mit der GPX-Import-Erweiterung für ArcGis einen Importtest der Superroute gemacht… Wenn ich damit einen Import mache, kommen bei Tracks 2 Dinge heraus:

  • tracks
  • tracksegments
  • trackpoints

Heraus kam das, was ich erwartet habe. : aus dem Gurkenradweg wird:

  1. ein Track mit allem Segmenten (ich kann beim Import auch angeben, daraus mehrere Feature-Classes zu machen)
  2. 11 Tracksegmente
  3. 5957 Trackpunkte

Die 11 Tracksegmente entstehen durch den Westring, des Verbindungsegmentes und den Forward/Backward-Anschnitten.

Weiterer Q-Gis-Test:

gpx direkt geöffnet. Man lädt 2 Teile:

  • tracks (1 Element)
  • track_points (5957 Punkte)

Bei den Trackpoints gibt es die Spalte track_seg_point_id Das ist die fortlaufende Nummerierung der Trackpoints pro Segment. Die ist immer sauber aufsteigend.

Fazit für mich: die gpx ist in Ordnung. BaseCamp kann mit solchen Tracks, die aus mehreren Segmenten bestehen, nicht umgehen, was anderes fällt mir nicht ein.

Sven

Wenn waymarktrail und overpass nicht auf zeitlich stark verschiedene Daten zurückgreifen, dann sieht der Inntal-Radweg - Bayern in meinem GPX-Viewer je nach Quelle unterschiedlich aus. Ich habe von beiden Quellen innerhalb einer Minute heruntergeladen.

Wenn nichts Intelligentes kommen sollte, Relation mit Brouter nachbauen. Was vielleicht einen Vorteil hat, weil man musste mal bei Garmin die Tracks teilen. Also Du sparst Dir vielleicht Schnippelarbeit.

Die Alternative bei bikerouter.de gefällt mir mittlerweile besser als der (oft nicht aneinanderhängende) gpx-Download von waymarkedtrails. Wenn man bei bikerouter.de die Karte mit den Radwegen darunter hat, kann man seinen Track zur Planung ganz schnell bauen.

1 Like

Nach gpx-Logik sind der Westring, der Nord- und Ostring sowie der Verbindungsweg jeweils ein eigenser Track, aiso die eindeutige Verbindung vom Start- zum Endpunkt entlang der trackpoints gemäß ihrer Reihenfolge in der Datei. Die Tracksegmente dienen dabei der Gliederung des Tracks in Abschnitte, wenn Unterbrechungen während der Trackaufzeichnung auftreten.

Dass Basecamp innerhalb eines Tracks den Endpunkt eines Segments mit dem Anfangspunkt des folgenden Segments verbindet, ist kein Fehler von Basecamp sondern in der Logik bei Erstellung der gpx-Datei begründet.

Für die Syntax trifft das wohl zu, aber semantisch entspricht ein einzelner Track für separate Wegverläufe nicht der Logik von gpx.

BaseCamp verarbeitet aber in keiner Weise die in der GPX-Datei vorhandene Angabe zu den Tracksegmenten. Das wird ignoriert. Kann das eine Garmin-Eigenheit sein?

Hi mhpr262,

wenn das gpx-Kaputt ist… und du für OSM keine Zeit hast. Und es keiner von hier richten kann… Würd ich eine andere Quelle versuchen im Internet.

Ist leider so das die gerne Kaputt gehen… oder nicht vollständig sind in OSM :frowning:

Gruß Miche