Affichage des coordonnées et des entrées en tant que LatLon ou LonLat?


72

J'essaie de savoir s'il s'agit d'un problème pour les autres ou si chaque entrée / sortie doit être étiquetée de manière à ce que l'utilisateur ne soit pas dérouté et ne s'en mêle pas?

Je pense que presque tout le monde le prononce comme "LatLon".

Qui a commencé?

Est-ce parce que c'est dans l'ordre alphabétique comparé à "LonLat"?

Mappage de Lat et Lon sur le plan cartésien Lon est "x" et Lat est "y", donc puisque nous disons "(x, y)", il convient de le dire "LonLat". Et maintenant, pour l'affichage d'informations.

La barre d'état d'une application cartographique doit-elle afficher La, Lo ou Lo, Lat?

Devrait-il simplement être étiqueté comme un moyen et laisser l’utilisateur le gérer?

Et comme pour les entrées, quel est le bon moyen de commander les champs?

Le format de KML est Lon, Lat, Altitude. Alors que les autres applications sont Lat, Lon, il faut donc être très vigilant lors de la conversion de formats.

Y a-t-il une norme?


1
Bien personnellement, je dis Lat / Lon mais je saisis toujours X / Y. Lorsque je travaille avec des données et que je les reçois de mes clients ou que je les retire de sites Web, je reçois probablement environ 90% du temps X / Y.
Tac194


1
Convertir ceci en Wiki car il n’a pas une seule bonne réponse, mais suscite, espérons-le, une discussion utile.
scw


Réponses:


38

Vous devriez jeter un oeil à la norme ISO 6709. Voici l'entrée de wikipedia: ISO 6709

L'élément principal est que cet ordre doit toujours être latitude longitude.

La latitude vient avant la longitude

[modifier maintenant que j'ai une copie de 6709: 2008]

Pour l'échange de données, utilisez DD, mais pour la compatibilité ascendante, sexagésimal est valide.

Il y a une section intitulée "Les coordonnées de latitude et de longitude ne sont pas uniques" avec une image.

Il existe un libellé très fort concernant l’ordre des coordonnées pour l’ affichage (pas l’échange). Il indique que les navigateurs utilisent traditionnellement l'ordre de la longitude et de la latitude et que leur modification peut compromettre la sécurité. Utilisez des symboles sexagésimaux, de direction plutôt que +/-, etc. Les valeurs Z suivent la longitude. Les valeurs de grille / plan doivent utiliser l'ordre spécifié dans la définition de CRS.

34 ° 05'09.76 "N 117 ° 02'01.23" L 829.1m

(Hah! J'ai commencé à écrire un échantillon et à écrire automatiquement la valeur de la longitude en premier)


7
Cela ne signifie pas que la norme est la meilleure. Mes étudiants sont confus avec le mélange de lat / long ... puis vous introduisez est et nord ... puis x / y. Je préférerais que l'on s'en tient à la représentation mathématique des coordonnées, qu'elles soient sphériques ou planes, x / y, est / nord, long / lat ... peut-être qu'un mouvement pourrait être à pied

Melita - vous êtes parfaitement au fait que la norme ISO 6709 est la norme. Mais la révision ISO 6709: 2008 "... spécifie en outre la représentation de la position du point horizontal à l'aide de types de coordonnées autres que la latitude et la longitude". Pourriez-vous s'il vous plaît développer ces aspects de la norme pour les gens.
V Stuart Foote

1
@Stuart, malheureusement, je n'ai pas accès à la révision de 2008 et je n'ai pas envie de payer 122 euros pour le privilège! Quelqu'un ici pourrait l'avoir; Je verrai si je peux trouver une copie. Il y a toujours des problèmes de copyright sur ce que je peux poster.
Mkennedy

@Dan, oh, je suis tout à fait d'accord, mais le mouvement avait eu lieu et a finalement été révisé à la latitude actuelle, THEN longitude. Sur x, y: malheureusement, tout le monde n’est pas égal à x = est, y = nord! Esri a reçu plusieurs demandes d'amélioration pour pouvoir modifier les libellés des axes, l'ordre de permutation, etc.
mkennedy

2
@Stuart, j'ai modifié ma réponse pour inclure des informations provenant de la norme.
Mkennedy

14

Représenter une position sur un globe terrestre nécessite non pas deux, mais trois valeurs, qui sont généralement représentées par (latitude, longitude, altitude). Les ordinateurs fonctionnent généralement dans des espaces cartésiens, de même que nos cartes papier, qui sont plus faciles à comprendre en tant que coordonnées (x, y), d’où le conflit.

L'ordre a suivi une convention historique pour les coordonnées sphériques, qui correspondent aux coordonnées géographiques comme suit:

geographic spherical   symbol
---------- ---------   ------
longitude  azimuth       φ
latitude   inclination   θ 
elevation  radius        r

L’ordre commun de (r, θ, φ) (une norme ISO dans la communauté des physiciens, bien que non définie ailleurs ) se simplifie en (θ, φ) lorsque vous supposez que nous travaillons sur une sphère unitaire, et donc (latitude, longitude).

Étant donné qu'un SIG est implémenté dans un environnement utilisant des coordonnées cartésiennes utilisées dans le reste du système, il nous reste un conflit . Je pense que la question clé est de bien comprendre ce que vous utilisez et de vous y tenir.

Personnellement, je préfère les unités cartésiennes en raison de leurs points communs ailleurs et, si les connexions académiques aux coordonnées sphériques ne doivent pas être oubliées, ce n'est pas un choix pragmatique lors de la mise en œuvre de nouveaux systèmes. Le formulaire (x, y) est utilisé en interne dans la plupart des formats de fichiers spatiaux tels que WKT, Shapefiles, GeoJSON, etc., mais si vous présentez des données à un public profane, le meilleur choix dépend de ce qu'il est le plus facile pour eux de comprendre. .


2
(+1) Il existe cependant une convention pour l' orientation des systèmes de coordonnées . Selon cette convention, par exemple, (x, y) est positif tandis que (y, x) est négatif. Sur la sphère, (lat, lon) est négatif alors que (lon, lat) est positif (en prenant les longitudes occidentales et les latitudes méridionales comme des nombres négatifs, ce qui semble être universel). Par conséquent, si vous souhaitez utiliser une orientation cohérente pour les systèmes de coordonnées, vous utiliserez (est, nord) sur vos cartes et (lon, lat) sur la sphère.
whuber

4

Les deux réponses précédentes couvrent déjà l'historique, voici juste mes deux cents sur les normes:

Aux fins de l'échange de données, l'ordre des coordonnées est déterminé par le choix du CRS , tel que préconisé par OGC dans sa note d'orientation sur la politique relative aux ordres dans les axes .

Si vous regardez bien, tout CRS EPSG spécifie l’ordre des axes, qui doit être respecté dans toute charge utile identifiée pour utiliser le CRS. Par exemple, tout ce qui publie des données dans epsg: 4326 (WGS 84 Geographic 2D) devrait avoir des coordonnées exprimées sous la forme (lat, lon). Vous pouvez vérifier le registre EPSG vous-même (recherchez le code 4326 et regardez sous Ellipsoidal CS / Axes).

Le WKT de projection (section 7; également disponible ici ) est un autre moyen largement utilisé de spécifier CRS , qui prescrit également la commande. Par exemple

...
AXIS["Lat",NORTH],
AXIS["Lon",EAST],
...

Les paramètres AXIS sont toutefois facultatifs et les valeurs par défaut, conformément à cette spécification, sont identiques.

AXIS["Lon",EAST],AXIS["Lat",NORTH].

Cela rend le problème assez déroutant, car cela signifie que beaucoup de fichiers .prj référençant epsg: 4326 ( par exemple celui de spatialreference.org ) ne spécifient pas explicitement le même ordre d’axe que EPSG, mais font néanmoins référence au Code EPSG, sont en conflit avec la note explicative OGC.


Je ne crois pas que les spécifications dictent l'ordre de stockage. Ils dictent l'ordre d'échange / d'affichage. C'est un peu comme la physique quantique. Vous ne pouvez pas (pas besoin de) savoir ce qui se passe jusqu'à ce que vous observiez le phénomène. Acceptez le format wkt. Esri a ajouté la prise en charge de l'ordre des axes lors de l'utilisation de serveurs, mais pas dans le logiciel général.
mkennedy

1
@ mkennedy vous êtes techniquement correct. Dans un fichier de formes, vous pouvez avoir n'importe quel ordre. Mais dès que vous envoyez ce fichier de formes à quelqu'un et que vous le décrivez comme epsg: 4326, vous devez vous assurer que la commande est bien (lat, lon). J'ai supprimé 'magasin' de la réponse pour préciser que la norme concerne la publication de données.
mkadunc


0

Cela a posé un gros problème pour moi pendant des années sur AutoCAD 2D, du fait qu'autocad lit les angles dans le sens inverse des aiguilles d'une montre, à 0 degré à partir de la position 90d. Pendant un certain temps, j'ai aimé croire que j'avais résolu le problème en changeant le SCU de telle sorte que x devienne nord-est et y est. Tant que j'ai continué à produire des plans de propriétés 2D, je n'ai jamais vraiment eu à faire face à mon erreur: l'axe z était dirigé dans le mauvais sens.

Bien sûr, mon texte de cote se lisait généralement de droite à gauche, mais j’ai estimé que c’était un petit prix à payer pour obtenir une lecture d’angle correcte et plus précise, en mettant x et y à leur emplacement intuitif (selon Northing / Easting, Lat./Lon . conventions). Ensuite, je suis passé à Autocad Civil 3D et j'ai essayé de reproduire le truc et je me suis retrouvé face à face avec la ligne du bas: y est nord / lat et x est est / long. Accepter ça.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.