A pocket query query

[+Shanghai Joe]

Pocket queries for say, 1000 caches within 50 miles of X, often return exactly 1000 caches. It's likely that there are actually more than 1000 caches within a 50 mile radius of X so so does anyone know how are the results selected. Is it on the basis of an ever increasing radius until 1000 results are found?

[+Bear and Ragged]

Starts at the centre point and works out to the maximum distance (if there are more than 1,000 caches in your distance)

 

If you want ALL the caches in a set distance, eg 50 miles, you need to set the PQ's for Date Placed.

 

An excellent guide for PQ's is Markwell... http://markwell.us/pq.htm

Edited August 31, 2012 by Bear and Ragged

[+Beach_hut]

It's the nearest caches to the centre of your circle. (if that makes sense)

 

Some of my PQs do this, so I've subdivided them by difficulty into two PQs. Another way I sometimes cut it for PQs I run every week is to specify only caches that have been updated since last week. That way the PQ doesn't return caches that were exactly the same last week when they appeared in my PQ.

[+dartymoor]

This is my biggest annoyance with the PQ system, that 1,000 cache limit. Might have been okay in the early days, but density is such now that it means you need multiple PQ's for even a small area, and that means you end up with many duplicates after downloading the same caches which overlap.

 

I wonder if this 1k limit will ever be revised? 5k would work for me since that's the limit of my gpsr...

[+Graculus]

If you tick the box in the PQ 'Is enabled' it won't include any disabled caches (which may not be in place). That can reduce the number of caches in the PQ.

 

Chris

Graculus

Volunteer UK Reviewer for geocaching.com

UK Geocaching Information & Resources website - www.follow-the-arrow.co.uk

UK Geocaching Wiki

Geocaching.com Help Center

[+Happy Humphrey]

This is my biggest annoyance with the PQ system, that 1,000 cache limit. Might have been okay in the early days, but density is such now that it means you need multiple PQ's for even a small area, and that means you end up with many duplicates after downloading the same caches which overlap.

 

I wonder if this 1k limit will ever be revised? 5k would work for me since that's the limit of my gpsr...

Simply refresh your cache data (or "get geocaches") in GSAK instead. You can download 6000 caches per day based on a centre point, so that should be more than sufficient for you without having to trouble the PQ system at all.

[Alan White]

This is my biggest annoyance with the PQ system, that 1,000 cache limit. Might have been okay in the early days, but density is such now that it means you need multiple PQ's for even a small area, and that means you end up with many duplicates after downloading the same caches which overlap.

 

I wonder if this 1k limit will ever be revised? 5k would work for me since that's the limit of my gpsr...

It's only "recently" (2 years?) that it was increased from 500 to 1000. With the arrival of the API I wouldn't expect a further increase anytime soon.

 

You can avoid overlaps by filtering on conditions which don't overlap, such as placed date.

[+and1969]

This is my biggest annoyance with the PQ system, that 1,000 cache limit. Might have been okay in the early days, but density is such now that it means you need multiple PQ's for even a small area, and that means you end up with many duplicates after downloading the same caches which overlap.

 

I wonder if this 1k limit will ever be revised? 5k would work for me since that's the limit of my gpsr...

It's only "recently" (2 years?) that it was increased from 500 to 1000. With the arrival of the API I wouldn't expect a further increase anytime soon.

 

You can avoid overlaps by filtering on conditions which don't overlap, such as placed date.

 

My day job involves working with XML files, of which GPX files ("PQ's") are an excellent example of the genre. Because of this I can safely say that - in theory - the only technical limit on the size of a PQ, is the size of Groundspeak's database, or the disk that will hold the file, whichever kicks in first.

 

One of the minor caching sites allows download of a PQ with 5000 caches, which in their case, for a query centred on Britain, covers most of north west Europe. That PQ, which I downloaded earlier this evening, was 20 megabytes.

 

I can understand Groundspeak's caution in increasing the limit above 1000 caches. People would always ask for the maximum number of caches and this would place more demands on their servers, which would prompt an increase in our subscriptions.

 

Also, if people could download an entire country's (or US state's) caches, an unscrupulous individual - possibly the same type of chap that swaps ammo boxes for cheaper containers - could upload the PQ to a torrent site and this would damage Groundspeak's income, and cause an increase in subs from the rest of us who do stick to the rules.

[+Happy Humphrey]

But as I said above, currently you can download 6000 caches in a single query using the API via GSAK. I think that Groundspeak have a reasonable compromise at the moment.

[+Pharisee]

But as I said above, currently you can download 6000 caches in a single query using the API via GSAK. I think that Groundspeak have a reasonable compromise at the moment.

 

Yes you can but by the cringe, it doesn't 'arf take a long time to generate and GSAK is notoriously resource hungry. My computer slows down massively whilst GSAK is doing it's thing

[+Happy Humphrey]

I tend to either refresh a subset of caches (e.g. if I'm just interested in a particular group or if I want to make sure the caches I have on today's list are up to date), or populate a whole new database for an area I'm visiting (leave the PC to get on with it for half an hour). That doesn't take long at all.

I don't have the latest and greatest PC but I barely notice GSAK working in the background.

If it's a big refresh of several thousand caches then I just start it at bedtime and it's finished long before I wake up. Better than having to wait a day or two for a PQ to arrive (assuming you have several regular queries, you can't always just order one and then load it up straight away).

[+Malpas Wanderer]

But as I said above, currently you can download 6000 caches in a single query using the API via GSAK. I think that Groundspeak have a reasonable compromise at the moment.

 

Yes you can but by the cringe, it doesn't 'arf take a long time to generate and GSAK is notoriously resource hungry. My computer slows down massively whilst GSAK is doing it's thing

 

The API is useful but as Pharisee says it takes a while and as phone lines are not good to my residence I either use Satellite or mobile dongle with restricted data levels.

 

So if I'm likely to refresh the same caches in bulk regularly, I go;

 

Filter the ones I want in GSAK

Create a bookmark (remember reduce filter to 1000 caches).

Create a PQ from the bookmark.

Download the PQ which is zipped and uses much less data allowance.

 

If you retain the bookmark a quick scan will indicate unavailable ones.

Grease monkey script allows you to view 1000 caches per page and bulk delete etc.

[Alan White]

The API is useful but as Pharisee says it takes a while

I agree: the API is extremely useful and it's a great benefit. There are three aspects which cause its poor performance when compared with PQs.

 

Firstly, the API data retrieves, packages, transmits, and - in GSAK at least - loads the data in real time whereas a PQ is created offline and only the last two functions need to be done in real time.

 

Secondly, the API currently sends more information about each cache than is in a PQ (favourite points, premium status, avatars etc).

 

Thirdly, and to my mind most significantly, the API has a much greater overhead of data for the same information. This is partly as a result of the extra information but isn't helped by the tags in the API being huge. Here's a small sample: "<a:IsArchived>false</a:IsArchived>". This uses thirty-four bytes to send five bytes of information; "<a:AdminActionable>false</a:AdminActionable>" user forty-four bytes to send five (I've no idea what this tag is or how useful it is); and so on.

 

The result is that the files are also correspondingly huge: a 1000-cache PQ is typically slightly under 1Mb; a 300-cache API file (GSAK splits the call into such files) is over 6Mb. Even allowing for the fact that a PQ contains five logs per cache and I usually ask for ten logs in an API call then the API still needs about four times as much data as a PQ for the same information.

 

Still, mustn't grumble. The API is a very useful enhancement to Groundspeak/GSAK and I'm very grateful for it.

[+Malpas Wanderer]

Many thanks for the explanation and maths Alan, you have such a greater understanding of these things than myself.

 

Certainly not complaining about the API I just balance the way I use it considering my data allowance constraints.

[+Shanghai Joe]

Thanks everyone for your replies, they have confirmed what I thought and given me food for thought. I do like Markwells site, especially the idea of using dates to keep below the 1000 cache limit. I shall be doing that for new locations. The reason I asked the question is that I'm working in Kentucky just now and given the density of caches here it is easy to go over the 1000 limit in a very small radius from "home".

[+Alfiegeorge]

I've come across an associated issue a couple of times;

 

When you are generating a PQ using a "caches along a route" method, the resultant .gpx will contain the nearest X caches (max 1,000) to the route's start that also fit your selection criteria you use (with the additional stipulation of the width, distance either side, of your route corridor being one of the criteria).

 

So if you make the width too large, you end up with X caches that maybe only cover the first half/third/quarter of the length of your route.

 

I think that I'd prefer always to see the nearest X caches to the route, that are within the stipulated width, irrespective of how far they are from the route's start.

 

Does that make sense?

[+Bear and Ragged]

I've come across an associated issue a couple of times;

 

When you are generating a PQ using a "caches along a route" method, the resultant .gpx will contain the nearest X caches (max 1,000) to the route's start that also fit your selection criteria you use (with the additional stipulation of the width, distance either side, of your route corridor being one of the criteria).

 

So if you make the width too large, you end up with X caches that maybe only cover the first half/third/quarter of the length of your route.

 

I think that I'd prefer always to see the nearest X caches to the route, that are within the stipulated width, irrespective of how far they are from the route's start.

 

Does that make sense?

 

GSAK has it's own version of 'Caches Along a Route...'

Allows you to see, and alter, the selected area...

 

Can run heavily into your 6,000 caches allowance on the API though!