Mostrar coordenadas y entradas como LatLon o LonLat?

72

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?

Vadim
fuente
1
Bueno, personalmente, digo Lat / Lon pero siempre ingreso X / Y. Cuando trabajo con datos y los recibo de clientes o los elimino de sitios web, probablemente alrededor del 90% de las veces obtengo X / Y.
Tac194
1
ahh esto seguro trae recuerdos ... blogs.msdn.com/b/isaac/archive/2007/12/27/…
Kirk Kuykendall
1
Convertir esto a Wiki ya que no tiene una sola respuesta correcta, pero con suerte genera alguna discusión útil.
scw

Respuestas:

38

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)

mkennedy
fuente
77
Eso no significa que el estándar sea el mejor. Mis estudiantes se confunden con la combinación de lat / long ... luego introduces este y norte ... luego x / y. Yo preferiría que se quede con la representación matemática de las coordenadas, ya sea esféricas o planas, x / y, este / norte, largo / lat ... quizás un movimiento podría estar en marcha
Melita: estás en el punto de que ISO 6709 ES el estándar. Pero la revisión ISO 6709: 2008 "... además especifica la representación de la ubicación del punto horizontal utilizando tipos de coordenadas distintos de la latitud y la longitud". ¿Podría por favor ampliar esos aspectos del estándar para la gente?
V Stuart Foote
1
@Stuart, desafortunadamente no tengo acceso a la revisión de 2008, ¡y no me apetece pagar 122 euros por el privilegio! Alguien aquí podría tenerlo; Veré si puedo encontrar una copia. Todavía hay problemas de derechos de autor sobre cuánto puedo publicar.
mkennedy
@ Dan, oh, estoy completamente de acuerdo, pero el movimiento había tenido lugar y terminó siendo revisado a la latitud actual, ENTONCES longitud. En x, y: desafortunadamente, ¡no todos igualan x = este, y = norte! Esri tiene varias solicitudes de mejora para apoyar el cambio de las etiquetas para los ejes, para el intercambio, etc.
mkennedy
2
@Stuart, edité mi respuesta para incluir información del estándar.
mkennedy
14

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. .

revs scw
fuente
2
(+1) Sin embargo, existe una convención para orientar los sistemas de coordenadas . Según esta convención, por ejemplo, (x, y) es positivo mientras que (y, x) es negativo. En la esfera, (lat, lon) es negativo mientras que (lon, lat) es positivo (tomando las longitudes occidentales y las latitudes meridionales como números negativos, lo que parece ser universal). Por lo tanto, si desea usar una orientación consistente para los sistemas de coordenadas, usará (este, norte) en sus mapas y (lon, lat) en la esfera.
whuber
4

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.

revs mkadunc
fuente
No creo que las especificaciones dicten el orden de almacenamiento. Dictan orden de intercambio / visualización. Es un poco como la física cuántica. No puede (no es necesario) saber qué está pasando hasta que observe el fenómeno. Acuerde el formato wkt. Esri ha agregado soporte para el orden de los ejes cuando se trabaja con servidores, pero no en el software general.
mkennedy
1
@mkennedy eres técnicamente correcto. En un archivo de forma, puede tener cualquier orden que desee. Pero tan pronto como envíe ese archivo de forma a alguien y lo describa como epsg: 4326, debe asegurarse de que el orden sea (lat, lon). Eliminé 'store' de la respuesta para dejar más claro que el estándar se trata de publicar datos.
mkadunc
0

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.

revs Enenenwa Okwudili
fuente