Jump to content

pocket query filtering caches by favorite points


topi20

Recommended Posts

Hello Groundspeak team,

is it planned to build in a favorite points filter into a pocket query?

example:

build a pocket query, which shows you all tradies around 10 miles

from your home koords with more than 50 favorite points.

 

kind regards

topi20

Link to comment

Since this is not a bug report, I'm moving the topic to the "Feature Discussions and Suggestions" thread. FYI, a GPX schema overhaul is coming shortly that will include favorite points, and once that is in place it will open the door to PQ enhancements such as this.

And what does it mean "shortly"? Because I am waiting for this feature since Favorites introduction - more than one year! If I remeber well, it was one of TOP voted required features in your forum with voting...

 

 

Link to comment

Since this is not a bug report, I'm moving the topic to the "Feature Discussions and Suggestions" thread. FYI, a GPX schema overhaul is coming shortly that will include favorite points, and once that is in place it will open the door to PQ enhancements such as this.

 

So when is this going to be added? Shortly has come and gone since you posted this IMHO.

 

Now I have to refresh cache data in GSAK 8, yeah Clyde rocks:D

Link to comment

Since this is not a bug report, I'm moving the topic to the "Feature Discussions and Suggestions" thread. FYI, a GPX schema overhaul is coming shortly that will include favorite points, and once that is in place it will open the door to PQ enhancements such as this.

 

So when is this going to be added? Shortly has come and gone since you posted this IMHO.

 

Now I have to refresh cache data in GSAK 8, yeah Clyde rocks:D

 

A GPX schema overhaul is not something that can be taken lightly. The GPX file format is pretty much the defacto standard for the transport of waypoint information between GPS devices and applications. It is essential that any changes made to the specification be done right. Give them time to make sure that it's not pushed out the door before it's ready.

Link to comment

A GPX schema overhaul is not something that can be taken lightly. The GPX file format is pretty much the defacto standard for the transport of waypoint information between GPS devices and applications. It is essential that any changes made to the specification be done right. Give them time to make sure that it's not pushed out the door before it's ready.

It isn't actually a GPX overhaul, but rather a Groundspeak GPX extension overhaul. The tags used by the standard GPX schema won't be changed. It's the additional tags Groundspeak adds on top of the base GPX that are being changed. Applications that don't care about the Groundspeak extensions will still just ignore them, and nothing will change. It's only geocaching-related applications that will be affected. The new schema has already been determined and published here many months ago, so the only thing that still needs to be done is to update the site to generate GPX files with the new schema. With the new cache submission process now in beta, it probably won't be much longer until the new GPX comes out.

Link to comment

I was going to submit this idea myself but found this thread already in place. Is anyone able to give us an update about either the GPX update or if the idea to add favorite points to PQs is still on the table for consideration by GS?

Unfortunately, it appears the GPX update has been "deprioritized":

The change to "medium" will be reverted. It sneaked in accidentally when we made some localization changes in the last release (and into the new cache submission wizard before that). We had planned to switch to that terminology, but it was supposed to wait for a change to the GPX schema. That change has been deprioritized and so we will go back to using "regular" everywhere.

Link to comment

I just tried again with my Montana running the latest firmware (my Oregon is at home) and it is still failing to recognize anything other than 1.0 as geocaches. (I'm running my PQs in 1.0.1 format through GSAK and outputting as 1.0. If I select what GSAK calls 1.1, the GPS sees no geocaches.)

Link to comment

I just tried again with my Montana running the latest firmware (my Oregon is at home) and it is still failing to recognize anything other than 1.0 as geocaches. (I'm running my PQs in 1.0.1 format through GSAK and outputting as 1.0. If I select what GSAK calls 1.1, the GPS sees no geocaches.)

As I understand it, the "1.0" and "1.1" listed in GSAK are the GPX version numbers, not the Groundspeak extension version numbers. According to this post from a couple of years ago, the Groundspeak extensions are "bolted onto" GPX version 1.0, creating the Groundspeak version 1.0.1. That would explain why exporting from GSAK with 1.1 doesn't work. If you're Groundspeak account is set to use 1.0.1, and you load a cache straight onto your Montana, you'll probably find it works just fine.

Link to comment

Ah, well, I like to manipulate my data in GSAK before sending to my GPS, so I'll continue to have to export as 1.0 since that is all that works.

Roger that, I just wanted to point out that Garmin does support Groundspeak version 1.0.1, contrary to what you posted earlier.

Link to comment

Maybe you did not notice original request here. topi20 was not asking for new GPX file format or whatever like that. topi20 asked you for filtering caches by Favorites in PQ. It means by simple words to add one more condition to "New Pocket Query" page ( http://www.geocachin...et/gcquery.aspx ) where we can enter number with minimum Favorite points and only caches with more or equal Favorites will be filtered to PQ result.

 

Please, do not hide this issue by GPX schema changes. Especially, If you are not able to generate correct gpx files that will work with current hardware&software. Do not expect Garmin or whoever will update their hardware (firmware) for you ;)

 

BTW: I can live well with 1.0.1 format and my old Colorado. No issues I have. And I see also attributes, which are originaly not shown by Colorado, as my software will move them from "not vissible attribute for Garmin" to cache description...

Link to comment

Maybe you did not notice original request here. topi20 was not asking for new GPX file format or whatever like that. topi20 asked you for filtering caches by Favorites in PQ. It means by simple words to add one more condition to "New Pocket Query" page ( http://www.geocachin...et/gcquery.aspx ) where we can enter number with minimum Favorite points and only caches with more or equal Favorites will be filtered to PQ result.

 

Please, do not hide this issue by GPX schema changes. Especially, If you are not able to generate correct gpx files that will work with current hardware&software. Do not expect Garmin or whoever will update their hardware (firmware) for you ;)

 

BTW: I can live well with 1.0.1 format and my old Colorado. No issues I have. And I see also attributes, which are originaly not shown by Colorado, as my software will move them from "not vissible attribute for Garmin" to cache description...

 

HA! GOOD POINT!

 

The favorite point information does not need to be included in the exported file, just used as a means to filter the available caches BEFORE THEY ARE ADDED to the final .gpx export.

 

This would be a good intermediate step, and would satisfy most users needs.

Link to comment

Also looking for this feature and found this thread. Any news?

 

Status looks to be for more than half year still the same. We will not get it as GS ignores us and is not even able to reply to this topic (I do not count replies about GPX schema as relevant ones, as this topic has nothing to do with GPX schema).

Link to comment

Also looking for this feature and found this thread. Any news?

 

Status looks to be for more than half year still the same. We will not get it as GS ignores us and is not even able to reply to this topic (I do not count replies about GPX schema as relevant ones, as this topic has nothing to do with GPX schema).

 

3 more months without any progress. Any news?

Link to comment

(I do not count replies about GPX schema as relevant ones, as this topic has nothing to do with GPX schema).

 

Those statements have everything to do with this issue, since the schema would need to be 'updated' to include the FP information.

 

Originator of this topic did not ask to have FP in generated PQ gpx file. He asked to have just filter on frontend (PQ creation site), so resulted PQ file will include just caches with relevant FP count.

Link to comment

(I do not count replies about GPX schema as relevant ones, as this topic has nothing to do with GPX schema).

 

Those statements have everything to do with this issue, since the schema would need to be 'updated' to include the FP information.

 

Originator of this topic did not ask to have FP in generated PQ gpx file. He asked to have just filter on frontend (PQ creation site), so resulted PQ file will include just caches with relevant FP count.

 

Even so, TPTB have clearly stated they are not planning to update the PQ generation system in favor of improving (we'll see) the API delivery system.

Link to comment

*bump*

 

would be really useful

Yes would, but since there is a viable third party solution it is not going to happen. Besides Moun10bike has already said that the PQ aren't going to be changing and any new functionality will be delivered via the API.

Link to comment

*bump*

 

would be really useful

Yes would, but since there is a viable third party solution it is not going to happen. Besides Moun10bike has already said that the PQ aren't going to be changing and any new functionality will be delivered via the API.

 

Several people have claimed that PQs aren't changing so perhaps it makes sense to define what, exactly a PQ actually is.

 

I pocket query is essentially a stored search, that can be periodically executed, that (optionally) delivers the results via email in GPX (zipped up unzipped format). There are essentially three parts of the PQ system.

 

There is the search form, which provides the searching and filtering criteria.

 

There is the storage and scheduling piece (i.e. we can define a set of search/filtering criteria, give it a name, and the schedule it to be re-executed on a periodic basis)

 

The is the delivery of the results. The results of a query can be previewed as a list, on a map, or sent via email (and if the result list is large enough...and for the MyFinds PQ) the results, must be downloaded "manually". When not previewing the results or viewing them on a map, the results are encapsulated as a GPX file.

 

GS *has* said that changes to the GPX file have been de-prioritized. That essentially means that new fields (such as the number of favorites) won't be added the the GPX file. However, that doesn't mean that the search form and what criteria are used to produce the results can't changed. As others have suggested, a filter by favorites (i.e. only show caches with 10 or more favorite points) would just limit the number of results that went into the GPX file.

 

It would probably be helpful if GS explained what "delivered via the API" actually means, because, as I understand it, that does *not* mean that delivery of waypoints as a GPX file is going to go away. If they did that, we would essentially have to use a third party application such as GSAK to obtain cache data via the API, and have GSAK create a GPX file if we are using a dedicated GPSr. A smartphone app can call the API directly but a handheld (or auto navigation) GPS can not.

Link to comment

Good point NYPC!

Filtering the results for number of FP would not necessarily mean the number of FP would have to be included in the resulting .gpx file.

 

But, wouldn't peeling back that layer just reveal another layer of the onion, and produce a bunch of other complaints about why the FP are not included in the .gpx and why don't they add an option to filter for this or that other parameter?

Link to comment

Did this ever get added/implemented? I've not been able to find a way of filtering by favourites, other than sorting by favourites in a list, and that doesn't help if you want to view it on a map!

 

Thanks, Hq.

Use the NewSearch and map the result. It's easy. ;-)

 

Hans

Link to comment

Use the NewSearch and map the result. It's easy. ;-)

 

Thanks - is there a way of using the filters of the newsearch to search for attributes as well? (e.g. any caches with the 'requires boat' attribute?) Might be missing something obvious, but I can't see that in the filters.

 

Also, there doesn't seem to be any way of downloading results to devices yet like with pocket queries?

 

Thanks, Hq.

Link to comment

Use the NewSearch and map the result. It's easy. ;-)

 

Thanks - is there a way of using the filters of the newsearch to search for attributes as well? (e.g. any caches with the 'requires boat' attribute?) Might be missing something obvious, but I can't see that in the filters.

No, unfortunately not.

Also, there doesn't seem to be any way of downloading results to devices yet like with pocket queries?

No. HQ said "we're working on it ..."

At the moment you may check all caches from the result and bookmark it. Then PQ the bookmark.

Personally I use a GSAK macro that gets the resulting caches via the Api. ;-)

 

Hans

Link to comment
Personally I use a GSAK macro that gets the resulting caches via the Api. ;-)

 

That's in fact great, but only at home, sitting in front of your Windows PC.

 

On the road, with nothing else than your mobile or even an Android tablet, it would be way better to be able to filter a PQ by "more than x Favorite Points".

Can't be that hard to implement (just another conditional "WHERE" condition to the already existing "SELECT").

Esp. as the function is already there anyway - but most sadly just and only in the new search, which does not allow filtering for attributes.

And, yes, there are of course even more ways to filter _after_ downloading (e. g. in c:geo) but you have to download a lot of sh*t before being able to.

What is not really nice for your data plan - esp. in foreign countries.

Moreover you produce a huge mass of load to the GS server - which can in fact be avoided easily (and should be in GS's sense!).

Edited by Magpie42
Link to comment

BTW: Would be great to have another filter like "more than x % Favorite Points",

and the poss. to combine it via OR or AND with "more than x Favorite Points":

OR: to get "good" caches even before they have this x of Favorite Points (mostly because of "less than x Logs so far" :))

AND: to filter out just seemingly(!) "High Favorite Caches", which just live of their highly frequented location, but are in fact "rubbish"

(as you would knwo, if you could have seen that these 100 Fav Points of the cache to do are just 1 % of the logs ...)

 

Thx & Cheers, Mag'

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...