Jump to content

Possible GPX Conflict?


Recommended Posts

After having a downloaded GPX cache on my GPSr for a while, I wish to download a more recent GPX file containing more recent logs. If I send a new GPX file to the GPSr will it just overwrite the old file without causing a problem or causing a second GPX file to coexist? Or, must I go in and delete the old file off the GPSr first?

 

Thanks

Link to comment

After having a downloaded GPX cache on my GPSr for a while, I wish to download a more recent GPX file containing more recent logs. If I send a new GPX file to the GPSr will it just overwrite the old file without causing a problem or causing a second GPX file to coexist? Or, must I go in and delete the old file off the GPSr first?

 

Thanks

If you overwrite a file with a file of the same name ... well ... you overwrite the file - old data is gone. Problem is, we don't know what brand/model you have or what kind of filenames it might expect. In the case of a recent Garmin, any change to any *.gpx file (even a date/time stamp due to a new file, same name) will cause its contents to be evaluated. Any caches previously recorded as "found" that were in changed *.gpx files are discarded entirely (unless, for some reason, they show up in your new file).
Link to comment

Appreciate the response. I have a GPSMAP 62s. I have not marked the cache as found or in any other way modified the GPX file I originally downloaded. So it sounds like when working with any other windows file, I will essentially replace the file currently in the 62s with the more recent one to be downloaded. Thanks again.

For recent Garmin units, and a Premium membership, most of us just replace one PQ file with another when the old one gets too 'stale'.

 

When you replace one PQ with another, you get the newer logs and any other updates to the listing. Here's a description of what happens on these units... some of which isn't directly to your question, but covers the whole gamut:

 

 

Caches are loaded to the unit by placing one or more gpx files into the Garmin/GPX folder of the unit. A gpx file may contain information one or more than one cache. The total number of gpx files is limited to 200, and the permitted total number of caches represented in the 'one or more' gpx files varies with the unit model. A unit might handle 2000 or 5000 caches. Filenames can be whatever you prefer so long as they retain the *.gpx suffix.

 

When a gpx file is loaded to the Garmin/GPX directory, it is 'discovered' by the unit as new if there is any hint of difference between this gpx file and what was in that folder during the last power up of the unit. So much as a tick of difference in the time stamp causes the unit to recognize this as a new file. What happens when a 'new' file is found? We'll get back to that in a moment.

 

There are three 'databases' of cache information held in the unit.

  • #1 is the gpx file that is the original source for cache information. Note that at NO time does the unit modify the gpx file. It is retained AS LOADED by the user.
  • #2 is an internal table of caches that you CANNOT see - it is not part of the unit's visible file system, and you will not find it by connecting the unit to a computer.
  • #3 is a text file (geocache_visits.txt) that is created when a cache is logged (found, not found, etc.). All cache logs are appended to that file until it is deleted by the user. It is into the lines of this text file that any 'field notes' are also appended.

Taking the simplest of models, we'll work with a single gpx cache file created from a Pocket Query. When the gpx file (#1) is moved to the Garmin/GPX directory and the unit is booted, this new gpx file is discovered by the unit. ALL previous knowledge of found/not-found caches is at this time deleted from the internal table (#2, above). The unit now recreates its internal #2 table with slots for each of the caches found in the gpx file, and each slot retains certain current information about the cache, including its found/not-found state, even through power down/up cycles.

 

[Note: In the event that more than one gpx file is loaded, and data for any cache is found in more than one of the loaded gpx files, the design intent seems to have been that the most recent data (from whichever file) should be used. In practice, it seems to work that way most of the time, but not all of the time. ONLY ONE internal slot (#2) is created for a cache even if it is found in more than one loaded gpx file].

 

Go into the field. Look for a cache. Log the cache as found.

 

  • As stated previously, the gpx file (#1) is NOT touched.
  • The slot for this cache in the unit's internal table (#2) has the 'found' bit set. You'll see it as found on the map, and "Show Found" is the only way to bring it up in the cache list again.
  • A record is appended to the geocache_visits.txt (#3) file for this log.

Things continue as described above as caches are found (or not) and logged. The gpx file is untouched, the internal table keeps getting updated with found/not-found information, and the geocache_visits.txt log file keeps getting bigger.

 

Items to know...

First - There is NO mechanism for deleting individual caches from the control panel of the unit. This same bloody question gets asked at least once a week in these forums, is politely answered by someone, is already well defined in the old Oregon Wiki, and frankly, isn't that hard to find in these threads if people would read them. You cannot delete a found cache from the unit's control panel. You cannot delete an unfound cache from the unit's control panel.

Second - There is NO mechanism for reading or editing your geocache_visits.txt field notes from the control panel of the unit after you complete the entry. This question comes up fairly frequently as well.

 

If you forgot to add a field note or need to add additional field note information to a cache you've already logged as found, you can select "Geocaches" / "Show Found", select the cache that you have already found, and create another log (even an "unattempted" log) for it and add more field note information. That WILL create a duplicate log for this cache, and you need to pay attention to that if you are using the gc.com field notes feature so that you don't accidentally double log the cache, but at least it's a way to get more information recorded rather than relying upon memory. If you logged the cache as "Not Found", you can simply repeat the "Not Found" and add more field note data. Again, you need to manage the fact that there will now be two Not Found entries in the field notes.

 

If you log as found by accident, using "Show Found", reselect the cache. "Log Attempt" again, but this time, log it as "Did Not Find". This will do two things. First, it will place it BACK into the list of unfound caches again such that you will see it when looking at the list of unfound caches. It will also cause the map icon to revert to the 'unfound' icon. There is a 3rd effect that you'll have to remember -- the geocache_visits.txt file will now contain TWO logs for this cache. The first will be a "found" log, and the second the "didn't find" log. You will need to manage this manually by deleting the unnecessary log if you upload your field notes to gc.com.

 

Managing geocache_visits.txt:

 

Right. Done caching for now. Go home, hook up, and upload the field notes (geocache_visits.txt) file. Manage any duplicates you may have found it necessary to create, or that were created by accident. Uploading this file does not delete it from your unit. gc.com recalls the last time you uploaded notes, and attempts to avoid acceptance of logs that have already been uploaded. So while you may be sending the entire geocache_visits.txt file, only those entries that post-date the date shown on the gc.com field notes page will actually be accepted (unless you change that date for some reason). So while it may appear to purge that file after each uploading session, it does NOT. This file will just continue getting larger and larger with each geocaching expedition, one log line being appended to it for every cache you log on the face of your unit. The only way to prevent this file from growing endlessly is to hook it up to your PC, navigate to the Garmin directory, and delete it.

 

Managing found/not-found states and gpx files:

 

The only way to remove caches from your unit (either found or unfound) is to send a new gpx file to the unit. The idea that BaseCamp can delete individual caches is VERY misleading. A text editor could do the same job. In both cases, it's the fact that the gpx file on the unit has been modified directly by an application or a new file has been loaded in place of the old file (could be read from the unit, modified and sent back to the unit, or could be a new file entirely) that causes the unit to re-read and parse all gpx file info in the GPX directory and rebuild its internal (#2) table. BaseCamp does NOT and CANNOT modify the internal (#2) table of the GPS. It can only modify and move gpx files to/from the unit.

 

Even changing the time stamp on a gpx file (#1) causes the unit to reevaluate the gpx files for changes and reload the internal table (#2) for those caches found in modified gpx file(s). Therefore, the way to 'remove' found caches from the unit is to supply it with a gpx file that does not any longer contain those found caches. During the reevaluation, the unit will 'forget' anything it already knew about caches, and no longer seeing your found cache in a gpx, doesn't even know that they exist.

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