Can anyone convert this 60-bit value to geographic coordinates?!

Question

I have a (DB2) database table containing location information, one column of which is a CHARACTER(16) and contains a single hexadecimal number. I have a program that displays these as points on a map, but no access to its source. Changing the numbers moves the points on the map — I just don't know the algorithm.

Some examples (edited to include more):

04867C279DE2D6EC -32.063657°  115.7658683°
04867C27C030085E -32.0633982° 115.7649085°
04867C27C230A5FE -32.0633846° 115.7653336°

Are there any standard ways that this is done? Is this some DB2 convention or something? Any ideas on how I could figure this out?

Thanks!

Answer 1

Perhaps its a UTM grid format?

http://www.uwgb.edu/dutchs/usefuldata/utmformulas.htm

There are a lot of variables in UTM of course (such as the Datum used).

Answer 2

Well, just trying to unpack the hex values in various ways...

#! /usr/bin/python
import struct
import binascii

a = '04867C279DE2D6EC'
b = '04867C27C030085E'
c = '04867C27C230A5FE'

formats = ['2I', '2i', '2f', 'd', '4h', '4H']
formats += ['>'+item for item in formats]

for fmt in formats:
    print fmt, '-->'
    for item in [a,b,c]:
        coords = struct.unpack(fmt, binascii.unhexlify(item))
        print '    ', coords

Yields some ideas...

2I -->
     (662472196, 3973505693)
     (662472196, 1577595072)
     (662472196, 4272238786)
2i -->
     (662472196, -321461603)
     (662472196, 1577595072)
     (662472196, -22728510)
2f -->
     (3.5044675291578432e-15, -2.07824221089183e+27)
     (3.5044675291578432e-15, 2.4533886735682109e+18)
     (3.5044675291578432e-15, -1.0978789217059195e+38)
d -->
     (-1.9722947342913136e+216,)
     (9.4395557694675488e+144,)
     (-1.135288151092706e+302,)
4h -->
     (-31228, 10108, -7523, -4906)
     (-31228, 10108, 12480, 24072)
     (-31228, 10108, 12482, -347)
4H -->
     (34308, 10108, 58013, 60630)
     (34308, 10108, 12480, 24072)
     (34308, 10108, 12482, 65189)
>2I -->
     (75922471, 2648889068)
     (75922471, 3224373342)
     (75922471, 3257968126)
>2i -->
     (75922471, -1646078228)
     (75922471, -1070593954)
     (75922471, -1036999170)
>2f -->
     (3.1617264522911893e-36, -6.0043925910101893e-21)
     (3.1617264522911893e-36, -2.7505106925964355)
     (3.1617264522911893e-36, -44.162101745605469)
>d -->
     (7.3832340678903009e-287,)
     (7.3832347392384709e-287,)
     (7.383234778429458e-287,)
>4h -->
     (1158, 31783, -25118, -10516)
     (1158, 31783, -16336, 2142)
     (1158, 31783, -15824, -23042)
>4H -->
     (1158, 31783, 40418, 55020)
     (1158, 31783, 49200, 2142)
     (1158, 31783, 49712, 42494)

Unpacking it as a big-endian unsigned 32bit integer (>2I) looks a bit like it might be projected coordinates of some kind...

 (-32.063657, 115.7658683) --> (75922471, 2648889068)
 (-32.0633982, 115.7649085) --> (75922471, 3224373342)
 (-32.0633846, 115.7653336) --> (75922471, 3257968126)

If it is in UTM, it's probably UTM Zone 50S, based on the lat, long... We don't know the datum, but that shouldn't make more than a couple of hundred meters difference.

For zone 50S:

(lat, long) --> (Easting, Northing)
(-32.063657, 115.7658683) --> (383506.31320936838, 6451842.2821839228)
(-32.0633982, 115.7649085) --> (383415.3800562254, 6451869.9348384682)
(-32.0633846, 115.7653336) --> (383455.49221963808, 6451871.9016738012)

(Using OSR's (horribly unpythonic) python wrappers...)

from osgeo import osr
def latlong2utm(lat, long):
    epsg_wgs84 = 4326
    epsg_utm50S = 32750
    inproj = osr.SpatialReference()
    inproj.ImportFromEPSG(epsg_wgs84)
    outproj = osr.SpatialReference()
    outproj.ImportFromEPSG(epsg_utm50S)
    transform = osr.CoordinateTransformation(inproj, outproj)
    x,y,_ = transform.TransformPoint(long, lat)
    return x, y

Unfortunately, it doesn't look like UTM Zone 50S, anyway... And Zone 49 doesn't look any better...

So, not much help, but I figured I'd post this to help other folks who might be trying the same path... (I also tried unpacking things as IBM floats instead of IEEE floats... No luck there either...) Maybe I'm just being stupid, but I'm out of ideas. Hopefully this helps a bit, though...

Answer 3

This could be morton codes.They are used to pack coordinates in one dimension.

Generating a Morton number is easy. All you do is convert the x and y coordinate numbers into binary. Then “interleave” the bits to get the Morton number. It does not matter which goes first, but you must be consistent.