Jump to content
Sign in to follow this  
Followers 13
yodasands

Loading a pocket query on to a Garmin eTrex 20

Recommended Posts

Before taking it back I'd be tempted to redownload the PQ from Geocaching.com, and also create another large PQ but from a different area and try that - in case there's something in the PQ that's bad.

 

I regularly load PQs of 2-3000 onto my Etrex30, and haven't had a problem, I think I'm still on 3.60 (but can't check at the mo)

Share this post


Link to post

My wife gave me a new Garmin eTrex 20x for Christmas. Despite the relative simplicity of the device, I found Garmin's documentation severely lacking, especially with regard to methods for loading GPX files onto the device. Nevertheless, I dug in and completed some research, and discovered the process was shockingly simple: treat the device like a simple USB flash drive and copy the files using Windows File Explorer. (Is it really so difficult to state this simply and up front in the device manual?)

 

I started by downloading a GeoTour which my buddy and I had started several weeks back. The GPX file copied and loaded quickly and I thought I was in business, until I tried to load a GPX for a Pocket Query.

 

By the way, some of us are n00bs and don't understand all of the abbreviations, like PQ; it would be a good idea for folks to keep that in mind when contributing to these threads.

 

The GPX file for my first Pocket Query generated a result of approximately 560 caches and seemed to be well within the limits described by other contributors to this thread. Still, after copying the file to my device, none of the caches appeared on the map or in what is essentially a custom list of waypoints. I further refined the query and brought the total number of caches down to approximately 230. Still, the Pocket Query would copy to the device but would not be available within the list of caches in which the GeoTour caches were already presented.

 

Now, I've read plenty of supposition on the reasons why the caches within the Pocket Query GPX may not be listed but all of the conversation revolves around the device software, version 2.30 versus 2.20 or 2.10, etc. All of this ignores the simple fact that some GPX files from the Geocaching website work (i.e. GeoTours) while others (Pocket Queries) do not.

 

Since I have a bit of background with XML schemas, I opened each of the GPX files in Notepad and compared the tags in each. I discovered there is one remarkable difference between the GeoTour GPX file which worked, and the Pocket Query GPX file which failed... There's an additional XML tag in the Pocket Query file which does not exist in the GeoTour file. After I eliminated the extra tag, saved and closed the Pocket Query GPX file, and then copied it back to the device... SURPRISE!!! It loaded correctly. Imagine that!

 

So, the offending tag? It's the <bounds [...] /> tag.

 

In my case, the tag looked something like this...

 

<bounds minlat="nn.nnnnnn" minlon="nnn.nnnnnn" maxlat="nn.nnnnnn" maxlon="nn.nnnnnn" />

 

To be clear, I first attempted to load the Pocket Query GPX file, unaltered, to my device, and it failed. After removing the file from my device, saving it to my local Desktop, opening the file and deleting the <bounds /> tag, saving the file and copying it back to my device, the caches are now available. That's it; I made no other changes.

 

This issue is probably a limitation of the device software, in that it doesn't know what to do with the extra tag. However, a bit of consistency on the part of the Geocaching website might also be in order. I might suggest the simple elimination of the <bounds /> tag from the query generator template. In the meantime, I'll be sure to edit my GPX files prior to copying them to my device for the foreseeable future.

 

Here's hoping what I've learned may help others having similar problems.

 

Please note, this is not meant as any sort of sleight against the Garmin eTrex 20x; I love the device and am looking forward to many years of caching with it. But, neither the documentation from Garmin, nor the data files generated by the Geocaching website are simple and straight-forward enough for novice users, which may prove a deterrent in a consumer marketplace. I would ask that both Garmin and Geocaching evaluate their pieces of the puzzle and try to iron out the defects.

 

Thanks,

 

KAPA Pilot

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

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

Share this post


Link to post

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 by geodarts

Share this post


Link to post

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.

Share this post


Link to post

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...
Sign in to follow this  
Followers 13

×
×
  • Create New...