Jump to content

GPX Needs High-Order Zeros in Waypoint ID


Norm DePlume

Recommended Posts

I don't pretend to understand much about how GPX works, so I may be missing something here. I'm hoping you can help me.

 

Are you saying there is an ID field in the XML that is separate from the Waypoint field? If so, I don't see it when I bring the GPX file into ExpertGPS. I also only see "Waypoint" listed on the "Available Columns" menu. Perhaps something's missing from ExpertGPS?

 

If they both exist in the GPX file, and the ID field has the leading zeroes, I'll take it up with TopoGrafix. And in that case you're right, I wouldn't want to mess with the waypoint field either.

 

Thanks for any information you can give me.

Link to comment

The ID field is a numeric field (the last portion of each cache's url).

 

50000[/b]]www.geocaching.com/seek/cache_details.aspx?ID=50000

 

That 50000 is translated to Hex (GCC350). Both are stored in the GPX file.

 

Here's a portion of one of the caches:

 

GC1E07

Black Partridge Surprise by grampa, Unknown Cache (1/1)

http://www.geocaching.com/seek/cache_details.asp?ID=7687

Black Partridge Surprise by grampa

Geocache Found

Geocache

 

It's an issue with Topografix programs not displaying it (yet). You might want to look into some of the other applications being built to look at GPX files.

 

Or, as you said, take it up with Topographix and have them fix it in EasyGPS and ExpertGPS.

 

Markwell

Chicago Geocaching

Link to comment

quote:
Originally posted by Markwell:

The ID field is a numeric field (the last portion of each cache's url).

 

http://www.geocaching.com/seek/cache_details.aspx?ID=_50000_

 

That 50000 is translated to Hex (GCC350). Both are stored in the GPX file.

 


 

While that's true today, according to Elias' recent comments, it's soon to be hex-not and instead become an insanely complicated encoding that I'll wager right now will be screwed up by a substantial number of programs.

 

I have software (not GPSBabel, different stuff) that does naive things like

 

if ( $cn =~ m/^GC/) {

$cn =~ s/GC//;

$cn = hex($cn);

 

and it will spontaneously combust when "GCGK" (hey, we need a term to describe the rollover in a sound-byte that CNN can grasp) hits.

 

I'll start a pool right now that the cited program won't be the only one that'll start coughing up its skull when GCGK hits. I'll bet LOTS of stuff is predicated on this being a straight hex->decimal conversion since that's what it's been so far.

 

Curiously, I'm not motivated to actually fix my stuff yet as I keep hoping that a simpler scheme will be produced before it actually matter.

 

P.S. I just filed a trademark on "GCGK" to describe the rollover on GC#'s after GCFFFF. I can find no prior art to it and demand a royalty of one cache placement and $.37 and the left eye of a goat every time it's used. icon_biggrin.gif

Link to comment

I know, I know. My query to put that stuff up in my DB now is pretty simple, too.

 

IIF([GCIDDecimal]=null or <=65535,"GC"&Hex[[GCIDDecimal]),"GCGK©")

 

It's what to put in that query when we hit 65536. I then may go back to what I did originally (which was a real problem), figure out the definition that Elias and Jeremy are going to implement, and list the IDs in one column and the resultant waypoint name in another on a lookup table. icon_eek.gif My database was huge when I did that for the 64K hex waypoints.

 

Markwell

Chicago Geocaching

Link to comment

quote:
Originally posted by Markwell:

The ID field is a numeric field (the last portion of each cache's url).

 

http://www.geocaching.com/seek/cache_details.aspx?ID=_50000_

 

 

It's an issue with Topografix programs not displaying it (yet).


 

That explains it, then. I now understand, and I withdraw my original request.

 

Thanks for the help. Hmmmm... have I been Markwelled without having been "Markwelled"?

Link to comment
Guest
This topic is now closed to further replies.
×
×
  • Create New...