MapSource kann kein GPX lesen

Garmin fenix 7X und epix Gen 2 im Test

Der Schwerpunkt dieses Tests und Vergleichs der Garmin Fenix 7X Solar und Garmin Epix Gen 2 liegt auf den Sensoren wie Höhenmesser, Positionsbestimmung und Herzfrequenz. Was unterscheidet die beiden GPS-Outdoor-Smartwatches? Und wie gut ist die Taschenlampe der Fenix 7X für den Outdoorbereich? Hier geht es zum Test der Outdoor-Smartwatches ...

    Die Version 6.12.2 von MapSource weigert sich standhaft standard-konforme
    GPX-Files mit einer nichts-sagenen Fehlermeldung zu öffnen :mad::motz:


    Wofür gibt es Standards wenn Monopolisten wie Microsoft und Garmin diese einfach ignorieren und unter gleichen Namen irgendeinen S* verzapfen? :motz::motz::motz:


    Konkreter Fall ist ein GPX-File von Pathway, welches jede andere Software lesen kann außer MapSource.


    Weis jemand, wie ein Garmin-GPX-File ausschauen muss, damit MapSource dies lesen kann?


    Bitte keine Verweise auf die offizielle GPX-Definition, ich kenne sie, nur bei Garmin hat sie keiner gelesen :mad::gaga:.


    Für hilfreiche Infos zum Garmin-GPX-Derivat wäre ich dankbar.
    ...
    Bin immer noch stinksauer, habe schon einiges raus gefunden.
    Im Falle des standard-konformen Pathway-GPX-track, ist es die Reihenfolge der Tags.
    garmin besteht darauf, das in <trkpt...>...</trkpt> zuerst <ele> und dann <time> kommt :gaga:. Pathway macht es gerade andersherum, was ja XML- und GPX-konform ist.


    Bei Waypoints sieht es mit Garmin ganz übel aus.
    Hier verwendet Garmin Extension, das ist legitim.
    Aber leider besteht Garmin beim Lesen darauf das diese enthalten sind.


    Mit G7t kann man dieses Problem mit Waypoints lösen in den man standard-konforme GPX-Files ins Garmin-GPX-Derivat konvertiert.


    Ohne Worte.


    Ich gehe jetzt schlafen
    Gute Nacht :bye:Naviboard :)


    Ray

    TwoNav Cross 5.x , TwoNav Android 5.x + CompeGPS Land Mac 9.2.4 (History: Papierkarte ;), Magellan Meridian Platinum, Garmin GPSmap 60CSx (SIRF3!), Aventura 2008, Sportiva+, TwoNav Anima+, TwoNav Aventura 2017)
    TwoNav Wissensbasis

    mit gpx hab ich noch nie Probleme gehabt, vielleicht tut es die MS Vers. 6.12.4

    Das Pathaway Problem wurde hier irgendwo schon mal diskutiert. Da war irgendwo ein Fehler im System. Entweder wars das mit den zu vielen Nachkommastellen bei den Koordinaten (7 anstatt 6) oder mit dem Speichern in ASCII UTF-8. Eines von Beiden. Gabs da nicht ein Update von Pathaway, das das Problem behoben hatte?


    Problemlösung ist simpel: Lade das gpx in GTA4.net rein und speicher es nochmal ab. Dann gehts mit jedem Programm. Der 'Fehler' liegt nicht an MS direkt sondern offenbar an der verschiedenen Interpretation was nun richtig ist.

  • Datenschutz ist uns & Euch wichtig, daher verzichten wir auf Bannerwerbung & Web-Analysetools! Um das Forum zu unterstützen bitten wir Euch über diesen Link: bei Amazon zu bestellen....
    Für Euch ist das nur ein Klick, uns hilft es das Forum langfristig und werbefrei für Euch zu betreiben! Vielen vielen Dank...

    Hallo ray,

    ich habe mir mal eine *.gpx Datei angesehen die nicht mit MapSource funktioniert.
    Dabei habe ich ein wenig mit dem Header experimentiert, und siehe da, nach Einfügen
    der fett makierten Zeile im Header funktioniert die Datei auch in MapSource.

    <?xml version="1.0" encoding="ISO-8859-1"?> <gpx
    version="1.0"
    creator="www.alpin-koordinaten.de"
    xmlns="http://www.topografix.com/GPX/1/0"
    >


    Garmin erwartet scheinbar den Eintrag eines „XML Schema“.

    Mehr zu XML Schema.


    Edit:

    Eine andere GPX-Datei aus MagicMaps2go erstellt, schreibt  vorden gpx-tag.

    <gpx version="1.1"
    creator="MagicMaps2Go"
    xmlns="http://www.topografix.com/GPX/1/1"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

    Zu sehen ist das in einem normalen Editor nicht, nur in einem Code-Editor.
    Wen man die Datei im Windowseditor als ANSI speichert funktioniert sie auch in MapSource.


    Am Dateianfang fehlt auch das:
    <?xml version="1.1" encoding="UTF-8" standalone="no" ?>


    Gruss Kerstin

    Zitat von ray

    .... Wofür gibt es Standards wenn Monopolisten wie Microsoft und Garmin diese einfach ignorieren und unter gleichen Namen irgendeinen S* verzapfen? :motz::motz::motz:


    Hallo ray,


    ich beschäftige mich jetzt seit einem Jahr intensiv mit GPX und habe hunderte Dateien analysiert und ich kann Dir sagen, dass Du da komplett auf dem falschen Trip bist. Der "Monopolist Microsoft" ist einer der ganz wenigen, der sich 100%-ig exakt an die GPX-Syntax hält.
    Garmins MapSource ist da sogar noch ein Stück großzügiger und akzeptiert auch einige falsche Tags und Interpretationen anderer Programme. An den beiden liegt es mit Sicherheit nicht. Aber viele andere Progs, darunter auch Pathway, meinen, dass sie sich nicht wirklich an die Syntax halten müssen.


    Übrigens ist es vollkommen Wurscht, in welcher Reihenfolge z.B. die Tags <ele>, <time> etc. in der trkpt-Struktur stehen. das ist auch nicht in der Syntax festgelegt!


    MapSource besteht bei den Waypoints auch nicht auf die <extensions>.


    Es gibt auch kein "Garmin-GPX-Derivat".


    Sorry, aber Deine Angaben sind durchweg nicht zutreffend.


    Analysiere Deine Pathway-Datei noch mal genau.


    blackwilli

    Zitat von blackwilli

    Übrigens ist es vollkommen Wurscht, in welcher Reihenfolge z.B. die Tags <ele>, <time> etc. in der trkpt-Struktur stehen. das ist auch nicht in der Syntax festgelegt!


    Also das kann ich leider nicht bestätigen!

    Gerade nochmal getestet. MapSource 6.12.4 ist es ganz und garnicht Wurst in welcher Reihenfolge die beiden Tags kommen. Steht <time> vor <ele> dann liesst MapSource das GPX-File nicht ein.

    Ich würde die Ursache/Schuld hier nicht unbedingt bei MapSource suchen. Das könnte auch an der lokal in Windows integrierten XML-Unterstütung liegen und wie stark die GARIN-Entwickler auf diese Systemunterstützung zurückgreifen. Wir hatten ja schon mal glaube ich das Problem, das einige ein bestimmtes GPX-File nicht einlesen konnten, während andere mit der gleichen MapSource-Version das File aber lesen konnten.

    Aber ansonsten bin ich auch der Meinung, das MapSource recht gnädig ist, wenn es darum geht, GPX-Files einzulesen. Gerade bei den letzten Version hat GARMIN da viele Bugs beseitigt.

    Was ich mir aber bei MapSource wünschen würde, wäre ein etwas bessere Fehlerausgabe, warum ein GPS-File nicht eingelesen werden konnte. Es wäre schon manchmal sehr Hilfreich, wenn zu wissen welches Tag oder welche Zeilennummer das Problem verursacht hat.

    mfg
    JLacky

  • Datenschutz ist uns & Euch wichtig, daher verzichten wir auf Bannerwerbung & Web-Analysetools! Um das Forum zu unterstützen bitten wir Euch über diesen Link: bei Amazon zu bestellen....
    Für Euch ist das nur ein Klick, uns hilft es das Forum langfristig und werbefrei für Euch zu betreiben! Vielen vielen Dank...
    Zitat von JLacky

    Also das kann ich leider nicht bestätigen!

    Gerade nochmal getestet. MapSource 6.12.4 ist es ganz und garnicht Wurst in welcher Reihenfolge die beiden Tags kommen. Steht <time> vor <ele> dann liesst MapSource das GPX-File nicht ein.

    Ich würde die Ursache/Schuld hier nicht unbedingt bei MapSource suchen. Das könnte auch an der lokal in Windows integrierten XML-Unterstütung liegen und wie stark die GARIN-Entwickler auf diese Systemunterstützung zurückgreifen. .....


    Sorry, hast recht. Ich hatte noch 6.12.3 drauf und bin davon ausgegangen, das dies (gemeldete) Problem erledigt ist. Habe gerade 6.12.4 installiert und das haben die Jungs tatsächlich verpennt.


    Trotzdem ist grundsätzlich die Reihenfolge egal, es dürfte m.E. auch nicht am vielleicht von MS benutzten Windows XML-Reader liegen, den auch GTA verwendet. Der Zugriff mittels des XML-Readers auf Tags innerhalb von Strukturen (hier <trkpt>) ist vollkommen positionsunabhängig und erfolgt direkt über den Tag-Namen. Da MS die Waypoints akzeptiert, wenn das <ele> Tag fehlt und <time> dadurch an erster Stelle steht, denke ich, dass das Problem nicht am Lesezugriff, sondern an der nachfolgenden Datenauswertung besteht. Was natürlich nichts an der Tatsache ändert, das MS hier immer noch ein Problem hat.


    blackwilli

    Hi blackwilli,


    genau das hatte ich gesagt, die Reihenfolge der Tags sollte egal sein.


    Egal, ich hatte etwas "Dampf" abgelassen, vielleicht etwas zu pauschal.


    Es ist mir eigentlich vollkommen egal, ob es am Parsen oder in der nachfolgenden Verarbeitung liegt, es gibt definitiv Probleme beim Lesen von GPX-Files mit MapSource.


    Bist du dir sicher, das MapSource den XML-Parser von MS verwendet?


    Ich werde wenn ich etwas mehr Zeit habe, versuchen rauszufinden wie die Datenstruktur aussehen muss damit MapSource die GPX-Files lesen kann.


    Bei <trkpt> ist die Reihenfolge der includierten Tags <ele> und <time> entscheidend, zumindest für MapSource. Das hat ja JLacky bestättigt.


    Mit Waypoints werde ich noch etwas spielen müssen, um heruaszufinden wie es MapSource genehm ist.


    Ray


    P.S.: Nicht ohne Grund kann man in G7ToWin eine Flag setzen, damit Garmin-kompatible GPX-Files erzeugt werden ;)

    TwoNav Cross 5.x , TwoNav Android 5.x + CompeGPS Land Mac 9.2.4 (History: Papierkarte ;), Magellan Meridian Platinum, Garmin GPSmap 60CSx (SIRF3!), Aventura 2008, Sportiva+, TwoNav Anima+, TwoNav Aventura 2017)
    TwoNav Wissensbasis

    Zitat von ray

    ... Bist du dir sicher, das MapSource den XML-Parser von MS verwendet? ...


    Nein, MS wird keinen Parser von Windows benutzen, da es sonst noch empfindlicher auf nicht ganz konforme Dateien reagieren würde - So wie GTA. ;)


    Zitat von ray

    ... Ich werde wenn ich etwas mehr Zeit habe, versuchen rauszufinden wie die Datenstruktur aussehen muss damit MapSource die GPX-Files lesen kann. ...


    Dazu kannst Du Dir auf meiner Homepage unter "Track-Beispiele" entsprechende GPX aus GTA herunterladen. Diese sind sauber strukturiert und eingerückt, so das sie auch in einem normalen Texteditor gut lesbar sind.


    Zitat von ray

    ... Bei <trkpt> ist die Reihenfolge der includierten Tags <ele> und <time> entscheidend, zumindest für MapSource. Das hat ja JLacky bestättigt.


    Mit Waypoints werde ich noch etwas spielen müssen, um heruaszufinden wie es MapSource genehm ist.


    Ist mit den Waypoints genauso.


    blackwilli

  • Datenschutz ist uns & Euch wichtig, daher verzichten wir auf Bannerwerbung & Web-Analysetools! Um das Forum zu unterstützen bitten wir Euch über diesen Link: bei Amazon zu bestellen....
    Für Euch ist das nur ein Klick, uns hilft es das Forum langfristig und werbefrei für Euch zu betreiben! Vielen vielen Dank...

    ich habe mal mit den Waypoints gespielt:


    Dieser Waypoint ist aus einen KML-Waypoint entstanden.


    Für MapSource muss die Reihenfolge der Tags wie oben sein.
    Falls <time> angegeben ist, dann muss es direkt nach <ele> folgen.


    MapSource mag überhaupt kein <![CDATA[...beliebiger text...]]>
    jedes Element was ein xsd:string ist darf aber auch ein CDATA sein.


    @blackwilli, GTA hat leider auch Probleme mit CDATA.
    Kannst ja bei Gelegenheit ein Bugfix nachschieben.
    Ich weis CDATA ist ganz übel da es alles enthalten kann.
    Mein Script stolpert z.B. über geschachtelte CDATAs.


    wer sich sonst noch für GPX interessiert, findet die Definition unter http://www.topografix.com/gpx.asp

    ray

    TwoNav Cross 5.x , TwoNav Android 5.x + CompeGPS Land Mac 9.2.4 (History: Papierkarte ;), Magellan Meridian Platinum, Garmin GPSmap 60CSx (SIRF3!), Aventura 2008, Sportiva+, TwoNav Anima+, TwoNav Aventura 2017)
    TwoNav Wissensbasis


    Hallo ray,


    schmeiß nicht kml und gpx durcheinander. Beide basieren zwar auf xml, haben aber ansonsten nicht viel miteinander zu tun. gpx ist ein Ausstauchformat zwischen unterschiedlichsten Anwendungen und kml ist ein reines GE-Format, für das der eine oder andere Hersteller halt Import- oder Export-Filter geschrieben hat.


    GTA liest gpx. Aus kml werden aber nur die Pfade (also Tracks) extrahiert.
    Daher bedarf es auch keines Bugfixes.


    blackwilli