Welche Angaben zu Tracksegmenten sollen verarbeitet werden und wie? Ein GPX-Tracksegment nichts als eine Liste von Koordinatenpunkten. In der Reihenfolge wie sie innerhalb des GPX-Tracks angeordnet sind, ergeben sie den ganzen Trackverlauf.
Das ist eine GPX-Eigenheit. Ein GPX-Track dient ja dazu, einen zurückgelegten Weg aufzuzeichnen bzw. nachzufahren. Der Wegeverlauf wird dabei durch die Reihenfolge der Segmente und Wegekoordinaten festgelegt.
Auch andere GPX-Anwendungen stellen GPX-Tracks in gleicher Weise dar, z.B.https://www.j-berkemeier.de/ShowGPX.html.
Bei der Darstellung z.B. in QGIS spielt Reihenfolge bzw. Richtung keine Rolle, da werden die Segmente unabhäng voneinander behandelt.
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.
waymarked trails macht es richtig im Sinne dass es wiedergibt was in OpenStreetMap ist, wenn eine superroute nicht linear ist weil approach oder alternative oder so dabei ist, dann ist das halt so und man löscht sich lokal bei Bedarf das raus was man nicht braucht, oder exportiert sich gleich nur die Einzelteile. Das Löschen sollte schnell gehen, vor allem beim 2. oder 3. mal
<trk>
<!-- Attribute des Tracks -->
<trkseg>
<trkpt lat="xx.xxx" lon="yy.yyy"> <!-- Attribute des Trackpunkts --> </trkpt>
<!-- weitere Trackpunkte -->
</trkseg>
<!-- weitere Track-Segmente -->
</trk>
Das <trkseg> ... </trkseg> wird nicht verarbeitet, das wird ignoriert. Da steht aber die Segmente mit ihren zugehörigen Stützpunkten drin. Da das ignoriert wird und nur <trk> dann <trkpt lat="xx.xxx" lon="yy.yyy"> und dann </trk> verarbeitet wird, denkt man daher, die gpx wäre kaputt. GPSvisualizer stellt die GPX des Gurkenradweges ordentlich da.
Für Waymarked Trails wäre es sicher auch keine Hexerei, für jede Routenrelation in einer Superroute einen eigenen Track in die GPX Datei zu schreiben. Für mich ist so wie es ist jedenfalls nicht logisch und richtig, gerade auch im Hinblick auf das was in OSM ist.
Kann es sein, dass es hier um verschiedene Varianten von “Waymarked Trails” geht? Ich habe dort gestern versuchsweise den o.g. Gurkenweg runtergeladen und eine gpx-Datei bekommen, in der meherere Segmente (trkseg) sind, also genau das, was man erwarten kann.
Habe allerdings nicht geschaut, was Basecamp daraus macht, aber im GPX Editor sieht die Dateinvöllig OK aus und wenn Basecamp damit Probleme hat, dann vielleicht, weil die einzelnen Segmenten nicht in der gegebenen Reihenfolge abgefahren werden könnten ohne zwischendurch zu fliegen
Das Problem ist nicht ob Tracksegmente vorhanden sind oder nicht, sondern dass Waymarked Trails die Tracksegmente aller Routen einer Superroute einfach in einem einzigen Track aneinanderhängt. Und bei 2 Rundstrecken und einem Verbindungsstück kommt da zwangsläufig Unsinn heraus.
Ich halte das für einen Irrglauben. Das gpx-Format ist eine Art Container-Format. Neben Linien darf gpx eben auch Punkte enthalten. …und… und da kommen wir zu des Pudels Kern: eben auch Angaben zu einem Routing-Graphen…
Die Nutzung von gpx durch GPS-Geräte hat sich je nach Gerätehersteller später erst entwickelt. Früher wurden die Daten propitär intern gespeichert.
Aber eben doch als getrennte Segmente… einige Software wertet diese gtrennten Segmente aus, andere ignorieren es… zugelassen ist beides. Da sind wir wieder bei der Verarbeitung…
…ungeachtet dessen: natürlich kann der gpx-Generator auch jedes Tracksegment in ein eigens track-Statement schreiben. Damit würde in meinem Beispiel Gurkenradweg in der gpx-Datei 11 tracks sein. Aber: Zugelassen ist beides, auswertbar muß beides sein!
Das ist übrigens der Weg, mit dem ich aus einem Flächenshape mit Flurstückssgeometrien eine gpx-Datei mache… mein Ergebnis ist eine gpx-Datei mit z.B. >>1000(!) Flurstücksumringe, jede als separater track mit eigenem Namen… damit meine Kolleginnen und Kollegen bei Bedarf mit dem Handy das finden… (Nur z.B. Osmand hat das so seine Probleme)
Diese ergeben aber keinen sinnvollen Track. Natürlich kann man die Segmente aus dem Zusammenhang eines Tracks reissen und sie einzeln darstellen, dann hat man zwar eine hübsche Darstellung, aber es ist einem Benutzer, der den Track für seine Tourenplanung mit einem Routenplaner wie komoot oder Basecamp verwenden will, nicht geholfen. Dabei ist es nicht Aufgabe eines solchen Programms, einen Track anders zu verarbeiten, als es gemäß Spezifikation des GPX-Formats vorgesehen ist. Dafür, dass die bereitgestellten Daten für den gwünschten Zweck geeignet sind, ist der zuständig, der sie bereitstellt.
Für mich eine Zweckentfremdung gegenüber der ursprünglichen Absicht. Aber warum nicht alle in einem einzigen Track, es sind ja getrennte Segmente. Bei richtiger Verarbeitung werden sie ja ordentlich dargestellt.
Mit der Anzahl der Umringe oder ist entspricht GPX nicht der Spezufikation?
Nein, das ist nur die Aussnutzung der Möglichkeiten des Datenformates… Es widerspricht dem nicht, daß auch bei einem Track bestehend aus 4 Eckkoordinaten Start- und Endkoordinate gleich sein können. Es widerspricht nicht dem Datenformat, daß eine gpx-Datei nicht auch aus mehreren Tracks bestehen kann, was natürlich auch nach dem Auslesen eines GPS-Gerätes auch sehr oft passieren kann. Es wird eh jeder ein einzelner Track mit einem eingenen Tracknamen versehen, ob ich das in meiner Verarbeitung mache, oder das GPS-Gerät bei der Trackaufzeichnung und in meiner Verarbeitung kommt es eben darauf an.
Bei der Ausgangsfrage ist es eben andersherum: ein Track mit mehreren Segmenten und das wird von einigen GPS-Tools nicht verarbeitet, obwohl es auch hier das Datenformat hergibt.
Meine Endverarbeitung ist übrigens die Erstellung einer img-Kartendatei aus den gpx-Dateien für Garmin-Geräte, da wird mir dann der vorher festgelegte Trackname wieder angezeigt. Ich brauch das nicht fürs Routing, sondern zur Darstellung und Abfrage!
Nun mit einer Anzahl von derzeit 3936 Tracks in einer gpx-Datei wird Osmand vielleicht etwas träge, das ist nicht das Problem… Ich lege aber einen Tracknamen fest und der wird bei der kleinen Schaltfläche, die auf der Kante des Tracks erscheint, nicht angezeigt, nur der Name der gpx-Datei.
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.
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.
das nach Südosten verlaufende Segment endet im nirgendwo… Was gehört wozu? Für mich unklar!
des weiteren anscheinend weitere Lücken in einem nach meiner ersten Betrachtung aus Rundweg angedachten Radroute…
Ich habs mir mit JOSM angeschaut; beim Ediitieren lasse ich die Finger von… keine Gebietskenntnisse!
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)
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.
