Avec quelle précision dois-je stocker la latitude et la longitude?

103

Je lisais cette question ici:

Quel type de données utiliser lors du stockage des données de latitude et de longitude dans des bases de données SQL?

Et il semble que le consensus général est que l'utilisation de Decimal (9,6) est la voie à suivre. La question pour moi est, dans quelle mesure ai-je vraiment besoin de cela?

Par exemple, l'API de Google renvoie un résultat comme:

"lat": 37.4219720,
"lng": -122.0841430

Sur -122.0841430, de combien de chiffres ai-je besoin? J'ai lu plusieurs guides mais je ne peux pas en comprendre assez pour comprendre cela.

Pour être plus précis dans ma question: si je veux être précis à moins de 50 pieds de l'emplacement exact, combien de décimales dois-je stocker?

Peut-être qu'une meilleure question serait en fait une question non liée à la programmation, mais ce serait: combien plus précis chaque point décimal vous donne-t-il?

Est-ce simple?

Élément de liste
x00 = 6000 miles
xx0 = 600 milles
xxx = 60 milles
xxx.x = 6 milles
xxx.xx = 0,6 mille
etc?

mysql geolocation

— Citoyen
source

7

La précision des coordonnées dépend de l'endroit où se trouvent ces coordonnées, car la surface de la planète n'est pas une sphère parfaite et la distance des pôles est également un facteur MAJEUR MAJEUR. Cependant, 3 décimales décimales font en moyenne environ 120 mètres / 400 pieds. 4 décimales seraient 12 mètres / 40 pieds, etc ...

— Marc B

1

Voir cette question sur GIS stackexchange: gis.stackexchange.com/questions/8650/…

— Flimm

1

duplication possible de Quel est le type de données idéal à utiliser lors du stockage de latitude / longitudes dans une base de données MySQL?

— Gajus

191

Précision par rapport aux décimales à l'équateur

decimal  degrees    distance
places
-------------------------------  
0        1.0        111 km
1        0.1        11.1 km
2        0.01       1.11 km
3        0.001      111 m
4        0.0001     11.1 m
5        0.00001    1.11 m
6        0.000001   0.111 m
7        0.0000001  1.11 cm
8        0.00000001 1.11 mm

réf: https://en.wikipedia.org/wiki/Decimal_degrees#Precision

— Noushad
source

4

S'ils sont à l'équateur, cela signifie-t-il qu'il s'agit des pires erreurs?

— Liath

6

En fait, l'équateur est le meilleur des cas. Un degré de latitude et un degré de longitude ont la même taille à l'équateur (69 miles), mais un degré de longitude se réduit à zéro à l'approche de l'un ou l'autre des pôles. Voici une très belle explication: nationalatlas.gov/articles/mapping/a_latlong.html#four

— codingoutloud

11

@codingoutloud Ce qui ferait ces pires erreurs. Ou pour être pédant, ce sont les pires erreurs d'utilisation de lat / lon au niveau de la mer. À une altitude de 6 378 m, l'erreur augmente de 0,1%.

— Scott B

@codingoutload: Ce lien n'est apparemment plus présent :(

— Tom Stambaugh

1

@Tom Stambaugh: Il y a web.archive.org pour ça: web.archive.org/web/20070810120810/http://nationalatlas.gov/…

— Stefan Steiger

19

+----------------+-------------+
|    Decimals    |  Precision  |
+----------------+-------------+
|    5           |  1m         |
|    4           |  11m        |
|    3           |  111m       |
+----------------+-------------+

Si vous voulez une précision de 50 pieds (15 m), optez pour 4 chiffres. Alorsdecimal(9,6)

— Gustav
source

9

Si vous utilisez SQL Server ... Il convient de noter qu'une précision de 1 à 9 utilise 5 octets. Vous pouvez donc utiliser un décimal (9,6) au lieu d'un décimal (7,4) et profiter de la plus grande précision car ils occupent tous les deux le même espace.

— Theo

Pour la latitude, utilisez (8,6)(ou (6,4)pour enregistrer enregistrer un octet (dans MySQL).

— Rick James

15

Je conçois des bases de données et j'étudie cette question depuis un moment. Nous utilisons une application standard avec un backend Oracle où les champs de données ont été définis pour permettre 17 décimales. Ridicule! C'est dans les millièmes de pouce. Aucun instrument GPS au monde n'est aussi précis. Mettons donc de côté 17 décimales et traitons les aspects pratiques. Le gouvernement garantit que son système est bon à "une" précision de pseudo-portée "dans le pire des cas" de 7,8 mètres à un niveau de confiance de 95% ", mais poursuit en disant que la FAA (utilisant ses instruments de haute qualité) a montré que les lectures GPS sont généralement bonnes pour à moins d'un mètre.

Vous devez donc vous poser deux questions: 1) Quelle est la source de vos valeurs? 2) À quoi les données seront-elles utilisées?

Les téléphones portables ne sont pas particulièrement précis, et les lectures de Google / MapQuest ne sont probablement bonnes qu'à 4 ou 5 décimales. Un instrument GPS de haute qualité peut vous en procurer 6 (aux États-Unis). Mais capturer plus que cela est un gaspillage d'espace de frappe et de stockage. De plus, si des recherches sont effectuées sur les valeurs, il est bon pour un utilisateur de savoir que 6 serait le maximum qu'il / elle devrait rechercher (évidemment, toute valeur de recherche saisie doit d'abord être arrondie à la même précision que la valeur de données recherchée. ).

De plus, si tout ce que vous voulez faire est de visualiser un emplacement dans Google Maps ou de le mettre dans un GPS pour y arriver, quatre ou cinq, c'est beaucoup.

Je dois rire des gens d'ici qui entrent tous ces chiffres. Et où prennent-ils exactement cette mesure? Bouton de porte avant? Boîte aux lettres à l'avant? Centre du bâtiment? Haut de la tour cellulaire? ET ... est-ce que tout le monde le prend systématiquement au même endroit?

En tant que bonne conception de base de données, j'accepterais des valeurs d'un utilisateur pour peut-être quelques chiffres de plus de cinq décimales, puis arrondir et capturer seulement cinq pour la cohérence [peut-être six si vos instruments sont bons et votre utilisation finale le justifie].

— Greg
source

4

Bien que je convienne que 17 chiffres, c'est trop, je suggère que 6 est trop peu si les données doivent être post-traitées. Lorsque vous effectuez des actions telles qu'une requête de rayon ("Répondre à des entités dans un rayon de 0,5 mile de ce point"), les erreurs - y compris la troncature - sont amplifiées. Si vous avez besoin de 6 chiffres décimaux sur la sortie d'une telle requête, l' entrée doit commencer par beaucoup plus. Notre boutique a tendance à utiliser DECIMAL (18,15). Notre objectif est de faire en sorte que la base de données ne soit pas le facteur limitant de la précision des calculs spatiaux.

— Tom Stambaugh

Aller au-delà de 6 décimales va au-delà de la précision disponible des satellites GPS actuels. Le post-traitement n'introduira pas une quantité significative d'erreur. DECIMAL(18,15)prend 9 octets.

— Rick James

11

La distance entre chaque degré de latitude varie en raison de la forme de la terre et la distance entre chaque degré de longitude diminue à mesure que vous vous rapprochez des pôles. Parlons donc de l'équateur, où la distance entre chaque degré est de 110,574 km pour la latitude et de 111,320 km pour la longitude.

50 pieds équivaut à 0,01524 km, donc:

0,01524 / 110,574 = 1/7255 d'un degré de latitude
0,01524 / 111,320 = 1/7304 d'un degré de longitude

Vous avez besoin de quatre chiffres d'échelle, assez pour descendre à dix millièmes de degré, avec un total de sept chiffres de précision.

DECIMAL(7,4) devrait être suffisant pour vos besoins.

— Bill Karwin
source

5

En tenant compte des différentes parties d'une sphère et d'une distance diagonale, voici un tableau des précisions disponibles:

   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

- http://mysql.rjweb.org/doc.php/latlng#representation_choices

— Rick James
source

3

Ne stockez pas de valeurs à virgule flottante. Bien que vous puissiez supposer qu'ils sont exacts, ils ne le sont pas. Ils sont une approximation. Et il s'avère que différentes langues ont différentes méthodes pour "analyser" les informations en virgule flottante. Et différentes bases de données ont différentes méthodes d'implémentation des approximations de valeurs.

À la place, utilisez un Geohash . Cette vidéo présente et explique visuellement le Geohash en moins de 5 minutes. Le Geohash est de loin le meilleur moyen d'encoder / décoder les informations de longitude / latitude de manière cohérente. En ne "sérialisant" jamais les valeurs approximatives en virgule flottante d'une longitude / latitude dans des colonnes de base de données et en utilisant un Geohash, vous obtiendrez les mêmes garanties de cohérence aller-retour souhaitables que vous obtenez avec les valeurs String. Ce site Web est idéal pour vous aider à jouer avec un Geohash.

— équilibre chaotique
source

FLOATet DOUBLE, dans ce contexte , ne souffre pas de certains des problèmes que vous décrivez.

— Rick James

@RickJames Vous n'avez pas suffisamment spécifié "ce contexte". Si vous voulez dire, strictement dans le stockage d'une valeur dans deux colonnes DB, alors peut-être. Cependant, les valeurs données ne se trouvent pas simplement dans des colonnes de base de données inutilisées, l'hypothèse implicite qu'il y aura des requêtes (de proximité) écrites sur ces valeurs. Et tenir cette hypothèse assez pragmatique signifie alors que tous les problèmes d'une approximation non fiable continuent de se poser.

— équilibre chaotique

1

Si une FLOATvaleur et la valeur «suivante» sont si proches l'une de l'autre que vous ne pouvez pas distinguer une ville (ou un véhicule ou une personne ou une puce) d'une autre, alors les erreurs d'arrondi et de représentation n'ont pas d'importance. En attendant, il est presque toujours insensé de comparer deux FLOATs(ou DOUBLEsou approximativement DECIMALs) avec '='.

— Rick James

Vous semblez manquer le point. Toute tentative de requête utilisera implicitement égales, sinon explicitement. Et cela suppose que vous ne passiez pas par d'autres couches et langages avec les valeurs, en restant strictement à l'intérieur de SQL Server. Voici une réponse officielle de Microsoft à cela pour SQL Server: blogs.msdn.microsoft.com/qingsongyao/2009/11/14/…

— chaotic3quilibrium

Je suis désolé, je pensais que la question était balisée [mysql], pas SQL Server.

— Rick James

2

Si vous cliquez sur des emplacements sur Google Maps, vous obtenez la latitude et la longitude avec 7 décimales

— Sauvage
source