• Willkommen im Geoclub - dem größten deutschsprachigen Geocaching-Forum. Registriere dich kostenlos, um alle Inhalte zu sehen und neue Beiträge zu erstellen.

Fehler beim Exportieren einer GPX-Datei im CW (Cachewolf)

JonDo

Geocacher
Hallo Ihr fleißigen Programmierer! Es ist wird ein Fehler angezeigt, wenn der Cache GC25PMB nach GPX exportiert wird.
Benutzt habe ich den CW NB 1.3.3385.
Weitere Einstellungen:
PQ Like
Classic ID
Customs Icons
Attrib.->LOG
Max Logs 8


Dieser Fehler ist reproduzierbar, da ich diesen in einem neuen Profil erstellt habe, und nur diesen Exportiert.

Es wäre schön, wenn Ihr den Fehler finden könntet.

Mit freundlichen Grüßen
JonDo
 

arbor95

Geoguru
Es wäre noch schön, wenn ich die Fehlermeldung hätte (vorzugsweise die log.txt, am besten mit eingeschaltetem debug = Fehlersuchmodus).

Bei der Einstellung "Custom Icons" wird auch noch die entsprechende Referenzdatei benötigt.

Bei mir wird die gpx-Datei erzeugt.
(in den logs hat sich mal wieder jemand ausgetobt, was eventuell einen Import in andere Programme verhindert)
 
OP
JonDo

JonDo

Geocacher
Hallo Ihr fleißigen Programmierer!

Da habe ich ein Problem, auch bei mir wird die GPX-Datei ohne Fehler erzeugt.
Jedoch kann diese nicht in MapSource, oder dem GPS (Oregon 550t) benutzt werden.
Der Fehler wird im Programm XML Notepad 2007 mit Zeile und Stelle in den Logs angegeben.

Zeile 140 Pos 60 ungültiges Zeichen -> Datei ist angefügt.

Anhang anzeigen X_Test.gpx

Es wäre noch schön, wenn ich die Fehlermeldung hätte (vorzugsweise die log.txt, am besten mit eingeschaltetem debug = Fehlersuchmodus).

Wenn es hilft würde ich Dir ja die Dateien zusenden, habe jedoch keine Ahnung wie das geht.

Es wäre schön wenn der CW diesen Fehler beim Exportieren korrigieren könnte, damit die Datei nicht immer nach dem Exportieren überprüft werden muß.

Mit freundlichen Grüßen
JonDo
 

arbor95

Geoguru
Woher soll CW wissen, was Mapsource oder Orgon nicht versteht.

Die Ursache ist auf jeden Fall der log von "kikikil" vom 2013-09-15. (Wieso nimmst du so alte logs mit?)
Wie der log bei gc (gpx - export) aussieht kann ich nicht sagen, der liegt ja schon lange zurück und gc gibt ja nur ein paar logs mit aus.
Es lassen sich diese Zeichen, die hier mapsource oder oregon stören, aber auch nicht grundsätzlich ausschliessen.

Falls so etwas gehäuft auftreten sollte, dann ....
Ansonsten....
 
OP
JonDo

JonDo

Geocacher
Hallo Ihr fleißigen Programmierer!

Da hast Du sicherlich recht! Grundsätzlich nehme ich immer die letzten 8 Logs mit.
Wenn keine jüngeren Logs mehr vorhanden sind werden die alten halt nicht überschrieben.

Da es offensichtlich grundsätzlich nicht gewünscht wird dieses störende Zeichen auszuschließen, ist es denn möglich beim Exportieren immer diese und andere Zeichen außer den Benötigten (Buchstaben, Zahlen und Satzzeichen) aus den Logs zu entfernen? Dann würde der Fehler ja nur noch auftreten, wenn dieses Zeichen in der Beschreibung steht. Was dann etwas berechenbarer ist.

Was hindert einen Logger denn daran auch in einem aktuellen Logeintrag diese Zeichen zu verwenden?
Nichts fürchte ich.
Die Alternative wäre immer eine GPX Datei zu erzeugen, die keine Logs enthält. Das wäre aber schade.

Zur Häufigkeit: Bislang ist dieser Fehler erst in 12 Cache aufgetreten.
Jedoch ist dann die gesamte Datei nicht lesbar. Obwohl nur eine Log darin diesen Fehler enthält.

Die zugesandte Datei enthält alle 12 Caches. Vorsichtshalber habe ich eine Zip Datei angehängt mit den xml Dateien

Benutzt habe ich den CW NB 1.3.3390. der sehr gut und bislang fehlerfrei funktioniert.

Mit freundlichen Grüßen
JonDo
 

Anhänge

  • Fehler-Cache.zip
    489 KB · Aufrufe: 51

arbor95

Geoguru
Das ganz ist halt ein Balanceakt zwischen exakter Wiedergabe und grober Vereinfachung.
Wobei die exakte Wiedergabe nicht unbedingt im CW selbst sein muss sondern auch den Export für andere Geräte bzw Programme betrifft.

Ich kann, wie schon geschrieben, nicht einfach irgendwelche Sequenzen rauswerfen, die in anderem Zusammenhang durchaus gültige sinnvolle ev. wichtige Texte produzieren können.

Aber ich schaue mir die 12 Beispiele gerne mal genauer an.

Es sind bei mir aus dem zip auch nach "index neu erstellen" nur 8 Cache (und 3 Wegpunkte). (Wem wurde wo was zugesandt?)
 
OP
JonDo

JonDo

Geocacher
Hab mich verzählt. Ich habe einfach alle kml Dateien gezählt ohne zu bemerken, daß nur Dateien mit GC...kml Caches sind.
Mit freundlichen Grüßen
JonDo
 

w_koe_ddorf

Geocacher
Hi,

ja das wäre scherlich hilfreich wenn da nur valides xml in die GPX Files käme, muss auch
immer mühsam die Schmierzeichen aus den Logs entfernen, groundspeak muss das auch irgendwie filtern bei deren PQ sind die Schmierzeichen nicht drin.

VG Wolfgang

VG Wolfgang
 

arbor95

Geoguru
Es könnte bei uns beim Wandeln der erhaltenen Webseite in UTF8 Zeichen passieren (im BetterUTF8Codec).
Ich habe mal kurz reingeschaut, aber dann nicht weiter gemacht.
 

ColleIsarco

Geowizard
Moin moin,
Den hatte ich doch mal geschrieben. An und für sich hatte ich den JUnit-Tests entwickelt, heisst natürlich nicht, dass alle Fälle abgedeckt sind.
Auf den ersten Blick sehe ich da erst einmal eine 3-Byte-Sequenz, dass kann der Decoder aber auf jeden Fall. Vor dem WE kann ich mir das aber nicht anschauen.

Gruß
ColleIsarco
 

Sourwart

Geocacher
Hallo,
ich benutze den Cachwolf und exportiere die Daten als GPX PQ-like dann in smartgpx auf meinem alten, Nokia 5800.

Das funktionierte bis Version 3394 absolut zuverlässig.

Als ich die Tage die Versionen 3398 bis einschließlich 3400 testete, brach der Import in smartgpx immer wieder ab.

Daraufhin habe die 3394 erneut installiert und die GPX-Dateien verglichen. Und siehe da, das scheint sich im Export-Modul ein Fehler eingeschlichen zu haben:

korrekt in Version 3394
<groundspeak:date>1900-00-00T00:00:00</groundspeak:date>

Abbruch ab Version 3398
<groundspeak:date>T00:00:00</groundspeak:date>

Das Problem liegt im nicht vollständigen Datum/Uhrzeit-Format. Denn ändert man dies in den Dateien ab 3398 auf ein vollständiges Datum/Uhrzeit-Format wie in 3394 dann klappt es auch wieder mit dem Import in smartgpx.

Liebe Programmierer, wäre es möglich den vermeintlichen Bug zu reparieren? Denn ich würde gerne weiterhin mit meinem alten Nokia 5800 und seperater SIRF-Bluetoothmouse auf Dosenjagd gehen. Denn in der Kombi kann ich dank des geringen Stromverbrauchs über 6 Stunden lang am Stück cachen!

DANKE!
 

arbor95

Geoguru
Wie du vielleicht gesehen hast, wird der gpx-export gerade überarbeitet (und hoffentlich noch besser gemacht).

Vielleicht kannst du mir mal den vollständigen log oder cache mitteilen, bei dem der Fehler auftritt.

Bei mir steht wohl immer ein korrektes Datum drin:
<groundspeak:date>2014-09-08T00:00:00</groundspeak:date>
 

Sourwart

Geocacher
Hallo,
kein Problem, dachte ich. Der Fehler scheint - so wie es sich mir darstellt - bei allen Caches vorzukommen. Und zwar immer beim letzten Log wird das Datumsfeld nur verkürzt dargestellt.

Beispiel-Caches:
GC2WRYZ (funktioniert nach Aktualisierung)
GC2PZ4B (siehe unten)

Und jetzt wird es kompliziert: Nachdem ich diese Caches mal aktualisiert habe, funktioniert der Export wieder einwandfrei. Komisch oder?

Vielleicht liegt es daran, dass ich zwischendurch mal die letzten 5 der der letzten 3 Caches in den Wolf importiert habe und danach wieder auf 3 umgestellt habe.

Es sieht so aus, als ob die Schleife einen Durchlauf zu früh abgebrochen wurde und deshalb im letzten Durchlauf das Kurzdatum ausgegeben wurde.

Aber wie gesagt, die 3394 hat damit überhaupt kein Problem, ab 3398 geht es nur noch, wenn man die Caches aktualisiert.


Auszug aus der GC2PZ4B.xml-Datei
<LOGS>
<OWNLOGID></OWNLOGID>
<OWNLOG><![CDATA[]]></OWNLOG>
<LOG><![CDATA[<img src='2.png'> 2014-02-02 by Mumpel1625<br>Bei bestem Wetter schnell gefunden und geloggt. Danke]]></LOG>
<LOG><![CDATA[<img src='2.png'> 2013-11-08 by Team fmx2002<br>Beim Sauerlandbesuch ne schöne Runde gedreht!<br />DFDC<br /><br />Das war der Letzte für den Tag <img src="icon_smile_wink.gif" border="0" align="middle" />... schliesslich wartete noch ein 40ster Geburtstag!!!<br />Happy Birthday Stefan!!!]]></LOG>
<LOG><![CDATA[<hr>Es gibt mehr Logs<hr>]]></LOG>
</LOGS>

Und diese Logs im GPX-Export ab Version 3398 (die 3395 bis 3397 hatte ich nicht im Einsatz, aber 3394 verarbeitet das korrekt:
<groundspeak:logs>
<groundspeak:log id="21202890">
<groundspeak:date>2014-02-02T00:00:00</groundspeak:date>
<groundspeak:type>Found it</groundspeak:type>
<groundspeak:finder id="">Mumpel1625</groundspeak:finder>
<groundspeak:text encoded="">Bei bestem Wetter schnell gefunden und geloggt. Danke</groundspeak:text>
</groundspeak:log>
<groundspeak:log id="21202891">
<groundspeak:date>2013-11-08T00:00:00</groundspeak:date>
<groundspeak:type>Found it</groundspeak:type>
<groundspeak:finder id="">Team fmx2002</groundspeak:finder>
<groundspeak:text encoded="">Beim Sauerlandbesuch ne schöne Runde gedreht!
DFDC

Das war der Letzte für den Tag ... schliesslich wartete noch ein 40ster Geburtstag!!!
Happy Birthday Stefan!!!</groundspeak:text>
</groundspeak:log>
<groundspeak:log id="21202892">
<groundspeak:date>T00:00:00</groundspeak:date>
<groundspeak:type>unknown logtype </groundspeak:type>
<groundspeak:finder id=""></groundspeak:finder>
<groundspeak:text encoded=""></groundspeak:text>
</groundspeak:log>
</groundspeak:logs>

Ich hoffe das hilft, den Fehler, der offensichtlich bei mir auftritt, zu finden.

Ansonsten muss ich wohl oder übel alle Caches aktualisieren. Oder für den Export immer die 3394 nehmen.
 

Sourwart

Geocacher
Hallo noch ein Nachtrag:

gerne hätte ich die komplette GC2PZ4B.xml hochgeladen, doch das wird leider als Angrfiffsversuch gewertet und ist somit nicht möglich.

Nachfolgend noch der Auszug aus der index.xml:
<CACHE name = "Bestwiger Panoramaweg | Etappe 4 | St. 9" owner = "Projekt Panorama" lat = "51,340983333333" lon = "8,386333333333" hidden = "2011-05-25" wayp = "GC2PZ4B" status = "" ocCacheID = "" lastSyncOC = "20140421121421" num_recommended = "423" num_found = "-1" attributesYes = "275951691776" attributesNo = "1048576" boolFields="1027" byteFields="33689359" attributesYes1 = "0" attributesNo1 = "0" />


Wie gesagt: die 3394 verarbeitet die Daten einwandfrei, ab 3398 passiert mit der gleichen index und cache - xml der Fehler. Es sei denn, man aktualisiert.
 
OP
JonDo

JonDo

Geocacher
Hallo arbor95


Nochmal zu
Zitat

Die Ursache ist auf jeden Fall der log von "kikikil" vom 2013-09-15.

Ich kann, wie schon geschrieben, nicht einfach irgendwelche Sequenzen rauswerfen, die in anderem Zusammenhang durchaus gültige sinnvolle ev. wichtige Texte produzieren können.


Prima Du hast ja in der 3401 Version eine Punkt eingefügt mit dem man die HTML Tags in Logs entfernen kann. Ich weiß zwar nicht genau wozu die gut sind, vermute aber das es sich au hierbei um störende Elemente handelt.

Nach meinen Untersuchungen stört immer wieder das Zeichen 63 welches ein Fragezeichen erzeugt, in Excel wird es als Fragezeichen in Quadrat dargestellt.

Bitte füge doch noch einen Punkt ein der, dieses Zeichen, in den Logs entfernt. Das wäre Spitze.

Wenn ich Manuell (mit dem Texteditor) das Zeichen entferne, dann wird die GPX-Datei fehlerfrei geöffnet. Nach meinen Untersuchungen, auch im Garmin.

Im Anhang habe ich mal den fraglichen Export Datei angefügt einmal mit Fehler einmal Korrigiert, die Einstellungen beim Exportieren und die Original XML Datei

Sonst bin ich von mal zu mal begeisterter was Du und andere mit dem CacheWolf geschafft haben. Super. Prima. Spitze

Mit freundlichen Grüßen
 

Anhänge

  • Pack.ZIP
    459,1 KB · Aufrufe: 42

Sourwart

Geocacher
Hallo,

alles super, habe die 3402-Win-Version gestestet. Import einwandfrei, Export für GPX-PQ-Like funktioniert auch wieder und zwar mit als auch ohne HTML-Tags.

Zum Thema von JonDo
===================

Ich habe auch ab und an einige Logs, die Sonderzeichen enthalten und dann beim Import in smartgpx für Abstürze sorgen. Ich schaue mir dann das exportierte GPX-File an. In Notepad++ sind die Sonderzeichen dann schwarz hinterlegt. Diese lösche ich dann einfach. Oder nutze meine Liste für die Suche nach diesen Sonderzeichen und das Ersetzen durch Leerzeichen. Damit ist das Problem dann auch gelöst.

Zwie Sonderzeichen habe ich mir aber "verwahrt", weil die immer wieder für Fehler sorgen:

, das entpspricht in Notepad++ einem ENQ
, entspricht einem STX

Vielleicht hilft das weiter.

Ansonsten vielen Dank - Alles wieder prima!
 

arbor95

Geoguru
Ich habe die Ursache behoben: eine fehlerhafte Konvertierung von html in den verwendeten Zeichensatz.

Das hilft beim Export erst mal nichts, da die Daten ja schon in der "DB" sind.
Ein Aktualisieren des/der Cache/s (am besten mit Ersetzen der vorhandenen Logs) führt aber zum Erfolg.
 
Oben