type approprié/meilleur pour stocker la latitude et la longitude

Question

Dans un langage de programmation de niveau système comme C, C++ ou D, quel est le meilleur type/encodage pour stocker la latitude et la longitude ?

Les options que je vois sont :

• IEEE-754 FP en degrés ou radians
• degrés ou radians stockés comme une valeur à virgule fixe dans un int de 32 ou 64 bits
• mise en correspondance d'un intervalle de nombres entiers avec l'intervalle de degrés : -> deg = (360/2^32)*val
• degrés, minutes, secondes et fractions de secondes stockés sous forme de champs binaires dans un fichier int.
• une sorte de structure.

La solution facile (FP) présente l'inconvénient majeur d'avoir une résolution très inégale (quelque part en Angleterre, il peut mesurer en microns, alors qu'au Japon, il ne le peut pas). Elle pose également tous les problèmes de comparaison des PF et autres. Les autres options nécessitent des efforts supplémentaires à différents stades du cycle de vie des données. (génération, présentation, calculs, etc.)

Une option intéressante est un type de précision flottante où, à mesure que la latitude augmente, le nombre de bits augmente et la longitude diminue (car ils se rapprochent l'un de l'autre vers les pôles).

Questions connexes qui ne couvrent pas tout à fait ce sujet :

• Quel est le type de données idéal à utiliser pour stocker les latitudes et les longitudes dans un fichier MySQL ?
• Travailler avec des valeurs de latitude/longitude en Java

---

BTW : 32 bits vous donnent une résolution E/W à l'équateur d'environ 0.3 in. C'est proche de l'échelle à laquelle les GPS de haute qualité peuvent travailler (IIRC, ils peuvent descendre à environ 0,5 pouce dans certains modes).

Par contre, si les 32 bits sont répartis uniformément sur la surface de la terre, vous pouvez indexer des carrés d'environ 344 m de côté, 5 octets donnent 21 m, 6B->1,3 m et 8B->5 mm.

Je n'ai pas d'utilisation spécifique en tête pour le moment, mais j'ai déjà travaillé avec ce genre de choses et je compte bien le faire à nouveau, à un moment donné.

Answer 1

Le plus simple est de le stocker sous la forme d'un flottant/double en degrés. Positif pour N et E, négatif pour S et W. N'oubliez pas que les minutes et les secondes sont en dehors de 60 (donc 31 45'N est 31.75). Il est facile de comprendre quelles sont les valeurs en les regardant et, si nécessaire, la conversion en radians est triviale.

Les calculs sur les latitudes et les longitudes tels que le Grand Cercle La distance entre deux coordonnées dépend fortement des fonctions trigonométriques, qui utilisent généralement des doubles. Tout autre format va dépendre d'une autre implémentation de sinus, cosinus, atan2 et racine carrée, au minimum. Les nombres de précision arbitraire (par exemple BigDecimal en Java) ne fonctionneront pas pour cela. Quelque chose comme l'int où 2^32 est réparti uniformément va avoir des problèmes similaires.

La question de l'uniformité a été soulevée dans plusieurs commentaires. À ce sujet, je me contenterai de noter que la Terre, en ce qui concerne la longitude, n'est pas uniforme. Une seconde d'arc de longitude au cercle arctique est une distance plus courte qu'à l'équateur. Les flotteurs de double précision donnent une précision inférieure au millimètre partout sur la Terre. N'est-ce pas suffisant ? Si non, pourquoi ?

Il convient également de noter ce que vous voulez faire avec ces informations, car les types de calculs dont vous avez besoin auront un impact sur le format de stockage que vous utiliserez.

Answer 2

Les longitudes et les latitudes ne sont généralement pas connues avec une précision supérieure à un flottant de 32 bits. Donc, si vous êtes préoccupé par l'espace de stockage, vous pouvez utiliser des flottants. Mais en général, il est plus pratique de travailler avec des nombres sous forme de doubles.

Les radians sont plus pratiques pour les mathématiques théoriques. (Par exemple, la dérivée d'un sinus n'est un cosinus que si l'on utilise des radians). Mais les degrés sont généralement plus familiers et plus faciles à interpréter, c'est pourquoi il est préférable de s'en tenir aux degrés.

Answer 3

Une représentation décimale avec une précision de 8 devrait être plus que suffisante selon cet article de wikipedia sur Degrés décimaux .

0 decimal places, 1.0 = 111 km
...
7 decimal places, 0.0000001 = 1.11 cm
8 decimal places, 0.00000001 = 1.11 mm

Answer 4

Les problèmes que vous avez mentionnés avec les valeurs à virgule flottante pourraient-ils devenir un problème ? Si la réponse est non, je vous suggère d'utiliser simplement la valeur radians en double précision - vous en aurez besoin si vous effectuez des calculs trigonométriques de toute façon.

S'il y a un problème de perte de précision lors de l'utilisation de doubles ou si vous n'avez pas l'intention de faire de la trigonométrie, je suggérerais votre solution de mappage sur une plage d'entiers - cela vous donnera la meilleure résolution, peut facilement être converti en n'importe quel format d'affichage utilisé dans votre région et - après avoir choisi un méridien 0 approprié - peut être utilisé pour convertir en valeurs à virgule flottante de haute précision.

PS : Je me suis toujours demandé pourquoi personne ne semble utiliser les coordonnées sphériques géocentriques - elles devraient être raisonnablement proches des coordonnées géographiques, et ne nécessiteront pas toutes ces mathématiques fantaisistes sur les sphéroïdes pour faire les calculs ; pour le plaisir, j'ai voulu convertir les coordonnées Gauss-Krüger (qui sont utilisées par le Katasteramt allemand) en coordonnées GPS - laissez-moi vous dire que c'était moche : l'une utilise l'ellipsoïde de Bessel, l'autre le WGS84, et la cartographie Gauss-Krüger elle-même est assez folle en soi. ..

Answer 5

La résolution de 0,3 pouce se rapproche du point où les tremblements de terre sur quelques années font une différence. Vous devriez peut-être reconsidérer la raison pour laquelle vous pensez avoir besoin d'une résolution aussi fine à l'échelle mondiale.

Certains centres d'expansion dans l'océan Pacifique changent jusqu'à 15 cm/an .