Feature Request: Pocket Query: Updated in the last XX days

[Bruce A. Johnson]

For Pocket Queries:

 

Change "Updated in the last 7 days", to be adjustable for any number of days.

 

During busy geocaching weeks, there can be more than 500 geocaches that get updated in an area, so some will be left out of the query. I would like to get the updates more often than once a week.

 

Other options I've considered:

 

1) Running the "Updated in the last 7 days", query several times a week. This produces a lot of duplication, increases the demand on the query server, and doesn't solve the problem of some updated geocaches being left out.

 

2) Running the "Updated in the last 7 days" query for limited distances, multiple locations, and several times a week each. This produces a significantly greater demand on the query server. Since the queries are based on circular areas, there will have to be either overlap that produces duplication of results, or there will be missing geocaches. Then there is the standard problem of duplication due to "updated in the last 7 days" being run more often than once every 7 days.

[Keystone]

There are more efficient ways to split up large pocket query searches than to perform overlapping radial searches.

 

For instance, you could update all puzzles and multicaches in one query, all traditional micros in a second query, and everything else in a third query. Puzzles and multis tend to get found less often and could be run once per week, with queries for the other types running twice per week.

 

Or, you could split up the queries by date range. Older caches tend to get found less often so you could run that once per week, and the newer queries could run more frequently.

[Bruce A. Johnson]

OK, now I have 15 Pocket Queries running for a total of 20 times a week. Whereas with my idea, I would have just one Pocket Query run 2 or 3 times a week.

 

Based on dates of placement, even though I've split recent years into two queries each, there are more than 500 caches for a 7-day update. This means there is the potential for missing some again.

 

I came up against one of these that didn't get updated on my computer when I was geocaching yesterday. I found out when I got home and logged it, that a geocache I spent almost an hour looking for had been archived two weeks before, but despite all the PQs I had at the time, that status never got updated on my computer. I was not happy.

 

I guess I'll have to give up the idea that I can have the geocaches in my area up-to-date on my computer automatically, and instead create one-use PQs for any areas that I plan to cache in, just before I leave.

[+BruceS]

Seeing that archived caches are not sent in your pocket query your idea would not have helped. Your data would not have been updated on your computer. If data is not updated that is your sign to investigate if the cache has been archived.

 

Your idea of running a query just before you go is really a better way than trying to keep an off line database up to date.

Edited October 5, 2009 by BruceS

[Keystone]

Looking at your home location near the border between Alberta and Saskatchewan, I see that right now there are 8328 caches and 2491 caches, respectively, in those provinces. You could run a weekly update on EACH cache in the province and use just 22 of your allotted 35 weekly queries. You could also then get more frequent updates on caches that are closer to home, like the 478 caches that are within 100 miles of Hardisty.

 

If you are regularly caching outside of a 100 mile biweekly update area or outside of a weekly update area as vast as those two provinces, then you ought to consider a mobile phone solution, a WiFi solution, or targeted queries on demand for the areas you're visiting (including caches along a route).

 

Short of that, there is something wrong either in your query construction method, your database update method, or both. If you could describe your system in greater detail, we'd be happy to help.

[CoyoteRed]

You're pretty much required to pull full datasets if you keep an OLDB (Off Line Data Base). Archived caches are not sent in regular PQs--only bookmarked PQs and Found It PQs. Therefore, the only way to know if a cache has been archived is try to determine whether it had been included in your last update. If not, then check online to see why.

 

Yes, the PQ scheme now in use is extremely inefficient, but TPTB have had lots and lots of suggestions over the years without implementing them. We're all simply left to do whatever we need to do to get our data.

[+tozainamboku]

I find it interesting that many of people trying to maintain a large offline database are so interested in trying to "reduce" the load on Grounspeak servers or finding "efficient" ways to update their offline databases that require fewer pocket queries (that perhaps they could run more often).

 

Parkinson's Law says that work will expand to fill the time available to complete it. And the corollary is that the data you keep will expand to be the maximum you can get with whatever pocket queries are allowed. If Groundspeak were to implement some method for telling you when a cache was archived so you would only need to get the updated caches in your pocket query, I have no doubt that people would just start having larger offline databases. They would run just as many pocket queries and put just as much load on the servers.

 

Groundspeak provides pocket queries to allow premium members to download a small portion of the Geocaching.com database that can be used to plan a geocaching outing or to gather personal geocaching statistics. They have put limits on the number of Pocket Queries you can run because they believe that these numbers allow plenty of caches for the intended purposes. They want to discourage larger offline databases because they have had experience with sites that scraped information from the Geocaching.com site. Groundspeak sees these sites as a direct threat to their business model and it is not just from the performance hit the scrapers take. They actively want to discourage anyone copying large portions of the Geocaching.com database. While the information on the individual cache pages belongs to the cache owner, Groundspeak sees the collection of data (the database) as its proprietary information. In order to protect this information pocket queries are limited and to some extent intentionally inefficient. Groundspeak has clearly expressed a preference that pocket queries be used on an as needed basis to get the caches in a particular area you may be planning to cache in shortly before your trip. They do realize however that some people will want to keep a slightly larger offline database of the caches in their immediate area where they are most likely to go caching. Cachers who are highly mobile and have a larger area where they might go caching on the spur of the moment have other options such as the iPhone or the Trimble Geocache Navigator applications. The Geocaching.com WAP site allows any phone with a WAP browser to look up caches as well.

[CoyoteRed]

Of the theoretical 17,500 maximum caches a week, my OLDB is only a little over 5k and that includes the caches I've found which I don't download on a weekly basis, caches from other sites, the ones we own, and private caches. So, the PQs only maintain around 4k of unfound caches.

 

Additionally, in order to create an OLDB larger than 17,500 caches then a full dataset of more than a week's worth would have to pulled. Not every cache is going to be found on a weekly basis, so the very reason a well thought-out differential scheme would reduce the server load would also discourage the use of over-large OLDBs.

[+Valentijn77]

However the replies above are interesting, I don't think it needs any argument to have a 'updated last xx days' (or 'updated last 24u') option for pocket queries.

 

In todays 24/7 econmy everybody wants information to be up-to-date, efficient and quick.

 

It will be especially interesting for bcaching users.

 

So you have my vote.

[Bruce A. Johnson]

This topic went off-topic, but...

 

Being a relatively new geocacher, I figured I would cogitate on how I could get by without a personal off-line geocache database. I figured that it would be even more time-consuming and difficult.

 

My personal off-line geocache database (using GSAK), allows me to experiment quickly and easily with various combinations of search specifics. Plus, GSAK can quickly make me a GPX file of whatever geocaches I want, without a limit of the number of geocaches. The only limit is the number my GPSr can hold.

 

Geocaching.com currently cannot match this same ease. That is why I will continue to use a personal off-line geocache database.

 

Back on topic:

For the above reasons, that is why I still think that "Updated in the last x days", would make sense. I wouldn't run as many Pocket Queries as often as I do now, if that option was available.

[+cron]

[removed questions to open a new thread in order to get an answer]

Edited October 27, 2009 by cron