Aktualisieren von per GPX importierten Caches via geocaching.com geht nicht mehr

[kaktuskoeln]

Hallo zusammen,

ich exportiere regelmäßig von mir für eine Tour zusammengestellte Caches aus GSAK in ein GPX, das ich dann in c:geo importiere. Anschließend aktualisiere ich dann die Caches via geocaching.com. Seit kurzem funktioniert das nicht mehr: Die importierten Caches werden mit speziellen sechseckigen Symbolen angezeigt (= Quelle ist nicht geocaching.com oder opencaching) und eine Aktualisierung bewirkt schlicht nichts mehr.

Hat jemand einen Tipp, wie ich das Problem lösen kann, also auch via GPX importierte Caches über Geocaching.com aktualisieren kann?

Gruß
Michael

 

[SammysHP]

Dein GSAK exportiert eine ungültige GPX Datei. Mit GSAK kann ich dir leider nicht helfen.

 

[HHL]

ich exportiere regelmäßig von mir für eine Tour zusammengestellte Caches aus GSAK in ein GPX

Öffne das GPX mit einem Texteditor und sieh nach was im Name-Tag steht. Für ein Garmin- resp. Groundspeak-konformes GPX-File darf dort nur der GCcode sehen und sonst nichts.

<wpt lat="53.162517" lon="9.529883">
    <time>2011-09-21T00:00:00</time>
    <name>GC34E18</name>
    <desc>Westervesede Int'l Airport by daRAMA, Multi-cache (1.5/2)</desc>

Natürlich ist das GPX auch ein valides XML-File wenn im Name-Tag mehr als nur der GCcode steht (z. B. noch eine Ordnungsnummer). Jedes GPX-fähige Programm (selbst Garmingeräte) wird das anstandslos importieren. Es sieht so aus als könne c:geo nur vorhandene GPX-Daten von Groundspeak scrapen, wenn es den reinen GCcode vorfindet, und versagt, wenn dort mehr als der GCcode steht. Damit wäre das TO-Problem dann doch ein c:geo-Problem und in diesem Unterforum falsch.

Hans

 

[kaktuskoeln]

Öffne das GPX mit einem Texteditor und sieh nach was im Name-Tag steht. Für ein Garmin- resp. Groundspeak-konformes GPX-File darf dort nur der GCcode sehen und sonst nichts.

Nun gut, das lässt sich ja in den Einstellungen des GPX-Exports anpassen. Jo, funktioniert, besten Dank. Offenbar hatte ich da irgendwann dran rumgefummelt.

Natürlich ist das GPX auch ein valides XML-File wenn im Name-Tag mehr als nur der GCcode steht (z. B. noch eine Ordnungsnummer). Jedes GPX-fähige Programm (selbst Garmingeräte) wird das anstandslos importieren. Es sieht so aus als könne c:geo nur vorhandene GPX-Daten von Groundspeak scrapen, wenn es den reinen GCcode vorfindet, und versagt, wenn dort mehr als der GCcode steht. Damit wäre das TO-Problem dann doch ein c:geo-Problem und in diesem Unterforum falsch.

Die Garmin-Geräte verarbeiten das Zeug aber auch genau so wie es dasteht. Und das bekommt c:geo ja auch hin. Das Problem trat ja erst auf, wenn dann auf die gc-com-Seite zugegriffen werden soll... und da kann ich verstehen, wenn c:geo dann vermutlich gar nicht weiß, um welchen Cache es sich handelt.

Gruß
Michael

 

[SammysHP]

Was stand denn im Name? Wenn es nicht nur der GC-Code ist, versucht c:geo auch noch diverse andere Möglichkeiten (inkl. GSAK GPX Erweiterung). Aber grundsätzlich erwartet c:geo, dass eine GPX-Datei aussieht wie eine normale GPX-Datei von Groundspeak, OpenCaching usw.

Hier gibt es den entsprechenden Code. Wie man am Umfang sieht, ist das nicht ganz trivial.

https://github.com/cgeo/cgeo/tree/master/main/src/cgeo/geocaching/files

 

[kaktuskoeln]

Was stand denn im Name? Wenn es nicht nur der GC-Code ist, versucht c:geo auch noch diverse andere Möglichkeiten (inkl. GSAK GPX Erweiterung).

Wildes Zeug, das eigentlich in das Feld "Cache description" der GSAK-Export-Einstellung gehört hätte.

 

[HHL]

Das Problem trat ja erst auf, wenn dann auf die gc-com-Seite zugegriffen werden soll

Ja klar. c:geo nimmt den name-tag und bildet dann eine url um den Cache aus dem Web zu laden. Wenn mehr als der GCcode dort steht, dann läuft das nicht. Mit einem ordentlichen Regex-String ließe sich das aber abfangen. Also doch eher ein c:geo-Problem. Definitiv aber kein GSAK-Problem.

 

[SammysHP]

Ja klar. c:geo nimmt den name-tag und bildet dann eine url um den Cache aus dem Web zu laden. Wenn mehr als der GCcode dort steht, dann läuft das nicht. Mit einem ordentlichen Regex-String ließe sich das aber abfangen. Also doch eher ein c:geo-Problem. Definitiv aber kein GSAK-Problem.

Wie kommst du auf die Idee? Es gibt einen mehrstufigen Parser, welcher aus diversen Feldern der XML-Datei versucht, einen "Geocode" zu extrahieren. c:geo unterstützt ja nicht nur GC, sondern auch OC, NL, LC, EC, TC und viele mehr. Jeder Connector definiert Pattern. Die werden erstmal versucht, vollständig zu matchen, dann partiell (um z.B. "GC12345 - Ein Cache" zu matchen) usw. Wenn es keinen eindeutigen Match gibt, wird ein Geocode generiert und der Cache als "Benutzerdefinierter Cache" gespeichert.

In diesem Fall stand – wie von @kaktuskoeln bestätigt – nirgends ein GC-Code drin, daher konnte c:geo den Cache auch keiner Plattform zuordnen.

Kein Fehler von GSAK, aber immerhin ein Bedienerfehler bei GSAK.