C:GEO was bedeuten die beiden Zahlen in der Kopfzeile ?

[Papa Delta]

Hallo,
nachdem ich längere Zeit nicht mehr mit C:GEO "rumgemacht" habe, fällt mir jetzt auf dass in der Kopfzeile von den gespeicherten Caches zwei Zahlen (durch / getrennt) stehen - die zweite Zahl müssten die gespeicherten Caches sein - aber was ist die erste Zahl??

 

[Staffy]

Das müssten die Caches sein, die gemäß Filter nicht rausgefiltert wurden

 

[SammysHP]

Heiliger Bimbam, sind das viele Caches.

@Staffy hat die richtige Antwort genannt.

 

[Papa Delta]

Das müssten die Caches sein, die gemäß Filter nicht rausgefiltert wurden

Danke für den Tip - scheint zu stimmen, denn jetzt hab ich mal alle Filter auf ALLE umgestellt - nun steht die Zahl wieder alleine ...

 

[DNF_BLN]

Heiliger Bimbam, sind das viele Caches.

Schön zu sehen das ich nicht der einzige bin der soviele Caches gespeichert hat.

 

[schatzi-s]

Im Namen aller Ressourcenschoner hoffe ich mal, dass die entweder langsam angewachsen sind oder per Pocketquery auf das Geraet gekommen sind ...

 

[2Abendsegler]

Ich dachte es macht keinen Unterschied im Hinblick auf den Ressourcenverbrauch auf den GS Servern, egal ob ich einen Cache manuell speichere, über Send to c:geo importiere oder per Pocketquery oder Bookmarkliste in c:geo lade. Ist das nicht so?

 

[schatzi-s]

Ich denke (!) nicht. In meiner kleinen Vorstellungswelt laeuft es folgendermassen:

C:geo verhaelt sich wie ein automatisierter Browser. D. h., wenn z. B. die 1000 naehesten Caches um einen Punkt geholt werden sollen, dann erzeugt c:geo erst eine Abfrage nach den GC Codes dieser Liste und anschliessend wird jeder Cache einzeln. Der Webserver erhaelt unabhaengige 1000 Anfragen (in der Praxis sogar viel mehr, da fuer jede Webseite diverse Abfragen noetig sind). Anschliessend werden die Anfragen in die Logdatei eingetragen und pro Cache mindestens eine Datenbankabfrage gemacht. Anschliessend werden die Daten pro Cache und unkomprimiert uebertragen.

Im Unterschied dazu ist bei einer Pocketquery die Anzahl der Datenbankzugriffe vermutlich nicht abhaenig von der Anzahl der Caches. Hier wird nicht ein "gib mir die Details zu Cache GC123", sondern "ein gib mir die Details von maximal Caches im Umkreis von X Metern um Y" zum Datenbankserver. Das ist deutlich weniger aufwendig als die einzelnen Abfragen (gerade weil die Abfrage, um welche Caches es ueberhaupt geht bei beiden Verfahren gleich ist). Die ermittelten Daten werden anschliessend gepackt und koennen dann als Block runtergeladen/ gemailt werden.

Dazu kommt noch, dass c:geo die Daten anfragt, sobald der Anwender den Prozess gestartet hat. Eine Pocketquery kann auch mal spaeter erzeugt werden, wenn die Server gerade weniger zu tun haben (gefuehlt war das frueher mehr?!). So werden Auslastungsspitzen ein wenig gemildert.

Sprich: Deutliche Entlastung des Webservers, des Datenbankservers und der Uebertragungswege.

So zumindest haette ich es gemacht. Wenn dem nicht so ist, dann lasse ich mich gerne eines Besseren belehren.

 

[2Abendsegler]

Ich hatte bei einer Pocketquery eher an das direkte Laden als Feature von c:geo gedacht. Aber eine Pocketquery über GC runterladen geht wohl auch, stimmt.

Ich kann das nicht beurteilen, ob das so ist wie du es beschreibst. Ich vermute aber, dass es mit dem Einspielen einer gpx Datei in c:geo aus einer herunter geladenen Pocketquery nicht getan ist. Die Pocketquery enthält meines Erachtens viele Daten gar nicht die c:geo verwendet. Und ich bin mir auch nicht sicher, ob Daten von Caches noch wie bei einem Browser besorgt werden. War da nicht mal die Rede von Web API?

 

[SammysHP]

c:geo verhält sich ähnlich wie ein Webbrowser: Jeder Cache wird einzeln abgerufen, dazu noch eine weitere Abfrage für die Logs. Allerdings ist es deutlich sparsamer als ein Browser, da beispielsweise keine Dateien für die Darstellung abgerufen oder Scripte ausgeführt werden, die zusätzliche Serveranfragen stellen würden.

Bei einer Pocket Query werden die Daten vom Server bereits in eine einzelne Datei gepackt (das kann mit geringer Priorität erfolgen), allerdings fehlen dann auch die Bilder aus der Beschreibung und es werden auch nur fünf Logs exportiert.

Über die API wäre ein Weg dazwischen möglich, aber bei so vielen Caches würdest du mit der Anzahl von täglich erlaubten Anfragen auch nicht auskommen.

 

[HHL]

Über die API wäre ein Weg dazwischen möglich, aber bei so vielen Caches würdest du mit der Anzahl von täglich erlaubten Anfragen auch nicht auskommen.

16.000 Caches im Full Format und 10.000 Caches im Light Format sind täglich nicht genug?
Mit Verlaub, aber das ist hanebüchener Unsinn (leider wie so oft bei c:geo-Propaganda)

 

[SammysHP]

16.000 Caches im Full Format und 10.000 Caches im Light Format sind täglich nicht genug?
Mit Verlaub, aber das ist hanebüchener Unsinn (leider wie so oft bei c:geo-Propaganda)

Quatsch. Hier geht es darum, 20.000 Caches im Full Format abzurufen.

 

[RSKBerlin]

aber bei so vielen Caches würdest du mit der Anzahl von täglich erlaubten Anfragen auch nicht auskommen.

Sicher?

16,000 full geocaches per premium user per day, falls ich die API restrictions richtig verstehe.

Ist aber ein anderes Thema...

Mit Verlaub, aber das ist hanebüchener Unsinn (leider wie so oft bei c:geo-Propaganda)

Hans, bitte freundlich sein. Man kann über ein Thema unterschiedlicher Meinung sein (und ich bin 100% bei @schatzi-s und Dir), ohne gleich ausfallend zu werden, bitte.

 

[RSKBerlin]

Quatsch. Hier geht es darum, 20.000 Caches im Full Format abzurufen.

Ja, genau. 4k mehr als an einem Tag möglich. Oder habe ich die API-Doku missverstanden?

 

[schatzi-s]

c:geo verhält sich ähnlich wie ein Webbrowser: Jeder Cache wird einzeln abgerufen, dazu noch eine weitere Abfrage für die Logs. Allerdings ist es deutlich sparsamer als ein Browser, da beispielsweise keine Dateien für die Darstellung abgerufen oder Scripte ausgeführt werden, die zusätzliche Serveranfragen stellen würden.

Danke fuer die Klarstellung. Es freut mich zu lesen, dass "nicht der ganze Schrott" immer wieder neu geholt werden muss.

Über die API wäre ein Weg dazwischen möglich, aber bei so vielen Caches würdest du mit der Anzahl von täglich erlaubten Anfragen auch nicht auskommen.

Das vermutlich schon, da ich davon ausgehe, dass die 17.000 Dosen dann doch nicht an einem Tag geholt wurden (und hoffentlich niemand auf die Idee kommt, c:geo anzuweisen die komplette Liste zu aktualisieren)

 

[2Abendsegler]

Bei einer Pocket Query werden die Daten vom Server bereits in eine einzelne Datei gepackt (das kann mit geringer Priorität erfolgen), allerdings fehlen dann auch die Bilder aus der Beschreibung und es werden auch nur fünf Logs exportiert.

Bedeutet das nicht auch, dass man einen Cache nochmal aktualisieren muss, wenn man Bilder und mehr als 5 Logs haben möchte?

 

[SammysHP]

dass die 17.000 Dosen

19.631 bitte.

Bedeutet das nicht auch, dass man einen Cache nochmal aktualisieren muss, wenn man Bilder und mehr als 5 Logs haben möchte?

Genau.

 

[RSKBerlin]

19.631 bitte.

Immer noch gerade einmal ~4k weniger als man als zahlender Nutzer gemäß der geltenden Nutzungsbestimmungen herunterladen kann. Richtig?

Genau

Genau. Und wenn sich in der Zeit, als ich mich zuletzt mit APIs beschäftigt habe, nicht etwas Grundlegendes geändert hat (Du als Entwickler wirst das besser wissen als ich), ist die Belastung für den Server durch einen API Call erheblich geringer als beim erneuten Aufruf der Website plus mehrfaches erneutes Abrufen von Logs mittels diverser JS Script-Calls. Oder?

 

[Papa Delta]

also die Zahl der in C:GEO gespeicherten Caches ist die Anzahl der GESAMTEN (gefunden, nicht gefunden, archivierten etc..) Caches seit 2008!
C:geo wird jetzt dazu genutzt, dass ich spontan und offline die Infos dabei habe - Meine "Master"-DB ist auf dem PC und wird mit GSAK verarbeitet, da werden/wurden dann auch immer die PQ's reingeladen...
Man kann dann die Daten aus GSAK sehr schnell mittels export nach c:geo transferieren..

 

[SammysHP]

Immer noch gerade einmal ~4k weniger als man als zahlender Nutzer gemäß der geltenden Nutzungsbestimmungen herunterladen kann. Richtig?

Um die letzten 4k Caches herunterladen muss man bis zum nächsten Tag warten, genau. Das dauert mindestens rund 5 Stunden (rate limit). Dürfte aber immer noch schneller sein, als die Requests von c:geo.

ist die Belastung für den Server durch einen API Call erheblich geringer als beim erneuten Aufruf der Website plus mehrfaches erneutes Abrufen von Logs mittels diverser JS Script-Calls. Oder?

Früher war das gefühlt anders herum, als die Server jedes Wochenende durch die API-Nutzung in die Knie gezwungen wurden. Ansonsten hast du recht, dass die API etwas ressourcenschonender ist. Die Anfragen von c:geo sind trotzdem noch schonender als das Aufrufen der Webseite.