Loading a pocket query on to a Garmin eTrex 20

[+KAPA Pilot]

Which document did you look at? In common with pretty much every manufacturer these days only a quick start manual comes with the device. You can download the full manual or there may be a copy on your device, there was on my Etrex.

 

D. All of the above.

 

I referenced both the quick start guide and the owner's manual which accompanied the unit, and I used what turned out to be the same documents available from the Garmin support website.

[+chelmerfamily]

Thanks for this amazing fix .... the technology is well above me but it worked!

I had downloaded a pocket query with 62 caches but only 48 appeared on my new garmin. I followed the above about removing the bounds tag using notebook resaved, recopied and now I have all 62.

No idea why but thanks Kapa Pilot

[+geodarts]

As I wrote in reply to another post, I do not see an issue with the <bounds> tag. It is not only used in Groundspeak's pocket queries (GPX versions 1 and 1.0.1), but by Garmin's basecamp, iPhone apps including Geosphere's GPX export, GSAK export, and other cache managers. I do not have enough technical knowledge to know the purpose of the <bounds> tag and whether it could cause problems, but it is not inherently suspect. I wonder if what might have happened was that by editing and replacing the file, the unit reindexed the cache data and restored the missing caches.

 

Garmin units have occasional indexing problems and I would not want to have to edit each gpx file by hand. So going through the indexing procedure (deleting the file or removing the sd card, turning the unit on; shutting it down after it completes the start-up; and then restoring the file or the sd card) might be the first place I would start. It has worked for me in the past - although fortunately it's been quite a while since I only use the handheld for certain things.

Edited August 25, 2016 by geodarts

[robertlipe]

I share geodarts' skepticism. If the presence or absence of a (well-formed and correct) <bounds> tag results in lost data, that's a bug in the reader. It's far more likely that the act of editing the files removed characters you didn't see or forced a timestamp update that made the device re-read the file. But enough people are observing this that there's an issue somewhere. I wonder if people are being confused by the Garmin silliness of only showing points w/in a hundred miles by default - a UX problem they could fix by adding "some points are not shown because they're too far away" instead of silently truncating. Since this is an extremely common tag, there would be rioting in the streets if this poisoned Garmins. I'd want to put the files before and after into an XML validator before placing blame, but even things like Notepad removing Byte Order Marks or changing the encoding wouldn't match this failure mode.

 

<bounds> is completely optional in GPX. It exists as an optimization for streaming readers. By having a tag at the top that says "you're about to get data that falls in the following rectangle", the software could center a map that contained that and let you watch the data as it's streamed in, for example. The example that geocachers might most relate to is pocket query preview. In preview, you get to stare at a little slice of Seattle that presumably contains Groundspeak HQ while your thousand points are being sent; then the camera is repositioned over the received data. If something like <bounds> was being used (it doesn't actually use GPX, IIRC, though it could...) your map could be centered and you could then see the points appear on the map to see the progressive disclosure as they load without the need of an indeterminate spinner.

 

When I saw that one of the posters was in the UK, I suspected problems involving the Prime Meridian. Bounding Boxes that span hemisphere boundaries are hard and lots of software gets them wrong. When you have four close points on a sphere, there is some ambiguity whether you're describing one small slice of the planet or a big slice of the planet that excludes that slice and software that assumes that "east" is less than "west" can get fooled at the sign wraps at the meridian or antemeridian. I can imagine Basecamp caring about <bounds> for the reason I described above. But since the GPS is "just" reading them into a database, I can't imagine why it would care; it seems unllikely, for example, that they're allocating quadtree nodes at that point, for example. <bounds> could give you the hint that the contents are potentially far apart, but not nearly enough info to be used effectively. It seems unlikely that if a bounds tag were present and wrong that a reader would discard points outside that bounding box, though I suppose that would be legal. (It would slow the read and probably not really provide any benefit...)

 

If I need credentials, I helped create GPX am the author of the first cross-platform app to read and write GPX, helped Groundspeak define the format of the original PQs, etc.