Welches ist der ideale Datentyp für die Speicherung von Breiten- und Längengraden in einer MySQL-Datenbank?

Question

In Anbetracht der Tatsache, dass ich Berechnungen auf Lat/Long-Paaren durchführen werde, welcher Datentyp ist am besten für die Verwendung mit einer MySQL-Datenbank geeignet?

Answer 1

Im Grunde genommen hängt es davon ab, welche Präzision Sie für Ihre Standorte benötigen. Mit DOUBLE haben Sie eine Genauigkeit von 3,5nm. DECIMAL(8,6)/(9,6) geht bis zu 16cm. FLOAT ist 1,7m...

Diese sehr interessante Tabelle enthält eine vollständigere Liste: http://mysql.rjweb.org/doc.php/latlng :

Datatype               Bytes            Resolution

Deg*100 (SMALLINT)     4      1570 m    1.0 mi  Cities
DECIMAL(4,2)/(5,2)     5      1570 m    1.0 mi  Cities
SMALLINT scaled        4       682 m    0.4 mi  Cities
Deg*10000 (MEDIUMINT)  6        16 m     52 ft  Houses/Businesses
DECIMAL(6,4)/(7,4)     7        16 m     52 ft  Houses/Businesses
MEDIUMINT scaled       6       2.7 m    8.8 ft
FLOAT                  8       1.7 m    5.6 ft
DECIMAL(8,6)/(9,6)     9        16cm    1/2 ft  Friends in a mall
Deg*10000000 (INT)     8        16mm    5/8 in  Marbles
DOUBLE                16       3.5nm     ...    Fleas on a dog

Ich hoffe, das hilft.

Answer 2

Verwenden Sie die MySQL räumliche Erweiterungen mit GIS.

Answer 3

Google stellt eine komplette PHP/MySQL-Lösung für eine Beispielanwendung "Store Locator" mit Google Maps zur Verfügung. In diesem Beispiel werden die lat/lng-Werte als "Float" mit einer Länge von "10,6" gespeichert.

http://code.google.com/apis/maps/articles/phpsqlsearch.html

Answer 4

Die Spatial Extensions von MySQL sind die beste Option, da Ihnen die gesamte Liste der räumlichen Operatoren und Indizes zur Verfügung steht. Mit einem räumlichen Index können Sie sehr schnell entfernungsbasierte Berechnungen durchführen. Bitte denken Sie daran, daß die Spatial Extension in Version 6.0 noch unvollständig ist. Ich will MySQL Spatial nicht schlecht machen, sondern Sie nur auf die Fallstricke hinweisen, bevor Sie zu weit in die Sache einsteigen.

Wenn Sie ausschließlich mit Punkten und nur mit der Funktion ABSTAND arbeiten, ist das in Ordnung. Wenn Sie Berechnungen mit Polygonen, Linien oder gepufferten Punkten durchführen müssen, liefern die räumlichen Operatoren keine genauen Ergebnisse, es sei denn, Sie verwenden den Operator "relate". Siehe die Warnung am Anfang von 21.5.6 . Beziehungen wie "enthält", "innerhalb" oder "schneidet" verwenden den MBR und nicht die genaue Geometrieform (d. h. eine Ellipse wird wie ein Rechteck behandelt).

Außerdem sind die Entfernungen in MySQL Spatial in denselben Einheiten wie Ihre erste Geometrie. Das heißt, wenn Sie Dezimalgrad verwenden, dann sind Ihre Entfernungsmessungen in Dezimalgrad. Dadurch wird es sehr schwierig, genaue Ergebnisse zu erhalten, wenn Sie sich weiter vom Äquator entfernen.

Answer 5

Als ich dies für eine Navigationsdatenbank auf der Basis von ARINC424 gemacht habe, habe ich eine Menge Tests durchgeführt, und wenn ich mir den Code anschaue, habe ich eine DECIMAL(18,12) verwendet (eigentlich eine NUMERIC(18,12), weil es ein Firebird war).

Floats und Doubles sind nicht so präzise und können zu Rundungsfehlern führen, was eine sehr schlechte Sache sein kann. Ich kann mich nicht erinnern, ob ich echte Daten gefunden habe, bei denen es Probleme gab - aber ich bin mir ziemlich sicher, dass die Unfähigkeit, genau in einem Float oder Double zu speichern, Probleme verursachen könnte

Der Punkt ist, dass wir bei der Verwendung von Grad oder Bogenmaß den Bereich der Werte kennen - und der Bruchteil benötigt die meisten Stellen.

El Räumliche Erweiterungen von MySQL sind eine gute Alternative, denn sie folgen Das OpenGIS-Geometriemodell . Ich habe sie nicht verwendet, weil ich meine Datenbank portabel halten musste.