[Request] Pocket Query Overhaul Wishlist

[+Mineral2]

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 September 28, 2018 by Mineral2

[+Harry Dolphin]

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.

[+Isonzo Karst]

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?

 

 

[+hzoi]

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 September 24, 2018 by hzoi

[+Mineral2]

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. 

[+niraD]

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.

[+HHL]

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 September 25, 2018 by HHL

[+Lynx Humble]

Living in a cache crowded area I would love that they increase that 1000 limits too. 

[+hzoi]

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.

[+Gamma5]

Last update 2018, I guess this is not going anywhere?

[+lee737]

After the recent 500 cache bug in the PQ interface, I was going to make some requests about PQs, mainly a limit increase, but the page refreshing fix and rectangular queries would be great too, so I'll bump this old thread.

A PQ with nearly 1000 WPs comes to me as a zip under 2MB. Surely a limit to 5,000-10,000 could be implemented very easily, without a complete backend overhaul.

 

To be honest - with the time it takes me to craft a PQ for a trip to a dense area, I'd pay a higher premium membership to be able to just slam 10,000 caches into a single query. 

[+MartyBartfast]

I would definitely support an increase of the 1000 cache limit. If there are concerns over the server load that might be incurred by increasing the limit then that would be countered by the fact that people would probably be running fewer PQs, e.g. I have 42 that I run to cover the area of my interest, if the limit were increased to 5000 then I would only be running 8 PQs for that same task.

 

 

I'd also like to see a "create PQ" button on the search results page to create a PQ with the criteria used to create the search, with a few additional options on the search criteria this would allow GS to ditch the current PQ creation  form - one less thing to support/maintain.

I remember chatting to Jeremy over a pint at an event many years ago where I asked him about increasing the PQ limit over 500, his stance back then was that the cache database was effectively the product he was selling and he wasn't prepared to "give it away" by having large PQ limits. Several years later of course , as the game had grown significantly,  the limit was increased to 1000 and the number of PQs also increased. Today the game has increased WAY more and  anyone using  tool such as GSAK can download 26,000 caches a day via the API, so I'm sure it's not going to be such a problem to increase the PQ limit, and I'm sure that it's not technically difficult..

[+Goldenwattle]

More complicated, but the number of caches being downloaded could often be reduced by being able to fence the area for caches. Say driving along a road it could be fenced to say 2kms either side. Fenced to within geological features would be another. You aren't crossing that river or climbing over that high ridge; only walking on this side of the river on low parts for example. Fencing would eliminate unneeded areas and eliminate unneeded caches to download.

Another way to do this, allow clicking on shires/council areas (whatever the local name is) to choose areas to download. They are far smaller than states.

Offered only to paying members of course.

[+lee737]

18 minutes ago, Goldenwattle said:

Say driving along a road it could be fenced to say 2kms either side.

 

We can do this already, using routes....

[+Goldenwattle]

4 hours ago, lee737 said:

 

We can do this already, using routes....

Thanks, learnt something.