Jump to content

Search on 'published date' in PG and save 1000's pg to run


greibe

Recommended Posts

Until now I thought I could make my PG's for Denmark by splitting on placed date and then when it has ran once, I could use the 'update cache data' in GSAK to refresh data. So I only needed one active pg.

 

Now I discovered that the placed by date is not trustable and that people can add the date way back in history, so I need to rerun old pg's.

 

If this was changed, so the date placed was right, or change PG search so we can search on published date, Groundspeak could save 10000's of PG's to run every day - and I and many other would only need to maintain a single pg for new caches.

 

Or, is there another way I can accomplish the same?

Link to comment

I see 2 puzzle caches in Dnemark with placed dates before 2000.

http://www.geocaching.com/seek/nearest.aspx?country_id=57

 

Just grab those two if you want them. If you've got a good date range set of queries for Denmark, you should be getting most all of the country as you re-run your queries. If someone back dates a newcache, you'll still get it in the date ranged query for that period.

 

You have to re-run those queries, to weed out the archived. Caches that aren't returned when you run the query again have been archived.

 

Published date as a PQ query criteria has been suggested before. It then creates a larger problem with events.

It's a trade off, with fewer problems associated with the current system.

 

With around 26,500 caches, it takes 27 queries to cover Denmark, not 1000s.

Edited by palmetto
Link to comment

You shouldn't be caching with old information. If the PQ you have is more than a few days old, it shouldn't be trusted. Caches get archived and disabled all the time for various issues, some of which may mean its not a good idea to even be in the area.

 

 

He's not using stale data. He's using the PQ to get the caches into GSAK, then using the api to periodically refresh them. He's missing caches because they have funny placed dates. The problem is that you can only set a date period for a PQ back to 1988. Presumably, no caches listed on the site have been place prior to that. The field is configurable by the cache owner, however, so it can basically be any date. Some people use strange dates as part of their puzzle, or a clue, or they just think that they'll be cute.

 

As it is, I'm not sure that his solution is feasible as I don't believe that they have been tracking publish dates and the information is probably not in the db. There has never been a "publish date" in the GPX and it sure isn't in the api. Everything is based on "placed date".

Link to comment

I see 2 puzzle caches in Dnemark with placed dates before 2000.

http://www.geocaching.com/seek/nearest.aspx?country_id=57

 

Just grab those two if you want them. If you've got a good date range set of queries for Denmark, you should be getting most all of the country as you re-run your queries. If someone back dates a newcache, you'll still get it in the date ranged query for that period.

 

You have to re-run those queries, to weed out the archived. Caches that aren't returned when you run the query again have been archived.

 

Published date as a PQ query criteria has been suggested before. It then creates a larger problem with events.

It's a trade off, with fewer problems associated with the current system.

 

With around 26,500 caches, it takes 27 queries to cover Denmark, not 1000s.

 

Right, it is 26 queries to many, but I meant 10000's saved for Groundspeak. There must be 1000 of geocachers all running 25 or more PG's every week just to get caches with 'wrong' placed date - if we could trust the placed date we all needed only one to run every week getting last weeks changes.

 

Also requires that gsak refresh cache data is used before downloading to gps in order to get the last status and remove archived caches - so not everybody might reduce their pg's - but anyway;-)

Link to comment

You shouldn't be caching with old information. If the PQ you have is more than a few days old, it shouldn't be trusted. Caches get archived and disabled all the time for various issues, some of which may mean its not a good idea to even be in the area.

 

 

He's not using stale data. He's using the PQ to get the caches into GSAK, then using the api to periodically refresh them. He's missing caches because they have funny placed dates. The problem is that you can only set a date period for a PQ back to 1988. Presumably, no caches listed on the site have been place prior to that. The field is configurable by the cache owner, however, so it can basically be any date. Some people use strange dates as part of their puzzle, or a clue, or they just think that they'll be cute.

 

As it is, I'm not sure that his solution is feasible as I don't believe that they have been tracking publish dates and the information is probably not in the db. There has never been a "publish date" in the GPX and it sure isn't in the api. Everything is based on "placed date".

 

Thanks for your input, if the published data is not in the db, then the only option left for Groundspeak is to not allow placed dates before current date.

I think I will continue to only run pg's for new caches and then now and then run all my pg's for older dates. I will always miss the caches with dates before the possible search from date in the PG, but anyway there are plenty of caches out there;-)

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...