Pocket Queries

[+larryc43230]

When I generate a pocket query, the results are limited to 500 caches (apparently not counting child waypoints like parking coordinates, trailheads, etc.). I'm curious as to how the system determines which 500 caches are sent to me and which aren't. Do I get the 500 caches that are closest to the origin? The first 500 caches alphabetically by waypoint code? 500 caches chosen at random that fit my criteria? Anyone know how this works?

 

--Larry

[+Miragee]

That is an interesting question, and it depends on how you set them up. If you set up your pocket queries by "Date Placed," you can get all the caches in your area.

 

For this area, it took a long time to set up the six PQs (to get just under 500 caches in each PQ) to cover the region I am likely to travel through. By getting all of those PQs once each week I know that for at least a little while, I have the most up-to-date data in my GSAK database, after filtering by the "Last .gpx update."

[+larryc43230]

That is an interesting question, and it depends on how you set them up. If you set up your pocket queries by "Date Placed," you can get all the caches in your area.

 

For this area, it took a long time to set up the six PQs (to get just under 500 caches in each PQ) to cover the region I am likely to travel through. By getting all of those PQs once each week I know that for at least a little while, I have the most up-to-date data in my GSAK database, after filtering by the "Last .gpx update."

Thanks! I'm vaguely familiar with this method of getting around the 500-cache limitation, though I've never tried it myself. Though I would be among the first to take advantage if they ever raised the limit (or increased the number of pocket queries I could run on a given day), it hasn't really caused me any great burden so far. I'm just curious as to whether there are any predictable rules regarding which caches are left out when you exceed the 500-cache limit in a pocket query.

 

--Larry

[+StarBrand]

The ones nearest the origin unless it is a "caches along a route" PQ.

[+larryc43230]

The ones nearest the origin unless it is a "caches along a route" PQ.

That would make sense.

 

I generate a pocket query almost every day that includes all the active caches within 60 miles of my home coordinates, omitting the caches I've already found, the three caches I own, and the caches on my Ignore List. Recently, due to a good number of new caches being published in my area, this pocket query hits up against the 500-cache limit. Since I wasn't sure exactly which caches were being omitted because I was over the limit, I shrank the radius of the search from 60 miles to 59 miles, which brought the query just under the limit. It sounds like I've been doing manually what the system does automagically!

 

--Larry

[+Markwell]

If there is an origin, the farthest ones disappear. If it's for a political boundary (like a state), the newest ones drop off. If it's for a route, it's the furthest ones from the route, I believe.

[+larryc43230]

If there is an origin, the farthest ones disappear. If it's for a political boundary (like a state), the newest ones drop off. If it's for a route, it's the furthest ones from the route, I believe.

How's that for a complete answer! This will definitely help with my planning. Thanks!

 

--Larry

[+Lil Devil]

If there is an origin, the farthest ones disappear. If it's for a political boundary (like a state), the newest ones drop off. If it's for a route, it's the furthest ones from the route, I believe.

When route queries were brand new, I tested this and found it worked it's way along the route until it hit the limit. Thus, the caches nearest the end point were omitted.

 

Admittedly this was a long time ago and things could have changed

[+Markwell]

I tested it and I stand corrected. I have a route that I had set at 5 miles, specifically made it so it would hit more than 500 caches. It still included caches up to 5 miles from the route. But not all of them.

 

Unfortunately it still included caches that were 5 miles from the end point of my 208 mile route. I'll have to experiment a little more and waste a PQ to see what kills a cache on a route query.

[+Markwell]

Interesting results.

 

I went to a cache rich area - making sure to hit caches within 10 miles of San Francisco, CA. Since there are 565 caches in that radius, I started off site down by Menlo Park and created a route I-280 into San Francisco and over to Oakland and then Richmond. Then I crossed the route back across the Richmond-San Rafael bridge and went back south to Sausalito.

 

I needed to make sure to hit the 10 mile radius, and yet not create a route with 500 miles and a gazillion waypoints. The route was approximately 70 miles with 31 points.

 

I uploaded and ran the query, and the preview said 500. I knew that I was definitely over the limit.

 

After converting it to GSAK and mapping it, here's the results of the 500 caches:

 

It doesn't appear that there are less caches near the end of the path by Sausalito, but there's a definite concentration near Menlo Park.

 

However, the most interesting thing was looking at the raw data. It appears that the regular caches included were all placed prior to 4/14/2006. That would confirm the limitation that when it looks at the list after getting all of the caches, it returns the 500 oldest caches.

 

BUT WAIT - there's more. There WERE some caches included that were placed more recently and that had newer GC numbers: Earthcaches. There were 5 earthcaches included in the search, and their dates of placement (and inclusion in the GC.com database is backed up by the GC codes) were anywhere from 11/15/2006 to 6/8/2007.

 

Even those however, don't appear to be ALL of the earthcaches. According to the cache list and mapping them, there should be eight Earthcaches included in that route, but only 5 were. Here's the map:

The red dots are the included earthcaches and the yellow dots are excluded. The three that were eliminated were placed on 11/21/2006, 8/25/2005 and 11/15/2006. Other earthcaches placed on 11/15/2006 and 11/20/2006 WERE included.

 

SO...

 

It looks like the regular caches pick the earliest ones to include, EXCEPT that it tries to include some of the earthcaches as well. How many earthcaches, and why those particular earthcaches were included is still a mystery.

 

So - no explanation, and I can't see any pattern, however, I *AM* quite sure of these two statements

If there is an origin, the farthest ones disappear. If it's for a political boundary (like a state), the newest ones drop off.

Edited August 22, 2007 by Markwell

[+PeterNoG]

I thought I would try to duplicate Markwell's experiment.

 

I had I route that had over 500 caches. I split the route into two parts and got 806 caches. When I tried sorting by date placed, the split was close but not exact (5 caches screwed up the split.) Resorting by GC number gave a perfect split. GC3EF to GCYP53 were included in the single 500 cache (red in pic below) query. GCYP6E to GC15942 were the extra 306 caches (yellow in pic) that were skipped.

 

[+Isonzo Karst]

I'm not 100% sure I'm following your post but I'd guess that the reason for this:

 

When I tried sorting by date placed, the split was close but not exact (5 caches screwed up the split.)

 

is that date placed doesn't = GCxxxx order - I have an old GCxxxx number on a cache page I use to test html, hold my coins etc. If I actually submitted it for publication today with its original '03 date it would have a Aug '07 publish and an '03 GCxxxx and date placed.

Also, I could write up a new cache today, and back date the placed date to Jan 01, 2000.

Edited August 23, 2007 by Isonzo Karst

[+PeterNoG]

is that date placed doesn't = GCxxxx order - I have an old GCxxxx number on a cache page I use to test html, hold my coins etc. If I actually submitted it for publication today with its original '03 date it would have a Aug '07 publish and an '03 GCxxxx and date placed.

Also, I could write up a new cache today, and back date the placed date to Jan 01, 2000.

 

The only true constant is the GC number (which is based on when the 'page' was created). Your old GC number from '03 could have any date placed (as long as it's not in the future). The same goes for a brand new GC number.

 

In my test for caches along a route, the first 500 GC numbers (regardless of date placed) were included in the PQ.

 

That doesn't explain Markwell's Earthcache anomoly. No earthcache were included in my PQ; four were missed.