Mostrar coordenadas y entradas como LatLon o LonLat?

Estoy tratando de tener una idea de si esto es un problema para otros o si cada entrada / salida debe etiquetarse para que el usuario no se confunda y simplemente continúe.

Creo que casi todos lo pronuncian como "LatLon".

Quien lo empezo?

¿Es porque está en orden alfabético en comparación con "LonLat"?

Mapeando Lat y Lon al plano cartesiano Lon es "x" y Lat es "y", por lo que como decimos "(x, y)" debería decirse "LonLat". Y ahora para mostrar información.

¿Debería la barra de estado en una aplicación de mapeo mostrar La, Lo o Lo, Lat?

¿Debería etiquetarse como unidireccional y dejar que el usuario se encargue de ello?

Y lo mismo con la entrada, ¿cuál es la forma correcta de ordenar los campos?

El formato de KML es Lon, Lat, Altitude. Mientras que otras aplicaciones son Lat, Lon, deben estar muy atentas al convertir formatos.

¿Hay un estándar?

Debería echar un vistazo al estándar ISO 6709. Aquí está la entrada de Wikipedia: ISO 6709

El elemento principal es que el orden siempre debe ser latitud longitud.

La latitud viene antes que la longitud

[editar ahora que tengo una copia de 6709: 2008]

Para el intercambio de datos, use DD, pero para compatibilidad con versiones anteriores, sexagesimal es válido.

Hay una sección llamada "Las coordenadas de latitud y longitud no son únicas" completa con una imagen.

Hay una redacción muy fuerte sobre el orden de coordenadas para la visualización (no intercambio). Dice que los navegadores han usado tradicionalmente el orden de latitud y longitud y que cambiar el orden podría comprometer la seguridad. Utilice sexagesimal, símbolos de dirección en lugar de +/-, etc. Los valores Z siguen a la longitud. Los valores de cuadrícula / planar deben usar el orden especificado en la definición de CRS.

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

(¡Ja! Empecé a escribir una muestra y automáticamente escribí el valor de longitud primero)

Representar una posición en un globo requiere no dos, sino tres valores, que en la tierra generalmente están representados por (latitud, longitud, elevación). Las computadoras generalmente trabajan en espacios cartesianos, al igual que nuestros mapas en papel, que son más fáciles de entender como coordenadas (x, y), de ahí el conflicto.

La ordenación siguió algunas convenciones históricas para coordenadas esféricas, que se asignan a coordenadas geográficas de la siguiente manera:

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

El orden común de (r, θ, φ) (un estándar ISO en la comunidad de física, aunque no está establecido en otro lugar ) se simplifica a (θ, φ) cuando se supone que estamos trabajando en una esfera unitaria, y por lo tanto (latitud, longitud).

Debido a que un SIG se implementa en un entorno que utiliza coordenadas cartesianas en todo el resto del sistema, nos queda un poco de conflicto . Creo que la cuestión clave es tener claro lo que está usando y apegarse a él.

Personalmente prefiero las unidades cartesianas debido a su comunidad en otros lugares, y aunque las conexiones académicas con las coordenadas esféricas no deben olvidarse, no es la opción pragmática al implementar nuevos sistemas. La forma (x, y) se usa internamente en la mayoría de los formatos de archivos espaciales como WKT, Shapefiles, GeoJSON y similares, pero si está presentando datos a un público lego, lo correcto depende de lo que sea más fácil de entender. .

Las dos respuestas anteriores ya cubren la historia, aquí están solo mis dos centavos sobre estándares:

Para el intercambio de datos, el orden de las coordenadas se determina mediante la elección de CRS , según lo promovido por OGC en su Nota de Orientación de la Política de Orden del Eje .

Si observa de cerca, cualquier EPSG CRS especifica el orden de los ejes, que debe respetarse en cualquier carga útil marcada para usar el CRS. Por ejemplo, cualquier cosa que publique datos en epsg: 4326 (WGS 84 geográfico 2D) debe tener coordenadas expresadas como (lat, lon). Puede verificar el registro EPSG usted mismo (busque el código 4326 y busque en Elipsoidal CS / Axes).

Otra forma ampliamente utilizada de especificar CRS es el Projection WKT (sección 7; también disponible aquí ), que también prescribe el orden. Por ejemplo

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

Los AXIS parámetros son opcionales sin embargo, y los valores por defecto, de acuerdo con esta memoria descriptiva, son

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

esto hace que todo el asunto sea bastante confuso, porque significa que muchos de los archivos .prj que hacen referencia a epsg: 4326 ( por ejemplo, el de spatialreference.org ) que no especifican explícitamente el mismo orden de ejes que EPSG, pero sin embargo hacen referencia al El código EPSG está en conflicto con la nota de orientación de OGC.

Este es un problema común, aquí hay otra discusión previa:

• ¿Por qué algunos sistemas de coordenadas definen el eje x como norte y otros como este?

Hay una discusión muy exhaustiva en http://wiki.osgeo.org/wiki/Axis_Order_Confusion

@wwnick proporcionó la información anterior como un comentario a una pregunta duplicada

Esto planteó un gran problema para mí durante años en AutoCAD 2D, compuesto por el hecho de que autocad lee ángulos en sentido antihorario con 0 grados comenzando en la posición 90d. Por un tiempo me gustó creer que lo había resuelto cambiando el UCS de tal manera que x se volviera hacia el norte y hacia el este. Mientras continué produciendo planos de propiedades en 2D, nunca tuve la oportunidad de enfrentar mi error: el eje z apuntaba en la dirección incorrecta.

Por supuesto, el texto de mi dimensión generalmente se leía de derecha a izquierda, pero sentí que era un pequeño precio a pagar por la lectura correcta del ángulo y más al punto, colocando x e y en sus lugares intuitivos (según Northing / Easting, Lat./Lon convenciones) Luego me gradué en Autocad Civil 3d e intenté realizar el truco nuevamente y me encontré cara a cara con la línea inferior: y es norte / lat y x es este / largo. Acepta eso.