Garmin 64s showing TOO MANY Pocket Query Geocaches

[+RufusClupea]

Thought I had everything working alright (see Garmin 64s not showing Pocket Query Geocaches ) until... when I went out cachin' I started going through what the PQ had yielded.  There are a LOT of caches that I filtered out (i.e. I filtered out any caches with T>1.5) that are in the query--caches with Ts of 2-4.5.  Not ALL caches with Ts that high, but quite a few.

Jes' spitballin' here, but could it be that there were so few caches with the parameters I specified, that the PQ generator filled in with other caches?  The parameters I specified were: 1000 caches (I got ~850) within 15 miles; with T<=1.5; size>Small; that were Regular, Multi-, Puzzle, that is enabled; placed anytime; no attributes chosen.

I haven't gone through the whole 850, but there are 20 out of the first 30 that shouldn't be there.

Thoughts?

[+Mineral2]

No. The PQ process will return 0 caches if you parameterize it properly. Go back and double check your PQ on the website. It could be that you filtered for Difficulty rather than Terrain?

It could also be that you have other caches loaded (another PQ file?, or individual caches), or that those appearing with a T>1.5 are from the pre-loaded ggz file that hasn't actually been deleted. (make sure to empty your trash or recycle bin before disconnecting the GPS from the computer)

[+RufusClupea]

3 hours ago, Mineral2 said:

No. The PQ process will return 0 caches if you parameterize it properly. Go back and double check your PQ on the website. It could be that you filtered for Difficulty rather than Terrain?

It's gone, but I did triple check before submitting, as T is the most important variable.

3 hours ago, Mineral2 said:

It could also be that you have other caches loaded (another PQ file?, or individual caches), or that those appearing with a T>1.5 are from the pre-loaded ggz file that hasn't actually been deleted. (make sure to empty your trash or recycle bin before disconnecting the GPS from the computer)

No other caches/PQs/ggz... This was the first PQ in a "virgin" 64s.  The pre-loaded ggz file was deleted directly from the 64s, so the file never went to the recycle bin (I checked) or are you saying there's a recycle bin in the unit?  I looked (after first reading the above) but I couldn't find one.

I'm going to try running the PQ again, but check the results sooner.

 

[+Mineral2]

In the meantime, you can also filter out geocaches by terrain directly on your GPS. 

[+RufusClupea]

Thanks, I did not know that.  It may be moot; I just ran the PQ again.  This time it yielded ~350 caches--500 fewer.  (Due to the hour--I'm guessing--it came back in about 5 min. of submitting...  )  Previewing it looks good so far.

One thing I noticed that may have been the problem (don't know)--I told the query AND T<=1.5, but I forgot/neglected to check the previous box for D>1.  I'm not sure how this would've included more Ts, but that's all I can figure I messed up.

This time, I screen-clipped the query form--just in case...

Thanks.

Edited August 9, 2017 by RufusClupea

[+RufusClupea]

I'm good to go.  TA 

[robertlipe]

The PQ form doesn't go much out of its way to protect you from "attractive nuisances"; you should always preview - sorting by the params in question - the PQ before submitting, and certainly before shipping to the device and departing for a trip.

If you want to submit a query with things that are "obviously" mutually exclusive like "have found" AND "haven't found" (guaranteed to result in the null set) or "is enabled" AND "is disabled", it'll happily run you an empty PQ. These should be radio buttons (mutually exclusive - you can't listen to more than one at once) instead of checkboxes and I imagine the dumb form is a result of a form generated by (dumb) code instead of a human listening to a UX designer.  IMO, that page needs some serious love from a combination of UX, UI, and dev teams as it's been a frustration for many over the years it's been basically unchanged.

The PQ interface has a lot of sharp edges in it. Combine that with Garmins accepting multiple PQs in different directories with different names - including when Macs "delete" files by copying them into a hidden file that Garmins don't recognize as "deleted" and it's all too easy to get caches on the device that you can't explain.

Always remember that PQs are glorified text files and you can bring them up in your favorite text editor, search for them, run find/grep whatever on them. GPSBabel will convert a GPX to a GPX, but make it more human readable by adding indented whitespace.

[+RufusClupea]

1 hour ago, robertlipe said:

Always remember that PQs are glorified text files and you can bring them up in your favorite text editor, search for them, run find/grep whatever on them. GPSBabel will convert a GPX to a GPX, but make it more human readable by adding indented whitespace.

Thx--good to know.   Did you mean to say that, or is it a typo?

[robertlipe]

I could have worded it better. Groundspeak's GPX writer often leaves the optional whitespace out of the XML tags. GPSBabel's GPX writer values human readibility, so converting a GPX file that's all on one line with no space - which is valid - to a GPX file will add whitespace to improve readability. Likewise for KML or many other XML-based formats: using GPSBabel to "convert" a format to itself will make the file easier to read and edit because it will add whitespace and line breaks when it can.