Quel est le type de données idéal doit être utilisé lorsqu'il est stocké des latitudes stockées / Longitude dans la base de données MySQL?

Considérant que je vais effectuer des calculs sur des paires lat / long, Quel type de données convient le mieux à une utilisation avec la base de données MySQL?
Invité:

Dominique

Confirmation de:

Utilisation
https://dev.mysql.com/doc/refm ... .html
MySQL avec GIS.

Emile

Confirmation de:

Google Fournit une solution start to finish PHP/MySQL Par exemple "Store Locator" avec Google Maps. Dans cet exemple, ils stockent des valeurs lat/lng comme "Float" Avec longtemps "10,6"

http://code.google.com/apis/ma ... .html

Hannah

Confirmation de:

Cela dépend principalement de la précision requise pour vos emplacements. Utilisant DOUBLE, Vous obtiendrez une précision 3.5nm. DECIMAL/8,6///9,6/ Décomposition 16 Voir le float est 1.7m. ..

Cette table très intéressante a une liste plus complète:
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


J'espère que cela aidera.

Gaetan

Confirmation de:

Extensions spatiales MySQL - La meilleure option est que, à votre disposition, il existe une liste complète des opérateurs et des index spatiaux. L'indice spatial vous permettra d'effectuer des calculs très rapidement basés sur la distance. S'il vous plaît gardez à l'esprit comme 6.0 L'expansion spatiale n'est toujours pas terminée. Je ne mets pas MySQL Spatial, vous informez simplement des pièges avant d'aller trop loin dans cette affaire.

Si vous traitez strictement avec des points et seulement avec une fonction DISTANCE, c'est normal. Si vous devez effectuer des calculs avec des polygones, des lignes ou des points tamponnés, les opérateurs spatiaux ne donnent pas de résultats exacts si vous n'utilisez pas l'opérateur. "relate". Voir avertissement en haut
http://dev.mysql.com/doc/refma ... .html
. Relations comme contains, within ou intersects, Utilisé MBR, et non exacte forme géométrique /C'est-à-dire que l'ellipse est considérée comme un rectangle/.

En outre, des distances dans MySQL Spatial Sont dans les mêmes unités de mesure que votre première géométrie. Cela signifie que si vous utilisez des degrés décimaux, vos mesures de distance sont effectuées en degrés décimales. Il sera très difficile d'obtenir des résultats précis tels que l'équateur.

Hannah

Confirmation de:

Quand je l'ai fait pour une base de données de navigation construite à partir de ARINC424, J'ai passé beaucoup de tests et je regarde en arrière le code, j'ai utilisé DECIMAL/18,12/ /réellement NUMERIC/18,12/, Parce que c'était firebird/.

Les flotteurs et les jumeaux ne sont pas aussi précis et peuvent entraîner des erreurs d'arrondies, ce qui peut être très mauvais. Je ne me souviens pas si j'ai trouvé quoi - ou les données réelles qui avaient des problèmes, mais je suis tout à fait sûr que l'incapacité de les stocker avec précision dans le flotteur ou la jumeau peut causer des problèmes

Le fait est que lorsque vous utilisez des degrés ou des radians, nous connaissons la gamme de valeurs. - Et la partie fractionnée nécessite plus de chiffres.

http://dev.mysql.com/doc/refma ... .html
MySQL sont une bonne alternative parce qu'ils suivent
http://dev.mysql.com/doc/refma ... .html
OpenGIS . Je ne les utilisais pas parce que j'avais besoin de conserver ma base de données portable.

Gilles

Confirmation de:

Dépend de la précision dont vous avez besoin.


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


De:
http://mysql.rjweb.org/doc.php/latlng
Résumation:

L'option disponible la plus précise disponible
DOUBLE

.

Le type le plus couramment utilisé
DECIMAL/8,6///9,6/

.

Commençant
https://dev.mysql.com/doc/relnotes/mysql/5.7/en/
5.7, Faire l'objet d'une utilisation
https://dev.mysql.com/doc/refm ... .html
/SDT/, en particulier
https://dev.mysql.com/doc/refm ... .html
Pour stocker une coordonnée. Avant que 5.7 SDT Ne prend pas en charge les index /à l'exception de 5.6, quand le type de table est égal MyISAM/.

Noter:

Lorsque vous utilisez la classe
POINT

L'ordre des arguments de stockage des coordonnées devrait être
POINT/latitude, longitude/

.

Il y a une syntaxe spéciale pour
https://dev.mysql.com/doc/refm ... .html
.

Le plus gros avantage d'utilisation SDT est-ce que vous avez accès à
http://dev.mysql.com/doc/refma ... .html
, Par exemple, le calcul de la distance entre deux points /
http://dev.mysql.com/doc/refma ... tance
/ et déterminer si un point contient dans une autre zone /
http://dev.mysql.com/doc/refma ... tains
/.

Agathe

Confirmation de:

Basé sur cet article wiki
http://en.wikipedia.org/wiki/D ... uracy
Le type de données approprié dans MySQL-Decimal /9,6/ pour stocker la longitude et la latitude dans
Champs séparés.

Daniel

Confirmation de:

Utilisation
DECIMAL/8,6/

Pour la latitude /de 90 avant que -90 degrés/ et
DECIMAL/9,6/

Pour la longitude /de 180 avant que -180 degrés/. 6 Les signes décimaux sont parfaits pour la plupart des applications. Les deux doivent être "signed", Prendre en compte les valeurs négatives.

Alice

Confirmation de:

Il n'y a pas besoin de marcher, selon Google Maps, la meilleure chose FLOAT/10,6/ pour lat et lng.

Gabriel

Confirmation de:

Nous stockons la largeur / Longitude X 1,000,000 Dans notre base de données oracle comme NUMBERS, Pour éviter d'arrondir des erreurs avec doubler.

Considérant que la latitude / longitude au 6ème signe après la précision de la virgule 10 Voir, c'était tout ce dont nous avons besoin. Beaucoup d'autres bases de données stockent également lat/long jusqu'au 6ème signe décimal.

Gilbert

Confirmation de:

Dans une perspective complètement différente et plus simple:

Si vous comptez sur Google Pour afficher vos cartes, des marqueurs, des polygones, tout ce qui permet de faire les calculs Google!

Vous enregistrez des ressources sur votre serveur et continuez de garder la latitude et la longitude ensemble sous la forme d'une ligne. /
VARCHAR

/, E.g.: "
https://www.google.com/maps/search/-0000.0000001,-0000.0000001
" /35 Longueur et si le nombre a plus 7 chiffres décimaux, alors il est arrondi/;

si un Google Retourne plus 7 Numéros décimaux au nombre, vous pouvez obtenir ces données stockées dans votre ligne de toute façon, au cas où vous voudriez détecter certains

;

Vous pouvez les utiliser
https://developers.google.com/ ... atrix
ou
https://developers.google.com/ ... metry
calculer des distances ou
https://developers.google.com/ ... ation
Utilisation d'appels simples comme celui-ci:
google.maps.geometry.poly.containsLocation/latLng, bermudaTrianglePolygon//


il y a beaucoup de "server-side" APIs peut être utilisé /à
https://github.com/googlemaps/ ... ython
,
http://www.sitepoint.com/use-google-maps-rails/
,
https://github.com/egeloen/ivory-google-map
,
http://biostall.com/codeignite ... brary
,
https://github.com/bradcornford/Googlmapper
,
http://www.yiiframework.com/extension/egmap/
,
https://github.com/cderue/GoogleMaps
, etc./ Que utiliser Google Maps API.

Ainsi, vous n'avez pas besoin de vous soucier des numéros d'indexation et de tous les autres problèmes liés aux types de données pouvant gâcher vos coordonnées.

Giselle

Confirmation de:

TL;DR

Utilisation FLOAT /8,5/, Si vous ne travaillez pas dans NASA / Militaire et ne produisent pas de systèmes de navigation aéronaucratique.

Pour répondre complètement à votre question, vous devrez envisager quelques choses:

Format


Degrés minute secondes

: 40° 26' 46 "N 79° 58' 56 " W

Minutes décimales de degrés

: 40° 26.767 'N 79° 58.933' W

Degrés décimaux 1

: 40.446° N 79.982° W

Degrés décimaux 2

: -32.60875, 21.27812

Un autre format maison? Personne ne vous interdit de créer votre propre système de coordonnées de coordonnées et de le conserver comme un cours et une distance de votre maison. Cela peut avoir du sens pour certains problèmes spécifiques que vous travaillez.

Donc, la première partie de la réponse sera la suivante: vous pouvez stocker les coordonnées dans

format qui utilise votre application

, Pour éviter les transformations constantes là-bas et le dos et faire des demandes plus simples SQL.

Plus probablement que vous utilisez Google Maps ou OSM Pour afficher vos données et GMaps Format d'utilisation "decimal degrees 2". Il sera donc plus facile de stocker les coordonnées dans le même format.

Précision

Ensuite, vous voulez déterminer la précision dont vous avez besoin. Bien sûr, vous pouvez stocker les coordonnées du type "-32.608697550570334,21.278081997935146", Mais vous êtes-vous déjà soucié de millimètres lorsque vous naviguez vers le point? Si vous ne travaillez pas dans NASA Et ne faites pas de trajectoires de satellites, de roquettes ou d'aéronefs, vous devriez bien aller avec une précision de plusieurs mètres.

Format habituellement utilisé - 5 chiffres après des points, qui vous donne une précision 50 cm.

Exemple

: il y a 1 Voir la distance entre x et

H.

21.278081

8,9

21.278081 . De cette façon, 7 chiffres après le point vous donner une précision 1/2 SM, A. 5 Chiffres après le point vous donnera une précision 1/2 mètre /Parce que la distance minimale entre différents points est 1 m, donc l'erreur d'arrondi ne peut pas être supérieure à la moitié/. Pour la plupart des fins civils, cela devrait suffire.

Format décimal degrés /40° 26.767 'N 79° 58.933' W/ vous donne exactement la même précision que 5 Chiffres après un point

Stockage spatio-efficacité

Si vous avez choisi un format décimal, votre coordonnée est un couple /-32.60875, 21.27812/. Il est évident que 2 x /1 Un peu pour le signe 2 chiffres de degrés et 5 Chiffres d'exposition/ sera suffisant.

Par conséquent, ici je voudrais soutenir

Alix Axel

Des commentaires, disant que l'offre Google continuer FLOAT/10,6/ vraiment superflu parce que vous n'avez pas besoin 4 Chiffres pour la partie principale /Puisque le signe est divisé, la latitude est limitée 90, Et la longitude est limitée 180/. Vous pouvez facilement utiliser FLOAT/8,5/ Pour Precision 1/2 m ou FLOAT/9,6/ Pour Precision 50/2 voir ou vous pouvez même stocker lat et long Dans certains types, parce que FLOAT/7,5/ assez pour lat. Voir le lien MySQL float types
https://dev.mysql.com/doc/refm ... .html
. Aucun d'entre eux sera similaire à celui habituel FLOAT Et en tout cas est égal 4 octets.

Habituellement, l'espace n'est actuellement pas un problème, mais si vous pour une raison quelconque, vous souhaitez vraiment optimiser le référentiel /Disclaimer: ne pas pré-optimiser/, Vous pouvez compresser lat/Pas plus 91 000 Valeurs + signe/ + long /Pas plus 181 000 Valeurs + signe/ avant que 21 Bit

, Ce qui est significativement moins

2xFLOAT /8 octet == 64 Bit/

Christine

Confirmation de:

En fonction de votre application, je propose d'utiliser FLOAT/9,6/

Les clés spatiales vous donneront plus d'opportunités, mais dans des repères de production, les floats sont beaucoup plus rapides que les clés spatiales. /0,01 VS 0,001 à AVG/

Camille

Confirmation de:

MySQL Les usages double Pour tous les flotteurs ...
Par conséquent, utilisez le type double. Utilisant float conduira à des valeurs arrondies imprévisibles dans la plupart des situations

Gilbert

Confirmation de:

Bien qu'il ne soit pas optimal pour toutes les opérations, si vous faites des carreaux de carte ou que vous travaillez avec beaucoup de marqueurs /Points/ seulement avec une projection /par exemple, Mercator, comme Google Maps et de nombreuses autres cartes-cadre glissantes attendent/, J'ai trouvé ce que j'appelle "Vast Coordinate System", Très très pratique. En principe, vous stockez les coordonnées des pixels x et y À un certain niveau way-zoomed-in - J'utilise le niveau de zoom 23. Il présente plusieurs avantages:

Vous effectuez une conversion coûteuse LAT/lng dans le pixel du merci une fois, et pas à chaque fois que vous traitez le point

L'obtention des coordonnées de la tuile de l'enregistrement avec un niveau de zoom spécifié occupe un décalage à droite.

L'obtention d'une coordonnée de pixels de l'enregistrement prend un décalage vers la droite et un bitwise AND.

Les changements sont si faciles à les rendre pratiques dans SQL, Que voulez-vous dire ce que vous pouvez faire DISTINCT, Pour ne renvoyer qu'un seul enregistrement sur l'emplacement de pixel, qui réduira le nombre d'enregistrements renvoyés par le backend, ce qui signifie moins de traitement à l'avant.

J'ai parlé de tout cela dans un blog récent:
http://blog.webfoot.com/2013/0 ... tion/
/

Emmanuel

Confirmation de:

Je suis très surpris par certains answers/comments.

Pourquoi sur Terre était-il nécessaire d'améliorer volontairement la précision, puis effectuer des calculs sur les pires chiffres? Cela semble extrêmement stupide.

Si la source a une précision 64-bit, Bien sûr, il serait stupide de fixer volontairement l'échelle, par exemple, 6 signes décimaux et limitent la précision maximale 9 Numéros significatifs /Qu'advient-il du format décimal habituellement proposé 9.6/.

Naturellement, les données sont stockées avec la même précision que le matériau source. La seule raison de la réduction de la précision serait un espace de stockage limité.

Gardez les chiffres source avec une précision originale

Gardez les nombres calculés à partir de la source, exactement avec lequel le calcul se produit /Par exemple, si le code d'application utilise le doublement, stockez les résultats en doublant/

Format décimal 9.6- Phénomène des caisses snap-to-grid. Ce devrait être la dernière étape si cela se produit du tout.

Je n'inviterais pas les erreurs accumulées dans votre nid.

Eugene

Confirmation de:

Fonctions spatiales B. PostGIS Beaucoup plus fonctionnel /c'est-à-dire non limité BBOX Exploitation/, que dans MySQL Caractéristiques spatiales. Vérifie ça:
http://postgis.refractions.net/

Charles

Confirmation de:

Latitude fluctue OT. -90 avant que +90 /degrés/, de sorte que DECIMAL/10, 8/ Très approprié pour cela

La longitude fluctue de -180 avant que +180 /degrés/, Par conséquent, vous avez besoin DECIMAL/11, 8/.

Remarque: premier numéro - Il s'agit du nombre total de numéros stockés et du deuxième numéro après le point décimal.

Bientôt parler:
lat DECIMAL/10, 8/ NOT NULL, lng DECIMAL/11, 8/ NOT NULL

Frederic

Confirmation de:

Je vous suggère d'utiliser Float datatype pour SQL Server.

Fabien

Confirmation de:

Lat Long Les calculs exigent une précision, utilisez donc un certain type de type décimal et faites-la de la précision au moins sur 2 Plus haut que le nombre, vous serez stocké pour effectuer l'informatique mathématique. Je ne connais pas mes types de données sql, Mais sur le serveur SQL Les gens sont souvent utilisés float ou real au lieu decimal Et ils tombent dans des ennuis, car il est estimé en nombre et non réel. Par conséquent, assurez-vous simplement que le type de données que vous utilisez est un vrai type décimal et non un type décimal flottant, et tout ira bien.

Clement

Confirmation de:

A
<a href="[url=http://dev.mysql.com/doc/refman/5.1/en/numeric-type-overview.htm"]http://dev.mysql.com/doc/refma ... ot%3B[/url] rel="nofollow noreferrer">
FLOAT
</a>

Doit vous donner toute la précision nécessaire et être meilleure pour les fonctions de comparaison que de stocker chaque coordonnée sous la forme d'une chaîne ou similaire.

Si votre version MySQL Plus tôt que 5.0.3, Vous devrez peut-être faire attention à certains
http://dev.mysql.com/doc/refma ... .html
.

Avant que MySQL 5.0.3 Colonnes DECIMAL Valeurs de stockage avec une précision précise telles qu'elles sont présentées sous forme de chaînes, mais des calculs par des valeurs DECIMAL Effectuée à l'aide d'opérations de point flottant. Commençant par 5.0.3, MySQL Effectuer DECIMAL Opérations jusqu'à 64 chiffres décimaux qui devraient résoudre les problèmes les plus courants d'inexactitudes quand il s'agit de DECIMAL Colonnes

Pour répondre aux questions, connectez-vous ou registre