Jump to content

[Request] Pocket Query Overhaul Wishlist


Mineral2

Recommended Posts

Now that HQ is upgrading server hardware to make the website run faster and smoother and handle newer web technologies, I have some suggestions for overhauling the dated pocket query system. I realize that some of the limitations on pocket queries was to keep the servers from being overtaxed. I wonder if the new hardware is powerful enough to expand these limitations.
 

  1. Pocket query sizes larger than 1000 geocaches. This used to be a good limit, but now that GPS and smartphone applications can handle more geocaches, it is perhaps time to increase the limit per single search.
  2. Run more than 10 pocket queries each day. Improving #1 might negate the need for this one.
  3. Update the interface to the PQ web page so that turning a PQ on and off does not trigger a page refresh. I think some kind of  live-updating form utilizing javascript or html5 would reduce the need to refresh the page (or open in a new tab as I do) after every click. Not only does this waste time for the end user, but the page refreshes to the top making us scroll down the list to continue activating/deactivating pocket queries. If this isn't doable, then at least a form system where we can make all of our changes to the PQ scheduling and then hit a submit button.
  4. Integrate pocket queries with the new search. This will undoubtedly require that all pocket query options be added to the search function (which can be limited to premium members), but in return, the search function can be used to create pocket queries (ie, save searches). 
  5. Rectangular queries: Maybe adding to the options a north-south latitude limits, and east-west longitude limits so that our results cover a rectangular area instead of a circle. We'd need fewer PQs to cover a large area since we could produce them without gaps and no need for overlap. 
  6. The ability to filter for solved coordinates - extra points if you can allow this to only affect Unknown/Mystery caches while returning all other caches in the search results.

 

Edited by Mineral2
  • Upvote 2
Link to comment

I would like to see a filter for counties.  I live about thirty miles west of New York City. My PQs cover 65 miles.  I have no interest in ever geocaching in Kings, Queens, The Bronx, Nassau or Suffolk counties again.  Rarely in Westchester or Richmond counties.  But they keep showing up in my PQs.  It used to be that counties showed up in my PQs.  But not any more.

Link to comment

Mineral2 - speaking to your "rectangular queries" and "overlap". If you're trying to get all caches in some area, say Idaho, use 18 or 19 date ranged queries . See project gc, PQ splitter for dates. Once you've set these up the first time, you can just refresh the data through the api. 

Or you could make a large radius around yourself, that might include a couple of   states, and date range those queries.

A learning curve and some time in the initial   set up curve, but handy.

 

Harry Dolphin, I'm not sure what you mean by, "it used to be that counties showed up in my PQs". County data isn't part of a Geocaching.com  gpx file, and to my memory has never been part of a PQ, and I doubt it's possible to make it so - at least not without a lot of work and coding.  I used to have a  GSAK column for county, perhaps that's what you're recalling?

 

 

Link to comment
1 hour ago, Isonzo Karst said:

County data isn't part of a Geocaching.com  gpx file, and to my memory has never been part of a PQ, and I doubt it's possible to make it so - at least not without a lot of work and coding.  I used to have a  GSAK column for county, perhaps that's what you're recalling?


Second point first - there still is a GSAK column for county.  FindStatGen3 will update for counties if you ask it to, and I believe there is a separate macro to get county information -- all based on polygons.

 

Which brings to the first point - if GSAK and project-gc can both break down which county a cache is in by maintaining a giant set of polygons, couldn't Groundspeak?  Or add counties to the database and have it user selected.  I don't remember exactly when states outside the US came into play, but they haven't always been there - I know when we started in 2007, there was no option for German states, just "Germany," and later it was added in.  Even caches archived in Germany before states were added have states assigned now are assigned to states.  Not sure when this happened, but all the 2001 caches I checked that were archived before 2007 all have the same "last updated" time stamp:

 

Quote

Last Updated: 11/15/2017 15:57:39 (UTC-08:00) Pacific Time (US & Canada) (23:57 GMT)

 

so perhaps it was a batch job.

 

 

 

 

Edited by hzoi
Link to comment
5 hours ago, Isonzo Karst said:

If you're trying to get all caches in some area, say Idaho, use 18 or 19 date ranged queries .

I know about the date range method. I used it to make 10 PQ's of the Denver metro area when I had planned to visit the area. But I was also making PQs for other areas I was planning to visit, as well as places along my route to get there. Some of those were PQs by route, and some were city area PQs. My point with these suggestions is to make it easier for people to get the caches they want without having to resort to the date split method, which was created as a way to deal with the limitations on pocket queries. I remember when PQs were limited to 5 per day, and that expansion to 10 per day really made a difference. I think now, as long as the hardware can handle it, we could use either another increase - 20 per day? - and/or an increase in PQ size - say say 2000 or even 5000 results per query. Think how much easier that would be. If I did want to load the entire state of Idaho (I don't.), I wouldn't need 18 or 19 queries. Rectangles may also not be necessary with increases on the PQ limits, but they do help for people who are trip planning as rectangular areas are easier to visualize. Even GSAK lets you filter rectangular areas to load onto your GPS.

 

 

4 hours ago, hzoi said:

if GSAK and project-gc can both break down which county a cache is in by maintaining a giant set of polygons, couldn't Groundspeak?

I suspect that GSAK and Project-GC use external georeferencing services to determine county from the coordinates and Groundspeak probably wants to minimize the number of external services it has to rely on. It's still a worthy request even if they can't fulfill it. 

Link to comment
21 hours ago, Mineral2 said:
  • Pocket query sizes larger than 1000 geocaches. This used to be a good limit, but now that GPS and smartphone applications can handle more geocaches, it is perhaps time to increase the limit per single search.
  • Run more than 10 pocket queries each day. Improving #1 might negate the need for this one.

Does anyone really need 10k geocache listings for actual geocaching? Or do people download all that data so they can use a third-party tool to filter it, ultimately producing a smaller list of geocaches that they'll use for actual geocaching?

 

I think it would be more useful to improve the filtering capabilities of the PQ system, so that third-party tools aren't needed to get filtered lists for actual geocaching.

 

Speaking of which...

21 hours ago, Mineral2 said:
  • Integrate pocket queries with the new search. This will undoubtedly require that all pocket query options be added to the search function (which can be limited to premium members), but in return, the search function can be used to create pocket queries (ie, save searches).

Yeah, there are search criteria available for PQs that are not available for the new search, and vice versa. It would be nice to have all of that integrated.

 

And there are many more search criteria that people have asked for here in the forums. Once the systems are integrated, it would be nice to have them expanded.

  • Upvote 1
Link to comment

It would be pretty nice if PQ, Bookmark list and mapping limits raise from poor 1000 to a sufficient limit that let us load a Garmin unit in one go. Even in cache crowded areas. And without fiddling around on PQ's from-to dates.

I often have results in the 4500 to 6000 range when searching with the new search. But I neither can map those results (limit 1000), nor check the entire list (limit 1000) nor even bookmark it (limit 1000) to easily send it from the bm list to the unit. Having said that: all limits of these interacting features should be updated to the current limit that most Garmin can hold: 5000. Personally I'd prefer to align PQ, BM list and mapping limits to the currently valid api limits.

 

Hans

Edited by HHL
Link to comment

Adding in favorite points would be nice, both in the search criteria and in the PQ output.

 

The search filters have a "Minimum favorite points" criteria, but the pocket query page does not allow using favorite points as search criteria.  And pocket query output does not include information about favorite points - to get this into GSAK I have to first load a pocket query in GSAK and then use the API to update cache information.

Link to comment

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...