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

Probleme bei Export aufs Oregon

Lamima

Geocacher
Hallo,

ich habe hier ein kleine Exportproblem auf mein Oregon 200.
Folgender Fall:
Ich löse einen Mystery und nehme dann den Eintrag im CW, ändere die Koordinaten, das Logo und den Namen des Wegpunktes von GC12345 in FI12345 damit beim nächsten spidern nicht wieder die "falschen" Koordinaten da stehen. Klappt auch ganz prima, das spidern überlebt der Eintrag.
ABER: Wenn ich nun eine gpx aufs Oregon schreibe kommen zwar alle anderen Caches dort an...aber genau dieser eine gelöste Mystery nicht. Fehlermeldung gibt es keine. Warnsymbole gibt es auch keine.

Gruß

Lamima

Edit: Hier läuft Windows mit CW in der Version 1.1.2129
 

pfeffer

Geowizard
hmm - ja, nun, das Ändern des Wegpunktnames ist gefährlich ;-)

Ich würde es so machen, dass ich die berechnete Koordinate als Zusätzlichen Wegpunkt anlege "Addi" (Final). Ich denke, damit müsstest Du (hoffentlich) den gleichen Effekt haben, dass er beim Spidern (hoffentlich) nicht gelöscht wird, aber exportierbar ist.

Gruß,
Pfeffer.

EDIT: Aber ich würde es dennoch als Bug bezeichnen, dass nicht alle Wegpunkte übertragen werden.
 

greiol

Geoguru
die von pfeffer vorgeschlagene variante hat den vorteil nicht nur zu funktionieren (das umbenennen ist leider noch nicht vollständig in profile / cache datenbank implementiert), sondern auch platz zu sparen, da text und bilder nicht erneut geladen werden müssen.
 
OP
L

Lamima

Geocacher
Das könnte funktionieren.
unschön daran ist jedoch, dass ich generell ALLE addi waypoints ausfiltere und nicht mit exportieren.
Wenn also nun jemand bei nem multi den final als addi angelegt hat (und keine koords mitgeliefert hat) exportiert man mehr oder minder viele unnötige daten....
 
OP
L

Lamima

Geocacher
ah ok, DAS wusste ich nicht....dann werd ich die oben vorgestellte lösung als privaten workaround nehmen...aber wenn das mit dem Ändern irgendwann klappen sollte wäre das natrülich viel besser
 
OP
L

Lamima

Geocacher
Die Probleme reisen nicht ab...
Ich hab mein Garmin jetzt komplett leer gemacht(es müssten also 1000Caches drauf passen) und ein CW Profil mit 603 Caches im Umkreis von 15km. EIGENTLICH sollten die nach einem ganz normalen GPX Export ja alle auf dem Oregon zu finden sein, oder?
Stattdessen sind nur caches im Umkreis von 10,23km zu finden....es fehlen also eindeutig eine ganze Menge Caches....was man auch sofort mit dem optischen Vergleich Radar und Kartenansicht im Oregon bestätigen kann. Woran kann das liegen?

Gruß

Marco
 

Vitrus

Geocacher
Hallo Marco,

bei mir war es ähnlich. Von ca. 500 Caches kamen von der gpx nur 80 St. auf dem Oregon an. Es war bei 12 Km Umkreis ende.
Auch gsak wollte die gpx erst gar nicht haben. Das Problem war bei mir ein einziger Cache mit Sonderzeichen und zwar dieser:

http://www.geocaching.com/seek/cache_details.aspx?guid=b8960b24-e6bb-4c13-ad21-fe58a740d0e1

Ich habe einfach diesen Cache aus dem Profil gelöscht und alles war wieder i.O. Auch gsak beschwerte sich nicht.
Vielleicht ist es bei dir so ähnlich? Hier die Beiträge dazu:

http://www.geoclub.de/viewtopic.php?f=40&t=37840

Grüße

Vitrus
 
OP
L

Lamima

Geocacher
Danke Vitrus!!!

In genau der besagten Entfernung gab es einen Cache mit wirklich seltsam anmutenden Zeichen in der Beschreibung....habe die Zeile durch eine xml-validation ausfindig gemacht, die zeichen gelöscht, den cache auf meine blacklist gesetzt und schon geht alles.

An die DEVs: Ist in Bezug auf die Vermeidung solcher Exportfehler was in Arbeit? Weil eigentlich ist es ja schon fahrlässig ein UTF-8 dokument zu erstellen ohne sich zu stellen dass auch nichts anderes drin steht...

Gruß

Marco
 

MiK

Geoguru
Lamima schrieb:
An die DEVs: Ist in Bezug auf die Vermeidung solcher Exportfehler was in Arbeit? Weil eigentlich ist es ja schon fahrlässig ein UTF-8 dokument zu erstellen ohne sich zu stellen dass auch nichts anderes drin steht...
Als wir dieses Problem das letzte mal untersucht haben, stellte sich heraus, dass diese Zeichen sehr wohl gültiges UTF-8 ist. Nur kommen anscheinend nicht alle Programme damit klar.
 

xileF1337

Geonewbie
Hallo Leute, das ist mein erster Beitrag in diesem Forum :winken:

Ich habe genau dasselbe Problem wie Lamima: hier in der Gegend gibt es einige Cache-Listings, die merkwürdige Sonderzeichen enthalten, weshalb mein Oregon 200 nur bis zu einem bestimmten Cache die GPX-Datei ausliest.
Als Work-around habe ich die GPX-Datei im Open XML Editor geöffnet und per Tools -> Check Wellformedness die "Wohlgeformtheit" (wie auch immer...) die entsprechenden störenden Sonderzeichen suchen lassen. Dann habe ich nur diese Sonderzeichen aus der GPX-Datei gelöscht ("Check Wellformedness" und die Korrektur muss man so lange wiederholen bis es an der "Wohlgeformtheit" nichts mehr zu meckern gibt) und die veränderte Datei gespeichert. Und... :gott: :gott: :gott: mein Oregon zeigt alle Caches auf der Karte :gott: :gott: :gott:
Nun muss man das natürlich für jede aus CacheWolf exportierte GPX-Datei machen, damit das Garmin sie komplett auslesen kann, was durchaus etwas nervig ist ;)

Lamima schrieb:
An die DEVs: Ist in Bezug auf die Vermeidung solcher Exportfehler was in Arbeit?
MiK schrieb:
Als wir dieses Problem das letzte mal untersucht haben, stellte sich heraus, dass diese Zeichen sehr wohl gültiges UTF-8 ist. Nur kommen anscheinend nicht alle Programme damit klar.

Ich wiederhole die Frage von Lamima, da die Antwort von MiK sehr... nebulös ist ;) War das ein klares "Nein"? Oder wird doch drann gewerkelt? Und wenn ja, wie wird das ganze dann funktionieren? Würde beim Export jedes problematische Sonderzeichen automatisch gelöscht werden, oder wird gleich der ganze Cache nicht exportiert? Ersteres wäre natürlich bessere, dann könnte man auch "betroffene" Caches noch lösen :)
 

MiK

Geoguru
Wenn mir jemand einen vernünftigen Weg nennt, wie wir damit umgehen sollen, dann kann ich den gerne umsetzen. Im Moment haben wir gültige UTF-8, wie wir es von Groundspeak bekommen. Und Garmin kommt mit einem Teil der Zeichen darin nicht klar. Wobei mich wundert, dass auch andere Programme behaupten, dass das nicht in Ordnung wäre. Vielleicht findet ja mal jemand heraus, was an den Zeichen genau falsch ist und woran man sie erkennt.
 

xileF1337

Geonewbie
So wie ich das verstehe verstoßen diese Zeichen gegen die XML-Konventionen.

Wenn mir jemand einen vernünftigen Weg nennt, wie wir damit umgehen sollen...

Löschen. Vielleicht mit einer Character-Whitelist? Wenn nicht standardmäßig, dann wenigstens als optionales Feature.
Open XML Editor ist Open Source. Es ist zwar Delphi-Code, aber vielleicht könnt ihr euch trotzdem was abschaun?

Hier ist mal ein Beispiel für so ein ungültiges Sonderzeichen (ich weiß nicht in wie fern das mit dem Kopieren und Einfügen klappt, ich sehe nur Kästchen):

Code:
<p>Viel Spaß beim schnellen Suchen.</p>
ĸ،ᰀ婀</span>

In der zweiten Zeile alles was vor dem '&' steht ist so ein nicht erlaubtes Sonderzeichen.

Ich hab mal ein betroffenes GPX-File hochgeladen. Die betroffenen Zeilen sind 20137; 32873; 67350. Dort stehen überall komische Zeichen. Außerdem enthält das Archiv nochmal dieselbe GPX-Datei, allerdings von mir von Hand (per Open XML Editor) korrigiert, sodass mein Garmin sie frisst.

http://ul.to/k1xh5g

Ich hoffe du kannst damit was anfangen, falls ich noch irgendwie helfen kann, sag bescheid ;)
 

MiK

Geoguru
xileF1337 schrieb:
So wie ich das verstehe verstoßen diese Zeichen gegen die XML-Konventionen.
Wenn Du mir diese Konvention zeigst, die genau beschreibt, welche UTF-8-Zeichen erlaubt sind und welche nicht, sind wir schon weiter.
 

xileF1337

Geonewbie
Mh also so auf die schnelle habe ich nur das hier gefunden:

2.2 Characters

[Definition: A parsed entity contains text, a sequence of characters, which may represent markup or character data.] [Definition: A character is an atomic unit of text as specified by ISO/IEC 10646:2000 [ISO/IEC 10646]. Legal characters are tab, carriage return, line feed, and the legal characters of Unicode and ISO/IEC 10646. The versions of these standards cited in A.1 Normative References were current at the time this document was prepared. New characters may be added to these standards by amendments or new editions. Consequently, XML processors MUST accept any character in the range specified for Char. ]
Character Range
[2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]
/* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */

The mechanism for encoding character code points into bit patterns may vary from entity to entity. All XML processors MUST accept the UTF-8 and UTF-16 encodings of Unicode [Unicode]; the mechanisms for signaling which of the two is in use, or for bringing other encodings into play, are discussed later, in 4.3.3 Character Encoding in Entities.

Note:

Document authors are encouraged to avoid "compatibility characters", as defined in section 2.3 of [Unicode]. The characters defined in the following ranges are also discouraged. They are either control characters or permanently undefined Unicode characters:

[#x7F-#x84], [#x86-#x9F], [#xFDD0-#xFDEF],
[#x1FFFE-#x1FFFF], [#x2FFFE-#x2FFFF], [#x3FFFE-#x3FFFF],
[#x4FFFE-#x4FFFF], [#x5FFFE-#x5FFFF], [#x6FFFE-#x6FFFF],
[#x7FFFE-#x7FFFF], [#x8FFFE-#x8FFFF], [#x9FFFE-#x9FFFF],
[#xAFFFE-#xAFFFF], [#xBFFFE-#xBFFFF], [#xCFFFE-#xCFFFF],
[#xDFFFE-#xDFFFF], [#xEFFFE-#xEFFFF], [#xFFFFE-#xFFFFF],
[#x10FFFE-#x10FFFF].
Quelle
 

MiK

Geoguru
Geo_Okami schrieb:
Das ist doch aber nicht neu, daß sich Garmin nicht an die XML Standards hält.
Richtig. Aber anscheinend gibt es auch ein echtes Problem mit diesen Zeichen, sonst würden sich nicht auch andere Validatoren beschweren.
 
Oben