Datenbank aktuell halten - Überlegung zu GSAK 8

[Mark]

Ich hatte gerade diese Idee, vielleicht ist es eine Schnapsidee, aber ich möchte sie denoch mit euch teilen

Bisher habe ich zich PQs für Baden-Württemberg gehabt und diese regelmäßig in GSAK eingelesen, um die Datenbank aktuell zu halten. Alle paar Tage filtere ich alle Caches nach "Kein GPX seit 14 Tagen" und lasse den Status Check drüber laufen. So kann ich sicherstellen, daß die alle Caches in der Datenbank maximal 14 Tage alt sind.

Jetzt hatte ich folgende Idee: Die Datenbank habe ich ja schon aufgebaut. Eigentlich bräuchte ich nur noch eine Pocket Query mit neuen Caches. Änderungen über Status Check scheinen ja nicht von den API-Aufrufen abgezogen zu werden.

Also quasi täglich eine PQ mit neuen Caches, alle paar Tage Status Check über alle Caches (oder irgendwie aufgeteilt) und ich habe eine aktuelle Datenbank.

Kann das jemand nachvollziehen oder liegt hier ein Denkfehler meinerseits vor?

Mark

 

[8812]

[…]
Also quasi täglich eine PQ mit neuen Caches, alle paar Tage Status Check über alle Caches (oder irgendwie aufgeteilt) und ich habe eine aktuelle Datenbank.
[…]

Nein, hast Du nicht. Weder neue Logs an alten Caches sind dabei, noch hast Du eventuelle Änderungen in der Cachebeschreibung, dem Hint oder gar der Koordinate dabei.

Frohes Jagen

 

[Mark]

Nein, hast Du nicht. Weder neue Logs an alten Caches sind dabei, noch hast Du eventuelle Änderungen in der Cachebeschreibung, dem Hint oder gar der Koordinate dabei.

Okay, stimmt, da haben wir den Denkfehler Dann müßte man quasi zusätzlich eine Möglichkeit finden, Caches zu markieren, die mit "Refresh Cache Data" aktualisiert wurden. Das geht ja von den API Calls ab und die sind begrenzt.

Hintergrund ist einfach, so viel wie Möglich über die API automatisieren zu können, statt nur mit PQs zu arbeiten.

 

[Angrentil]

Arbeite weiterhin mit den PQ und automatisiere den Einladeprozess in GSAK 8. Das geht über die API ganz geschmeidig. Speicher die ein Setting, dass nur ungeladene PQ einließt. Das ganze kannst du dann einem Macro-Button zuweisen und dann drückst du nur noch einen Knopf und die alle neuen PQ werden automatisch eingeladen...

Dieses Macro kannst du dann individuell immer noch erweitern, dass nicht aktualisierte Caches mit einem StatusCheck überprüft werden... dann hast du in Randgebieten vielleicht Caches, die nicht immer hundertpro aktuell sind, aber zumindest weißt du, ob sie findbar sind... oder du schmeißt Randgebietcaches komplett raus... je nachdem was dir lieber ist.

 

[Mark]

Arbeite weiterhin mit den PQ und automatisiere den Einladeprozess in GSAK 8. Das geht über die API ganz geschmeidig. Speicher die ein Setting, dass nur ungeladene PQ einließt. Das ganze kannst du dann einem Macro-Button zuweisen und dann drückst du nur noch einen Knopf und die alle neuen PQ werden automatisch eingeladen...

Ich mache das bisher über PQDL. Das ist nicht das Problem. Aber PQs sind einfach sehr unkomfortabel. Die API-Daten habe ich sofort.

Dieses Macro kannst du dann individuell immer noch erweitern, dass nicht aktualisierte Caches mit einem StatusCheck überprüft werden... dann hast du in Randgebieten vielleicht Caches, die nicht immer hundertpro aktuell sind, aber zumindest weißt du, ob sie findbar sind... oder du schmeißt Randgebietcaches komplett raus... je nachdem was dir lieber ist.

Ich habe keine Randgebiete

 

[Angrentil]

Arbeite weiterhin mit den PQ und automatisiere den Einladeprozess in GSAK 8. Das geht über die API ganz geschmeidig. Speicher die ein Setting, dass nur ungeladene PQ einließt. Das ganze kannst du dann einem Macro-Button zuweisen und dann drückst du nur noch einen Knopf und die alle neuen PQ werden automatisch eingeladen...

Ich mache das bisher über PQDL. Das ist nicht das Problem. Aber PQs sind einfach sehr unkomfortabel. Die API-Daten habe ich sofort.

Aber, dass die API auch nur GPX Datein runter und wieder reinlädt, ist dir schon bewusst?
Letztendlich ist es das gleiche, nur dass die PQ in vordefinierten Abständen kommen und du mehr Filteroptionen hast... mal abgesehen von den wenigen Inhalten wie Favouritenpunkte, usw., die in die PQ noch nicht implementiert sind.

PQDL ist mit der API unnötig, wie schon gesagt, das Einlesen der PQ kann man jetzt automatisieren, ohne irgendwelche zusätzlichen Scripte oder dass man was manuell anpacken muss.


Also ich weiß ja nicht was du willst, du wolltest Vorschläge zum Handling, ich hab dir eine komfortable Variante genannt, die zumal noch Server-schonend ist, (im Vergleich zum täglichen Refresh, wo nach 6000 Caches zick ist). Wenn dir das nicht passt, musst du dir selbst was einfallen lassen... aber denk dran, GSAK 8 ist deswegen noch Beta, weil Clyde noch nicht die finale Freigabe von GS für die Nutzung der API bekommen hat. Und wenn User täglich bis Anschlag die API strapazieren und sich nur über Refresh und GetGeocaches ihre Daten holen, dann kann Seattle uns immer noch ganz schnell das Limit runterdrehen. :/

 

[Mark]

Aber, dass die API auch nur GPX Datein runter und wieder reinlädt, ist dir schon bewusst?

Klar. Was unter der Haube passiert, ist mir als Anwender ja erstmal egal.

PQDL ist mit der API unnötig, wie schon gesagt, das Einlesen der PQ kann man jetzt automatisieren, ohne irgendwelche zusätzlichen Scripte oder dass man was manuell anpacken muss.

Jepp, aber ist halt Gewohnheit.

Also ich weiß ja nicht was du willst, du wolltest Vorschläge zum Handling, ich hab dir eine komfortable Variante genannt, die zumal noch Server-schonend ist, (im Vergleich zum täglichen Refresh, wo nach 6000 Caches zick ist).

Die 6000 sind ja nur ein Beispiel. Wieviele das im Endeffekt täglich werden, steht in den Sternen. Mir geht es konkret eigentlich nur darum, eine bereits aufgebaute Datenbank mit so wenig PQs wie möglich uptodate zu halten. PQs sind einfach altbacken. APIs/Webservices gibt es seit über 5 Jahren, also sollte man sie so langsam auch nutzen

Wenn dir das nicht passt, musst du dir selbst was einfallen lassen... aber denk dran, GSAK 8 ist deswegen noch Beta, weil Clyde noch nicht die finale Freigabe von GS für die Nutzung der API bekommen hat. Und wenn User täglich bis Anschlag die API strapazieren und sich nur über Refresh und GetGeocaches ihre Daten holen, dann kann Seattle uns immer noch ganz schnell das Limit runterdrehen. :/

Das wird sich wie gesagt zeigen. Ich habe die API bisher noch recht selten mit mehr als 1000 API-Calls strapaziert. Aber wenn man eine API anbietet, muß man damit rechnen, daß sie genutzt wird.

 

[Angrentil]

Ich glaub jemand hat mal beschrieben, dass er seine Datenbank einmal die Woche mit Refresh aktualisiert (in kürzeren Abständen dann höchstens den Status Check durchlaufen lässt) und ansonsten für Neuveröffentlichungen eine PQ erstellt hat, die nur Veröffentlichungen in den letzten 7 Tagen beinhaltet...

Fand ich auch keinen schlechten Ansatz.

 

[Mark]

Sowas in der Art meine ich doch. Problem dabei ist, daß ich irgendwie vermerken müßte, daß ein Cache innerhalb der letzten X Tage schon refreshed wurde.

 

[Angrentil]

Guck in den Filter unter dates und setze da:

Last update gpx - not during - the last 7 days

und speicher dir den Filter.

Bei einem GcRefresh müsste das Datum von last update aktualisiert werden...
Bei einem Status Check tut es das auf jeden Fall nicht!

Somit weißt du, wann das letzte mal ein Update drüber kam... und Status Checks werden außen vor gelassen.

 

[Mark]

Werde ich daheim mal testen. Danke!

 

[dbox]

Ich lasse mir in meinen PQs nur die Caches schicken, die in den letzten 7 Tagen aktualisiert wurden. Diese PQs laufen dann auch nur alle 7 Tage. Dadurch brauchst du sehr wenig PQs, da nur ja bei weitem nicht alles Caches berücksichtigt werden, bzw. der Radius einer PQ mit 1000 Caches ist dann sehr groß.
Du musst natürlich dann alle PQs einspielen und darfst keine vergessen, sonst geht dir evtl. was zwischendrin verloren.

Gruß Rüdiger

 

[Eastpak1984]

Ich lasse mir in meinen PQs nur die Caches schicken, die in den letzten 7 Tagen aktualisiert wurden.

Wo stellst du dies ein?

 

[8812]

Ich lasse mir in meinen PQs nur die Caches schicken, die in den letzten 7 Tagen aktualisiert wurden.

Wo stellst du dies ein?

In der "That"-Abteilung, rechts, zweite Zeile von unten.

Das ist aber suboptimal, denn es ist nie klar, wann das PQ überläuft (Im Sommer werden ja vermutlich deutlich mehr Caches "upgedatet" als im Winter). Das ist also eine sehr unzuverlässige Art, seine Cachezone up to date zu halten.

Frohes Jagen

 

[Eastpak1984]

Gibts denn eine Erklärung, was mit der Aktualisierung gemeint ist?
Ist damit nur das Listing gemeint, oder zählen Logs auch als Aktualisierung?

Btw: Check mal deinen Posteingang nebst diverser Spamfilter - da scheinen mehrere Mails nicht zu dir durchgedrungen zu sein

 

[8812]

[...]
Btw: Check mal deinen Posteingang nebst diverser Spamfilter - da scheinen mehrere Mails nicht zu dir durchgedrungen zu sein

Hab ich. Da ist nichts.

 

[dbox]

Das ist aber suboptimal, denn es ist nie klar, wann das PQ überläuft (Im Sommer werden ja vermutlich deutlich mehr Caches "upgedatet" als im Winter). Das ist also eine sehr unzuverlässige Art, seine Cachezone up to date zu halten.

Frohes Jagen

Naja, es ist klar, dass der Durchmesser von PQ zu PQ schwankt, je nach Anzahl der Aktualisierungen, aber mich stört das in diesem Randbereich nicht. Für mich ist es trotzdem die bessere Lösung als immer wieder Caches in der PQ zu haben, an denen sich gar nichts geändert hat.

 

[dbox]

Gibts denn eine Erklärung, was mit der Aktualisierung gemeint ist?
Ist damit nur das Listing gemeint, oder zählen Logs auch als Aktualisierung?

Klar zählen neue Logs als Aktualisierung, sonst würde das nichts bringen.

 

[diehexer]

Arbeite weiterhin mit den PQ und automatisiere den Einladeprozess in GSAK 8. Das geht über die API ganz geschmeidig. Speicher die ein Setting, dass nur ungeladene PQ einließt. Das ganze kannst du dann einem Macro-Button zuweisen und dann drückst du nur noch einen Knopf und die alle neuen PQ werden automatisch eingeladen...

Habe das Setting gespeichert. Nun frage ich mich, wie ich dieses einem Macro-Button zuweise bzw. wo wird das Setting überhaupt abgespeichert?

 

[Angrentil]

Arbeite weiterhin mit den PQ und automatisiere den Einladeprozess in GSAK 8. Das geht über die API ganz geschmeidig. Speicher die ein Setting, dass nur ungeladene PQ einließt. Das ganze kannst du dann einem Macro-Button zuweisen und dann drückst du nur noch einen Knopf und die alle neuen PQ werden automatisch eingeladen...

Habe das Setting gespeichert. Nun frage ich mich, wie ich dieses einem Macro-Button zuweise bzw. wo wird das Setting überhaupt abgespeichert?

Für das Macro:

Macro -> Edit/Create

In das neue Formular schreibst du zB rein:

#Load all PQs via API that have not been downloaded yet
GcGetPQ Settings="<name des downloadsettings>"

#Load PQ in default database
LOAD Settings="<name des einladesettings (import dialog)>" database="<name der zieldatenbank>" ShowStats=Yes Notes=Prompt

Speicher das ganze mit einem sinnvollen Namen in den Macroordner (der sollte dir als erster Speicherort angegeben werden, denke ich). Ich habe mir angewöhnt meine eigenen Macros alle mit meinem Namen am Anfang zu speichern, um sie schnell wiederzufinden und nicht aus Versehen einen Namen zuzuweisen, den ein auf GSAK offiziell unterstütztes auch hat. (Sonst fängt GSAK dann an dich zu fragen, ob du die neuste Version deines Macros runterladen willst )

Für den Button:

Macro -> Button Configuration

Nimm eine beliebige Buttonnummer, gib ihm einen Namen und vllt ein Tootoptext und suche mit Macro File Name das gespeicherte Macro heraus. Speichern.

Macro -> Add Button to Toolbar

In der Liste zu Macros (nicht Macro!) gehen... Button raussuchen, und durch Drag&Drop in die Toolbar ziehen.

Draufklicken. Freuen.