MoapaPk wrote:Perhaps not the standard gdb, but I have at one time gotten output from MapSource (after directly reading the GPS), and I'd swear it had a column for "accuracy"; but I'm not certain, so that's why I said "may". If that information is never stored in the unit, I guess that I was dreaming. I also seem to remember that the accuracy field was flashing blue and pink, and had giraffes.
LOL. Yes, I did, literally out loud.
MoapaPk wrote:My only experience with gdb on the binary level, was when I used a binary editor to pull out the long and lat from a gdb file that someone had mistakenly tried to edit, then saved as text. My recollection is that the lat and long data were stored as scaled integers. Is there also a field that says how many fields follow in each structure?
In a GDB file, each record starts with four bytes indicating the length of record, but this length does not count these four bytes nor the byte following. The byte following designates the record type, and for waypoints it is hex 57 or ASCII for "W." I bet you can guess what it is for a track or a route.
For a waypoint record, the waypoint name is written next, in ASCII. So already the record length is variable, dependent on how many characters are in the waypoint name.
Immediately following this are 28 bytes. In hex, they are: 10-00s, 12-FFs, 2-00s, and 4-FFs.
Then there are four bytes for latitude followed by four for longitude. Both lat and lon are stored the same way, with the 360-degree range of values spread across the entire 4,294,967,296 values of the four bytes. (This gives a resolution of .0000000838 degrees.) So 0 degrees is hex 00 00 00 00, 90 degrees is hex 40 00 00 00, negative 90 degrees is C0 00 00 00, and 180 degrees equals negative 180 degrees, which is 80 00 00 00. Note that the four bytes are written with the least-significant byte first.
Following this is one byte indicating whether or not the elevation is known. The byte's value is either 00 or 01 hex. If the elevation is known, there are 8 bytes for elevation (in meters) which are in
double precision floating-point format according to IEEE Standard 754. If you think this looks complicated, with part of a byte being used for one value and the other part for another value, think about the fact that I was able to decode this before I read and knew about IEEE Standard 754. And the bytes are written in "reverse" order, with the least-significant byte first.
Next is the waypoint description, again in ASCII, and again this variable-length string adds another variable to the length of the waypoint record.
There are bytes for "proximity," display type, symbol type, depth, URLs, category, temperature, and modified date. Not all of these are used in the 60CSx, but these values can be used and modified by MapSource.