Import-Fehler bei Suunto Ambit / Movescount

Hallo Axel,

Zitat von netbees

<gpx xmlns='http://www.topografix.com/GPX/1/1'> wurde nicht erwartet.

der GPX-Header ist m.E. nicht in Ordnung. Zuerst wird der Namespace von GPX 1.0 für die Datei festgelegt, in der gleichen Zeile weiter dann der Namespace von GPX 1.1. Die beiden Namespaces widersprechen sich aber inhaltlich zum Teil, deswegen die Fehlermeldung. Aus meiner Sicht ist die Trackdatei von Movescount fehlerhaft erzeugt, der QV-Parser hat seinen Job gemacht.

Hallo Hans,
hallo Axel,
die Version 1.1 wird als default namespace angegeben und die Version 1.0 mit dem prefix gpxdata - das sollte so in Ordnung sein.
Warum der default namespace nicht akzeptiert wird, weiss ich nicht - wahrscheinlich geht es importieren, wenn einfach xmlns="http://www.topografix.com/GPX/1/1" aus dem Header gelöscht wird.
Bei den Werten aus den extension tags gilt wahrscheinlich, dass diese beim Import interpretiert werden müssten. Wenn das Format nicht implementiert ist, wird das ignoriert und verworfen. Vielleicht sind die beim Import als Training mit dabei (zumindest teilweise).

Zitat von netbees

QV halt mal wieder als einziges nicht.
Inzwischen muss ich für immer mehr Aktionen externe Programme bemühen.
QV wird zunehmend unkomfortabler und damit unattraktiver.

Axel, wenn Du das so sagst, dann wäre es natürlich schön, wenn Du das auch präzisieren könntest bzw. Beispiele dafür nennst. Muss ja nicht hier in dem Thread sein. Wünsche sind hier auch immer willkommen, aber es können natürlich auch nicht immer alle umgesetzt werden. Wenn da was vernünftiges dabei ist und es keinen Grund gibt, der dagegen spricht, dann hat man für gewöhnlich ganz gute Chancen für eine Umsetzung.

Viele Grüße
Denis

Hallo Dietmar,

Zitat von Dietmar

die Version 1.1 wird als default namespace angegeben und die Version 1.0 mit dem prefix gpxdata - das sollte so in Ordnung sein.
Warum der default namespace nicht akzeptiert wird, weiss ich nicht - wahrscheinlich geht es importieren, wenn einfach xmlns="http://www.topografix.com/GPX/1/1" aus dem Header gelöscht wird.

formal mag das in Ordnung sein, aber der für gpxdata angegebene Namespace enthält die Tags nicht und paßt nicht zur angegebenen SchemaLocation für gpxdata. Die Musterdatei läßt sich in QV importieren, wenn man im Header xmlns:gpxdata="http://www.topografix.com/GPX/1/0" durch xmlns:gpxdata="http://www.cluetrust.com/XML/GPXDATA/1/0" ersetzt passend zur dazugehörigen SchemaLocation, siehe Anhang.

Für mich bleibt das ein Fehler von Suunto/Movescount, die haben GPX nicht sauber implementiert. Sie sind aber nicht allein, wenn es mal irgendwo GPX-Probleme gibt, sind es oft fehlerhafte Implementierungen der Datenlieferanten. Deswegen hat sich schon mal jemand die Mühe gemacht, ein kleines Kommandozeilenprogramm zum Putzen von unsauberen GPX-Dateien zu schreiben, manchmal hilft es auch, nicht funktionierende GPX-Dateien einfach mal durch GPS Babel zu jagen.

Zitat von Polarlys

Für mich bleibt das ein Fehler von Suunto/Movescount, die haben GPX nicht sauber implementiert

Aber immerhin haben die sowas wie GPX, das man halt nachträglich korrigieren muss. Bei meiner Suunto X10 wären das paradiesische Zustände gewesen, war die doch in Bezug auf die restliche GPS-Welt ein Autist. Nur mit GPSBabel konnte man was retten.

Nach dem Wechsel zum Garmin Fenix 3 kann ich über die Probleme mit der Suunto-Kommunikation nur noch schmunzeln.
(... nachdem ich früher wütend auf Suunto war, prallten doch alle Proteste und Wünsche bezüglich der Kommunikation reaktionslos an denen ab)

Ach ja - und meiner Meinung nach muss man nicht jedes Unvermögen von Suunto auf QV schieben.

Hallo Hans,

Zitat von Polarlys

formal mag das in Ordnung sein, aber der für gpxdata angebene Namespace enthält die Tags nicht und paßt nicht zur angebenen SchemaLocation für gpxdata. Die Musterdatei läßt sich in QV importieren, wenn man im Header xmlns:gpxdata="http://www.topografix.com/GPX/1/0" durch xmlns:gpxdata="http://www.cluetrust.com/XML/GPXDATA/1/0" ersetzt passend zur dazugehörigen SchemaLocation, siehe Anhang.

das stimmt allerdings - wenn QV die ganzen Schema Definitionen herunterlädt und damit das GPX Dokument validiert, dann wird es bei dem gpxdata auf einen Fehler laufen, wenn das nicht korrekt ist (werden nur Namensräume ohne Validierung verwendet, wäre es egal). Vielleicht ist auch nur die Fehlermeldung irreführend, aber da muss man wahrscheinlich nehmen, was der Parser ausgibt und weiter schauen, warum es scheitert.

Zitat von Delago

Aber immerhin haben die sowas wie GPX, das man halt nachträglich korrigieren muss.

Werner das gibt es immer häufiger das qv bestimmte GPX nicht lesen kann , Grund mal dahingestellt. Hatte gestern auch 4 GPX in denen ich meine TRKs aus den letzten Tagen abgespeichert habe . Konnte die GPX nur mit einen GPX Editor öffnen .

gruss elmar

Zitat von elmar

Grund mal dahingestellt

der Grund ist das heute jeder macht was er will ....

Gruß
Horst

Zitat von Horst_H

der Grund ist das heute jeder macht was er will ....

Gruß
Horst

ja dem ist wohl so !

Ich nutze ein Programm mit dessen GPX hatte qv noch keine Probleme ! Nach einen Update auf eine neue Version kann qv die GPX nicht mehr lesen .

gruss elmar