BUG REPORT: Sort by Favorites

[+ATXTracker]

Summary: When sorting a pocket query by the number of favorite points, the caches in the sorted list are not the same set of caches as in the pocket query.

 

Steps to recreate the bug:

 

1) I have a pocket query with 500 total records. By default they appear to be sorted by distance, with the closest caches listed first. The closest cache (first in the list) is 0.62km N. If I click on the last page of the results (page 25), the farthest cache is 8.2km N.

2) Next I go back to the first page of the query and click the ribbon icon in the header above the favorites column.

3) The list appears to be sorted descending by favorites such that the caches with the most favorites are listed first.

4) However, the caches listed are now caches that originally didn't appear in the pocket query. There are many caches that show up in the list which are over 100km away. I would expect the sorted list to only contain those caches in the pocket query normally.

 

Please confirm if this is a bug and if it can be fixed. Finding high-quality caches in a particular area for me is the best advantages of having favorites.

 

Thanks

[+The A-Team]

Myself and others have reported this behaviour before, and we've been told this is the way the system has been designed and isn't a bug. It certainly isn't the way users would expect it to behave, but it's the way the developers have coded it.

 

Edit to add: Also, to clarify, you'll only see this behaviour if you've maxed out your PQ. If the PQ is returning fewer caches than the limit, it will sort as you'd expect.

Edited May 31, 2013 by The A-Team

[+ATXTracker]

Hmmm. This may be an expected behavior base on the way it was coded, but I'd argue it is not the expected behavior for the users. The bit about maxing out the PQ only makes it sound like more of a bug. If was intentionally designed that way, why would that threshold trigger a different behavior?

 

I stick with my request to have this fixed/changed.

 

Does anyone have a creative work-around? I'm trying to find high-quality (favorited) caches in an area. Being able to reliably query by favorite points seems like an obvious usage for the feature. If we are paying PQs and favorite points, I'd think this is an important feature.

[+Isonzo Karst]

Does anyone have a creative work-around? I'm trying to find high-quality (favorited) caches in an area.

 

Sure, go to Hide and Seek a cache page - enter coords or a GC Code of a cache to center your search ADD A DISTANCE.

 

This will limit the search to some number X of caches within that distance. Now sort on favorites, you won't lose the distance setting on this search.

 

Edit to add: Also, to clarify, you'll only see this behaviour if you've maxed out your PQ. If the PQ is returning fewer caches than the limit, it will sort as you'd expect

 

I just checked this statement, I'd say the "sort by favorites" misbehaves on any PQ preview, regardless of size.

 

I previewed a PQ for 50 caches closest to my home coords. This goes out about 3.3 miles.

When I click to sort on Favorites, I still have 50 caches - but it's not the same set of caches - now it's headed by the Orlando FL virtuals with high favorite counts over 40 miles away; it's now the top 50 most favorited caches in Florida.

Edited May 31, 2013 by Isonzo Karst

[+Cardinal Red]

Does anyone have a creative work-around? I'm trying to find high-quality (favorited) caches in an area.

 

]Sure, go to Hide and Seek a cache page - enter coords or a GC Code of a cache to center your search ADD A DISTANCE.

 

This will limit the search to some number X of caches within that distance. Now sort on favorites.

 

And you expected that this/most users would know that ADD A DISTANCE means adding:

&dist=?? or &dist=??.? (with ??.? representing miles in my case) to the end of the existing URL? That is a very useful tool, but I always have to explain it to my friends. They don't have a clue otherwise.

[+ATXTracker]

Does anyone have a creative work-around? I'm trying to find high-quality (favorited) caches in an area.

 

Sure, go to Hide and Seek a cache page - enter coords or a GC Code of a cache to center your search ADD A DISTANCE.

 

This will limit the search to some number X of caches within that distance. Now sort on favorites, you won't lose the distance setting on this search.

 

Can you walk me through this a little more. When I go to the hide and seek page, and enter a GC code and click the "GO" button next to the box, it takes me to that exact cache, not a list of caches near that cache. I don't see the "add a distance" option either. Sounds like I'm about to learn something really useful!

[+ATXTracker]

Can you walk me through this a little more. When I go to the hide and seek page, and enter a GC code and click the "GO" button next to the box, it takes me to that exact cache, not a list of caches near that cache. I don't see the "add a distance" option either. Sounds like I'm about to learn something really useful!

 

Nevermind, I think I got it. I don't think it works with a GC code, but I did get it to work with coordinates.

[+Cardinal Red]

Does anyone have a creative work-around? I'm trying to find high-quality (favorited) caches in an area.

 

Sure, go to Hide and Seek a cache page - enter coords or a GC Code of a cache to center your search ADD A DISTANCE.

 

This will limit the search to some number X of caches within that distance. Now sort on favorites, you won't lose the distance setting on this search.

 

Can you walk me through this a little more. When I go to the hide and seek page, and enter a GC code and click the "GO" button next to the box, it takes me to that exact cache, not a list of caches near that cache. I don't see the "add a distance" option either. Sounds like I'm about to learn something really useful!

 

When on the cache page of "that exact cache" click on the ...all nearby caches option. That will bring up the "list of caches near that cache" with "that exact cache" at the top of the list. Add the &dist=?? mileage limitation to end of that URL.

[+The A-Team]

Edit to add: Also, to clarify, you'll only see this behaviour if you've maxed out your PQ. If the PQ is returning fewer caches than the limit, it will sort as you'd expect

I just checked this statement, I'd say the "sort by favorites" misbehaves on any PQ preview, regardless of size.

 

I previewed a PQ for 50 caches closest to my home coords. This goes out about 3.3 miles.

When I click to sort on Favorites, I still have 50 caches - but it's not the same set of caches - now it's headed by the Orlando FL virtuals with high favorite counts over 40 miles away; it's now the top 50 most favorited caches in Florida.

It isn't a matter of how large the PQ is, but whether the PQ is reaching the specified maximum number of caches to return. For example, if your PQ is set to a maximum of 1000 caches, but the criteria of the PQ covers 2000 caches, you'll run into this wacky sorting behaviour. The sorting is based on that total of 2000 caches, which means you'll see caches in the sorted list that you wouldn't get when the PQ actually ran. However, if the same PQ only resulted in 900 caches, you wouldn't see a problem, because the sorting is using exactly the same caches as when the PQ runs.

 

In your test, you probably set it to return 50 caches, but left the distance to something that would mean the PQ would cover far more than 50 caches. When you sort the preview for that PQ, the sorting will be based on some superset of caches that fit the rest of the criteria, and the 50 caches you see for any particular sort will be the first 50 matching that sort order of that superset.

[+Don_J]

Does anyone have a creative work-around? I'm trying to find high-quality (favorited) caches in an area.

 

Sure, go to Hide and Seek a cache page - enter coords or a GC Code of a cache to center your search ADD A DISTANCE.

 

This will limit the search to some number X of caches within that distance. Now sort on favorites, you won't lose the distance setting on this search.

 

Edit to add: Also, to clarify, you'll only see this behaviour if you've maxed out your PQ. If the PQ is returning fewer caches than the limit, it will sort as you'd expect

 

I just checked this statement, I'd say the "sort by favorites" misbehaves on any PQ preview, regardless of size.

 

I previewed a PQ for 50 caches closest to my home coords. This goes out about 3.3 miles.

When I click to sort on Favorites, I still have 50 caches - but it's not the same set of caches - now it's headed by the Orlando FL virtuals with high favorite counts over 40 miles away; it's now the top 50 most favorited caches in Florida.

 

Thanks, it's always a good day when I learn something new.

[+Isonzo Karst]

It isn't a matter of how large the PQ is, but whether the PQ is reaching the specified maximum number of caches to return....

In your test, you probably set it to return 50 caches, but left the distance to something that would mean the PQ would cover far more than 50 caches. When you sort the preview for that PQ, the sorting will be based on some superset of caches that fit the rest of the criteria, and the 50 caches you see for any particular sort will be the first 50 matching that sort order of that superset.

 

Ah ha!! thanks for that, The A-Team

 

Re Add a distance, a picture is worth a 1000 words ;-) Image shows Lat Long search, but this works for any of the searches. You can modify the Radius, and that limitation will "stick" as you sort using any of the sortable columns

 

[AZcachemeister]

Hmmm. This may be an expected behavior base on the way it was coded, but I'd argue it is not the expected behavior for the users. The bit about maxing out the PQ only makes it sound like more of a bug. If was intentionally designed that way, why would that threshold trigger a different behavior?

 

I stick with my request to have this fixed/changed.

 

Does anyone have a creative work-around? I'm trying to find high-quality (favorited) caches in an area. Being able to reliably query by favorite points seems like an obvious usage for the feature. If we are paying PQs and favorite points, I'd think this is an important feature.

 

I agree, it should be fixed.

 

Why in the WWW would some developers code a behavior based on some behind-the-scenes detail that the user is probably not aware of?

 

Shouldn't quality coding make such details transparent rather than making the user think something is broken and give irrelevant results?

 

Chalk up another one for the Workaround Fairy.