"Caches along a route" results incomplete

[+WascoZooKeeper]

I know I saw a thread about this some time back, but couldn't locate it now when I searched. So, my apologies if this is a duplicate, and the mods are welcome to merge this into another thread or point to the right place and lock this if appropriate.

 

I am trying to get a PQ of all the caches on Whidbey Island and Fidalgo Island in Washington. So I built a route that looks like this:

 

 

I know there are somewhere in the vicinity of 270 +/- caches on those two islands, but the PQ is only returning 101 caches. On the following map, the red dots are the caches returned by the query; the yellow dots are caches that have previously been identified, but are currently not returned by the PQ.

 

 

For the benefit of the lackeys, the query I'm running is named "WA-Whidbey Island". FYI, I deleted the query of that name, which had been giving me the abbreviated results, and recreated it using the same route, just in case there was a problem with the query. But after re-creating it, I got the same result.

[+Hynr]

I quickly created this route with the new route tool:

http://www.geocaching.com/my/userrouteedit...d0-1bd0b0bc53e9

It is similar to your route. With about a 5 mile width PQ with no checkboxes checked, the preview suggests that I will get 310 caches returned.

[+Raine]

I used the route that Hynr created and made a PQ with out applying any filters. It was 5.01 miles with max of 500 caches. It returned to me 310 caches according to EasyGPS.

 

Can you verify that you don't have any filters being applied?

[+WascoZooKeeper]

I used the route that Hynr created and made a PQ with out applying any filters. It was 5.01 miles with max of 500 caches. It returned to me 310 caches according to EasyGPS.

 

Can you verify that you don't have any filters being applied?

[OpinioNate]

You didn't mention whether or not the preview reported a different number than what you got in the actual PQ. Does it say 310 caches when you preview?

[+Rumpled]

I'm having a similar problem. I have a route query set to 3.11 miles and 250 either side. It only yields 28 caches on the preview and the "cloud" map of the route has returned to the world map after modifying. No filters were checked.

This is in a very cache dense area and should yield hundreds of caches.

I also wish those slider inputs could be done numerically.

[+WascoZooKeeper]

You didn't mention whether or not the preview reported a different number than what you got in the actual PQ. Does it say 310 caches when you preview?

No, the preview also only gave me 101 caches.

 

Here's some more info. My original query, with the original route, worked fine until 6/19/09, and returned about 280 +/- caches. Sometime during the next seven days, something went wrong, because the next time the query ran on 6/26, it returned only about 101 caches. Ever since then, the original query has returned only about 101 caches -- it may have varied a few in either direction with new/archived caches.

 

This morning I created a new route, using the gc.com route tool, and added some zig-zags in to make sure I got complete coverage. These two pictures give you a pretty complete view of the route -- it's called "Whidbey/Fidalgo", and I made it public.

 

 

A query built on that route now gives me 194 caches -- better, but still not complete. So I took my three query results and mapped them out with Microsoft Streets & Trips. In the following picture, the blue squares are caches that were returned by my original query on 6/19, the white circles are those returned since 6/26, and the red dots are those returned by the new query I built on the new route this morning.

 

 

Pretty much all the points ought to show a red dot on a white circle on a blue square.

 

A blue square all by itself means that my original query returned that cache on 6/19 and earlier, but neither my original query nor my new one returns that cache now. Some of those are outliers in my original query -- over on the Olympic Peninsula and Camano Island -- so I'm not worried about them not showing up in my new query. But they all ought to have both a blue square and a white circle. The lone blue square just to the NE of the "d" in "Puget Sound" is GC1HA23, which is temporarily disabled -- so it ought to show up, since I'm not filtering out disabled caches. The lone blue square due west of "Swinomish I.R." is GCNR2G, which is also disabled. The lone blue square just SW of "Swinomish I.R." is GCQQB7, another disabled cache -- so maybe that gives you a hint. But there's also that huge cluster of blue squares at the very north end -- those are not all disabled caches.

 

The blue squares with red dots mean they were returned my original query on 6/19, and are also returned by my new query, but are not presently being returned by my original query. There's a huge cluster of those due west of Coupeville, and another cluster at the north end of the islands, and then a large number scattered around at the southeast end of the islands.

 

And then there are the blue squares with white circles. Those are ones that were returned by my original query on 6/19 and are still returned by that query today -- but are not returned by my new query. The ones that are outliers don't concern me -- over by Port Townsend Bay and at the south end of Swinomish I.R. But there are quite a few on Fidalgo Island itself which ought to be showing up with red dots.

 

And here's one more interesting case. This picture shows two locations at the southeast end of Whidbey where the new query (red dots) is missing caches even though it's returning other caches very near by. GC1NQKH is disabled, but GC1MGA8 is not.

 

[OpinioNate]

We're kind of at a loss here, Wasco. Both Raine and I have followed your instructions to the letter and still receive the proper number of caches in the query. I even logged in as you and previewed your route and the one Hynr posted. I loaded the .GPX in Google Earth and EasyGPS. All of these tests have failed to reproduce the error. I don't know how much more we can do at this point.

 

The only thing I can think is that you have some greasemonkey script that interferes or something. That isn't the case, is it?

[+Puppy Dawg]

This happened to me as well. 41 out of well over 200 caches were loaded in. I think routes will work for lackeys, but not the general community. Just an idea.

[jholly]

This happened to me as well. 41 out of well over 200 caches were loaded in. I think routes will work for lackeys, but not the general community. Just an idea.

 

That is always possible, but OpinioNate said he logged in as WascoZooKeeper (lackeys can do that) and got the proper results. Certainly is strange.

 

Edit: I have done some comparisions between CAR and the GE KML tool and the results seem consistent.

 

Jim

Edited August 4, 2009 by jholly

[OpinioNate]

This happened to me as well. 41 out of well over 200 caches were loaded in. I think routes will work for lackeys, but not the general community. Just an idea.

 

That is always possible, but OpinioNate said he logged in as WascoZooKeeper (lackeys can do that) and got the proper results.

 

That's right, I did. Logging in as him should have given me a fair test.

[+WascoZooKeeper]

We're kind of at a loss here, Wasco. Both Raine and I have followed your instructions to the letter and still receive the proper number of caches in the query. I even logged in as you and previewed your route and the one Hynr posted. I loaded the .GPX in Google Earth and EasyGPS. All of these tests have failed to reproduce the error. I don't know how much more we can do at this point.

 

The only thing I can think is that you have some greasemonkey script that interferes or something. That isn't the case, is it?

No, I don't have any GreaseMonkey scripts loaded. I also logged in under another account that I have, using Internet Explorer instead of Firefox, and encountered the very same problem there.

[+WascoZooKeeper]

Results by a cacher I know in another forum:

 

[jholly]

I tried your steps and got 194.

 

Jim

[+AndrewRJ]

I tried your steps and got 194.

 

Jim

I also got 194.

[+AndrewRJ]

doesn't seem to be date based either.

[+WascoZooKeeper]

Here are the locations of the 71 caches that are missing from the query result. (The count may be off by just a few depending on any new or archived caches since 6/19).

 

[+WascoZooKeeper]

I've made my original route public, too -- it's named just "Whidbey Island". Creating a PQ on that route with a distance of 5 miles on either side returns a total of 101 caches, which is what I've been getting in my weekly PQ since 6/26. Others can see if they get the same result.

[jholly]

I tried my hand on this route and came up with 259. It looks like I picked up most of the ones your missing, but it is hard to tell from your posting. I think I might be missing one or two, perhaps the route needs to be tweaked. I made it public - "MJH Whidbey Island". One thing I noticed is your has a couple double backs, while with mine I have just a single track all the way down the islands. Could the double backs be causing a problem with the generator?

 

Jim

[OpinioNate]

I tried my hand on this route and came up with 259. It looks like I picked up most of the ones your missing, but it is hard to tell from your posting. I think I might be missing one or two, perhaps the route needs to be tweaked. I made it public - "MJH Whidbey Island". One thing I noticed is your has a couple double backs, while with mine I have just a single track all the way down the islands. Could the double backs be causing a problem with the generator?

 

Jim

 

I had a hard time searching for this route name for some reason, so here is a link.

[OpinioNate]

I've made my original route public, too -- it's named just "Whidbey Island". Creating a PQ on that route with a distance of 5 miles on either side returns a total of 101 caches, which is what I've been getting in my weekly PQ since 6/26. Others can see if they get the same result.

 

I got 101 results for this route as well. Raine seems to think it has something to do with the route not following an actual road and going off into the water. Does Jholly's route deliver?

[+WascoZooKeeper]

I've made my original route public, too -- it's named just "Whidbey Island". Creating a PQ on that route with a distance of 5 miles on either side returns a total of 101 caches, which is what I've been getting in my weekly PQ since 6/26. Others can see if they get the same result.

 

I got 101 results for this route as well. Raine seems to think it has something to do with the route not following an actual road and going off into the water. Does Jholly's route deliver?

That's possible, I suppose, but the question is, did you change something between 6/19 and 6/26 that would cause that to matter?

 

Jholly's route is close but still seems to have some discrepancies. I'm fooling around with some alternative routes that will provide the right coverage.

[jholly]

6/24 was the site update release. Only two changes I see that might be affecting your results are:

• Removed old version of cache along a route page
  
• Fixed "zoom to address" behavior in Google maps
  

I would be inclined to think the "zoom to address" change might be the likely cause.

 

Jim

Edited August 4, 2009 by jholly

[jholly]

Jholly's route is close but still seems to have some discrepancies. I'm fooling around with some alternative routes that will provide the right coverage.

 

If it matters I used a 4 mile radius on the PQ. Wider and it will start to pickup Marrowstone Island and a lot more of Camino Island.

 

Jim

[+WascoZooKeeper]

Jholly's route is close but still seems to have some discrepancies. I'm fooling around with some alternative routes that will provide the right coverage.

 

If it matters I used a 4 mile radius on the PQ. Wider and it will start to pickup Marrowstone Island and a lot more of Camino Island.

 

Jim

I'm trying to do a route with a 2-mile radius that zig-zags more without doubling back on itself. However, when I try to save it frequently and then make more modifications to tweak it, it seems to lose some of the earlier modifications.

[+Hynr]

Results by a cacher I know in another forum:

 

194 (with 3.11 mile band); with 5 mile band I get 244

 

A bit more investigation:

I loaded a GPX route file back to my computer and reversed it; then loaded both files back in (to make sure they would be identical.

 

My uploaded version of the original route (50 nodes)

http://www.geocaching.com/my/userrouteedit...41-5eb735197db8

yields 194 and 244 (ie same numbers as before)

 

With the reversed route (also 50 nodes):

http://www.geocaching.com/my/userrouteedit...9d-d410a9d99625

I get: 240 with 3.11 mile band and 294 with 5.03 mile band

 

Seems like the PQ routine is "running out of steam" as it progresses and when that happens in a cache-dense area (here it is in Anacortes which I know to be fairly dense) it has a greater impact than when it happens in a sparser area.

 

There is definitely a bug in the routine if it returns different results for the same route compared to the route in reverse.

[+Hynr]

Raine seems to think it has something to do with the route not following an actual road and going off into the water.

You are seriously scaring me!

Please tell me you are kidding.

[+Allanon]

Seems like the PQ routine is "running out of steam" as it progresses and when that happens in a cache-dense area (here it is in Anacortes which I know to be fairly dense) it has a greater impact than when it happens in a sparser area.

 

There is definitely a bug in the routine if it returns different results for the same route compared to the route in reverse.

I'm pretty sure this is the same conclusion that they came up with right after the recent CAaR changes were made.

 

Was it supposed to have been fixed? I hadn't heard that...

[+Hynr]

That was a month ago:

http://forums.Groundspeak.com/GC/index.php?showtopic=222221

No feedback was provided in that thread.

I guess we just assume Raine is "still working on it".

 

Another datapoint: if I combine the two routes to go down and back the islands along the same route with slightly different start and end points, (note that the CAaR tool simplifies this route to 50 nodes), upload these as a kml file, then I get 249 caches returning with 3.11 miles wide band, and 301 caches with 5.03 miles.

 

If I start at the southern end, route up to Anacortes and back to the starting point, I get 250 and 302, respectively.

 

Perhaps a work-around is to always run your routes to the destination and then back again?

[+Don_J]

I've made my original route public, too -- it's named just "Whidbey Island". Creating a PQ on that route with a distance of 5 miles on either side returns a total of 101 caches, which is what I've been getting in my weekly PQ since 6/26. Others can see if they get the same result.

 

I just tried it and it returned 101 caches.

It seems that the results can be duplicated. 5.1 mile range, 500 caches, no filters.

 

XP3, Firefox 3.5.2, with the popular Greasmonky scripts running.

[OpinioNate]

Interesting that the route delivers different results forward and backward.

 

At this point we've exhausted any casual attempts on Raine's part to identify a source for the problem. Since this isn't a "drop everything" issue he'll have to continue focusing on his scheduled tasks for now but I'll log the bug and a dev will investigate in more depth in the future. If you have any other information you think will help please continue to post it.

Edited August 5, 2009 by OpinioNate

[+mcrt]

I know I am hoping to get this fixed too. I just did a caches along a route (created on Google Earth) from Fairbanks to North Pole. No filters applied.

 

From the Fairbanks airport there are about 100 caches in a 5 mile radius, but the caches along a route returns 28 caches on the 17 mile route from Fairbanks to North Pole showing six miles on either side.

 

Argghh.

[+Hynr]

Wow. That's the most dramatic bug I have seen. It seems to have nothing to do with forward/backward because reversing the route makes no difference.

[OpinioNate]

Last week our dev David made a partial fix to CAAR that has had a dramatic effect on the caches returned by user routes.

 

If any of you are still following this please experiment with your results and let us know how effective they are. We will continue to work on improving the accuracy of CAAR in the meantime. Thanks.

 

Edit: For instance, mcrt's route from Fairbanks to the North Pole now returns a full 250 caches.

Edited September 9, 2009 by OpinioNate

[+sTeamTraen]

Does it make a difference which values I choose for the width, /a/ when I create the route, and /b/ when I create the PQ? What's the difference between the two? Would it be sensible for the default value proposed for the PQ to be the value which I gave when creating the route?

[+WascoZooKeeper]

The results on my query look much better. I still had 30 or so caches that I had a record of from PQs earlier this year that did not appear in the current results.

 

Of these, about 6 or 8 were on the fringes of the area covered by my older query. Since I had created a new query in the course of reporting this problem, it's not a surprise that there might be a few caches picked up by my old PQ that were not picked up by the new one. So these aren't really a problem.

 

There are about 24 more, though, that are in the area of my current PQ, that still aren't getting picked up. All except one of these are in "temporarily disabled" status. Since I'm not excluding "temporarily disabled" from my PQ, I should still be getting those -- is there something in the CAAR process that is suppressing disabled caches from the result even if I've asked for them?

 

And the one exception in the previous paragraph is Earthcache GC1E057 -- it's active, and it's within my PQ coverage area, but it wasn't returned by the PQ.

 

All in all, it's MUCH better. I'd still be interested in the remaining issues, though. And, without revealing corporate secrets, are you able to share any of what was discovered that was causing the problems?

[+Hynr]

Does it make a difference which values I choose for the width, /a/ when I create the route, and /b/ when I create the PQ? What's the difference between the two? Would it be sensible for the default value proposed for the PQ to be the value which I gave when creating the route?

My experience is that it does not matter what width you have on the screen when you create the route. That feature is there to help you identify where you need to detour sections of the route so as to get what you want for a particular width.

[+Hynr]

One quick test with data from during the week suggests a significant improvement. I'll run a battery of tests later this weekend.

[+Hynr]

Downloaded fresh data with a circular PQ (I haven’t found, Is Active); then used route tool to create short route within that; exported gpx of the route and used GSAK to filter so as to be identical to the PQ and the total number of caches came out exactly the same.

 

A test that I discussed in another thread:

As specific example: I have this public route:

http://www.geocaching.com/my/userrouteedit...95-2285789c5e66

Which is entirely in my "home" territory (i.e. I have all the data for this in my up-to-date offline database).

 

So if I run a PQ with that route, for "Is active", "I havn't Found", including all cache types except Wherigo, I get the following results, where "Actual" is the exact same filter applied to my up-to-date home database:

PQ, Actual, DatePlaced range

378 400 1/1/2000 to 1/1/2007

432 479 1/1/2007 to 1/1/2008

333 385 1/1/2008 to 7/1/2008

249 287 7/1/2008 to 1/1/2009

The discrepancies are, respectively, 22, 47, 52, and 38 caches, corresponding to 5.5%, 9.8%, 13.5%, and 13.2%.

Repeating the analysis (note I do not have exactly up-to-date data since the dataset is accumulated over 3 days during the last week)

PQ, Actual, DatePlaced range

368 375 1/1/2000 to 1/1/2007

427 433 1/1/2007 to 1/1/2008

345 350 1/1/2008 to 7/1/2008

266 268 7/1/2008 to 1/1/2009

Discrepancies of 7, 6, 5, 2 (1.9, 1.4, 1.4, 0.7 percent) are most likely due to attrition rate of caches over 3-5 days since I got the data.

 

Also reported in another thread:

When I generate a PQ from this public route:

http://www.geocaching.com/my/userrouteedit...de-49a715c660bd

and set the max number of caches to 500 while changing only the distance from the route as follows, I get the following results:

1 mile 306 caches

2 miles 161 caches

3 miles 169 caches

4 miles: 174 caches

Shouldn’t the last three returns be more than the first?

It is no longer possible to type in exactly 1, 2, 3 or 4 miles; with the closest alternative I get: 0.99 miles 500 caches

Clearly this test won’t work now.

Restricting the search to only Multi-caches:

0.99 miles 35 caches

1.99 miles 59 caches

2.98 miles 68 caches

Looks like this is now behaving correctly.

 

Running these tests is very slow due to sluggish website; I’ll do more testing later.

[+Lil Devil]

Wow thanks for that analysis, Hynr. Now I know I can use route queries for my upcoming trip and know I won't be missing anything.

[+fizzymagic]

Great analysis, Hynr. I would be interested to hear what the bug was, but now that it's fixed, I guess it doesn't matter except for curiosity.

[OpinioNate]

Great analysis, Hynr. I would be interested to hear what the bug was, but now that it's fixed, I guess it doesn't matter except for curiosity.

 

I will quote here what our dev David had to say about this fix:

 

When a cache is determined to be within the specified range, we add it to the "approved" caches list, remove the cache from the list of all caches (so we don't have to calculate it's distance again against other segments), and decrease the loop count to match the new length of the master caches list. This creates an issue because say cache of index 4 was approved, and then it was removed from the master cache list. All caches within that list that are above index 4 just slid down in index by 1, all while the index of our loop stayed the same. Next when we increased the index in the for-loop on the next iteration to 5, we skipped over the cache that is now indexed at 4.

 

To resolve this issue, when the loop count is decremented, I've added one more line to decrement the index of the-for loop as well.

 

Thanks to Hynr for taking the time to recreate some of your original tests. We are still only about 90% satisfied with the rate of return on CAAR, but for now we are going to let the edge cases go and focus on other things. This will get another look at some point.

 

Edit: flow

Edited September 14, 2009 by OpinioNate

[+WascoZooKeeper]

Thanks to OpinioNate and David for fine work on this! Sounds pretty consistent with what we observed, since it looks like for almost every cache that was accepted, one would be skipped over.

 

Thanks to the others (Hynr, et al.) who also provided test cases and their own analysis.

 

Now I just have to get back out to Whidbey so I can put this to use. Unfortunately, school is going to get in the way this term.

[+WascoZooKeeper]

This seems to be acting up again. The exact same query that was fine for the past few weeks is now missing some caches:

 

Code,Lon,Lat

GC1MEH7,-122.461,48.0252

GC1MA3T,-122.545883,47.967367

GCKT61,-122.409933,48.015

GCQK2C,-122.490783,48.12125

GCF86,-122.491583,48.12325

GC1MQCK,-122.444717,47.939233

GCW843,-122.37335,47.99935

GC1NT4Q,-122.401667,47.915

GCKX2E,-122.382033,47.9115

GC1MG9H,-122.37595,47.913517

GC1N07T,-122.735717,48.2212

GC1XECV,-122.67425,48.4301

GCKBJK,-122.673467,48.43275

GCP10M,-122.613183,48.460883

GCQF6Z,-122.6221,48.470283

GC1W5YQ,-122.65235,48.46745

GCK0RM,-122.585983,48.480983

GC19KK7,-122.66405,48.483083

GC1VCTF,-122.613,48.5057

GC1D19X,-122.658083,48.502667

GCRPZF,-122.67,48.50135

GC1VB2K,-122.627167,48.507583

GC1BQKK,-122.678267,48.505

GC1Z008,-122.638983,48.510983

GCZ1QF,-122.632767,48.51445

GCRG5B,-122.623833,48.518

GCTZR7,-122.624167,48.523333

 

I spot-checked a few and they were still active; it's possible that there may be some in this list that have actually been archived, though, since I didn't check them all. These are about 10% of the caches that the query should be returning.

Edited October 10, 2009 by WascoZooKeeper

[+WascoZooKeeper]

Same number of caches was missed again today; I spot-checked a few and they were missed both last week and this week, so I'm guessing it's the same ones being missed each time.

[+Hynr]

WascoZooKeeper, I meant to check into this last week but am having the same problem as you (school is back in session). Could you again post the link to the route you are using (make it public) and how you are using it (PQ settings). I just want to get the exact thing you are using rather than make assumptions. I'll try to replicate.

 

Since you have been able to isolate the discrepancy, are you able to observe some pattern in relation to your route when you plot these on the map (e.g. is it all on the edge?).

[+WascoZooKeeper]

WascoZooKeeper, I meant to check into this last week but am having the same problem as you (school is back in session). Could you again post the link to the route you are using (make it public) and how you are using it (PQ settings). I just want to get the exact thing you are using rather than make assumptions. I'll try to replicate.

 

Since you have been able to isolate the discrepancy, are you able to observe some pattern in relation to your route when you plot these on the map (e.g. is it all on the edge?).

Hi, Hynr,

 

The route is already public -- it's called "Whidbey Island" and has keywords "Whidbey" and "Fidalgo". The query settings are 500 caches, 5.1 miles, any type, any size -- nothing else is set.

 

The one on Camano might be an outlier, but I think the others definitely should be included -- in any event, they were picked up by the same query just a couple weeks ago!

 

[+LoveGPS]

Another problem (or is it related?) with CAAR is that the preview returns more caches than the actual PQ does. In my case, the preview shows 424 caches, the PQ has 391. If the TPTB are interested, I can point them to my CAAR PQ for them to replicate.