1

I'm a GIS newbie and I'm trying to figure out how I might store WGS84 coordinates as an integer efficiently. I could simply multiply it (10e7 for example) but I feel like this must be a problem that's been solved before. It seems, though, that there isn't any standard that uses integers. I'm using datasets that require integers for co-ordinates so need to create my own integer co-ordinate system, and I'm struggling to "stand on the shoulders of giants" with this particular problem.

Is there some standard to do this?

It looks like google just uses 10e7 for their tracking information for example.

Is that the most efficient way to do this?

PolyGeo
  • 65,136
  • 29
  • 109
  • 338
JasonG
  • 111
  • 3
  • ArcGIS uses multiplication, but also a false origin, so the resulting values are unsigned long integers (64-bit). Esri then applies an adaptive compression algorithm, so the byte stream is iX0,iY0,dX1,dY1,... It's documented in their whitepaper – Vince May 20 '21 at 02:21

2 Answers2

1

This does provoke the question of why is it beneficial to store WGS84 lat/lon as integers, versus a (32-bit?) real if you need WGS84 and just want to store efficiently, or in a projected CRS like UTM. But that's outside the scope of the question.

I do think scaling by 10^d, where d is number of significant decimal digits is probably your best bet. The extremely well written (and highly rated!) answer at Measuring accuracy of latitude and longitude? will help determine what d should be, depending on what distance rounding error is a meaningful one for you.

Alternately, you could think of storing the rounded-integer number of minutes or seconds by multiplying by 60 or 3600. 1 minute represents approx 1.85km in the N-S direction (latitude). 1 second is about 30 metres N-S. (Multiply by cos(latitude) for approx distance E-W).

The only other semi-canonical format I know of is the scaled latitude and longitude of GPS NMEA data, but that a) still has significant figures behind the decimal, and generates artifacts around 59->0 GPS minutes (it's a string not integer in format DDDMM.MMM...).

Houska
  • 7,976
  • 19
  • 48
0

WARNING: The simplest solution would be to just change the data format to allow decimals. Writing convoluted code to work around a seemingly arbitrary format constraint seems wrong

That being said, you can store the values in two fields, the 2nd one being just for the decimals. You can then stitch back the 2 together when you can work with decimals again.

JGH
  • 41,794
  • 3
  • 43
  • 89
  • Yeah I thought about that, or hms. Or *10e7 or bitshifting. There are some constraints around using floats depending on where you're working, like rust won't support hashing of floats. – JasonG May 20 '21 at 16:46