GPX mit Addi-Waypoints nach GSAK exportieren

[Wutschkow]

Irgendwie schaffe ich es nicht, dass GSAK bei einer von Cachewolf exportierten GPX-Datei die enthaltenen Addi-Waypoints als Child-Waypoints einliest. Ich habe es im Import-Dialog extra so eingestellt. Wenn ich die von Cachewolf erstellte GPX-Datei mit der von GC heruntergeladenen (bei der es klappt) vergleiche, scheinen mir die Unterschiede ziemlich minimal:
GC:

<wpt lat="52.281117" lon="8.028983">
    <time>2009-04-14T12:36:34.55</time>
    <name>S31Q22A</name>
    <cmt />
    <desc>Station3</desc>
    <url>http://www.geocaching.com/seek/wpt.aspx?WID=24c344cb-578e-4327-8786-150a41295add</url>
    <urlname>Station3</urlname>
    <sym>Question to Answer</sym>
    <type>Waypoint|Question to Answer</type>
  </wpt>

Cachewolf:

<wpt lat="52.28112" lon="008.02898">
    <time>2000-01-01T00:00:00.0000000-07:00</time>
    <name>S31Q22A</name>
    <cmt></cmt>
    <desc>Station3 by Florichan</desc>
    <url>http://www.geocaching.com/seek/cache_details.aspx?wp=S31Q22A&Submit6=Find</url>
    <urlname>Station3 by Florichan</urlname>
    <sym>Waypoint|Question to Answer</sym>
    <type>Waypoint|Waypoint|Question to Answer</type>
  </wpt>

Bei der GC-Version liest GSAK die Addis als Child-Waypoints ein, bei der Cachewolf-Version macht er daraus aber jeweils eigenen Waypoints. Hat jemand einen Tipp für mich, woran das liegt?

 

[Carsten]

Vielleicht liegt es daran, dass in <sym> und <type> etwas anderes drin steht. Aber wozu das eigentlich? Importier doch das GPX von Groundspeak direkt in GSAK.

 

[MiK]

Welchen GPX-Export mit welcher Version nutzt Du denn genau?

 

[Wutschkow]

Ich benutze einfach "Anwendung/Export/GPX". Buildnummer ist 2046.

Die Angaben bei <sym> und <type> hatte ich schonmal manuell angepasst, das ändert nichts.

 

[MiK]

Da ist wohl bei der Formatumstellung etwas kaputt gegangen. Früher gab es nur die Typstrings und der Exporter hat dann je nach Feld das "Geocache" oder "Waypoint" davor gesetzt. Jetzt steht bei den Strings der Addis das "Waypoint" schon fest davor. Damit kann man den richtigen String für <sym> nicht mehr richtig zusammenbauen. Man sollte wohl bei den Strings den Vorsatz wieder weglassen und erst im Exporter anfügen.

 

[MiK]

Ich benutze einfach "Anwendung/Export/GPX". Buildnummer ist 2046.

Die Angaben bei <sym> und <type> hatte ich schonmal manuell angepasst, das ändert nichts.

Dann passe doch mal weiter Schritt für Schritt an und schaue ab welcher Änderung es funktioniert.

 

[greiol]

probier mal den anwendung / export / nach GPX mapsource und wähle dort pqlike. vielleicht klappt der ja.

 

[MiK]

probier mal den anwendung / export / nach GPX mapsource und wähle dort pqlike. vielleicht klappt der ja.

Zumindest <sym> dürfte dort auch nicht stimmen. Aber daran liegt es ja anscheinend nicht.

 

[greiol]

probier mal den anwendung / export / nach GPX mapsource und wähle dort pqlike. vielleicht klappt der ja.

Zumindest <sym> dürfte dort auch nicht stimmen. Aber daran liegt es ja anscheinend nicht.

also bei mir stimmen sym und type.

 

[MiK]

probier mal den anwendung / export / nach GPX mapsource und wähle dort pqlike. vielleicht klappt der ja.

Zumindest <sym> dürfte dort auch nicht stimmen. Aber daran liegt es ja anscheinend nicht.

also bei mir stimmen sym und type.

Dann habe ich mich wohl im Code verschaut. Woher nimmt er denn den String für <sym> ohne das "Waypoint|" davor?

Edit: Ok, ich sehe es. Er schneidet es im Code wieder ab. Fand ich vorher schöner. Aber egal. Der alte Exporter fliegt dann ja sowieso raus.

 

[MiK]

Aber eine andere Frage: Fehlt beim NG bei den Hauptwegpunkten nicht ein "Geocache|" vor im <type>?

 

[Wutschkow]

probier mal den anwendung / export / nach GPX mapsource und wähle dort pqlike. vielleicht klappt der ja.

Das mag GSAK gar nicht erst importieren. "does not pass XML validation and will be ignored...not well-formed"

Ansonsten: Selbst wenn ich die einzelnen <wpt>...</wpt> komplett aus der GC- in die CW-GPX-Datei übernehme, klappt es nicht. Das Problem liegt also anscheinend nicht bei den einzelnen <WPT>-Definitionen sondern vielleicht schon weiter oben. Vielleicht ist es ja aber auch ein Problem von GSAK.

Ich habe allerdings beim Recherchieren zu den Child-waypoints einen Workaround für mein Problem gefunden. GSAK kann die Addis direkt aus der Cachebeschreiung grabben und als Child-Waypoints einfügen. Also exportiere ich in Zukunft einfach nur noch die Caches ohne Addis und grabbe die Addis dann in GSAK aus der Beschreibung.
Mir ging es nur darum, in GSAK nicht nochmal die ganzen Caches von GC runterladen zu müssen, nur um die Addis als Child-Waypoints zu haben.

 

[greiol]

das hast du recht, das sollte ich mal noch fixen. ich muss dafür aber erst nachher wieder das experiemtn wegsichern bevor ich zurück switche.

 

[greiol]

GSAK kann die Addis direkt aus der Cachebeschreiung grabben und als Child-Waypoints einfügen.

klappt da die zuordnung nach der art des addis? ich wollte sowas auch mal machen, aber ich habe keine methode gefunden sicher zu ermitteln ob das nun ein parkplatz, eine stage oder eine question ist.

Das mag GSAK gar nicht erst importieren. "does not pass XML validation and will be ignored...not well-formed"

das problem mit "not well formed" sollte seit gestern weg sein

 

[Wutschkow]

das problem mit "not well formed" sollte seit gestern weg sein

Ich habe heute morgen ein Update gemacht und selbst kompiliert (rev 2046). Das datfile ist auch von heute morgen.

 

[greiol]

ok, da war noch eine quelle für malformed wenn in den details für einen cache keine urls hinterlegt waren. und das fehlende "Geocache|" sollte dann auch kommen.

 

[Wutschkow]

Also mit dem aktuelle NB 2051 klappt der Import der per "Export/nach GPX Mapsource" erzeugten GPX-Datei ins GSAK nun.
Allerdings sind die Addis auch hier separate Wegpunkte und keine Child-Waypoints.

Außerdem haben alle importierten Wegpunkte in GSAK den Typ "Other".
Ich nehme mal an, das liegt hieran:

<groundspeak:type>Geocache|Traditional Cache</groundspeak:type>

In einer GC-GPX sieht das so aus:

<groundspeak:type>Multi-cache</groundspeak:type>

Dies hingegen ist bei beiden Versionen identisch:

<type>Geocache|Multi-cache</type>

Tja, da hat sich der Teufel wohl mal wieder im Detail versteckt, der Mistkerl!

 

[greiol]

die machen mich noch wahnsinnig mit ihren 25 verschiedenen schreibweisen an 18 stellen :zensur: ich schaus mir an

 

[Wutschkow]

So, mit ein wenig Fleiß habe ich jetzt auch das Geheimnis der Child-Waypoints entschlüsselt. Aber bitte festhalten, damit mir hier keiner vom Stuhl kippt!

Wenn man in der GPX-Datei aus

<desc>This is a list of waypoints for geocaches generated by CacheWolf</desc>

einfach

<desc>This is an individual cache generated from Geocaching.com</desc>

macht (egal ob nun ein Cache oder mehrere drinstehen), dann klappt es auch mit den Child-Waypoints. Offenbar brät GSAK da eine Extrawurst für GPX-Dateien von GC. Man müsste also unter falscher Flagge segeln, wenn man Child-Waypoints bekommen möchte.
Könnte man in den GPX Mapsource-Export eventuell noch eine Variante "GSAK" aufnehmen, die diesen Piratenstreich durchführt? Oder bestehen da grundsätzliche Bedenken? Dann frickel ich selber was für mich zurecht. Im Grunde genommen ist es ja ein Problem von GSAK und nicht von Cachewolf.

 

[greiol]

eigentlich wollte ich aufhören "unter falsche flagge" zu segeln und hätte mich gefreut wenn andere tools statt nach der desc nach den verwendeten namespaces geschaut hätten, aber natürlich ist das eine methode zu versuchen eine pq als solche zu erkennen.

holen wir also unsere flagge ein und hissen eine andere.

klappt es bis nächste woche noch ohne die änderung? da ich gerade an der gui bastel habe ich mir einen zweiten sourcetree aufgebaut (damit die NBs bis zum abschluss der arbeiten laufen) und es ist immer etwas lästig in zwei strängen gleichzeitig zu ändern.