PM-Features nutzen
Umfangreiche Cachedatenbank erstellen durch PQs

Der totale Ausfall von geocaching.com nach einem Brand im Serverraum hat gezeigt, wie sehr das Hobby Geocaching vom Internet abhängt. Dort werden schließlich die Listings veröffentlicht, die wir zur Suche der Dosen benötigen. Vorrangig auch geocaching.com, deren Server auch in Normalfall nicht immer erreichbar sind. Besonders tritt dies am Wochenende auf, wenn die ganze Welt ihre Wochenendtouren plant oder danach loggt.

Glücklich kann sein, wer alle benötigen Cachedaten in einer lokalen Datenbank gespeichert hat und so die meiste Zeit unabhängig von den GC-Servern ist.
So kann man in Ruhe offline planen, auch im Urlaub, oder hat bei einem erneuten Serverausfall die Caches seiner Homezone auf der eigenen Festplatte.
Doch wie bekommt man ein lückenlose und umfangreiche Cachedatenbank auf den heimischen Rechner?

Wir könnten ja jetzt anfangen sämtliche Caches in 1000km Umkreis per Cachewolf zu spidern. Aber ist nicht nur ein Verstoß gegen die Groundspeak-ToU sondern es dauert auch elendig lange. Gleichzeit erzeugt eine Last auf den Groundspeak-Server, was unsere Probleme mit der Erreichbarkeit nicht verbessern.
Also schlagen wir Groundspeak lieber mit seinen eigenen Waffen ein Schnippchen: Pocket Queries.
Wir erhalten nach etwas Aufwand jede Menge PQs mit noch viel mehr Caches, die wir in Cachedatenbanken wie Cachewolf oder GSAK laden können.
Doch wie geht man dabei gezielt vor? Schließlich möchte man möglichst viele Caches mit einer überschaubaren Anzahl Queries abfragen.
Das gehen wir in diesem Tutorial durch.

Erstbefüllung

Für die so genannte Erstbefüllung unserer Cachedatenbank müssen wir einmalig in Ärmel hochkrempeln und unser PQ-Limit von 40 PQs in der Warteschlange ordentlich ausschöpfen.
Das ist zwar viel Holz was dabei zusammen kommt, aber alles gemäß der ToU.
Enizige Hürde, die das Befüllen etwas langwierig macht, ist das 5-PQ-pro-Tag-Limit. Also kann die ganze Aktion ein paar Tage in Anspruch nehmen bis ein kompletter Datenbestand in Eurem Mailfach liegt.
Wenn ihr die unten aufgeführten PQs nachbaut seit ihr bei ca. 25 einzelnen PQs, die 5 Tage in Anspruch nehmen. Da man ja am Wochenende spontan mal eine Tour-PQ braucht, wollen wir da ein paar PQ-Kapazitäten freihalten. Die Ausführung der Queries legt man also am Besten auf Mo-Fr. Oder wie man halt meint ;)

Als Ausgangspunkt kann man entweder seine Homekoordinaten oder z.b. den Mittelpunkt des Landes wählen. Z.B. N 51 09.900, E 10 27.317 für Deutschland (eigentlich egal nach welcher Berechnungsgrundlage). Allerdings reicht eine PQ maximal 500 Meilen, dies aber kreisförmig um den Ausgangspunkt.
Mit Homezone in Westdeutschland reichen meine PQs oft bis Hamburg im Nordern und Frankreich im Westen. Aber bis Berlin komme ich damit nicht.
Das ist natürlich auch alles eine Frage der Cachedichte. In dicht bedosten Gebieten ist die flächenmäßige Abdeckung einer PQ geringer als in dünn bedosten Regionen.
Ganz Deutschland in PQs zu erfassen, ist insbesondere bei den drei Hauptcachearten Tradi, Multi, Mystery ein schwierigeres Unterfangen, bei dem man mit Sicherheit noch mehr PQs erzeugen lassen müsste.

Um eine möglichste große Reichweite zu erzielen (für den Fall der Fälle), aber auch alle Caches im realistischen Nahbereich (für die normalen Touren) abzudecken, bedienen wir uns eines Tricks. Wir fragen die Caches sowohl getrennt nach Typ als auch nach Freischaltdatum ab.

Hier die erste PQ als Beispiel. Ihr findet den fett formatierten Text als Feld auf der Seite http://www.geocaching.com/pocket/gcquery.aspx wieder.
Füllt die entsprechenden Textfelder aus bzw. markiert die jeweiligen (*) Optionen und setzt die entsprechenden [X] Häkchen.
Die wichtigsten Felder, die sich von PQ zu PQ ändern werden, sind grün formatiert.

Query Name PQ1 - Tradis 2009
Days to Generate Ein Tag Eurer Wahl. 
(*) Uncheck the day of the week after the query runs
Show me [500] Caches of
(*) Selected types: [X] Traditional Cache
(*) Any Container That
[X]  I haven't found
[X]  I don't own
[X]  Are not on my ignore list (optional)
Within (*) None Selected   
From Origin (*) My Home Coordinates
Within radius of [9999] (*)mi
Placed during  (*) between January/01/2009 and December/31/2009

Die zweite PQ gilt entsprechen nur für die Caches aus dem Jahr 2008:

Query Name PQ2 - Tradis 2008
Days to Generate Ein Tag Eurer Wahl. 
(*) Uncheck the day of the week after the query runs
Show me [500] Caches of
(*) Selected types: [X] Traditional Cache
(*) Any Container That
[X]  I haven't found
[X]  I don't own
[X]  Are not on my ignore list (optional)
Within (*) None Selected   
From Origin (*) My Home Coordinates
Within radius of [9999] (*)mi
Placed during  (*) between January/01/2008 and December/31/2008


In dem Schema erstellt ihr auch die PQs 3-5:
PQ3 - Tradis 2007
PQ4 - Tradis 2006
PQ5 - Tradis 2005

Für die Caches von 2004 und älter reicht sicher eine PQ aus, so viele sind das ja nicht mehr.
Es sei den in Eurer Region liegen noch viele alte Schätzchen, dann könntet ihr ja die Suche noch verfeinern.
(Ab hier alle PQ-Beispiele in Kurzform, nur noch die Änderungen zur ersten PQ werden angegeben.)

Query Name PQ6 - Tradis bis2004
(*) Selected types: [X] Traditional Cache
Placed during  (*) between January/01/1994 and December/31/2004


Für die Multis und die Unknowncaches verfahren wir identisch:

Query Name PQ7 - Multis 2009
(*) Selected types: [X] Multi-cache
Placed during  (*) between January/01/2009 and December/31/2009

PQ8 - Multis 2008
PQ9 - Multis 2007
PQ10 - Multis 2006
PQ11 - Multis 2005
PQ12 - Multis bis 2004

Query Name PQ13 - Unknows 2009
(*) Selected types: [X] Unknown Cache
Placed during  (*) between January/01/2009 and December/31/2009

PQ14 - Unknowns 2008
PQ15 - Unknowns 2007
PQ16 - Unknowns 2006
PQ17 - Unknowns 2005
PQ18 - Unknowns bis 2004

Für die "weniger beliebten" Cachetypen brauchen wir auch weniger PQs.
Bei den virtuellen und Webcam-Caches ist es besonders einfach, die dürfen ja seit ein paar Jahren nicht mehr neu eingestellt werden. Ich denke mal, dass es in Deutschland und Umgebung keine 500 Caches dieser Art mehr gibt

Query Name PQ19 - Virtuals
(*) Selected types: [X] Virtual Cache  [X] Webcam Cache
Placed during  (*) None Selected

Earthcaches, Letterboxen und WherieIGo sind hingegen eine noch einstellbare Cacheart und erfreuen sich durchaus einer gewissen Beliebtheit.
Am stärksten vertreten sind die Earthcaches. Für diese erstellen wir mehrere PQs, da allein 2008 fast 500 Es in Europa freigeschaltet wurden
Bei den Whereigos kommt man mit einer PQ locker bis nach UK, CZ und Ö'reich.

Query Name PQ20 - Earthcaches bis 2007
(*) Selected types: [X] Earthcache
Placed during  (*) between January/01/1994 and December/31/2007

Query Name PQ21 - Earthcaches  2008
(*) Selected types: [X] Earthcache
Placed during  (*) between January/01/2008 and December/31/2008

Query Name PQ21 - Earthcaches  2009
(*) Selected types: [X] Earthcache
Placed during  (*) between January/01/2009 and December/31/2009

Query Name PQ23 - WhereIGos
(*) Selected types: [X] Whereigo Cache
Placed during  (*) None Selected

Was die Letterboxen betrifft, reicht sicher eine PQ aus, jenach dem welchen Ausgangsort man wählt. Ggf. zerlegt man das auch in zwei Zeiträume oder

Query Name PQ23 - Letterbox
(*) Selected types: [X] Letterbox Hybrid
Placed during  (*) None Selected

Die Events (Event, CITO, Mega) und den ganzen Rest haben wir aber nicht vergessen.
Project APE Cache und GPS Adventures Exhibit gibt es ebenfalls nicht mehr, vor allem nicht in & um Deutschland.
Während es auch keinen Sinn macht in Events, die nur an einem Tag oder Wochenende loggbar sind, in eine statische Datenbank auf zunehmen.

Datenbank ergänzen

Jetzt hat man sich einmal die Arbeit gemacht, einen umfangreichen Datenbestand zu schaffen. Der wird aber morgen schon unvollständig sein. Jeden Tag kommen nun neue Caches hinzu.
Diese lasse ich mir wochenweise zuschicken und lade sie in die Datenbank hinzu. So sind zumindest in der Homezone immer alle neusten Caches dabei,
Meine Ergänzungs-PQ sieht so aus:

Query Name Neue im Umkreis
Days to Generate Ein Tag Eurer Wahl. 
(*) Run this query every week on the days checked
Show me [500] Caches of
(*) Any type
(*) Any Container That
[X]  I haven't found
[X]  I don't own
[X]  Are not on my ignore list (optional)
Within (*) None Selected   
From Origin (*) My Home Coordinates
Within radius of [9999] (*)mi
Placed during  (*) the last week

Wer wieder einen möglichst großen Bereich erfassen möchte, kann mehere PQs zur wöchentlich Bearbeitung einstellen. Zum Beispiel

Neue Tradis+Earthcaches
Neue Multis+Letterboxen
Neue Unknowns+Whereigos

oder beliebige Kombinationen daraus.
Andere als die genannten Cachetypen werden ja nicht mehr veröffentlicht bzw. Events sind zur Vorratsdatenspeicherung uninteressant.

Außerdem lade ich jede anderweitig erzeugte PQ, z.B. von geplanten Touren etc., auch in die Datenbank. Doppelt gemoppelt hält besser

Sonstiges


Wir haben nun eine schnell wachsende Datenbank mit Unmengen an Cacheinformationen geschaffen. Leider hat sie zwei Schönheitsfehler.

1. Es fehlen alle Abbildungen des Listings. Das können wichtige Spoilerbilder sein oder gar die Rästelbilder eines Multis/Mysterys. Übertragen werden in GPX-Dateien der Pocket Query ausschließlich die Eckdaten und der Text des Listings. Die Bilder bleiben ausschließlich im Internet verfügbar. Das ist besonders blöd, wenn man unterwegs auf das Spoilerbild angewiesen ist oder ohne Internetzugang einen Rästelcache lösen möchte.
Einzige Lösung ist wohl das Spidern dieser Abbildungen per Cachewolf, Spoilersync, Geopic oder ähnlichen Programmen. Da wären wir wohl aber wieder abseits der ToU.

2. Es fallen keine archivierten Caches aus der Datenbank. Geladen werden zwar nur aktive Caches, aber zwischenzeitlich landet bekanntlich ja auch der ein oder andere Cache im Archiv. Auf GC.com tauschen diese dann nicht mehr in der Suche auf, wohl aber in unserer lokalen Datenbank. Schlimmstenfalls plant man also einen bereits archivierten Cache zur Suche in.
Lösung: Falls möglich prüft man bei der Planung jeden Cache einzeln im Internet nach bevor man sich auf die Suche macht. Dumm nur wenn man keine Internetzugang hat oder eben die Server nicht erreichbar sind.
Andere Lösung: Das entsprechende Attribut muss regelmäßig durch die Datenbanksoftware per Abgleich mit GC.com aktualisiert werden. Im Klartext bedeutet dies: Der aktuelle Zustand des Caches wird wieder gespidert!

ACHTUNG: Es kommen sehr schnell sehr hohe Datenmengen zusammen. Es müssen u.U. locker 10.000 Caches gespidert werden. Aber das war je eigentlich nicht Sinn und Zweck dieser Übung.