Pocket Queries along a route

[+k6ccc]

I have recently discovered an issue with Pocket Queries along a route. The issue is that lots of caches within the area of the route do not show up. Let me give an example. First of all, comparing to a pocket query for a specific location, if you specify a radius and a max number of caches, you will get the closest ones up to the max number of caches. For example, I have a pocket query called "500 caches near home". It specifies an 11 mile radius with the maximum number of caches as 500. Now as it turns out at this time there are 795 caches within the 11 mile radius of home, so the pocket query gives me the 500 closest ones. All fine and as I expect it to work.

With a query along a route it does not seem to work that way. I have a route from home to work with a max of 500 caches and a distance of up to 5 miles off the route. What I would expect it to do is to go as far off the route (up to 5 miles) to get the closest 500 caches. What I get is caches up to 5 miles off the route, but lots of missing caches that are closer than 5 miles. Yesterday morning I ran that query and loaded it into my GPSr. I discovered the issue last night while driving home from work and noticed that a cache that is within a hundred yards or so of my route that I have looked for but not found was not showing up on my GPS. When I got home, checked the query and sure enough it was not there. Previewed the query again with the same result. As far as I could tell, it was the same ones that did not show up so it's not just a random collection that fail to show up. I then modified the query to allow caches up to 2 miles off the route and ran it again, and it showed a bunch of close to the route caches that had not shown up with the 5 mile limit.

[+Lil Devil]

From my understanding, the way it works is it starts at the beginning of the route, and works along it, until it reaches the max number of caches. So, in your example, it will return all the caches closest to home, out to 5 miles from the route, and leave off the ones at the end, towards your work.

 

Just like circular PQs, you need to preview your results to make sure you don't go over the limit.

Edited December 15, 2006 by Lil Devil

[+ThePropers]

, if you specify a radius and a max number of caches, you will get the closest ones up to the max number of caches. For example, I have a pocket query called "500 caches near home". It specifies an 11 mile radius with the maximum number of caches as 500. Now as it turns out at this time there are 795 caches within the 11 mile radius of home, so the pocket query gives me the 500 closest ones. All fine and as I expect it to work.

 

I believe this is a wrong assumption. See this post by me from 2 1/2 years ago. At that time it appeared to function differently depending on if you were using zip code or home coordinates, and I haven't tested much since then. I just always make sure my PQs return less than 500 now.

Edited December 15, 2006 by ThePropers

[+txoilgas]

With a query along a route it does not seem to work that way. I have a route from home to work with a max of 500 caches and a distance of up to 5 miles off the route.

 

The purpose, the way I use it and understand it, is to have a list of caches that are available while traveling cross country. The default option is .5 miles off the route. This makes the ones that are on rest areas or near intersections easily obtainable while traveling.

 

I travel between two cities in the area quite often and I have set up a route and limited it to 2 miles off the route and 300 max. If it goes over the 300 then I backoff the distance so that it shows less that the max.

 

The real key to the route option is to use all the variables that are there especially the I have found, I own, ignore list, and especially the active ones. Just remember you can preview this lists as many times you need before you check when you want the PQ sent to you.

[+klossner]

What I would expect it to do is to go as far off the route (up to 5 miles) to get the closest 500 caches.

That's really expensive in terms of database queries because there's no reasonable upper bound to the number of iterations. I don't think we'll ever get this behavior.

[+pppingme]

What I would expect it to do is to go as far off the route (up to 5 miles) to get the closest 500 caches.

That's really expensive in terms of database queries because there's no reasonable upper bound to the number of iterations. I don't think we'll ever get this behavior.

This behavior is what Raine and others have documented right here in this forum, and from my testing, seems true...

[Not So Lost Puppies]

if you are looking for more caches along your route than the site will provide, you may want to look into using PC based software such as GSAK, which provides you with more filtering options, including most any distance along a route (route of either selected caches, or list of specific lat/lon coordinates)

 

I've used it numerous times to select 5miles or more from a lat/long route list during trips. I started using it before they added the "along a route" feature here.

 

Though you do need to load its database with caches from the areas along your route. I think I used 4 or 5 queries to generate my data base for a trip from south central Wisconsin to southwest Missouri (over 600miles) by selecting a point along the route and seeing how far the 500cache PQ goes out. usually 50+ miles, so then pick another about 100 miles further along the route and check if it overlaps the previous.

[+sbell111]

What I would expect it to do is to go as far off the route (up to 5 miles) to get the closest 500 caches.

That's really expensive in terms of database queries because there's no reasonable upper bound to the number of iterations. I don't think we'll ever get this behavior.

This behavior is what Raine and others have documented right here in this forum, and from my testing, seems true...

I think it will work that way for regular PQs, but not for routes.

[+Lil Devil]

oops. should have read the whole post.

Edited December 15, 2006 by Lil Devil