Hidden-Date bitte richtig setzen

[goldensurfer]

Um die CacheScanner-Datenbank up-to-date zu halten habe ich eine PocketQuery laufen, die mir täglich alle deutschen Caches liefert, die während der letzten Woche versteckt wurden.
Jetzt habe ich mal eine weitere PQ laufen lassen: alle Caches rund um mein Home, die ich noch nicht gefunden habe - ohne weitere Einschränkung. Mit den 500 Caches die in einer PQ maximal möglich sind, habe ich einen Umkreis von 85 km abgedeckt. Es waren ca. 40 Caches dabei, die ich noch nicht in der Datenbank hatte.
Bei all diesen Caches liegt das "Hidden date" weit hinter dem Datum des "Published"-Eintrags. Die Caches gehen somit bei der PQ verloren.
Einen größeren Zeitraum als eine Woche einstellen ist leider keine Lösung, denn dann wird die Maximalgröße von 500 Caches pro PQ überschritten.

Deswegen meine Bitte vor allem an die Neuen unter Euch: setzt das Hidden-Datum bitte auf das Datum, an dem ihr den Cache veröffentlicht. Wenn ihr im Winter über einen zugefrorenen See zu einer Insel lauft um dort einen Cache zu verstecken, diesen aber erst im März veröffentlicht, dann ist das zwar cacheologisch eine witzige Idee, aber bitte setzt dann auch das Hidden-Date auf März.

Danke

 

[greiol]

eigentlich wäre das doch ein job für die freigabe, oder?
wenn das hidden datum auf das freigabe datum gesetzt würde (mal abgesehen von events) wäre doch allen geholfen, oder?

wobei mir caches einfallen bei denen das hidden datum schon der erste hint ist. das ginge dann halt nicht mehr. hmmm.

 

[goldensurfer]

wobei mir caches einfallen bei denen das hidden datum schon der erste hint ist. das ginge dann halt nicht mehr. hmmm.

Sowas hatte ich noch nicht. Aber ich muss ja nicht alles kennen

Ja, am besten wäre es, wenn das Datum vielleicht "Published date" hieße und automatisch per Datenbanktrigger gesetzt würde. Ob ich mal einen VV bei Groundspeak mache? Wird wahrscheinlich nix bringen, oder?

 

[emzett]

Die beiden Datumsangaben spiegeln doch zwei unterschiedliche Aktivitäten wieder.

 

[eigengott]

Um die CacheScanner-Datenbank up-to-date zu halten habe ich eine PocketQuery laufen, die mir täglich alle deutschen Caches liefert, die während der letzten Woche versteckt wurden.

Für inkrementelles Update sind Pocket Queries weder gedacht noch geeignet. Müsste sich inzwischen eigentlich 'rumgesprochen haben.

 

[greiol]

sie mögen dafür nicht gedacht sein und auch nicht alle eventualitäten abdecken, aber sie kommen dem was man für eine inkrementelle aktualisierung braucht noch mit am nächsten.

parallel sollte man aber zumindest eine notification für die archivierung mit gleichem mittelpunkt und radius haben.

ein published notifier schadet auch nicht, ist aber nicht zwingend erforderlich, denn spätestens nach dem ersten fund taucht der cache bei der wöchentlichen änderung auf.

alternativ kann der owner auch einfach das "published log" des reviewers stehen lassen. damit kommt der cache dann auch bei den wöchenlichen updates mit.

bei dauerqueries sollte man aber nicht vergessen, daß der ausführungszeitpunkt sich jedesmal leicht ändern kann. dadurch kann es sein, daß ein cache der vor 7 tagen und 2 minuten geändert wurde aus dem raster fällt.

 

[alex3000]

wenn das hidden datum auf das freigabe datum gesetzt würde (mal abgesehen von events) wäre doch allen geholfen, oder?

Jein. Es gibt Caches, die schon lange in der Gegend rumliegen, nur irgenwann kommen sie auch zufällig in die gc.com-Datenbank. Wieso soll sich der Cache einer weiteren Datenbank unterordnen?

 

[radioscout]

Jein. Es gibt Caches, die schon lange in der Gegend rumliegen, nur irgenwann kommen sie auch zufällig in die gc.com-Datenbank. Wieso soll sich der Cache einer weiteren Datenbank unterordnen?

Ganz richtig. Dafür sehe ich auch keinen Grund. Und wenn ich einen Cache vor einem Jahr bei nc gelistet habe und ihn jetzt auch bei gc liste, wird selbstverständlich das richtige Datum eingetragen.
Soll ich tatsächlich absichtlich falsche Daten angeben, nur weil irgendein Programm oder eine nicht optimal formulierte PQ Probleme hat?

Es ist besser, die PQ oder das Programm anzupassen, denn hier erreichst Du ohnehin nur einen kleinen Anteil der Cacher.

 

[dr_megavolt]

Verstehe die Forderung auch nicht. Bei "hidden" kommt das Datum rein, an dem ich die Box versenkt hab, ist ja wohl auch so gedacht ("richtig gesetzt", wie Du forderst). Für das "Published"-Datum zeichnet der Verstecker mit dem Zeitpunkt der Anmeldung bzw. der Reviewer verantwortlich, ab da darf geloggt werden.
Denke schon, daß das so seinen Sinn hat. Wenn wir jetzt irgendwelche work-arounds für irgendwelche Programme und ihre Bugs entwickeln, wo soll das hinführen? Endet doch alles in Chaos und Anarchie! :shock: Der nächste will keine Bilder, oder braucht sie unbedingt linksbündig, der andere hat Probleme mit schwarz-weiss, oder mit Text > 50 Worte...

 

[radioscout]

Und der nächste will dann etwas, was sein Problem löst, aber alle bisher "gelösten" Probleme wieder herstellt.

 

[Cornix]

Ja, am besten wäre es, wenn das Datum vielleicht "Published date" hieße und automatisch per Datenbanktrigger gesetzt würde. Ob ich mal einen VV bei Groundspeak mache? Wird wahrscheinlich nix bringen, oder?

Am allerbesten wäre es, wenn das "Published date" zusätzlich zum "Placed date" in der Datenbank abgelegt würde und man es mittels PQ abfragen könnte.

Du kannst ja mal dein Glück im blauen Forum versuchen. 8)

Cornix

 

[Banana Joe]

bei dauerqueries sollte man aber nicht vergessen, daß der ausführungszeitpunkt sich jedesmal leicht ändern kann. dadurch kann es sein, daß ein cache der vor 7 tagen und 2 minuten geändert wurde aus dem raster fällt.

Hier sind jetzt zwei unterschiedliche Dinge...

a) alte Caches, bei denen sich in den letzten 7 Tage etwas geändert hat
Hier zählt das Feld "Updated in the last 7 days". Da kann man wohl nichts machen.

b) neue Caches, die in den letzten Tagen eingestellt wurden
Hier kann man aber bei "Placed during ..." "last month" statt "last week" auswählen. Damit wäre das 7 Tage +/- ein paar Minuten/Stunden minimiert.