Jump to content
Sign in to follow this  
Followers 1
bijth

Pocket Queries and the 'Placed During' option

Recommended Posts

Hi,

Has anyone an idea on where I could go with following 'nice to have' corncerning the PQ's and it's 'Placed During' option. Maybe this has already been posted, but I couldn't find it back.

As I like to keep the Belgian (and other) cache database offline and up-to-date, I created a list of PQ's using the date option. e.g. for Belgium I have about 40 PQ's. On a regular base, I run the last one till it has about 1000 caches. Then I create a new one from the last day of the former PQ till I hit the 1000 again. The aim was to get all new caches without having to run all those PQ's over and over again.

Lately, I noticed that I missed caches here and there. I did some investigation, and I have the impression that PQ's are using the 'Hidden Date' and not the 'Published Date'. I had the case that caches were hidden in February, and published in April. As I only take care of my last PQ, those caches did not show up. When I rerun an older PQ, I suddenly get more than 1000 caches and the newly published are listed in those old PQ's.

 

So to summarize, wouldn't it be better to use the "Published Date" in the PQ selection rather than the "Hidden Date"?

 

 

I hope my post is clear. But as my native language is not English, some things might be confusing. But I'm still convinced my English is better than Google Translate :-)

Share this post


Link to post
Posted (edited)
2 hours ago, bijth said:

wouldn't it be better to use the "Published Date" in the PQ selection rather than the "Hidden Date"?

 

The publish log  began July 28, 2005. So "publish date" is not going to yield any caches older than that. Also, for at least the first year of the "new" publish log, many cache owners deleted it. They weren't used to the look of it, and it seemed unnecessary info.  At the time, most devices only took at most 5 logs, so if one of them was "publish" there  was less info in the logs.

Additionally, the "placed date" field is something the site is already set up to gather, it's in the body of cache page, the publish log  is not. 

 

The new publish log was coupled with and created in part to support the  notification feature rolled out at the same time.

Edited by Isonzo Karst
  • Helpful 1

Share this post


Link to post

Where are you keeping your PQ? A GSAK database?

If so, you can just use the API to get caches "published during the last xx days" or published between DD/MM/YYYY and DD/MM/YYYY" (30 days maximum).

 

I also run (weekly) PQs for Belgium using the "placed date" and when importing them (via API) the summary will show the amount of caches for each PQ, whenever a PQ has 1000 caches it's marked in red and it's time to adjust the dates. Since the PQ's run weekly I can just use the API to get the caches published during the last 7 days to keep the database complete.

 

Whenever I see PQs getting "too small" I rerun the placedPQ macro and adjust all PQ's placed dates. I do this 3/4 times a year and usually "win" 1 or 2 PQs.

 

I used to do the same for the Netherlands (but not weekly) but now use the API to refresh caches (max 16000/day) and also get new caches via API at least once or twice per month.

 

 

Share this post


Link to post
Posted (edited)

I'm just thinking now… If I create PQs to get e.g. a full country (1000 caches per PQ, etc...) and I load them in GSAK. And from that point on I use GSAK on a regular base to get the latest caches (by using the "published during the last xx days"), this would keep my database up to date for the new caches. Since GSAK is using the "Published date" and not the "Hidden date", my problem mentioned above would be solved.

 

If this is right, there is no need of using the classic PQ's anymore (once you have an initial database), and the upload of new caches could even be automated with a GSAK Macro?

Sounds too good to be true...

Edited by bijth

Share this post


Link to post
5 hours ago, bijth said:

If this is right, there is no need of using the classic PQ's anymore (once you have an initial database), and the upload of new caches could even be automated with a GSAK Macro?

Sounds too good to be through...

 

And yet, it's true ;)

You will have to update the caches anyway as caches get archived or are "Temporary Disabled" and "Enabled" all the time.

 

  • Upvote 1

Share this post


Link to post
10 hours ago, bijth said:

If this is right, there is no need of using the classic PQ's anymore (once you have an initial database), and the upload of new caches could even be automated with a GSAK Macro?

 

Yup.

 

You may also want to run the GSAK API function (not macro) "Refresh Cache Data" from time to time, this will catch archived caches so you can purge them out of the database.  Recommend setting the number of logs it collects per cache low so you don't massively inflate the database size.

  • Upvote 1

Share this post


Link to post
9 hours ago, hzoi said:

 

Yup.

 

You may also want to run the GSAK API function (not macro) "Refresh Cache Data" from time to time, this will catch archived caches so you can purge them out of the database.  Recommend setting the number of logs it collects per cache low so you don't massively inflate the database size.

 

Or. Every-so-often run Purge Logs to reduce the size of the database.

Share this post


Link to post
11 hours ago, hzoi said:

You may also want to run the GSAK API function (not macro) "Refresh Cache Data" from time to time, this will catch archived caches so you can purge them out of the database.  Recommend setting the number of logs it collects per cache low so you don't massively inflate the database size.

If all you care about is whether the status of the cache has changed, the best tool for the job would be the "Status check" option. All that does is update the active/disabled/archived status, and it doesn't consume any of your API balance (at least on the old API, not sure about the new one), so it can be run on a database of any size.

Share this post


Link to post
1 minute ago, The A-Team said:

it doesn't consume any of your API balance (at least on the old API, not sure about the new one)

There is no real status check anymore in the New API. You'd have to use API calls that consumes your balance.

 

Hans

Share this post


Link to post
48 minutes ago, The A-Team said:

If all you care about is whether the status of the cache has changed, the best tool for the job would be the "Status check" option. All that does is update the active/disabled/archived status, and it doesn't consume any of your API balance (at least on the old API, not sure about the new one), so it can be run on a database of any size.

 

Status check is no longer available with the new API.

 

Share this post


Link to post
40 minutes ago, HHL said:

There is no real status check anymore in the New API. You'd have to use API calls that consumes your balance.

 

Hans

Good to know. Thanks

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  
Followers 1

×
×
  • Create New...