Latitude and longitude storage requirements

Discussion in 'General GPS Discussion' started by Mike, Jun 26, 2006.

  1. Mike

    Mike Guest

    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.
     
    Mike, Jun 26, 2006
    #1
    1. Advertisements

  2. Mike

    peter Guest

    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.
     
    peter, Jun 26, 2006
    #2
    1. Advertisements

  3. Mike

    Mike Guest

    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???
     
    Mike, Jun 26, 2006
    #3
  4. 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
     
    Keith Sheppard, Jun 26, 2006
    #4
  5. Mike

    Peter Davis Guest


    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.
     
    Peter Davis, Jun 26, 2006
    #5
  6. Mike

    Mike Guest

    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.
     
    Mike, Jun 26, 2006
    #6
  7. Mike

    peter Guest

    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.
     
    peter, Jun 27, 2006
    #7
  8. 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
     
    Victor Fraenckel, Jun 27, 2006
    #8
  9. 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.
     
    Gilbert Smith, Jun 27, 2006
    #9
  10. Mike

    John Guest

    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.
     
    John, Jun 28, 2006
    #10
  11. Mike

    Mike Guest

    Very interesting and cool information, a big thanks to everyone.
     
    Mike, Jun 28, 2006
    #11
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Similar Threads
There are no similar threads yet.
Loading...