+Valentijn77 Posted August 20, 2014 Share Posted August 20, 2014 Hi, As a User I would like to be able to search for caches with "more than X" favorite points. When I travel to a certain area, I am trying to find the nicest/best/most beautiful/etc caches there. The favorite points system is a decent way of selecting these caches. However, currently there's no easy way to create a search or pocket query based on this. Or even sort your search result based on favorite points. Adding "favorite points" as optional criteria in search and pocket query creation would be a good feature to have! Let me know your thoughts, Opper. Quote Link to comment
+Walts Hunting Posted August 20, 2014 Share Posted August 20, 2014 (edited) It is not likely the PQ system will ever change as they have moved on to API. However there are two ways Go,to,the hide and seek page and search the area you want. Click on the header of the favorite column and it will sort. Also if you click the magnifying glass in the preview box you get a list that you can sort by favorite. Project-GC.com will do,that under the cache stats header. Edited August 20, 2014 by Walts Hunting Quote Link to comment
+Isonzo Karst Posted August 20, 2014 Share Posted August 20, 2014 you can click on the Favorite points icon on any search page, and it will arrange the caches by number of favorite points. This may be more useful if you limit the radius of your search. To do that, go to Hide and Seek a cache http://www.geocaching.com/seek/ Enter some coords, and a search Radius. Now click the returns on the blue favorite icon to rank on favorites. here's a link for such a search, limited radius 25 miles from De Wering GC4DA1M http://www.geocaching.com/seek/nearest.aspx?t=m&lat_ns=1&lat_h=51&lat_mmss=33.039&long_ew=1&long_h=005&long_mmss=36.002&dist=25&submit8=Search&sortdir=desc&sort=fav Quote Link to comment
+Valentijn77 Posted August 20, 2014 Author Share Posted August 20, 2014 Ok, so sorting seems to be there. But I still think filtering is useful. Now I have a list of 500 caches, which I can sort, but there's no way to use the sorting in the map. So I 'm still looking at 500 caches on the map without knowing the popular ones. Quote Link to comment
+Walts Hunting Posted August 20, 2014 Share Posted August 20, 2014 Get GSAK. Load the PQ. Run the Favorites macro to fill the favorites field then filter for the top 10 percent and sent it to Basecamp. Easy. Quote Link to comment
+Valentijn77 Posted August 21, 2014 Author Share Posted August 21, 2014 (edited) Get GSAK. Load the PQ. Run the Favorites macro to fill the favorites field then filter for the top 10 percent and sent it to Basecamp. Easy. Thanks for the tip to GSAK. Still I'd like to see this in the geocaching.com site. Would be way easier than to install 3rd party tools and go exporting/importing list of caches. GSAK only works on Windows BTW. Just tried GSAK and it shows that the favorite field is not a primary field in the api. It's not included in the PQ export, so GSAK has to perform ONE THOUSAND api calls just to get the favorite field populated. I am not sure this is only caused by the PQ Export lacking the favorites field, or that the same problem occurs when perform queries against the API. EDIT: And it doesn't work correctly. It says there are only 2 caches with >100 points, where in reality there are 30+ caches. Edited August 21, 2014 by Opperpanter Quote Link to comment
+Walts Hunting Posted August 21, 2014 Share Posted August 21, 2014 That is true favorites are not contained in the api or pq. There are hundreds of requests for GC to do but most will not get implemented for various valid reasons. So turning to third party is the solution. They could be added to the apI at one point but don't ever expect them to be in the pq. Making changes to that is a big deal and the last time they did it created problems downstream Quote Link to comment
+Mudfrog Posted August 21, 2014 Share Posted August 21, 2014 That is true favorites are not contained in the api or pq. There are hundreds of requests for GC to do but most will not get implemented for various valid reasons. So turning to third party is the solution. They could be added to the apI at one point but don't ever expect them to be in the pq. Making changes to that is a big deal and the last time they did it created problems downstream I know i'm not a software programmer but this is something i don't undertand. What are the valid reasons? Favorite points are not a perfect solution but they do help many people pick out better caches. It makes no sense for gc.com to give us a FP system but then not allow us to use it as a filter in a pocket query. Quote Link to comment
+Corfman Clan Posted August 21, 2014 Share Posted August 21, 2014 That is true favorites are not contained in the api or pq. There are hundreds of requests for GC to do but most will not get implemented for various valid reasons. So turning to third party is the solution. They could be added to the apI at one point but don't ever expect them to be in the pq. Making changes to that is a big deal and the last time they did it created problems downstream The above is wrong. Favorites are not included in pocket query results but they are included in the API call for retrieving cache details Quote Link to comment
+Corfman Clan Posted August 21, 2014 Share Posted August 21, 2014 Just tried GSAK and it shows that the favorite field is not a primary field in the api. It's not included in the PQ export, so GSAK has to perform ONE THOUSAND api calls just to get the favorite field populated. I am not sure this is only caused by the PQ Export lacking the favorites field, or that the same problem occurs when perform queries against the API. EDIT: And it doesn't work correctly. It says there are only 2 caches with >100 points, where in reality there are 30+ caches. Actually, you can retrieve data for 30 caches in one API call, so you should be able to get all the favorite points for 1000 caches in 34 API calls. One is limited to 30 API calls per minute, so to update 1000 caches will take just over a minute to perform. Quote Link to comment
+Valentijn77 Posted August 21, 2014 Author Share Posted August 21, 2014 Just tried GSAK and it shows that the favorite field is not a primary field in the api. It's not included in the PQ export, so GSAK has to perform ONE THOUSAND api calls just to get the favorite field populated. I am not sure this is only caused by the PQ Export lacking the favorites field, or that the same problem occurs when perform queries against the API. EDIT: And it doesn't work correctly. It says there are only 2 caches with >100 points, where in reality there are 30+ caches. Actually, you can retrieve data for 30 caches in one API call, so you should be able to get all the favorite points for 1000 caches in 34 API calls. One is limited to 30 API calls per minute, so to update 1000 caches will take just over a minute to perform. Ok, in that case GSAK or the macro could be improved Quote Link to comment
+Walts Hunting Posted August 21, 2014 Share Posted August 21, 2014 You are looking at the wrong end of the pipeline. GS sets the limits for the API and GSAK has to work within the constraints given. Quote Link to comment
+Valentijn77 Posted August 21, 2014 Author Share Posted August 21, 2014 You are looking at the wrong end of the pipeline. GS sets the limits for the API and GSAK has to work within the constraints given. I know, but since GS isn't to active reacting to feature requests and such, the only hope I have is that GSAK or the macro can be changed. I might take a look myself at the macro. If only GS went open source with their platform and work together with the community on improving it. Quote Link to comment
+Corfman Clan Posted August 21, 2014 Share Posted August 21, 2014 Just tried GSAK and it shows that the favorite field is not a primary field in the api. It's not included in the PQ export, so GSAK has to perform ONE THOUSAND api calls just to get the favorite field populated. I am not sure this is only caused by the PQ Export lacking the favorites field, or that the same problem occurs when perform queries against the API. EDIT: And it doesn't work correctly. It says there are only 2 caches with >100 points, where in reality there are 30+ caches. Actually, you can retrieve data for 30 caches in one API call, so you should be able to get all the favorite points for 1000 caches in 34 API calls. One is limited to 30 API calls per minute, so to update 1000 caches will take just over a minute to perform. Ok, in that case GSAK or the macro could be improved Actually, I think you just need to learn how to use GSAK and the macro. They work just fine. If you have questions about how to use them, then check out the GSAK forum. Quote Link to comment
+NYPaddleCacher Posted August 21, 2014 Share Posted August 21, 2014 That is true favorites are not contained in the api or pq. There are hundreds of requests for GC to do but most will not get implemented for various valid reasons. So turning to third party is the solution. They could be added to the apI at one point but don't ever expect them to be in the pq. Making changes to that is a big deal and the last time they did it created problems downstream This has come up many times and many times the response has been that it won't happen because GS isn't going to change the PQ. The PQ system consists of three parts. 1. The search form and backend logic which executes a query. 2. The ability to store and periodically execute saved queries 3. The delivery and formatting of the results The problems created previously were a result in a change to #3, and essentially due client software making assumptions about the content contained in the GPX file. The problems manifested due to the fact that even though a field was defined such that it could contain any string, some client software made the erroneous assumption that the value in field would be constrained a set of values, and didn't gracefully handle the condition when it wasn't. But that's a moot point as No changes to how PQ results are delivered or formatted are needed. No additional fields need to be added. The GPX format doesn't contain values for how many favorite points a cache has now and wouldn't need to have it added to implement this feature. The 2nd part is a non issue as well. The storage and re-execution of queries mechanism need not care what the query is. It's only the first part that would require changing, and if the API supported filtering by favorite points, most of the work would be done. What is being asked for is a filter. If I enter into the PQ form that I only want to see caches with 50 or more favorite points I don't need to know that one cache has 51 favorites and another has 70. All I am asking for is a list of caches which have at least 50 favorite points. If I'm seeing too many I just increase the 50 to 70 (or whatever). Quote Link to comment
+Valentijn77 Posted August 21, 2014 Author Share Posted August 21, 2014 Just tried GSAK and it shows that the favorite field is not a primary field in the api. It's not included in the PQ export, so GSAK has to perform ONE THOUSAND api calls just to get the favorite field populated. I am not sure this is only caused by the PQ Export lacking the favorites field, or that the same problem occurs when perform queries against the API. EDIT: And it doesn't work correctly. It says there are only 2 caches with >100 points, where in reality there are 30+ caches. Actually, you can retrieve data for 30 caches in one API call, so you should be able to get all the favorite points for 1000 caches in 34 API calls. One is limited to 30 API calls per minute, so to update 1000 caches will take just over a minute to perform. Ok, in that case GSAK or the macro could be improved Actually, I think you just need to learn how to use GSAK and the macro. They work just fine. If you have questions about how to use them, then check out the GSAK forum. This by itself indicates that its too difficult to retrieve the top favorited caches in a certain area :-) Using the macro is just pressing run and observing its doing 1000 api calls, not much too learn there. Not using PQ is better, because via API you get the favorite points automagically. Quote Link to comment
+Valentijn77 Posted August 21, 2014 Author Share Posted August 21, 2014 It's only the first part that would require changing, and if the API supported filtering by favorite points, most of the work would be done. What is being asked for is a filter. If I enter into the PQ form that I only want to see caches with 50 or more favorite points I don't need to know that one cache has 51 favorites and another has 70. All I am asking for is a list of caches which have at least 50 favorite points. If I'm seeing too many I just increase the 50 to 70 (or whatever). Exactly just make the favorite points field a first class citizen by allowing filtering. I know this might affect multiple layers in the system, but still it would a big plus if you could just go online en do a quick search and filter to find popular caches. No need to do any manual exporting importing filtering sorting macroing in 1 or more external tools. Quote Link to comment
+Lil Devil Posted August 21, 2014 Share Posted August 21, 2014 What macro are you talking about? There is no need to use any macro to get Fav Points into GSAK. Just use either the Get Geocaches or Refresh Cache Data built-in functions. Quote Link to comment
+Valentijn77 Posted August 21, 2014 Author Share Posted August 21, 2014 The tip was to load the PQ into GSAK and then use the getfavorite macro. As I am saying after that it's easier to use the API to get the caches, including favorites points. You are however limited to the limits of the API (few requests allowed). Quote Link to comment
+The A-Team Posted August 21, 2014 Share Posted August 21, 2014 (edited) It's only the first part that would require changing, and if the API supported filtering by favorite points, most of the work would be done. The API does support filtering by Favourite Points. Here's the relevant section of the SearchForGeocaches API call (bolding mine): <FavoritePoints> <MinFavoritePoints xmlns="http://schemas.datacontract.org/2004/07/Tucson.Geocaching.WCF.API.Geocaching.Types">2147483647</MinFavoritePoints> <MaxFavoritePoints xmlns="http://schemas.datacontract.org/2004/07/Tucson.Geocaching.WCF.API.Geocaching.Types">2147483647</MaxFavoritePoints> </FavoritePoints> Edit to add link to list of API calls Edited August 21, 2014 by The A-Team Quote Link to comment
+The A-Team Posted August 21, 2014 Share Posted August 21, 2014 The tip was to load the PQ into GSAK and then use the getfavorite macro. As I am saying after that it's easier to use the API to get the caches, including favorites points. You are however limited to the limits of the API (few requests allowed). FYI, you can download or refresh 6000 caches per 24 hour period using the API. How many caches are in the area you're wanting to filter? Quote Link to comment
+Lil Devil Posted August 21, 2014 Share Posted August 21, 2014 The tip was to load the PQ into GSAK and then use the getfavorite macro. I can't find any macro called getfavorite. But as I said above, no macro is required to get favorite points. You are however limited to the limits of the API (few requests allowed). you can download or refresh 6000 caches per 24 hour period using the API. Considering full AND light API calls both return favorite points, you could actually refresh 16,000 caches per 24 hour period. How many caches are in the area you're wanting to filter? Quote Link to comment
+The A-Team Posted August 21, 2014 Share Posted August 21, 2014 Considering full AND light API calls both return favorite points, you could actually refresh 16,000 caches per 24 hour period. Interesting. I didn't realize the light calls returned Favourite Points. Quote Link to comment
+Mudfrog Posted August 22, 2014 Share Posted August 22, 2014 Considering full AND light API calls both return favorite points, you could actually refresh 16,000 caches per 24 hour period. Interesting. I didn't realize the light calls returned Favourite Points. I didn't realize the "light" API call returned favorites either. I've been using the "full". Doesn't matter as i can't see myself ever hitting the 6000 limit. Still, it would definitely be nicer if we could just filter with the pocket query instead of refreshing, sorting, and deleting in gsak. Quote Link to comment
+NYPaddleCacher Posted August 22, 2014 Share Posted August 22, 2014 The tip was to load the PQ into GSAK and then use the getfavorite macro. As I am saying after that it's easier to use the API to get the caches, including favorites points. You are however limited to the limits of the API (few requests allowed). FYI, you can download or refresh 6000 caches per 24 hour period using the API. How many caches are in the area you're wanting to filter? And if the filter were done when constructing the query, instead downloading 6000 caches and filtering after the fact, filtering when the query is made would reduce (and probably significantly) the size of the download. Since, as you've shown, the API does support filtering, why doesn't backend code which processes the form elements just use the API? Then it's just a matter of adding the form element for specifying the minimum value for favorite points. Quote Link to comment
+Valentijn77 Posted August 23, 2014 Author Share Posted August 23, 2014 The tip was to load the PQ into GSAK and then use the getfavorite macro. As I am saying after that it's easier to use the API to get the caches, including favorites points. You are however limited to the limits of the API (few requests allowed). FYI, you can download or refresh 6000 caches per 24 hour period using the API. How many caches are in the area you're wanting to filter? And if the filter were done when constructing the query, instead downloading 6000 caches and filtering after the fact, filtering when the query is made would reduce (and probably significantly) the size of the download. Since, as you've shown, the API does support filtering, why doesn't backend code which processes the form elements just use the API? Then it's just a matter of adding the form element for specifying the minimum value for favorite points. The GC ecosystem has been growing over the years and it looks like it consists of multiple components working together, some newer, some older. Possibly a service oriented architectue. This is visible for example with the pocket query integration with maps. You can view the list of pocket queries and select a query to be displayed. But if you want to edit a query you have to go back to the website, find the query again and edit it. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.