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

Cachewolf bricht Import von GPX File ab

A

AndiOlli

Geocacher
Hallo zusammen,

ich habe eine PQ mir gerade gezogen und wollte diese in Cachewolf imortieren, doch leider bricht er nach 197 Cache das laden ab. Andere PQ laufen ohne Probleme durch. Auch sonst hatte ich keine Probleme mit dieser PQ. Kann mir jemand einen Tipp geben. Nutze Version die Version 1.2.3241

Im Anhang die Original PQ

VG Andi
 

Anhänge

  • 6813689_Neubrück.zip
    756,2 KB · Aufrufe: 19
OP
A

AndiOlli

Geocacher
Problem gefunden, da waren in einem Logeintrag undefinierbare Zeichen enthalten und die haben eine Fehler verursacht. Zeichen in GPX File gelöscht und schon liefs durch.
 
mity!

mity!

Geocacher
Hat Groundspeak denn da irgendwas an den GPXn gedreht?

Ich habe dieses Phänomen auch seit ziemlich genau einer Woche. Sieht so aus, dass teilweise Emoticons in den Logs in UTF-8-Zeichen konvertiert werden. Und damit kommt der Cachewolf dann nicht mehr zurecht und bricht den Import ab.

Etwas lästig... :(
 
ColleIsarco

ColleIsarco

Geowizard
Nein, Emoticons werden als Bilder dargestellt. Ich habe es gerade überprüft. Scheint irgendeine Neuerung aus einem Browser / Betriebssystem zu sein. Aber das Problem habe ich auch. Ich versuche eine Lösung dazu zu finden. Allerdings komme ich vor Sonntag nicht dazu.

Gruß
ColleIsarco
 
D

Deichgraf007

Geonewbie
Hallo,

habe das gleiche Problem. Kann mir mal jemand erklären, wie ich die Zeichen in den GPX-File löschen kann? Bitte gaaaaaanz einfach erklären. Vielen Dank!
 
ColleIsarco

ColleIsarco

Geowizard
Moin moin,

ich habe da etwas dran gedreht, aber bei den Test-Dateien bin auf ein anderes Problem gestossen. Das werde ich daher nicht fertig bekommen.

Gruß
ColleIsarco
 
mity!

mity!

Geocacher
Hi Deichgraf007,

das mit dem gaaanz einfach ist so 'ne Sache. Das ist nämlich gar nicht sooo einfach, weil nicht ganz klar ist, wonach man hier eigentlich sucht.

Also, hier mein Weg (und ich versuch's für Dummies ;) ):

Ich habe den Notepad++ (gibt's zum kostenlosen Download) benutzt und das GPX-File geöffnet.
  • Menü 'Suchen/Ersetzen'
  • 'Suchen nach': [^[:print:]]
    (sucht nach nicht-druckbaren Zeichen)
  • 'Ersetzen durch': _
    (Leerzeichen)
  • Dann noch unten den 'Suchmodus' umschalten auf 'Reguläre Ausdrücke'.
  • Über den Button 'Alle Ersetzen' den Ersetzvorgang starten.
Zum Schluss natürlich das so geänderte GPX speichern.

Das Ergebnis wurde von Cachewolf immer gefressen, aber da zum Teil recht beachtliche Trefferzahlen auftauchten, weiß ich nicht so recht, was ich da noch alles rausgeschmissen habe... :/
 
D

Deichgraf007

Geonewbie
Halo mity!

Vielen Dank für die Antwort. Bei mir wurde auch jede Menge raus geschmissen. Cachewolf frisst es jetzt aber!
 
ColleIsarco

ColleIsarco

Geowizard
Moin moin,

ich kann jetzt die GPX-Dateien (bzw. die ZIP-Datei) einlesen. Das solltet ihr jetzt auch mit dem nächsten Nightly-Build hinbekommen. Testet das und gebt mir bitte Feedback.

Gruß
ColleIsarco
 
mirabilos

mirabilos

Geocacher
Jepp, ich seh, was da los ist. Smilies werden als SMP Unicode (z.B. U-0001F604 SMILING FACE WITH OPEN MOUTH AND SMILING EYES) kodiert. Die brauchen 21 Bit statt 16 Bit intern und nutzen ein UTF-8 Encoding von 4 Bytes (oder halt UTF-16); Java™ wurde initial für 16-Bit Unicode (mit 1‥3 Bytes UTF-8 Repräsentation, eigentlich eher CESU-8) geschaffen.

Ich hau die raus. Könnte ein kleines C-Programm basteln, das die .gpx Dateien filtert (gern auch mit stdio, also plattformunabhängig, und versuchen, eine .exe draus zu machen), wenn Interesse (⇒ anschreiben!) besteht. Gern auch mit Shellskript drumrum, das die .zip entpackt, filtert¹ und wieder neu packt, das dann aber definitiv nicht plattformunabhängig (ich versuchs zwar, aber… wobei mit Cygwin geht das auch).

① Was filtern wir denn raus? Ich würde sagen: alles unter U+0020 SPACE (außer U+0009 CHARACTER TABULATION und U+000A LINE FEED), U+007F DELETE, alles oberhalb von U+FFFD REPLACEMENT CHARACTER, alle Surrogates (U+D800‥U+DFFF) und alle PUA (Private Use Area) Zeichen der BMP (U+E000‥U+F8FF), sowie alles, was nicht gültiges UTF-8 für ein gültiges 16-Bit Unicode-Zeichen ist; U+0080‥U+009F („C1 Control Characters“) kann ich anhand ihres Windows Codepage 1252 Äquivalents auf „printable characters“ mappen (bzw. die fünf, die nicht in cp1252 sind, rausstrippen).
 
OP
A

AndiOlli

Geocacher
Hallo,

ich erhalte nun mit der aktuelle NB Version 1.2.3247 folgenden Fehler im Logfile.

Code: 
08.05.2013/22:25:55.974: [GPXImporter:DoIt] GC2YZC3 LogID=
Document contains illegal control character with value 0
	at ewesoft.xml.MinML.fatalError(MinML.java:595)
	at ewesoft.xml.MinML.parse(MinML.java:193)
	at CacheWolf.imp.GPXImporter.doIt()
	at CacheWolf.MainMenu.onEvent()
	at ewe.ui.Control.postEvent()
	at ewe.ui.MenuState.onEvent()
	at ewe.ui.Control.sendToListeners()
	at ewe.ui.Control.postEvent()
	at ewe.ui.Menu.postEvent()
	at ewe.ui.Menu.onEvent()
	at ewe.ui.Control.sendToListeners()
	at ewe.ui.Control.postEvent()
	at ewe.ui.Menu.postEvent()
	at ewe.ui.Control.notifyAction()
	at ewe.ui.Menu.penReleased()
	at ewe.ui.Control.penClicked()
	at ewe.ui.Control.onPenEvent()
	at ewe.ui.Menu.onPenEvent()
	at ewe.ui.Control.onEvent()
	at ewe.ui.Menu.onEvent()
	at ewe.ui.Control.postEvent()
	at ewe.ui.Menu.postEvent()
	at ewe.ui.Window.doPostEvent()
	at ewe.ui.Window$windowThread.run()
	at ewe.sys.mThread.run()

Im Anhang die entsprechende GPX-Datei
 

Anhänge

  • 2792331_zu Hause.zip
    1,1 MB · Aufrufe: 18
arbor95

arbor95

Geoguru
ich hab deine Datei sowohl mit der Version 1.2 (3248) als auch mit 1.3 (3245) ohne Probleme eingelesen (ist ja auch der gleiche Code).
 
OP
A

AndiOlli

Geocacher
Hmm? Mit der heutigen PQ und Version 1.2.3248 klappte es wieder einwandfrei und es wurde alle 500 Caches importiert.
 
S

swiss-tandem

Geonewbie
Hallo zusammen

Das Problem hatten wir auch und sind ihm auf den Grund gegangen. Mehrbytige Zeichen an Buffer-Grenzen verursachen Fehler in BetterUTF8Codec.java. Im Anhang befindet sich ein Patch für dieses Problem. Vielleicht kann das jemand in den Source-Code übernehmen.

Happy Caching

swiss-tandem
 

Anhänge

  • BetterUTF8Codec.java.diff.zip
    648 Bytes · Aufrufe: 20
ColleIsarco

ColleIsarco

Geowizard
Eigentlich hatte die Testdatei genau dieses Problem gehabt. Ich schaue mir das morgen mal genauer an.

Gruß
ColleIsarco
 
ColleIsarco

ColleIsarco

Geowizard
Ok, ich bekenne mich schuldig. Ich hatte den Fall der 3-Byte-Sequenz nicht getestet. Die neue Version ist bereits comitted.

Gruß
ColleIsarco
 
S

swiss-tandem

Geonewbie
Vielen Dank

Müsste nicht die for-Schleife in den Fällen, in denen der ReadBackBuffer gefüllt wird abgebrochen werden, sonst werden die Folgebytes nochmals als Startbyte eines neuen Zeichens verarbeitet. Dafür waren die Erhöhungen von i in meinem Fix gedacht.

Viele Grüsse
swiss-tandem
 
ColleIsarco

ColleIsarco

Geowizard
Du hast im Prinzip Recht. Bei der 2-Byte-Sequenz ist das zwar nicht notwendig, aber jetzt mache ich das Verlassen der Schleife explizit.
Irgendwie bin im Moment nicht glücklich darüber, dass man hier keine JUnit-Tests schreiben kann. Das würde alles einfacher machen.

Ich habe jetzt mal eine main-Klasse geschrieben, die diverse Tests durchführt, werde diese aber nicht comitten, daher gibt es einen Patch
 

Anhänge

  • BetterUTF8Codec.java.patch
    5,2 KB · Aufrufe: 21
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben