Jump to content

Pocket Queries by Date Published


Stompy

Recommended Posts

Pocket queries are fantastic, it is possible to interrogate the database of caches in all sorts of combinations. Yet one very key feature appears to be missing and that is to be able to select caches by "DATE PUBLISHED".

 

It is currently only possible to select caches by "DATE PLACED" but if you are creating a Pocket Query for new caches in an area using "DATE PLACED" can miss out caches. For example I have a Weekly Pocket Query that runs to bring back newly published caches in the area outside of my Instant Notification Area. To do this I have set "Date Placed = Last Week" but any caches that were published last week but actually placed sometime before that will be missed out of the query for that week.

 

The key date for me is date published as that is the first date a cache became available to find. As there is a specific log type for "Published" it is likely that this information is in the Groundspeak data base and would therefore could be be added to the Pocket Query form.

Link to comment

Thats been mention before.

 

One simple solution is to setup a notification centered on that other area.

 

Thanks Starbrand, that is one solution for sure and thanks for the suggestion, I think that is all I can do at the current time, but it isn't ideal as you have to set up multiple notifications (as you can only do one notification per cache type) and it would be much better to be able to cover it off in a pocket query.

Link to comment
For example I have a Weekly Pocket Query that runs to bring back newly published caches in the area outside of my Instant Notification Area. To do this I have set "Date Placed = Last Week" but any caches that were published last week but actually placed sometime before that will be missed out of the query for that week.

 

The key date for me is date published as that is the first date a cache became available to find. As there is a specific log type for "Published" it is likely that this information is in the Groundspeak data base and would therefore could be be added to the Pocket Query form.

 

I would very much like to see this feature implemented as well.

 

Here's my situation: I am particular about what caches I want to seek so I keep a GSAK database for my entire state of caches that will interest me. I live in Florida which is pushing 40,000 active caches, but my database has less than 5,000.

 

I run a series of weekly PQs: for Earthcaches & Wherigos, for Wireless Beacon (Chirp) caches (my GPS is compatible), UV light requirements (since I own a UV flashlight), tree climbing caches (I've climbed more caches as a geocacher than as a child), etc.

 

If I run the weekly PQs for "Placed during the last week" then caches with more than 7 days between their Placed and Published Dates will never show up. If I run for the last month there is alot of redundancy each week and the are some caches from the PQs I don't add to my database. (For example, the Tree Climbing attribute seems to get misused on a semi-frequent basis; at least, I've been assuming that 1.5/1.5 caches with the Tree Climbing attribute are rated correctly and merely hanging in a tree.)

Link to comment

This would be very useful!

 

COs often forget to adjust the "placed" date before publishing a cache (sometimes months after creating a new listing...).

Therefore the "published" date is a much more relevant information and it is quite annoying that it can't be used in PQs!

Link to comment

GSAK and API. Its out there. Work well for me.

Hmm, it doesn't work for me. I thought I'd try using that function to see if it really uses the publish date, and not the placed date, but I couldn't get it to work. As soon as I change the "Publish date" dropdown to either "Between (Inclusive)" or "Equal to", it refuses to return any results at all, even if I'm 100% positive there are caches that fit the criteria. As soon as I turn off the "Publish date" criteria, it happily brings back a bunch of caches. Oh well.

Link to comment

GSAK and API. Its out there. Work well for me.

Hmm, it doesn't work for me. I thought I'd try using that function to see if it really uses the publish date, and not the placed date, but I couldn't get it to work. As soon as I change the "Publish date" dropdown to either "Between (Inclusive)" or "Equal to", it refuses to return any results at all, even if I'm 100% positive there are caches that fit the criteria. As soon as I turn off the "Publish date" criteria, it happily brings back a bunch of caches. Oh well.

I just tested those, and it doesnt work. Only the newer caches does work. This is very interesting. I think its more of a GSAK problem than GS.

Link to comment

This seems to get ask for by people who want to get more caches in their offline database with fewer pocket queries. They usually discover that if they simply ask for new caches by date placed since some recent date that eventualy they miss some caches - either becuase the publication was held up for a while or the hider mistyped the date placed on the cache form.

 

Attempting to add all the cache in some large area as they are placed (or published) has another problem however. You are going to have many caches in your database that are archived. This is because Groundspeak has chosen to never return archived caches in pocket queries. So if you set up a PQ to look for new caches and for cache that have changed in the past week, you won't ever know when a cache gets archived.

 

Groundspeak's rationale for doing this is to probably limit the number of caches you can reasonably keep in a offline database. They would prefer that you access the site more often to get fresh caching data - whether this is by using a targetted PQ to get only the caches you will likely be hunting on a certain day or by using the Geocaching.com smartphone app.

 

The query by placed date allows you to split up the caches in a region by date to creat several PQs with less than 1000 caches apiece. By limiting you to 5 PQs per day, it would would take 8 days to get all the caches in Florida. But in Grounspeak's opinion you don't need to copy that much of their database. They probably feel they are being more than generous with the number caches they allow you to get.

Link to comment

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...
×
×
  • Create New...