Cache Paradies Nordhessen

Moin zusammen,

ich bin auf der Suche nach Ideen, wie man seine Caches in GSAK optimal aktuell hält, also man beispielsweise auch mitbekommt, wenn Caches archiviert werden (die kommen ja nicht mehr per PQ) oder neue hinzukommen.

Die meisten handhaben es vermutlich so, dass sie sich ALLE Caches aus dem Zielgebiet per Pocket Query schicken lassen. Sind es viele Caches, macht man das verteilt über mehrere Pocket Queries an an verschiedenen Wochentagen.

Das o.g. Vorgehen scheint mir unnötig. Denn eigentlich bin ich doch nur an neuen Caches interessiert. Alle bereits in der Datenbank vorhandenen Caches kann ich doch direkt in GSAK aktualisieren.Dafür braucht es kein PQ.

Frage 1: Was spricht dagegen die Caches direkt in GSAK zu aktualisieren?


Frage 2: Warum setzt man in der PQ nicht einfach die Option "Published last week"?

Wird jetzt ein Cache archiviert, kommt dieser nicht mehr mit der Pocket Query. GSAK bekommt also erstmal nichts davon mit (es sei denn ich aktualisiere die Caches per GSAK, s.o.). Jetzt bin ich beim Recherchieren über eine Lösung gestolpert, die überprüft, wie lange ein Cache bereits keine Informationen mehr durch ein Query erhalten hat. Ist dieser Zeitraum länger, so kann man davon ausgehen, dass er archiviert wurde. Nachteil: Es gibt auch andere Gründe, warum er nicht aktualisiert wird. Man muss also alle Caches erneut prüfen. Das kann man nicht jeden Tag machen, also rennt man mit alten Cachedaten durch Wald und Wiesen.

Das hört sich für mach einer Frickellösung an, sauber ist etwas anderes.

Frage 3: Wie erfasst ihr archivierte Caches?

Ein weiteres Problem sehe ich bei gefundenen Caches. Ich habe meine gefundenen Caches in einer eigenen Datenbank. Hauptsächlich damit das Statistik-Makro diese schön auswerten kann. Jetzt stellt euch folgende Situation vor: Mein PQ läuft am Montag und Freitag. Diesen enthalten nur Caches, die ich noch nicht gefunden habe. Am Dienstag finde ich einen Cache, setze diesen in GSAK auf "gefunden" und verschiebe ihn in die "Gefunden"-Datenbank . Am Mittwoch importiere ich das Montgs-PQ in GSAK. Der Cache wird erneut importiert, weil ja nicht mehr in der Cachedatenbank. Wenn ich nicht haargenau den Import von PQs synchronisiere (also nur importieren, wenn gerade generiert), dann tritt dieses Problem recht häufig auf.


Frage 4: Ist es sinnvoll gefundene Caches in einer eigenen Datenbank zu haben?


Frage 5: Wie verhindert ihr, dass bereits gefundene Caches erneut importiert werden?




Wie ihr seht habe ich einige Fragen. Vielleicht gibt es ja den ein oder anderen, der mir einen Tipp geben kann.

Vielen Dank für eure sehr hilfreichen Antworten. An der ein oder anderen Stelle war mein Denkweise wohl etwas eingeschränkt. Beispielsweise kann ich ja durchaus alle Caches in einer DB (auch gefundene) und mit simplen Filtern bastel ich mir die Anzeige dann so zurecht, wie ich es brauche.

Die von Hussel beschrieben Vorgehensweise scheint die zu sein, die vorrangig eingesetzt werden. Aus o.g genannten Gründe halte ich sie aber für unnötig kompliziert. Ich werde es mal testweise mit der API-Aktualisierung versuchen. Je nachdem wie gut das klappt werde ich dann auf die PQ-Variante wechseln.

Zitat von »langerxxl«

Unter geocaching.com-Zugriffe gibt es den Punkt Statusprüfung. Damit kann man sehr einfach die archivierten ermitteln, da der Status jedes Caches in der Liste aktualisiert wird.

Stimmt, den gibt es ja auch noch und der Vorteil ist, dass es das API-Limit nicht verbraucht.

Zitat von »Sajoma«

...was bei einer Datenbank mit 15000 Caches durchaus ein "paar" Minuten dauern kann.

Ich habe es mal gemessen. Meine Datenbank hat 1000 Caches. Der Aktualisierungsvorgang hat ziemlich genau 1:30min gedauert. Wenn GS keine Strafrunden einbaut skaliert das auch mit 15000 Caches. D.h. so ein Vorgang würde dann gute 20 Minuten dauern. Das ist wohl verkraftbar. Zumal es in meinen Augen keinen Sinn ergibt diesen Vorgang für die gesamte DB zu machen. Vielmehr würde ich es ständig für die erweiterte Homezone von max 15km und von ausgewählten Regionen, wenn ich dort eine Tour plane.

Eine vollständige Aktualisierung dauert jedoch viel länger. Bei mir waren das ca. 6min für 1000 Caches. Aber auch das ist verkraftbar, wenn man unabhängig von PQs sein möchte. Dann schmeißt man die Aktualisierung morgens oder abend beim Essen an und danach ist es fertig. Außerdem müssen keine bereits gefundenen Caches aktualisiert werden. Wenn es immer noch zu viele sind, kann man auch im GSAK den Filter etwas schärfer einstellen, s.o.

Wirklich schön wäre es, wenn es ein Makro gibt, das genau das macht. Also abhängig vom API-Limit, Uhrzeit, etc im Hintergrund die Caches aktualisiert.

Zitat von »ElliPirelli«

Ich arbeite mit vielen Datenbanken. Funde und eigene für die statistische Auswertung.
Empfehlungen aus ferneren Gegenden in eine ToDo.
Jede weitere/längere Tour bekommt ihre eigene Datenbank, die nach der Tour gelöscht wird.
Und dann natürlich zwei quasi Homezones, einmal Kassel und bei meinem Freund.

Mein Setup ist sehr ähnlich, weil eben auch mehrere "Homezones". Aktuell habe ich Empfehlungen und gelöste Mysteries noch in eigenen Bookmark-Listen bei GC.com, die ich dann per PQ ständig aktualisiert erhalte. Bei den gelösten Mysteries werde ich aber wohl jetzt auf die GSAK-interne Funktion umsteigen.

Zitat von »ElliPirelli«

meine Api hab ich bisher nur einmal ausgereizt, als ich Favoritenpunkte bei Funden aktualisieren wollte.

Genau. Und hier frage ich mich, wie das die PQ-Nutzer machen? Um an die FPs zu kommen müssen sie doch auch die API in Anspruch nehmen und wenn ich das muss, kann ich auch gleich meine ganzen Caches per API aktualisieren.

Da gibt es zwei Möglichkeiten. Siehe Bilder:

index.php?page=Attachment&attachmentID=317 index.php?page=Attachment&attachmentID=316

Einige nutzen ja auch das Plugin "Google_Map_V3". Wenn man eine Tour plant kann man damit auf der Karte grob den Bereich mit einem Polygon abstecken und diesen Bereich anschließend zurück an GSAK senden. Die Caches, die man dann im Filter hat, kann man dann aktualisieren. So spart man sich viele (meist) unnötige API-Aufrufe.