GPX Export - PQ like vs. "old GPX export"

[Romanese]

Hallo,

ich habe das selbe Profil einmal mit dem GPX nach Mapsource mit "like PQ" exportiert und einmal mit der "alten GPX export" Funktion. Dabei ist mir aufgefallen, dass z.B. die folgenden Punkte unterschiedlich sind.

Old GPX export
|
GPX like PQ


<wpt lat="35.46418" lon="139.60940">
<wpt lat="35.464183333333" lon="139.6094"> <-- unterschiedliche Anzahl an Nachkommastellen

<groundspeakwner id="23">SBR555</groundspeakwner> <--- Owner ID ist immer 23
<groundspeakwner id="31415">SBR555</groundspeakwner>

<groundspeak:log id="0">
<groundspeak:log id=""> <-- Log ID fehlt

<groundspeak:text encoded="False">
<groundspeak:text encoded=""> <-- fehlt was

 

[MiK]

Den alten habe ich an ein paar Änderungen nicht mehr angepasst. Ich denke er wird auch kurzfristig vollständig durch den neuen ersetzt werden.

<wpt lat="35.46418" lon="139.60940">
<wpt lat="35.464183333333" lon="139.6094"> <-- unterschiedliche Anzahl an Nachkommastellen

Hier sollten wir wohl auch beim neuen die Funktionen getLatDeg/getLonDeg verwenden. Soweit ich weiß haben einige Programme Probleme mit zu vielen Nachkommastellen.

<groundspeakwner id="23">SBR555</groundspeakwner> <--- Owner ID ist immer 23
<groundspeakwner id="31415">SBR555</groundspeakwner>

Und beim neuen ist sie immer 31415. Das wird sich erst ändern, wenn wir sie korrekt erfassen und speichern.

<groundspeak:log id="0">
<groundspeak:log id=""> <-- Log ID fehlt

Auch hier haben wir die nötigen Daten bisher nicht. Der alte zählt dann einfach hoch. Beim neuen wird es noch gar nicht gesetzt.

<groundspeak:text encoded="False">
<groundspeak:text encoded=""> <-- fehlt was

Da der neue es hier auch nicht genauer weiß, sollte man vorerst auch False setzen.

 

[Romanese]

Im "GPX nach Mapsource" wird die <url> .. </url> nicht richtig exportiert (glaube ich zumindest)

so wird es exportiert:

<url>http://www.geocaching.com/seek/cache_details.aspx?wp=GC150XN&Submit6=Find&log=y</url>

so sollte es aussehen:

<url>http://www.geocaching.com/seek/cache_details.aspx?wp=GC150XN&Submit6=Find</url>

 

[greiol]

in einer aktuellen version sollte da

<url>http://www.geocaching.com/seek/cache_details.aspx?wp=GC150XN</url>

stehen

 

[Romanese]

in einer aktuellen version sollte da

<url>http://www.geocaching.com/seek/cache_details.aspx?wp=GC150XN</url>

stehen

Mit der NB 2065 steht nachwievor:

<url>http://www.geocaching.com/seek/cache_details.aspx?wp=GC150XN&Submit6=Find&log=y</url>

 

[Romanese]

Mit dem Export "GPX nach Mapsource" gibt es ein Problem mit der Symbol Darstellung auf Garmin Oregon und wahrscheinlich anderen Geraeten.


<type>Geocache|Multi-cache</type> (Meiner Meinung nach richtig)

<groundspeak:type>Geocache|Multi-cache</groundspeak:type> ("Geocache|" darf nicht vorkommen)

richtig sollte sein --> <groundspeak:type>Multi-cache</groundspeak:type>

 

[Romanese]

in einer aktuellen version sollte da

<url>http://www.geocaching.com/seek/cache_details.aspx?wp=GC150XN</url>

stehen

Mit der NB 2065 steht nachwievor:

<url>http://www.geocaching.com/seek/cache_details.aspx?wp=GC150XN&Submit6=Find&log=y</url>

Ich habe gerade gesehen, dass die Information <url> in GCxyz.xml steht. Ich nehme an, ich muss die Caches alle aktualisieren, damit "&Submit6=Find&log=y" entfernt wird. Richtig?

 

[greiol]

<type>Geocache|Multi-cache</type> (Meiner Meinung nach richtig)

<groundspeak:type>Geocache|Multi-cache</groundspeak:type> ("Geocache|" darf nicht vorkommen)

richtig sollte sein --> <groundspeak:type>Multi-cache</groundspeak:type>

known, aber danke fürs erinnern

 

[jhohn]

Ich habe gerade gesehen, dass die Information <url> in GCxyz.xml steht. Ich nehme an, ich muss die Caches alle aktualisieren, damit "&Submit6=Find&log=y" entfernt wird. Richtig?

Bei mir steht da bei dem neuen Export auch nach einem Aktualisieren der Caches noch das "&Submit6=Find&log=y"

Ausserdem können weder GPXEditor (http://www.knackes.com/blog/index.php?Logiciels&version=1.1.26.450) noch Trekbuddy oder GPSBabel die exportierten Dateien lesen.

Fehlermeldungen:

GPX: XML parse error at line 15 of 'C:\tmp\Caches\export_neu.gpx' : not well-formed (invalid token)

Öffnung export_neu.gpx
File: C:\tmp\Caches\export_neu.gpx. Line: 15 Col: 77 Error: Expected String: ';'
Datei nicht geöffnet
Keine GPX Datei geladen, nichts anzuzeigen

Failed to list store: df: unterminated entity ref (position:TEXT http://www.geoca...@15:78 in java.io.InputStreamReader@c5c7331

Die stören sich alle daran das da ein & und kein & steht.

Mein CW Version ist die 2071

 

[greiol]

Die stören sich alle daran das da ein & und kein & steht.

und sie haben damit auch recht. und weil sie damit recht haben, haben wir mit revision xxxx (hab gerade kein changelog zu hand) auch aufgehört die urls so im cachewolf abzulegen. ich habe aber noch keine gute idee wie wir den kram aus den altbeständen möglichst effektiv rausbekommen.

 

[MiK]

Ich benutze den GPX-Export zugegebenermaßen selten. Und mit dem neuen habe ich noch gar nichts gemacht. Aber mit dem alten GPX-Export hat mein Trekbuddy keine Probleme. Muss mal kontrollieren, ob ich da zufällig nur neue Daten hatte.

 

[MiK]

Ah... im alten Export wurde die URL neu zusammengesetzt aus der Wegpunktnummer. Im neuen wird eine gespeicherte URL verwendet. Spricht etwas dagegen auch beim neuen die URL aus der Wegpunktnummer zu generieren?

 

[greiol]

Ah... im alten Export wurde die URL neu zusammengesetzt aus der Wegpunktnummer. Im neuen wird eine gespeicherte URL verwendet. Spricht etwas dagegen auch beim neuen die URL aus der Wegpunktnummer zu generieren?

ich könnte natürlich fragen warum wir überhaupt eine url speichern wenn wir sie eh ausrechnen können ausrechnen können wir sie aber nur für gc.com hauptwegpunkte. der alte gpx export schreibt gnadenlos vor alles ein gc.com/irgendwas ob das nun passt oder nicht - vermutlich als workaround weil es mit den intern gespeicherten urls ärger gab und wer seinen wolf mit PQs füttert hat da sogar für addis die richtige url drin stehen.

ich hatte aus den "fallbacks" irgendwann mal das "&Submit6=Find&log=y" rausgenommen weil es eben ärger macht und nicht notwendig ist. ob es aber evtl. beim spidern doch wieder reinkommt kann ich - mangels spidern - nicht sagen.

 

[greiol]

ok, für die URLs hier mal die brutale lösung für java ab 1.5

im .zip ist ein .jar und der sourcecode

in der console mit
java -jar Urlfix.jar \pfad\zum\cachewolf\profil
aufrufen

das programm geht alle xml files im verzeichnis durch, sucht nach den zeilen mit der URL, schneidet alles ab dem ersten & ab und schreibt die datei zurück.

anwendung wie immer auf eigene gefahr und nur mit vorherigem backup.

 

[jhohn]

hat funktioniert, vielen Dank greiol

 

[Romanese]

Kann es sein, dass der GPX Export den Hint nicht mehr decodiert?

<groundspeak:encoded_hints>

 

[greiol]

im nächsten build gefixt