Database/SQL: How to store longitude/latitude data?

Question

Performance question ...

I have a database of houses that have geolocation data (longitude & latitude).

What I want to do is find the best way to store t

Answer 1

Float (10,6)

Where is latitude or longitude 5555.123456?

Don't you mean Float(9,6) instead?

Answer 2

I have the exact same schema (float(10,6)) and query (selecting inside a rectangle) and I found that switching the db engine from innoDB to myisam doubled the speed for a "point in rectangle look-up" in a table with 780,000 records.

Additionally, I converted all lng/lat values to cartesian integers (x,y) and created a two-column index on the x,y and my speed went from ~27 ms to 1.3 ms for the same look-up.

Answer 3

The problem with using any other data type than "spatial" here is that your kind of "rectangular selection" can (usually, this depends on how bright your DBMS is - and MySQL certainly isn't generally the brightest) only be optimised in one single dimension.

The system can pick either the longitude index or the latitude index, and use that to reduce the set of rows to inspect. But after it has done that, there is a choice of : (a) fetching all found rows and scanning over those and test for the "other dimension", or (b) doing the similar process on the "other dimension" and then afterwards matching those two result sets to see which rows appear in both. This latter option may not be implemented as such in your particular DBMS engine.

Spatial indexes sort of do the latter "automatically", so I think it's safe to say that a spatial index will give the best performance in any case, but it may also be the case that it doesn't significantly outperform the other solutions, and that it's just not worth the bother. This depends on all sorts of things like the volume of and the distribution in your actual data etc. etc.

It is certainly true that float (tree) indexes are by necessity slower than integer indexes, because of the longer time it usually takes to execute '>' on floats than it does on integers. But I would be surprised if this effect were actually noticeable.

Answer 4

It really depends on how you are using the data. But in a gross over-simplification of the facts, decimal is faster but less accurate in aproximations. More info here:

http://msdn.microsoft.com/en-us/library/aa223970(SQL.80).aspx

Also, The standard for GPS coordinates is specified in ISO 6709:

http://en.wikipedia.org/wiki/ISO_6709

Answer 5

float(10,6) is just fine.

Any other convoluted storage schemes will require more translation in and out, and floating-point math is plenty fast.

Answer 6

Google uses float(10,6) in their "Store locator" example. That's enough for me to go with that.

https://stackoverflow.com/a/5994082/1094271

Also, starting MySQL 5.6.x, spatial extensions support is much better and comparable to PostGIS in features and performance.