Voraussetzung: Der Einstieg in die Pocket Queries
Im Einsteigertutorial wurde beschrieben wie man eine einmalige PQ für Caches rund um einen Ort definiert.
Jetzt geht es darum mit GSAK eine möglichst aktuelle lokale Datenbank zu pflegen um sich eine eigenen Cacheauswahl aufs GPSr zu laden.
Abbildung 1: Die Daily-PQ soll jeden Montag, Mittwoch und Freitag laufen.
Der nächste Ansatz ist, sich jeden Tag eine PQ mit den Caches rund um seine Home-Location schicken zu lassen. Eigentlich keine schlechte Idee, es sei denn, man schaut mal, wie weit man
damit kommt. Die meisten werden den 10 km Radius nicht überschreiten. D.h. wenn ich nicht im Nachbarort sondern einen Ort weiter unterwegs sein möchte, ist meine lokale Datenbank schon
außerhalb ihrer Reichweite.
Daher stelle ich hier drei Optimierungsmöglichkeiten vor, um unseren Radius auszudehnen. Ich komme so auf eine lokale Datenbank, die Caches bis zu 50 Kilometer entfernt erfasst. Das sind meistens zw. 60 und 80 km Fahrstrecke und sollte als Home-Zone ausreichen. Alles darüber hinaus ist besser mit Spezial-PQs wie im Einsteiger-Tutorial beschrieben zu lösen.
Abbildung 2: Es reicht vollkommen aus, wenn ich nur die Änderungen der letzten 7 Tage mitbekomme.
Als erste Optimierung lasse ich mir nur die noch nicht gefundenen, nicht die eigenen und nur die Caches raussuchen, die in den letzten 7 Tagen ein Update (neuer Logeintrag, Listing oder
Koors geändert) erfahren haben. Ausgehend von einer einmalig initialisierten Datenbank reicht es ja nur die Änderungen mitzubekommen.
Um den Initialzustand zu erhalten kann ich auf die 6000 Caches aus der API setzen oder mir ne Woche lang jeden Tag 5 PQ zuschicken, die alle aktiven Caches enthalten.
Außerdem werden die meisten Caches in den Sommermonaten mind. einmal im Monat angegangen, sodass ich recht schnell ne ziemlich komplette Datenbank haben. Was nicht dabei ist, ist meistens so schwierig, dass es eher unwahrscheinlich ist, dass ich einen solchen Cache spontan angehe.
Abbildung 3: Neben Home Location und Reduzierung des Radius kann man gut über das Datum der Cacheauslegung mehrere PQs trennen.
Aber auch das ist noch viel zu viel, da im Sommer die meisten Caches innerhalb der letzten 7 Tagen angegangen werden.
Als zweite Optimierung müssen wir eine Möglichkeit finden, nicht eine sondern 4 PQs pro Tag zu erhalten (1 PQ sollte man sich immer für Notfälle oder Spontansuchen übrig halten). Da stellt sich die Frage, wie kann man die Caches voneinander trennen, also in Gruppen bzw. Packete aufteilen. Die Entfernung von zu Hause ist keine Möglichkeit, da immer die nähesten genommen werden. Eine PQ mit Tradies, eine mit Multis u.s.w. ist zwar nen Ansatz aber kein guter, da es mehr als 4 Cachetypen gibt und der Radius für die Tradis wesentlich kleiner ist als für Multis oder gar WherIGos.
Was sich dagegen hervorragend anbietet, ist die Unterscheidung nach Plazierungsdatum, also wann wurde der Cache gelegt. Vereinfach gesagt, eine PQ für die ganz alten Dosen bis 2009, eine für 2010 und 2011, eine für 2012 und die vierte für das aktuelle Jahr. Dabei werdet ihr feststellen, dass für die aktuellen Monate immer schwieriger wird, die 1000er Marke nicht zu knacken, besonders da jeden Tag der Zeitraum größer wird. Dafür verschinden aber immer mehr Dosen aus den "alten Zeiten", da ihr sie entweder gefunden habt oder sie archiviert werden, da Versteck "verbrannt" ist, Naturschützer und Behörden aufmerksam geworden sind oder die Owner nicht mehr die Zeit für die Dosenpflege aufbringen wollen. Es lohnt sich also ab und zu zu konrollieren wie viele Caches im Schnitt durch ein PQ erfasst werden und die Zeiträume zu verschieben. Dann heißt es 2000-2010, 2011-Juni2012, Juli2012-Feb2013, März2013-Dez2013.
Abbildung 4: Da in den letzten 2 Jahren die Cacheanzahl explodiert ist, muss der Zeitraum umso kleiner gewählt werden, je näher er am Tagesdatum liegt. Auch reichen 4 PQs nicht mehr aus. Deswegen alle zwei Tage jeweils 4 ergibt 8 PQs.
Je nach Radius den ihr abdecken wollt, reichen aber auch 4 PQs nicht mehr aus. Ich bin deswegen zur Tradeoff gelangt, dass es reicht jeden zweiten Tag eine aktuelle Datenbank zu besitzen.
Wie in Abb. 4 erkennbar ist, wird Montags, Mittwoch und Freitags die Caches Begin bis 01. Juni 2011 erfasst und Dienstags, Donnerstags und Samstags alle Caches ab 02. Juni 2011 bis heute.
Eine Codierung der Suchzeiten im PQNamen hilft ungemein, die Zeitfenster zu koordinieren. In der ersten Runde hab ich noch ein PQ frei. Sobald
Oder ich schreib weniger Tutorials und "bereinige" die PQ-Zone von den alten Caches .
Damit endet der zweite Teil der PQ-Einführung. Wir haben dieses Mal gelernt, wie man PQs so definieren und teilen kann, dass sie sich dazu eigenen eine lokale Datenbank wie z.B GSAK mit regelmäßigen Updates zu versorgen. Im nächsten Teil geht es darum, wie man die erzeugten PQs in GSAK importiert und was man damit machne kann.
Im Einsteigertutorial wurde beschrieben wie man eine einmalige PQ für Caches rund um einen Ort definiert.
Jetzt geht es darum mit GSAK eine möglichst aktuelle lokale Datenbank zu pflegen um sich eine eigenen Cacheauswahl aufs GPSr zu laden.
Geocaching.com API und tägliche PQ als erste Ansätze
Wozu der Aufwand mit PQs wird sich so manch einer denken, ich hab doch die Geocaching.com API und kann mir die Caches von GSAK aus direkt laden. Das stimmt, aber bei nem Limit von 6000 Caches pro Monat kommt man da auch nicht weit.
Abbildung 1: Die Daily-PQ soll jeden Montag, Mittwoch und Freitag laufen.
Was kann ich tun, um meinen Radius zu vergrößern
Daher stelle ich hier drei Optimierungsmöglichkeiten vor, um unseren Radius auszudehnen. Ich komme so auf eine lokale Datenbank, die Caches bis zu 50 Kilometer entfernt erfasst. Das sind meistens zw. 60 und 80 km Fahrstrecke und sollte als Home-Zone ausreichen. Alles darüber hinaus ist besser mit Spezial-PQs wie im Einsteiger-Tutorial beschrieben zu lösen.
Abbildung 2: Es reicht vollkommen aus, wenn ich nur die Änderungen der letzten 7 Tage mitbekomme.
Um den Initialzustand zu erhalten kann ich auf die 6000 Caches aus der API setzen oder mir ne Woche lang jeden Tag 5 PQ zuschicken, die alle aktiven Caches enthalten.
Außerdem werden die meisten Caches in den Sommermonaten mind. einmal im Monat angegangen, sodass ich recht schnell ne ziemlich komplette Datenbank haben. Was nicht dabei ist, ist meistens so schwierig, dass es eher unwahrscheinlich ist, dass ich einen solchen Cache spontan angehe.
Abbildung 3: Neben Home Location und Reduzierung des Radius kann man gut über das Datum der Cacheauslegung mehrere PQs trennen.
Als zweite Optimierung müssen wir eine Möglichkeit finden, nicht eine sondern 4 PQs pro Tag zu erhalten (1 PQ sollte man sich immer für Notfälle oder Spontansuchen übrig halten). Da stellt sich die Frage, wie kann man die Caches voneinander trennen, also in Gruppen bzw. Packete aufteilen. Die Entfernung von zu Hause ist keine Möglichkeit, da immer die nähesten genommen werden. Eine PQ mit Tradies, eine mit Multis u.s.w. ist zwar nen Ansatz aber kein guter, da es mehr als 4 Cachetypen gibt und der Radius für die Tradis wesentlich kleiner ist als für Multis oder gar WherIGos.
Was sich dagegen hervorragend anbietet, ist die Unterscheidung nach Plazierungsdatum, also wann wurde der Cache gelegt. Vereinfach gesagt, eine PQ für die ganz alten Dosen bis 2009, eine für 2010 und 2011, eine für 2012 und die vierte für das aktuelle Jahr. Dabei werdet ihr feststellen, dass für die aktuellen Monate immer schwieriger wird, die 1000er Marke nicht zu knacken, besonders da jeden Tag der Zeitraum größer wird. Dafür verschinden aber immer mehr Dosen aus den "alten Zeiten", da ihr sie entweder gefunden habt oder sie archiviert werden, da Versteck "verbrannt" ist, Naturschützer und Behörden aufmerksam geworden sind oder die Owner nicht mehr die Zeit für die Dosenpflege aufbringen wollen. Es lohnt sich also ab und zu zu konrollieren wie viele Caches im Schnitt durch ein PQ erfasst werden und die Zeiträume zu verschieben. Dann heißt es 2000-2010, 2011-Juni2012, Juli2012-Feb2013, März2013-Dez2013.
Abbildung 4: Da in den letzten 2 Jahren die Cacheanzahl explodiert ist, muss der Zeitraum umso kleiner gewählt werden, je näher er am Tagesdatum liegt. Auch reichen 4 PQs nicht mehr aus. Deswegen alle zwei Tage jeweils 4 ergibt 8 PQs.
Eine Codierung der Suchzeiten im PQNamen hilft ungemein, die Zeitfenster zu koordinieren. In der ersten Runde hab ich noch ein PQ frei. Sobald
w27_021212-011113 die 1000er
Marke regelmäßig knackt wird w24... zu w14... (d.h. Montags ausgeführt) und eine neue PQ w28_020713-010114erstellt. Wenn dann Ende des Jahres auch die
achte PQ gefüllt ist, geht der Tanz von vorne los. Da muss ich entweder einen dritten Tag einführen (also mit 2 Tage alten Cachedaten leben) oder den Radius reduzieren. Der entspricht bei mir
z.Zt 50 km, was verdammt viel ist, da die Fahrstrecke im Schnitt das 1,4 bis 1,5 fache der Luftlinie, also gut 70 km entspricht.
Oder ich schreib weniger Tutorials und "bereinige" die PQ-Zone von den alten Caches .
Damit endet der zweite Teil der PQ-Einführung. Wir haben dieses Mal gelernt, wie man PQs so definieren und teilen kann, dass sie sich dazu eigenen eine lokale Datenbank wie z.B GSAK mit regelmäßigen Updates zu versorgen. Im nächsten Teil geht es darum, wie man die erzeugten PQs in GSAK importiert und was man damit machne kann.
Keine Kommentare:
Kommentar veröffentlichen