Jump to content

Caches Along a Route Issue


mdplayers

Recommended Posts

Actually, I'm re-opening this thread as it turns out that this bug is not in fact related to the new CAaR changes. Rather, the attention that the new changes have put on CAaR appears to have revealed a pre-standing issue!

 

After initial investigation, it looks like filtering is only occurring *after* the cache limit is reached in a CAaR PQ. It appears that the system starts looking at all caches around your starting point, goes until it reaches the limit you have set (say, 500), and only then starts trimming down the results to meet your criteria. It then stops rather than checking to see if you are below the cap and moving on. The end result is that, in a cache-dense area, you might see all of your results clustered around the route start yet only see a small number of caches being returned.

 

There is still investigation to be done before this can be confirmed, and it will likely take a little while to fix as it likely involves some significant core changes to the PQ generator, so for the time being it's best to keep your search distance from route low in cache dense areas (to avoid bumping into the cap) or using other methods (such as GSAK filtering on a database you have fully populated) for filtering along a route if you are running into this issue.

Link to comment
Actually, I'm re-opening this thread as it turns out that this bug is not in fact related to the new CAaR changes. Rather, the attention that the new changes have put on CAaR appears to have revealed a pre-standing issue!

 

After initial investigation, it looks like filtering is only occurring *after* the cache limit is reached in a CAaR PQ.

 

So just to make sure I understand, this has been the behavior of the Route PQs "forever"?

 

(Edited to add: Not sure this makes sense. How could you get to 500 caches returned if you had any real filtering?...but I'll wait for the report of the investigation results.)

Edited by beejay&esskay
Link to comment

 

So just to make sure I understand, this has been the behavior of the Route PQs "forever"?

 

I don't know if it's been that way "forever". However, it is not something that was caused by the latest site updates.

 

 

(Edited to add: Not sure this makes sense. How could you get to 500 caches returned if you had any real filtering?...but I'll wait for the report of the investigation results.)

 

Please re-read my post. The filtering appears to be taking place *after* the system has pulled in the caches and reached the cap.

Link to comment

As the developer of CAaR I'll give you some insight of how it works.

 

I take the route and convert it into a bunch of small covering rectangles so that I can limit my queries against the database.

 

Once that happens I then determine which caches are of a right angle in distance from the route segment it falls into.

 

Taking those caches I then run any filtering that needs to be done against the list.

 

This last step is where this issue seems to be occurring. I'm looking in to it now.

 

-Raine

Link to comment

I agree with Moun10Bike's analysis. I changed the range (search distance from the route) from 4 miles to .5 miles and found that I was given caches all along the route, not just clustered around my starting point.

 

Also, I was limiting the PQ to return only traditional and virtual caches and then limiting the size of the container to Regular and Large. I imagine there are many Small and Micro containers in that area, causing the number of caches returned by the PQ to be very low (20 returned out of 100 requested) if the theory holds.

Link to comment

As the developer of CAaR I'll give you some insight of how it works.

 

I take the route and convert it into a bunch of small covering rectangles so that I can limit my queries against the database.

 

Once that happens I then determine which caches are of a right angle in distance from the route segment it falls into.

 

Taking those caches I then run any filtering that needs to be done against the list.

 

This last step is where this issue seems to be occurring. I'm looking in to it now.

 

-Raine

 

I just tried the new CAAR and am seeing the same problem. I created a 96 mile route out in the desert north of Los Angeles. When I previewed the PQ it only had 33 caches. I do have a little filtering, but it should have removed very few caches. I was looking for active caches that I have not found (I only have a few finds out there), and all cache types. So then I previewed it Google Maps and saw that I just had a 5 mile radius from the starting point. I am very familiar with how large route PQs have operated in the past, and this is definitely NOT the same.

 

I just tried it again with absolutely no filters at all, and got 37 caches all clustered around the starting point.

 

Jim - K6CCC

Link to comment

I had this problem earlier today too: all caches clustered around the large city at the start of my route, none elsewhere along the route.

 

Reran the query starting at the small city at the end of the route, and decreasing the search radius from 4 to .5 miles. Worked fine that time.

 

~erik~

Link to comment
I had this problem earlier today too: all caches clustered around the large city at the start of my route, none elsewhere along the route.

 

Reran the query starting at the small city at the end of the route, and decreasing the search radius from 4 to .5 miles. Worked fine that time.

 

~erik~

 

How would you feel about rerunning the PQ with just changing the search distance, leaving the starting point at the big city? I'm guessing that is all you need to do.

Link to comment

As the developer of CAaR I'll give you some insight of how it works.

 

I take the route and convert it into a bunch of small covering rectangles so that I can limit my queries against the database.

 

Once that happens I then determine which caches are of a right angle in distance from the route segment it falls into.

 

Taking those caches I then run any filtering that needs to be done against the list.

 

This last step is where this issue seems to be occurring. I'm looking in to it now.

 

-Raine

I am glad that this is being looked at. I had converted all my data retrieval PQs to route PQs only to find that nearly all of them left out caches. If my hunch is correct then you would not find the problem in the spot you are looking (the last step).

 

My sense is that the array (list) that accumulates the initial set during your first step is dimensioned too small. The reason I think so is the following observation: I have a route through an urban area where there would be more than 2000 caches that would meet the geographic criteria (much more if that list includes the archived caches in the database). Then I applied "date placed", "is active" and "I havn't found" criteria to effectively pull about 1600 caches with 4 PQs, each set up to return between 300 and 500 caches. The result was missing a significant, although small, number of caches. It seemed to me that perhaps your array was dimensioned to about 2000 so that about 10% would be missing from the initial list and thus also missing from each PQ but that the problem would be worse for PQs that pull more caches which are later in the sort order of the database (which is the case).

 

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%.

 

I hope this helps track the problem down. Thanks for taking a look at it.

 

Also, I have to say I am immensely impressed with the way the tool works now. Truely awesome. I especially like the way the band shows up on the google map. I look forward to someday seeing that band in the PQ preview facility.

Link to comment

I just ran into this problem this weekend.

Is there a workaround for this? I was thinking that if you didn't have any filters and your results were <500, you'd be good, but k6ccc's post makes me think that isn't the case.

Link to comment

I ran into this issue as well recently so I'm glad to find this thread. I was running a route PQ for my upcoming trip to Yosemite and compared the results to the caches near the route. And I found caches within 0.5 miles of the route skipped but caches 3 miles included elsewhere (near the beginning of the route). I thought I saw something happen like this a couple months ago, too. I had a limit of 4 miles and 200 caches.

 

I couldn't follow everything in this thread, but to me, if the limit of caches is hit, the most distant caches from the route should be tossed. I guess that is what is not working. I'll cut back my distance and see how that works.

Link to comment

As the developer of CAaR I'll give you some insight of how it works.

 

I take the route and convert it into a bunch of small covering rectangles so that I can limit my queries against the database.

 

Once that happens I then determine which caches are of a right angle in distance from the route segment it falls into.

 

Taking those caches I then run any filtering that needs to be done against the list.

 

This last step is where this issue seems to be occurring. I'm looking in to it now.

 

-Raine

 

First of all Raine, thanks for all the effort to make a better CAaR. The intent of the new version is really great. Just wish it worked right. From various messages, it has been stated that the process that generates the PQ has not changed, only the way that the route is created. I beg to differ. Warning, this will get a bit long...

 

I took an existing about 90 mile route generally along Interstate 10 in the Southern California desert that I created about a month ago using the Google Earth method. I created a PQ using that route about a month ago. This evening I used the new CAaR method to create a new route that exactly matches the previous route (or at least really darn close - the only difference is at the very east end where it is off-road). I then created a second PQ that uses the new route with exactly the same parameters. I show a couple of graphics here.

 

The first is the parameters of one of the PQs (they are both the same).

PQ%20submittal.jpg

 

Here is the result of the PQ that used the old method of generating the route:

PQ%20result%20old.jpg

 

And here is the result of the PQ that used the new method of generating the route:

PQ%20result%20new.jpg

 

You'll notice that they look quite different.

 

Shortly after the new route creation method was introduced, I created a route in the Southern California high desert that radically did not work (I mentioned it in my previous post on this subject). Even with absolutely no filters of any kind, the result was quite different than expected and the way it would have been with the old route creation method using Google Earth.

 

There is definitely something amiss with the PQ along a route using the new route generation method.

 

 

Jim - K6CCC

Link to comment

I guess I should point out that the two results shown in my previous method were both generated this evening - less than 1 minute apart.

 

Jim - K6CCC

 

Jim,

 

When you create the route try selecting 1/2 mile around the route. Then rerun the query and set it to return caches within 1/2 mile of the route. See if that returns caches along the whole route.

Link to comment

 

When you create the route try selecting 1/2 mile around the route. Then rerun the query and set it to return caches within 1/2 mile of the route. See if that returns caches along the whole route.

 

Yes, it does behave differently when the width is narrower. However that makes the query somewhat useless. And the real point of the post is that the results are behaving VERY differently depending on how the route was created. Raine has stated that the PQ creation is the same, only the route creation method is different. This is clearly not the case. Something changed. May not have been intended, but something is different.

 

Jim - K6CCC

Link to comment

What is the current status of the new Caching Route Feature? Am I doing something wrong since I only get a few caches along a route when I know there are plenty or is this feature still being worked on? The last attempt was yesterday. Thanks

Edited by Leftygator
Link to comment

What is the current status of the new Caching Route Feature? Am I doing something wrong since I only get a few caches along a route when I know there are plenty or is this feature still being worked on? The last attempt was yesterday. Thanks

 

Am I the only one having trouble with this new feature? I can generate a route (BTW, great method) but am unable to get many caches along the route unless I select .5 or so. If I select the larger mileage limits I get only a few caches. What am I doing wrong?

Thanks

Link to comment

Am I the only one having trouble with this new feature? I can generate a route (BTW, great method) but am unable to get many caches along the route unless I select .5 or so. If I select the larger mileage limits I get only a few caches. What am I doing wrong?

Thanks

 

Nope, not just you. It's a bug that we all are seeing. Read this whole thread and you will see some of the history. I agree that the new route generation is great, the bug needs to get fixed. The workaround is to use a short distance off-route, but that pretty much makes it useless.

 

Jim - K6CCC

Link to comment

Am I the only one having trouble with this new feature? I can generate a route (BTW, great method) but am unable to get many caches along the route unless I select .5 or so. If I select the larger mileage limits I get only a few caches. What am I doing wrong?

Thanks

 

Nope, not just you. It's a bug that we all are seeing. Read this whole thread and you will see some of the history. I agree that the new route generation is great, the bug needs to get fixed. The workaround is to use a short distance off-route, but that pretty much makes it useless.

 

Jim - K6CCC

Link to comment

Thank you Jim. I read all the post but since no one has recently been talking about it I thought it was just me. You are right, this is such an improvement over the other method as the routes allow change so easily but without proper results it is of little value. Maybe this will bring it to light again. Thanks

Link to comment

I just did a PQ for a trip I'm taking next week (first PQ). I set it for Earth Caches to try it out and see what was available along the route within 1/2 of the route. It returned everything as far as cache type so I have a bunch to sift through to find EC's. Put it in Google Earth and I have to say it was pretty impressive.

Link to comment

There seem to be several different problems. The problem I reported above is still an issue. The issue raised by k6ccc is one that I can also replicate but this seems to be due to the fact that the route created by the new tool has too many nodes.

If I create a route with the new tool from east of Reno to west of Salt Lake City (<500 miles, 4 mile width), and use that route as a basis for a PQ I only get about 180 caches along the first half of the route (caches from the start of the route to somewhere west of Elko, NV). When I run the route the reverse I get the same effect, except that 214 caches are returned and these start at the eastern end and stop near Elko, NV. When I have the webpage give me the gpx file of either of these routes, I find that both routes consist of more than 1000 nodes.

When I upload that gpx file back to the CAaR routes (which "simplifies" the data to have about 50 nodes) and use that for a PQ with exactly the same selections as before, I get exactly 400 caches along the route covering the entire distance. I do not know if that is the correct number of caches that should be returned, but it seems reasonably close.

Link to comment

This just happened to me. I generated a route from Malone, NY to Old Forge, NY with a 5 mile radius filtered for caches I have not found and are active with a 500 cache limit.

 

This is what I get:

 

3628154397_842687c79f.jpg

 

I then did a PQ with just caches around Old Forge, which as I suspected turned up caches that should have been along the route.

 

Then I came here and found this topic.

 

So, almost a month after being noticed and no update from GS? I guess I shouldn't be surprised.

Link to comment

I created a route between Ocean Springs, MS to Lafayette, LA starting first with 1/2 mile (returned 87 caches), then 1 mile (returned 98 caches), then 1 1/2 miles (returned 125 caches) and finally 2 miles from the route (returned 102 caches) of unfound caches by me. The cache return from 1/2 mile to 1 1/5 seem reasonably correct but problems arise with the selection of 2 miles or greater with the cache return reduction and nothing returned on the final 60 miles of the route. The higher mileage selected after 1 1/2 miles produces a much lower return with the next higher mileage selection. Other routes might produce different results

 

I must say that this feature is a great addition to the Geocache page and is greatly appreciated. It appears that most of the work has been done for this great feature and it might be a minor fix to correct this problem.

 

Thank you.

Edited by Leftygator
Link to comment

Ok, now it's my turn. I just ran my first route with the new software and I am having the same problem of all the caches showing up at the beginning of the route and then not listing any others. I was trying to create a route from Sacramento to Stinson Beach. I had my distance set at 2.5 miles. When I set it for 0.5 miles, it gets me to Cordelia, CA, with 320 caches.

 

Just posting to keep this topic active.

 

Thanks, ao318

Link to comment
Ok, now it's my turn. I just ran my first route with the new software and I am having the same problem of all the caches showing up at the beginning of the route and then not listing any others. I was trying to create a route from Sacramento to Stinson Beach. I had my distance set at 2.5 miles. When I set it for 0.5 miles, it gets me to Cordelia, CA, with 320 caches.

 

Just posting to keep this topic active.

 

Thanks, ao318

 

I tried looking for the PQ you created and don't see it. When I set up your route with the distance set to 2.5 miles, I quickly reach the 500 cache maximum due to the cache density in the area, so I do in fact get all of the caches clustered around the start as expected. However, when I take things down to 0.5 mile, I get 199 caches that take me all of the way along the route.

 

Could you try to recreate what you encountered and leave the PQ in your list so that I can take a look at it and see what might be causing the problems you are seeing?

 

Thanks!

Link to comment
Could you try to recreate what you encountered and leave the PQ in your list so that I can take a look at it and see what might be causing the problems you are seeing?

 

Sorry for replying so late but I have been stuck at work at the fire department and this is the first time since Saturday looking at the forums.

 

Ok,

 

Here is what I am doing.

1) Clicking on, “Create a route” from my profile page.

2) I type in 95827 in the “From” window and Stinson Beach, CA in the “To” Window.

3) Click on “search”.

4) I then drag my route from Interstate 80, going through the East Bay, to Highway 37, going through Marin County.

5) I then click on “Save route changes”.

6) It then opens the “Create/Edit Route” page.

7) I then name it and describe it and hit save.

8) It then opens a new window, “Find user routes near your trip”, and I select “Create Pocket Query” for the new route.

9) I then edit my information for the route settings for the following:

- Search 0.5 mi

- Show me – 500 caches

- Cache Type – Traditional

- Container – any

- Filter options - I haven’t Found, Is Active, and I don’t own

- Terrain – Less than or equal to – 2.5

- Difficulty – Less than or equal to – 2.5

- Placed – Anytime

- Attributes – Nothing selected

- Output – Account’s email address

- Format - .gpx

- Compress – Checked

10) I then select submit and then preview my PQ

 

In reviewing my PQ, it tells me that I have 383 records. The first record is Erin's Roundabout by Siddartha (GCC00B), which is in Davis, CA not Sacramento, and the last is Cache to Eagle #12 by mousewiz (GCMZR9), which is in Marin but not near Stinson.

 

I also created a route with the same parameters except the starting point was Davis, CA. I previewed the PQ for it and it listed 314 records and it also started at Erin's Roundabout by Siddartha (GCC00B) and ended at the cache Cache to Eagle #12 by mousewiz (GCMZR9).

 

I am using the current version of Firefox, running on windows XP. Email me via my profile if you need anymore info.

 

I have made these 2 routes public for you to see. One is called, "Davis Stinson" and the other is "Sac to Stinson".

 

Edited to add:

I have also left the PQ's, named the same, in my list. I had deleted the old Routes and PQ's because they were not getting me what I wanted prior to this forum post. I do get different numbers when I have different distances in the miles section.

Edited by ao318
Link to comment

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?

 

To ask the obvious, did the distance from the route possibly change with each route? Otherwise I agree.

 

Jim

Link to comment

It appears to me that a change has been made in the CAaR issue. I now notice a sliding bar to select the miles along with a sliding bar for the number of caches on each side of the route. I did a PQ and it appears to me that the issue has been solved. If true I want to thank those responsible for the fix and a great feature.

 

Would someone else check for results.

Link to comment

The website software has changed; so it is time to look at what is still problematic.

 

The issue I reported in post #11 above is changed (returned numbers a are a bit higher, but there still seem to be discrepancies.

 

The problem with caches only being returned for the first part of a route seems to have been fixed.

Link to comment

For my recent vacation, I ran a PQ to plan what caches to stop at on the way home. Then I re-ran the same query a week or so later (the day or two before driving the route) and this query produced results with at least two active caches missing that were in the original results. I had just assumed they had been disabled or archived, but when I looked (after getting home) I saw that they hadn't.

 

This kind of proved my theory that the query doesn't always return all of the results it should. I drive this same route once a year yet each time I run the query I get caches I didn't get before yet had been placed long before the first year I made this trip.

Link to comment

This particular issue seems to have been fixed. It's no longer possible to set the "search radius" to exactly 1, 2, 3 or 4 (so I cannot repeat the exact same query); but with 0.99 miles I now get 446 caches and with 1.99miles I get 500.

 

If I limit the queries to multi caches I get the following results for search radius vs caches returned:

0.99 miles, 25 caches

1.99 miles, 44 caches

2.98 miles, 50 caches

3.98 miles, 58 caches

5.03 miles, 62 caches

So widening the search radius does now work as one would expect.

 

I want to especially express my gratitude for giving us a much wider choice of search radius values.

 

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?

Link to comment

This particular issue seems to have been fixed. It's no longer possible to set the "search radius" to exactly 1, 2, 3 or 4 (so I cannot repeat the exact same query); but with 0.99 miles I now get 446 caches and with 1.99miles I get 500.

 

If I limit the queries to multi caches I get the following results for search radius vs caches returned:

0.99 miles, 25 caches

1.99 miles, 44 caches

2.98 miles, 50 caches

3.98 miles, 58 caches

5.03 miles, 62 caches

So widening the search radius does now work as one would expect.

 

I want to especially express my gratitude for giving us a much wider choice of search radius values.

 

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?

 

I'm glad that someone now agrees with my post #34. What a great feature this is, much better than the google one.

 

If anyone sees a bug in it, now is the time to speak up.

 

Thank You Geocaching.

Link to comment

I re-analyzed this particular issue:

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 (3 mile search radius as before), 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%.

I ran 7 PQs earlier this week (Jun 22 and 23) to give me all the data that would fall into this 3-mile band (that amounts to 1729 caches placed between Jan 2000 and last week). This time I included all cache types. Only the dates-placed where changed between the queries. Today the results are as follows:

PQ, Actual, DatePlaced range

368 383 1/1/2000 to 1/1/2007

432 458 1/1/2007 to 1/1/2008

352 367 1/1/2008 to 7/1/2008

248 274 7/1/2008 to 1/1/2009

The discrepancies are 15, 26, 15, 26 corresponding to 3.9%, 5.7%, 4.1%, and 9.5%, respectively.

Certainly an improvement, but this particular problem persists.

Link to comment

To test for the issues reported by a number of individuals in this post that the route PQ seemed to stop returning caches prematurely along the length of a route, I reran my analysis in post 26 above:

If I create a route with the new tool from east of Reno to west of Salt Lake City (<500 miles, 4 mile width), and use that route as a basis for a PQ I only get about 180 caches along the first half of the route (caches from the start of the route to somewhere west of Elko, NV). When I run the route the reverse I get the same effect, except that 214 caches are returned and these start at the eastern end and stop near Elko, NV.

Results from running the routes west to east and east to west:

Reno to SLC; Search Radius 3.98 mi: returns 395 caches

SLC to Reno; same search radius: returns 395 caches

In both cases caches are returned all the way to the end of the route. So this problem has been solved.

 

However, I pulled all the cache data using traditional circular PQs and constraining by state, I was able to get a complete data set that covers the area completely with 3 PQs. Filtering (GPSbabel via GSAK) on the SLC to Reno route (which I pulled as gpx file from the CAaR tool) resulted in 403 caches.

 

That is a 2% discrepancy. A discrepancy this small could probably be explained by differences in filtering algorithm.

Link to comment

Thank you for posting your findings, Hynr. I'm seeing the same things here in local routes and have mapped the differences seen between the results from CAaR and a polyline filter in GSAK. Hopefully the mapped locations of these variances (which are all falling within the specified bounds of the route) will help the devs track down the source of the issue.

Link to comment

I never saw the "clustered at the beginning problem" (possibly because my other conditions did not eliminate many caches) but I have just noticed an issue with some (not all) caches being left off near the end of the route.

 

If any developer wants an example, my "From Maine Day 2" PQ (current limit is 3.7km but I may be making changes to try to get the end caches) follows I-95 (and returns 453 caches) but does not include 3 caches that are essentially on that interstate. (GC172J1, GC12RJ4, GC11QB0)

Link to comment
Guest
This topic is now closed to further replies.
×
×
  • Create New...