New Pocket Query Generator

[+Clan-Wallace 14]

I can see that 'Groundspeak Customers' have been requesting an update to the old GPX format, still in existence today, way back in 2011. It looked like progress was being made in 2014, with more Customer frustration appearing in 2016. This post now makes that six years with no action taken as far as I know on matching the API to the Pocket Query generation tool. 

The new Advanced Search tool is a good example of improved use of the API.

The pocket query tool could offer many more filter options and generate a new GPX format that contains many additional and useful items of data that is currently accessible through the API.

Surely this also makes economical sense? How many Customers download the current GPX format and then have to use other applications, like GSAK, Android and IOS apps, which place further load on the Groundspeak servers, in order to download missing information they need to enhance their geocaching experience in the field and back home? 

Can a member of Groundspeak re-assure us that we are being listened to and action is being taken to fulfil these missing features that would make it better for everyone, including Groundspeak?

Thank you.

Edited September 29, 2017 by Clan-Wallace

[+Viajero Perdido 398]

+1

If Groundspeak were to put an effort into user-friendliness, making things less confusing, this would be a great place to start.  I just operate an app that's complicated enough without Groundspeak adding their own quirks.

(Usability #2 might be, un-confuse the concept of "Premium".)

[+Rincewind3 2]

Agreed. I used to be an official app user (after migrating from PQ/ETrex) but switched to C:Geo when the partially finished app came out.  I now have a list of 700+ solved puzzles on the website but need PQ to get it into C:Geo. I then save the PQ as an offline list. The sticking points: the PQ can't filter out found caches, when I delete a cache from the list on C:Geo there is no way for it to delete it from my GS list, I therefore have to take extra time (& use extra data - it's expensive in NZ) to open the list in my phone browser and remove the found cache - alternatively I need to remember to go to the list at least weekly, search 30 odd pages for found caches, and delete them.  If I don't the found caches keep turning up back in the PQ and therefore back in C:Geo.

First world problem, I know, but a pain in the neck nonetheless. 

[+Starkacher 0]

Whole-heartedly Agree.   More filter options should include optional Latitude and Longitude limitations (None, Only lower limit, Only upper limit, Lower and upper limit)    This can square off 1-4 edges of the "circle" and potentially make it a square.     This could actually lesson the burden on the geocaching,com servers as people could run fewer pocket queries to cover an area. That is because they would not have to waste returning duplicate caches within overlapping circles.   I have not thought through what happens for people on the zero (or 90?/180) longitude or longitude lines.  That may need an OR option for the limits?      A similar enhancement would be a distance range.     Instead just <= a particular distance, add >= a particular distance (subject to overall individual PQ cache count limitations), or at least add a between X and Y distances.   That way you could create Rings around earlier PQs in order to fully cover a desired area (again without having to have wasted/inefficient overlapping circles).       

Edited October 1, 2017 by Starkacher

[+Kai Team 4]

I'd be happy if the PQ's were just updated to include all of the information returned by the API - e.g. corrected coordinates, with an indicator, original coordinates, favorite points....  It would reduce the demand on the Groundspeak servers, since users would not have to update caches with the API to get missing information after loading PQ's.  Enhanced PQ generation search criteria would be the icing on the cake, but first we need the cake (complete cache information in the PQ's).