PQ mit Tradis nicht vollständig

[skylive]

Hallo Freunde,

seit ein paar Tagen habe ich ein Problem, welches ich einfach nicht verstehe:

Ich erstelle mir auf geocaching.com eine PQ die nur Tradis innerhalb von 50 km von meiner Homezone enthalten soll.
Die Vorschau von geocaching.com sagt: Es sind 1000 Tradis

Bisher alles prima. Wenn ich eben diese PQ auf mein Garmin Oregon 450 spiele, so erscheinen im Gerät genau 5 Tradis.
(Zielort: Speicherkarte ... Garmin/GPX)

Nebenher habe ich noch andere PQs, die aus Multis bestehen. Dort scheint alles in Ordnung zu sein.

Jetzt kommt das kuriose: Erstelle ich eine PQ, die nur Tradis enthalten soll welche etwas weiter weg von der Homezone liegen, so erscheinen diese Caches nach dem aufspielen ohne Probleme.

Was ich bisher alles versucht habe:
- Hard Reset meines Garmin Oregon 450
- ersetzen der Speicherkarte
- entfernen der Speicherkarte, Gerät neu starten, Karte wieder einsetzen
- PQs einzeln drauf kopieren, dazwischen wieder neu starten
- PQ einmal mit- und einmal ohne .wps Datei aufgespielt
- PQ auf den internen Speicher Garmin/GPX kopiert

- Tradi PQ auf meinem Handy mit C:Geo eingespielt <-- läuft


An der PQ kann es also definitiv nicht liegen.
Im GPS Gerät sind keine Filter aktiv. Die Caches erscheinen im Gerät weder auf der Karte, noch auf der Liste. Was auch immer ich anstelle, es sind nur 5 Tradis von 1000.

Vielleicht kann mir jemand helfen.

 

[Fadenkreuz]

1. Prüfen, ob die PQ wirklich 1000 Caches enthält. Dass das mit c:geo so aussieht, ist noch kein wirklicher Beweis, denn es könnte sich ja auf dem Smartphone noch eine andere gpx-Datei befinden. Am Besten einfach mal die Größe der entzippten gpx-Datei (nicht wpts-gpx) prüfen. Sie sollte bei 1000 Caches so ca. 1 bis 1,5 MB haben. Andere Möglichkeit: Die gpx-Datei im Editor oder in Basecamp öffnen, dann sieht man auf Anhieb, ob es nur 5 Caches oder zahlreiche Caches sind.

2. Wenn es wirklich 1000 Caches sind, dann alle alten gpx-Dateien aus dem entsprechenden Ordner löschen, Gerät sicher trennen, einmal hochfahren, wieder ausschalten, USB-Verbindung wieder herstellen, dann erst die 1000er gpx-Datei übertragen.

3. Wenn jetzt wieder nur wenige Caches angezeigt werden, kann es eigentlich nur an den Filtereinstellungen liegen.

 

[schliessdruide]

Zumindest alte Garmins haben eine maximal Zahl von Caches die sie verwalten können und eine maximal Zahl von Wegpunkten - vielleicht findest du die Zahl im Wiki für dein GPS...

 

[Fadenkreuz]

Stimmt, das wäre auch eine naheliegende Möglichkeit. Da er schreibt "Nebenher habe ich noch andere PQs ..." könnte einfach die maximale Anzahl an Wegpunkten erreicht sein, vor allem, wenn man neben der eigentlichen gpx-Datei auch noch die wpts-gpx aufs Oregon lädt.

 

[skylive]

Danke für eure Tipps.

Mittlerweile habe ich des Rätsels Lösung gefunden.

Die gpx-Datei im Editor oder in Basecamp öffnen, dann sieht man auf Anhieb, ob es nur 5 Caches oder zahlreiche Caches sind.

Die Datei sah im Editor zunächst normal aus, es waren viele viele .. Tradis, nicht nur 5

Öffnen mit Basecamp gab mir den ersten Fehler:
Unbekannter Fehler beim Öffnen der Importdatei.

Also habe ich nach diesen Suchwörtern etwas weiter recherchiert.
Irgendwie ließ mich der Gedanke nicht los, dass irgendein neu gelisteter Tradi vielleicht ein fehlerhaftes Zeichen im Text hat, den die gpx Datei falsch interpretiert.
Das könnte z.B. ein (größer als Zeichen) sein >
Genau das war hier der Fall. Ein neu gelisteter Cache hatte ein solches Zeichen in der Beschreibung.
Das Gerät interpretiert dieses > Zeichen als schliessen eines Tags an einer Stelle, wo es nicht hingehört.
Zumindest ist das meine Vermutung.

Ich habe den dazugehörigen Code dieses Caches (GC53HTM) aus der .gpx Datei ausgeschnitten, die PQ wieder aufs GPS gespielt. Und alle Caches sind da
Öffnen in Basecamp funktioniert jetzt auch.

Vielleicht ist meine Theorie auch verkehrt, aber seitdem geht es.

Vielen Dank an alle, die mir bis hierher geholfen haben.

 

[jennergruhle]

Das ist dann ein Fehler bei der Erzeugung der Datei durch GC. Tag-Zeichen in Tag-Inhalten lassen sich maskieren, z.B. mit < oder dem CDATA-Ausdruck.

 

[Fadenkreuz]

Dass die Formatierung eines einzelnen Caches eine gesamte PQ lahmlegen kann, habe ich noch nie gehört. Bekannt waren die Fälle, wo Base64-codierte Bilder im Listing waren, aber das hat sich dann auch nur auf die Anzeige dieses einen Caches ausgewirkt, die zum Absturz des GPS-Gerätes führen konnte.

Hast du mal die GC-Nummer dieses Caches? Gerne auch per PM.

Edit: Öh, wer lesen kann, ist klar usw.

 

[jennergruhle]

Ich habe mal die GPX-Datei (Einzeldownload) des Caches angesehen, hier ein Auszug:

      <groundspeak:short_description html="True"><p>Annewelta-Boor => Wasserquelle aus alter Eiche.</p></groundspeak:short_description>
      <groundspeak:long_description html="True"><p>Dies ist ein geheimnisvoller Ort, der so einige Rätsel aufgibt. Das wahre Mysterium - und auch die hier von uns versteckte Dose - erschließt sich erst bei genauerem Hinsehen.</p>
<p>für Bonus-Mystery (später): das Gebäude wird heute vor der Öffentlichkeit verschlossen gehalten. Wir haben allerdings Informationen erhalten, dass hier Versammlungen der Bruderschaft abgehalten wurden. Wer sich auf die Spuren dieser Bruderschaft begeben möchte notiert sich die beiden Zeichen, die sich auf dem  Deckel der Dose befinden.</p>
<p>Dieser Cache ist Teil der ZFS "Zeltinger Far Side" Runde in der 1. Ausbaustufe, der als Rundweg angelegt worden ist. Viel Spaß! </p></groundspeak:long_description>

Aus dem "Annewelta-Boor => Wasserquelle aus alter Eiche." der Kurzbeschreibung (nur dort ist ein ">" drin) wird in der GPX-Datei ein "<p>Annewelta-Boor => Wasserquelle aus alter Eiche.</p>" - das ist gültiges XML, nach Ersetzen der Zeichen wird es wieder zu "<p>Annewelta-Boor => Wasserquelle aus alter Eiche.</p>".
Eigentlich sollte das keine Probleme machen, es sei denn das Oregon interpretiert das danach als HTML und fällt dabei auf die Nase. Syntaktisch korrektes HTML sähe aber so aus:
"<p>Annewelta-Boor => Wasserquelle aus alter Eiche.</p>"

Sieht der Abschnitt denn in der PQ anders aus? Will jetzt nicht extra eine erstellen...
Scheint also

 

[skylive]

<wpt lat="49.969967" lon="6.9737">
    <time>2014-04-27T07:00:00Z</time>
    <name>GC53HTM</name>
    <desc>ZFS5 Annewelta Boor by Moselfun, Traditional Cache (2/1.5)</desc>
    <url>http://www.geocaching.com/seek/cache_details.aspx?guid=99979dc0-af6f-4b2e-8608-719e24bc937f</url>
    <urlname>ZFS5 Annewelta Boor</urlname>
    <sym>Geocache</sym>
    <type>Geocache|Traditional Cache</type>
    <groundspeak:cache id="4312990" available="True" archived="False" xmlns:groundspeak="http://www.groundspeak.com/cache/1/0">
      <groundspeak:name>ZFS5 Annewelta Boor</groundspeak:name>
      <groundspeak:placed_by>Moselfun</groundspeak:placed_by>
      <groundspeak:owner id="6759525">Moselfun</groundspeak:owner>
      <groundspeak:type>Traditional Cache</groundspeak:type>
      <groundspeak:container>Small</groundspeak:container>
      <groundspeak:difficulty>2</groundspeak:difficulty>
      <groundspeak:terrain>1.5</groundspeak:terrain>
      <groundspeak:country>Germany</groundspeak:country>
      <groundspeak:state>Rheinland-Pfalz</groundspeak:state>
      <groundspeak:short_description html="True"><p>Annewelta-Boor Wasserquelle aus alter Eiche.</p></groundspeak:short_description>
      <groundspeak:long_description html="True"><p>Dies ist ein geheimnisvoller Ort, der so einige Rätsel aufgibt. Das wahre Mysterium - und auch die hier von uns versteckte Dose - erschließt sich erst bei genauerem Hinsehen.</p>
<p>für Bonus-Mystery (später): das Gebäude wird heute vor der Öffentlichkeit verschlossen gehalten. Wir haben allerdings Informationen erhalten, dass hier Versammlungen der Bruderschaft abgehalten wurden. Wer sich auf die Spuren dieser Bruderschaft begeben möchte notiert sich die beiden Zeichen, die sich auf dem  Deckel der Dose befinden.</p>
<p>Dieser Cache ist Teil der ZFS "Zeltinger Far Side" Runde in der 1. Ausbaustufe, der als Rundweg angelegt worden ist. Viel Spaß! </p></groundspeak:long_description>
      <groundspeak:encoded_hints>Schiefer, dahinter</groundspeak:encoded_hints>
      <groundspeak:logs>
        <groundspeak:log id="404617712">
          <groundspeak:date>2014-05-05T08:19:27Z</groundspeak:date>
          <groundspeak:type>Update Coordinates</groundspeak:type>
          <groundspeak:finder id="6759525">Moselfun</groundspeak:finder>
          <groundspeak:text encoded="False">Coordinates changed from:
N 49° 58.201 E 006° 58.428

Coordinates changed to:
N 49° 58.198 E 006° 58.422

Distance from original: 29.7 feet or 9.1 meters.
Dank tatkräftiger Unterstützung von WillRiker (Merci) die Koordinaten präzisiert.</groundspeak:text>
          <groundspeak:log_wpt lat="49.969967" lon="6.9737" />
        </groundspeak:log>
        <groundspeak:log id="404619254">
          <groundspeak:date>2014-05-04T19:00:00Z</groundspeak:date>
          <groundspeak:type>Found it</groundspeak:type>
          <groundspeak:finder id="3692120">Dante & No & Moon</groundspeak:finder>
          <groundspeak:text encoded="False">Sehr cooler Ort! Auf dem Weg dorthin konnten wir einen Kuckuck hören und mehrere Füchse aus der Ferne bewundern! :) Allein das hätte sich schon gelohnt!
Nachdem wir uns dann von der Quelle losreißen konnten, war der Cache auch schnell gefunden!

TFTC
In: Ü-Ei Schweinchen
™ hinterlassen</groundspeak:text>
        </groundspeak:log>
        <groundspeak:log id="404460777">
          <groundspeak:date>2014-05-04T19:00:00Z</groundspeak:date>
          <groundspeak:type>Found it</groundspeak:type>
          <groundspeak:finder id="3456707">Will.Riker1311</groundspeak:finder>
          <groundspeak:text encoded="False">Heute wurde mir die Ehre zuteil, als Beta-Tester für den Final der ZFS-Runde tätig zu werden. Dafür musste ich natürlich erstmal die restlichen 6 mir fehlenden Caches der Runde einsammeln [:D]
Das war mein dritter heute und hier habe ich definitiv am längsten gesucht. Die Koordinaten waren doch ziemlich im Off und auch der Hinweis half nicht allzuviel, so gestaltete sich das Ganze als Suche nach der Nadel im Heuhaufen. [B)] Mein Stolz ließ es aber nicht zu, den Owner anzumailen und ich brauchte doch die Bonus-Hinweise, deshalb blieb ich hartnäckig und wurde schlussendlich auch belohnt [:D] 
Vor lauter Sucherei habe ich allerdings die kuriose Quelle kaum würdigen können...
Nach Beenden der gesamten Runde, die zwar anstrengend war, mir aber sehr viel Spaß gemacht hat, gab's noch eine kurze Auswertung mit dem Owner und dann ging's heim Zecken suchen [:P]
Danke für's Verstecken und lieben Gruß aus Andel!
Will.Riker1311
#1375</groundspeak:text>
        </groundspeak:log>
        <groundspeak:log id="403765040">
          <groundspeak:date>2014-05-03T19:00:00Z</groundspeak:date>
          <groundspeak:type>Found it</groundspeak:type>
          <groundspeak:finder id="4175798">TS-3</groundspeak:finder>
          <groundspeak:text encoded="False">Für den heutigen Samstag habe ich mir die ZFS-Tour ausgesucht. Ein schöner Weg mit zum Teil sehr schönen [:D] (und weniger schönen[V] Baustellen-)Ausblicken. Bis auf ein paar Motocrosser und Quads war ich auch ziemlich alleine.

Gut gefunden. TFTC</groundspeak:text>
        </groundspeak:log>
        <groundspeak:log id="402887169">
          <groundspeak:date>2014-05-01T10:09:09Z</groundspeak:date>
          <groundspeak:type>Found it</groundspeak:type>
          <groundspeak:finder id="8784220">Die Knusels</groundspeak:finder>
          <groundspeak:text encoded="False">Tftc</groundspeak:text>
        </groundspeak:log>
      </groundspeak:logs>
      <groundspeak:travelbugs />
    </groundspeak:cache>
  </wpt>

So sieht der Ausschnitt dieses Caches in der PQ aus.

Woran auch immer es liegt, wenn ich diesen Cache ausschneide, dann funktioniert die komplette PQ auf meinem Garmin.
Vielleicht haben in Zukunft andere User ja das gleiche Problem, dann haben wir ja hier eine Lösung zur Hand

 

[badnerland]

In dem Log vom Dante-Team ist ein ungewöhnliches Zeichen, das als HTML-Sonderzeichen codiert sein sollte, aber nicht ist. Soweit ich es überblicke, schreiben sie Logs dieser Art systematisch, aber erst seit ein paar Tagen. Vielleicht mal dieses Zeichen einfach mit dem nächstbesten Texteditor aus der GPX löschen und schauen, ob Basecamp die Datei dann akzeptiert.
Wenn ja, den Kollegen mal auf die Finger klopfen und Groundspeak gleich mit.

 

[skylive]

In dem Log vom Dante-Team ist ein ungewöhnliches Zeichen, das als HTML-Sonderzeichen codiert sein sollte, aber nicht ist. Soweit ich es überblicke, schreiben sie Logs dieser Art systematisch, aber erst seit ein paar Tagen. Vielleicht mal dieses Zeichen einfach mit dem nächstbesten Texteditor aus der GPX löschen und schauen, ob Basecamp die Datei dann akzeptiert.
Wenn ja, den Kollegen mal auf die Finger klopfen und Groundspeak gleich mit.

Dieses kleine ™Zeichen kann ich eigentlich ausschliessen.
Es handelt sich bei diesen Caches um eine Serie, andere Caches dieser Serie hat er auch mit diesem Zeichen geloggt. Alle anderen Caches machen mir keine Probleme, es war nur der eine.

Ich habs jetzt extra nochmal ausprobiert.™ entfernt. Basecamp startet immer noch nicht richtig.

Schade, ich kenne Dante persönlich, da hätte ich ihm persönlich auf die Finger kloppen können

 

[nah&amp;fern]

<urlname>ZFS5 Annewelta Boor</urlname>

Geht es wenn du

rausnimmst?

 

[Fadenkreuz]

Ich habe das mal ausprobiert und eine 1000er PQ mit dem Cache GC53HTM als Zentrum erstellt. Die entzippte gpx-Datei brachte in Mapsource und Basecamp jeweils eine Fehlermeldung und auch im Garmin konnte sie nicht erkannt werden. Übrigens auch nicht 5 Caches, sondern gar keine. Die erwähnten 5 Caches müssen also woanders her kommen.

Ich habe dann mal die gpx-Datei in Word geöffnet, was aber nicht ging und folgende Fehlermeldung ergab:

"Ungültiges Unicode-Zeichen in Zeile 13, Spalte 34."

Diese Zeichen kommen mehrfach vor und sind "ZFS5 Annewelta Boor&#xB"
Im Editor konnte die gpx-Datei geöffnet werden. Nach dem Löschen der Zeichen "&#xB" konnte die Datei dann problemlos von Mapsource, Basecamp und dem Garmin eingelesen werden.

 

[Eastpak1984]

Das Thema sollte man wohl fix an den Betreiber weiterleiten.

 

[jennergruhle]

Das Zeichen  ist ein Zeilen-Tabulator (Line Tabulation): http://www.fileformat.info/info/unicode/char/000B/index.htm

An etlichen Stellen des Listings (kann man im Quelltext der Seite sehen) taucht es auch auf - eventuell müsste der Owner des genannten Caches das Zeichen unabhängig davon mal aus dem Namen seines Caches entfernen, wo es vermutlich durch ungeschicktes Copy&Paste hineingeraten ist. Es könnte aber auch sein, dass das Hinein-Generieren des Zeichens nur durch einen Fehler der Software passiert und das Cache-Name-Feld für den Owner gar kein seltsames Zeichen enthält, das er entfernen könnte.

 

[Fadenkreuz]

Der Fehler ist auch auf der Website zu erkennen, wirkt sich dort aber nicht weiter aus. Ruft man das Cachelisting auf, erscheint im Firefox (bei entspr. Einstellungen) ganz oben in der Titelzeile ein "Kästchen" nach dem Cachenamen, was üblicherweise auf ein nicht decodierbares Zeichen hindeutet.

Meine weiter vorne geäußerte Vermutung, dass man mit einem einzelnen Listing nicht eine ganze PQ blockieren kann, muss ich jedenfalls revidieren. Und es sollten ja etliche Cacher davon betroffen sein, nämlich alle, die den Cache noch nicht gemacht haben, in deren PQ er aber auftaucht.

 

[aberermoidl]

Meine weiter vorne geäußerte Vermutung, dass man mit einem einzelnen Listing nicht eine ganze PQ blockieren kann, muss ich jedenfalls revidieren.

Das das wirklich der Fall ist, musste ich vorletzte Woche erfahren. Zuhause hab ich mit Neongeo noch meine Tour "geplant" und vor Ort angekommen fehlten auf dem Germin plötzlich einige Tradis - eigentlich sogar fast alle, die ich mir vorgenommen habe. Hat mich schon gewundert, weil ich sowohl auf dem Smartphone als auch auf dem Oregon die gleiche PQ aufgespielt hatte. Im Nachhinein hat sich auch herausgestellt, dass irgendwo in der PQ ein Fehler war. QLandkarteGT hat beim Öffnen auch eine Fehlermeldung erzeugt.
Kurioserweise kann Neongeo anscheinend fehlerhafte Listings überspringen, sonst wär's mir schon vor dem losziehen aufgefallen.

 

[Eastpak1984]

Solang man solche Fehler nicht nicht weiter leitet, wird man häufiger damit zu kämpfen haben.

 

[skylive]

An wem genau liegt es denn jetzt?
Garmin?
GC?

Dem Owner kann man ja keine Schuld geben. So etwas kann ja theoretisch bei jedem neu gelisteten Cache auftreten.

Vielleicht kann es jemand mal mit einem anderen GPS Gerät testen?

 

[Eastpak1984]

Ich würde behaupten, an der Absprache der Partner untereinander.

Am effektivsten sollte es Groundspeak herausfiltern können, eben exakt wie base64.