Wo finde ich denn einen kompakten Überblick über die Vorgaben, die beim Format .gpx zu beachten sind? Auf die Idee, dass in ausgewiesenem Text ein "&" nicht erlaubt ist, muss man ja auch erst mal kommen.
Gruß Hans
Wo finde ich denn einen kompakten Überblick über die Vorgaben, die beim Format .gpx zu beachten sind? Auf die Idee, dass in ausgewiesenem Text ein "&" nicht erlaubt ist, muss man ja auch erst mal kommen.
Gruß Hans
Hallo Hans
gpx = xml
Du kannst dich somit mit der Syntax von xml beschäftigen und findest so die 'Richtlinien'.
zB. Google Suche 'xml reservierte zeichen', 'xml reservierte worte' und/oder ähnliche Suchparameter.
Wo finde ich denn einen kompakten Überblick über die Vorgaben, die beim Format .gpx zu beachten sind?
Schau mal hier nach
http://www.topografix.com/gpx.asp
Zitat
Auf die Idee, dass in ausgewiesenem Text ein "&" nicht erlaubt ist, muss man ja auch erst mal kommen.
Sonderzeichen sind halt schon erlaubt. Man muss sie nur, wie in HTML richtig schreiben.
Also nicht
A&B
sondern
A&B
Dann kann MapSource das auch einlesen.
mfg
JLacky
hallo,
ich habe eine gpx-datei angehängt, die mein ms nicht öffnen kann.
ich habe schon versucht, den tipps hier zu folgen und den fehler zu suchen, aber wenn ich die datei mit dem editor öffne, sehe ich nur einen haufen zahlen und buchstaben, aber keinen fehler, leider sind meine kenntnisse auf diesem gebiet zu rudimentär.
falls mir jemand helfen könnte, wäre das sehr nett.
lg
harald
Hallo,
hier der reparierte Track
Viel Spass damit
Anton
hallo anton,
herzlichen dank für deine mühe.
lg
harald
Gestern 11.gpx, 16.gpx, 17.gpx, ... und heute nun 166.gpx. Dateikopf, Datenformat und Fehler sind identisch. War hier derselbe Spaßvogel unterwegs oder kann dies die Ursache sein:
bei mir ist es unterschiedlich, manchmal ist die verbindung da, manchmal muß ich sie erst wieder herstellen - das ist allerdings mit 5 oder 6 x drücken am zumo erledigt, dauer ca. 10 sekunden und ich sehe es auch nicht als problem.
rätselnd, Martin
Gestern 11.gpx, 16.gpx, 17.gpx, ... und heute nun 166.gpx. Dateikopf, Datenformat und Fehler sind identisch. War hier derselbe Spaßvogel unterwegs oder kann dies die Ursache sein:
rätselnd, Martin
martin, ich bin kein teil einer weltweiten verschwörung mit der absicht, macnetz, andreasL und anderen hilfreichen mitgliedern durch gefakte dateien das leben schwer zu machen. das ist dein zweiter beitrag in dieser richtung, ........:D
und nein, deine vermutung bezüglich der ursache ist nicht richtig, die datei stammt von juni 09, das scala rider habe ich erst wesentlich später gekauft.
lg
harald
p.s. ich habe die datei zwar mit dem editor geöffnet, habe aber keine ahnung, wo der fehler war oder wie man ihn findet. irgendwo habe ich einen beitrag von andreasL gelesen, dass der editor den fehler parst, oder so ähnlich, das sagt mir allerdings nichts und mir wurden vom editor auch keine fehler angezeigt
... und nein, deine vermutung bezüglich der ursache ist nicht richtig, die datei stammt von juni 09, das scala rider habe ich erst wesentlich später gekauft. ...
Hallo Harald,
vielen Dank für Deinen Hinweis auf den Monat der Trackaufzeichnung. Vielleicht führt das auf die Spur der Fehlerursache, denn der Monat Juni taucht überhaupt nicht in der Datei auf (, was meine erste Vermutung nicht so wirklich zu entkräften vermag). Vielmehr steht im Dateikopf das Datum des 26.Sept.2009, und alle Namen der Tracks und alle Zeitstempel der einzelnen Trackpunkte enthalten nur Daten vom 14.-26.Sept.2009. Wenn Du das 4032 Zeichen umfassende Stück von <trk><name>ACTIVE LOG: 26 SEP 2009 15:41</name><trkseg><trkpt lat="46.758404" lon="12.522471"><ele>1024.90</ele><time>2009-09-26T13:41:58Z</time></trkpt> bis <trkpt lat="46.743057" lon="12.468446"><ele>1087.87</ele><time>2009-09-26T13:45:35Z</time></trkpt><trkpt lat="46.742899" lon="12.468731"><ele>1089.31</ele> einmal löschst, dann kannst Du 166.gpx mit MapSource öffnen. Dieser Abschnitt steht nämlich doppelt in der Datei. Und weil demzufolge einmal </trkpt></trkseg></trk> fehlt, meldet MapSource eine fehlerhafte Datei. Vielleicht magst Du mitteilen, woher Du die Datei hast, und welcher Bearbeitung sie möglicherweise unterzogen wurde. Vielleicht kommt man so einem systematischen Fehler in einer Hard- oder Software auf die Spur, für den man bei Kenntnis eine Vermeidungsstrategie entwickeln könnte. Wenn Antons Datei Dir schon genügt, dann ist es natürlich auch gut.
Gruß, Martin
hallo martin,
tut mir leid, in meinem vorherigen posting habe ich was falsches geschrieben, die trackaufzeichnung stammt vom september.
die datei stammt aus dem archivordner von meinem zumo, und sie wurde vorher gar nicht behandelt. ich habe sie nur vom zumo auf den pc übertragen und wollte sie öffnen, was eben nicht ging.
original hat die datei die nummer 66, die 65 zuvor konnte ich alle problemlos öffnen, ebenso die darauffolgenden 4.
lg
harald
Hallo Harald,
wenn es so ist, wie Du schreibst, dann habe ich mal wieder falsch vermutet . Die zeitliche Nähe Deiner defekten *.gpx Datei und der von voni, dazu derselbe Fehler, keine Aussage über die Datenherkunft, ... da wäre ein Spaßvogel, der seine defekten Dateien auf einer Internetplattform zum Herunterladen anbietet die einfachste Ursache gewesen.
Dass ich meine Aussage so formuliert hatte, dass auch Du damit gemeint sein konntest, dafür möchte ich mich dann auch in aller Form bei Dir entschuldigen .
Leider ist dadurch die Ursache des Fehlers nicht gefunden. Und leider bin ich ohne Zumo und Motorradführerschein da auch am Ende meines Lateins.
In der Hoffnung, dass der Fehler nie wieder auftaucht, oder jemand anderes schreibt, wie das doppelte Datenstück zustandekommt, Martin
Hallo Martin,
das Problem ist alt und entsprechend im Forum behandelt - Suchfunktion
in Kürze:
wenn der Zumo abstürzt wird die Trackdatei beim gerade geschriebenen Trackpunkt nicht korrekt abgeschlossen. Der neue Track nach dem Einschalten wird dann korrekt geschrieben bis zum Dateiende (oder einem weiteren Software-Absturz).
Eine solche defekte Datei kann man einfach reparieren da ja der Anfang eines Tracks bekannt ist "<trk><trkseg><trkpt>" Wenn man nach dieser Zeichenfolge sucht und bei jedem Trackanfang auf den davor liegenden Tag schaut hat man die defekte Stelle innerhalb weniger Sekunden gefunden.
Grüsse - Anton
Alles anzeigenHallo Martin,
das Problem ist alt und entsprechend im Forum behandelt - Suchfunktion
in Kürze:
wenn der Zumo abstürzt wird die Trackdatei beim gerade geschriebenen Trackpunkt nicht korrekt abgeschlossen. Der neue Track nach dem Einschalten wird dann korrekt geschrieben bis zum Dateiende (oder einem weiteren Software-Absturz).
Eine solche defekte Datei kann man einfach reparieren da ja der Anfang eines Tracks bekannt ist "<trk><trkseg><trkpt>" Wenn man nach dieser Zeichenfolge sucht und bei jedem Trackanfang auf den davor liegenden Tag schaut hat man die defekte Stelle innerhalb weniger Sekunden gefunden.
Grüsse - Anton
hallo anton,
zumindest in meinem fall war ein absturz vom zumo nicht der auslöser für die defekte datei. ich hatte erst zwei, den einen vor ca 2 jahren und den anderen vorige woche.
lg
harald