Latitude and longitude storage requirements

[Mike]

After doing some research, it looks like in order to accurately store the
latitude and longitude of a point I must use an 8 byte (64 bits) floating
point variable for each of the coordinates. This would mean that to store
one point (latitude and longitude) I will need a total of 16 bytes (128
bits).

I came up with this conclusion after trying to parse some GPS coordinates
into a 4 Byte (32-bits) variable and noticing that the value was being
rounded.

The thing that bothers is that I took a look at the Garmin dlls that are
used to communicate with their GPS devices and notice that the dll returns
the coordinates using a 4-Byte value (32-bits), but then if I look at the
files generated by the devises after saving the track points I notice that
the track points are saved on the file needing an 8-Byte (64-Bit) variable.

I am sure that the accuracy for GPS is not really that big between using a 4
or 8 byte variables to store this points but I was wondering if anyone could
tell me what is the correct storage size that it should be used when storing
this values.

Any links explaining the subjects are appreciated.

Thanks.

 

[peter]

After doing some research, it looks like in order to accurately store the
latitude and longitude of a point I must use an 8 byte (64 bits) floating
point variable for each of the coordinates. This would mean that to store
one point (latitude and longitude) I will need a total of 16 bytes (128
bits).

I came up with this conclusion after trying to parse some GPS coordinates
into a 4 Byte (32-bits) variable and noticing that the value was being
rounded.

The thing that bothers is that I took a look at the Garmin dlls that are
used to communicate with their GPS devices and notice that the dll returns
the coordinates using a 4-Byte value (32-bits), but then if I look at the
files generated by the devises after saving the track points I notice that
the track points are saved on the file needing an 8-Byte (64-Bit) variable.

I am sure that the accuracy for GPS is not really that big between using a 4
or 8 byte variables to store this points but I was wondering if anyone could
tell me what is the correct storage size that it should be used when storing
this values.

My understanding is that internally Garmin uses 32-bit binary values to
represent lat/long values. That allows for resolution down to about 1
cm (i.e. 360 degrees of lat. divided by 2^32) which should be
sufficient for consumer GPS devices.

 

[Mike]

The problem is that the files generated by the Garmin devices (such as
Forerunner 305) call for latitude and longitude to be 64 bits. If their
devices use 32 bits internally then why have a file specification that calls
for 64 bits variables???



The worst part is that parsing some of the values on the file to 32 bit
variables will create rounding. My question again is, if Garmin uses 32 bits
internally, how in the world did it save values (on the file) that require a
64 bit variable??? Where did it get the extra precision from???

 

[Keith Sheppard]

The worst part is that parsing some of the values on the file to 32 bitCould be to allow for future enhancement. It's much easier to change your
internal workings than it is to change your file spec once it's been
published and/or you have existing files to accommodate.

In my own software (http://homepages.tesco.net/~Keith.Sheppard/MapMan.htm),
I use 64 bit floating point variables for all internal calculations and in
my file save format, simply because that was the highest resolution
available to me.

Keith

 

[Peter Davis]

The worst part is that parsing some of the values on the file to 32 bit
variables will create rounding. My question again is, if Garmin uses 32 bits
internally, how in the world did it save values (on the file) that require a
64 bit variable??? Where did it get the extra precision from???

I'd guess it's the difference between fixed point and floating point
representations. You're using 32 and 64 bit floats/doubles, which
wastes whole lot of values outside of the 0-360 range. Internally,
GARMIN uses a fixed point representation that maps all 32 bits into
that range to maximize precision-per-bit.

 

[Mike]

Let me see if I got this right, are you saying that Garmin uses an unsigned
32 bit number effectively dividing the latitude and longitude degrees into
4294967295 chunks?

So in the case of latitude, Garmin its actually dividing 180 degrees by
4294967295 ending up with an approximate
0.000000041909515867454352757766459313633 degree chunks? (I made the
division using the Windows built in calculator)

If this is true, this means that the resolution that Garming can have is
pretty darn big. I wasn't even able to parse this value into a double (64
bit) variable without loosing accuracy.

So in theory, you would need more than a 64 bit variable to store the value
(as degrees). I imagine that the GPS signal accuracy (even for the military)
is not that high anyway so using a 64 bit variable would be more than
enough, in fact after experimenting I saw no different whatsoever between
using 32 and 64 bit variable when plotting GPS points so I am wondering if I
should just use a 32 bit one.

 

[peter]

Let me see if I got this right, are you saying that Garmin uses an unsigned
32 bit number effectively dividing the latitude and longitude degrees into
4294967295 chunks?

So in the case of latitude, Garmin its actually dividing 180 degrees by
4294967295 ending up with an approximate
0.000000041909515867454352757766459313633 degree chunks?

Close, but it's 360 degrees (or a signed 180) to cover the globe in
longitude. So Garmin uses what they designate as semicircles of
1/(2^31) degrees for their internal format. That gives the resolution
of about a cm that I mentioned before.

If this is true, this means that the resolution that Garming can have is
pretty darn big. I wasn't even able to parse this value into a double (64
bit) variable without loosing accuracy.

So in theory, you would need more than a 64 bit variable to store the value
(as degrees). I imagine that the GPS signal accuracy (even for the military)
is not that high anyway so using a 64 bit variable would be more than
enough, in fact after experimenting I saw no different whatsoever between
using 32 and 64 bit variable when plotting GPS points so I am wondering if I
should just use a 32 bit one.

Up to you. The internally carried resolution certainly exceeds the
measurement accuracy by a wide margin.

 

[Victor Fraenckel]

I think that whatever compiler Garmin is using in their apps dictates
the size of their floating point numbers. Usually, IIRC, this means that
a size of a float is 32 bits (4 bytes) and the size of a double is 64
bits (8 bytes). If Garmin uses doubles for internal calculations they
can be "cast" into floats or vice versa.

Just my two cents

Vic
victorf ATSIGN windreader DOT com
KC2GUI

 

[Gilbert Smith]

Close, but it's 360 degrees (or a signed 180) to cover the globe in
longitude. So Garmin uses what they designate as semicircles of
1/(2^31) degrees for their internal format. That gives the resolution
of about a cm that I mentioned before.

Up to you. The internally carried resolution certainly exceeds the
measurement accuracy by a wide margin.

The semicircular unit is a signed 32 bit value used internally as
described, but for waypoint storage purposes (and therefore positional
resolution of stored points) they only keep the top 26bits for 'user'
waypoints, only the top 21bits for aviation database points, and only
the top 18bits for special use airspace points.

 

[John]

Memory isn't the scarce resource it used to be. However, if you're
saving a series of data points, you could save deltas rather than the
points themselves. Assuming 4 m accuracy, speed < 230 kph and updates
every second, you need 5 bits each to represent changes in lattitude
and longitude.

Add compression, and you could probably reduce memory again by 1/2.
Adaptive compression should work very well since walking is slow and
vehicles usually travel the same speed and direction from one second to
another.

 

[Mike]

Very interesting and cool information, a big thanks to everyone.