Orden preferido de escribir tuplas de latitud y longitud en servicios SIG


144

Cuando se trata con el código fuente SIG, a menudo necesita escribir tuplas de coordenadas de latitud y longitud.

Por ejemplo, en los enlaces de Google Maps (123, 456):

http://maps.google.com/maps/ms?msid=214518704716144912556.00046d7689a99e95b721c&msa=0&ll=123,456&spn=0.007996,0.026865

¿Cuál es el orden preferido (y por qué?)

  • latitud longitud

  • longitud latitud

He visto que ambos se usan en varios sistemas y espero encontrar alguna evidencia para seguir con otro.

¿Existe una práctica estándar y, de ser así, qué es / qué son?


2
en lugar del orden preferido, puede consultar una compilación de casos: macwright.org/lonlat
golimar

3
Es latitude, longitudeorden
onmyway133

1
Estoy votando para cerrar esta pregunta porque no se trata de programación sino de geografía. También es una pregunta basada en la opinión.
TylerH

1
@MikkoOhtamaa La diferencia es que su pregunta no pregunta cuál es el pedido requerido para una especificación técnica particular (que probablemente sería tan fuera de tema como una solicitud de información de documentación fuera del sitio), sino cuál es el método 'preferido' es [ en general ]. Los cambios preferidos se basan en la persona a la que pregunta y el propósito / contexto del uso. Como han mostrado las respuestas aquí, ambos ordenamientos tienen un seguimiento sustancial. Posteriormente, el tema de la relación de programación aún no se aborda por completo.
TylerH

1
@MikkoOhtamaa No tengo ningún problema con las preguntas de GIS sobre Stack Overflow. Esta no es una pregunta SIG; es una pregunta de "cómo debería ordenar latitud / longitud" ... ni siquiera está solicitando una aplicación GIS específica. Esta pregunta todavía se basa en la opinión (cualquier pregunta que solicite "métodos preferidos" se basa en la opinión), demasiado amplia (¿sobre qué contexto, escenario o aplicación está preguntando? Como muestran las respuestas, es diferente según esos criterios), y no sobre programación (latitud y longitud no son términos de programación sino términos de geografía).
TylerH

Respuestas:


210

EPSG: 4326 establece específicamente que el orden de coordenadas debe ser latitud, longitud. Muchos paquetes de software todavía usan la longitud, el orden de latitud. Esta situación ha causado estragos inimaginables en los plazos del proyecto y la cordura del programador.

La mejor guía que se puede ofrecer es ser plenamente consciente del orden de eje esperado de cada componente en su pila de software. PostGIS espera lng / lat. WFS 1.0 usa lng / lat, pero WFS 1.3.0 difiere del estándar y usa lat / lng. GeoTools tiene como valor predeterminado lat / lng pero puede anularse con una propiedad del sistema.

Vale la pena leer los documentos de GeoTools sobre el historial y la explicación del problema: http://docs.geotools.org/latest/userguide/library/referencing/order.html


66
Raramente veo una respuesta en SO.com que indica por qué esto está bien. Los latidos de esas respuestas "porque MongoDB lo usa" responden.
Mikko Ohtamaa

1
Su enlace no está de acuerdo con usted; En la base de datos EPSG, 4326 se asigna a un CRS geográfico con orden de eje (latitud, longitud). Sin embargo, la mayoría del software en el campo entiende EPSG: 4326 como un CRS geográfico con orden de eje (longitud, latitud), porque las especificaciones de OGC heredadas se diseñaron de esa manera.
Aaron McIver

77
Las primeras dos oraciones de mi respuesta: EPSG: 4326 establece específicamente que el orden de coordenadas debe ser latitud, longitud. Muchos paquetes de software todavía usan la longitud, el orden de latitud. ¿No es exactamente lo mismo?
Shane

55
Si alguien más tiene problemas con Google Maps y le proporciona un archivo KML, ¡el pedido es Longitud / Latitud! ¡Ninguna documentación para el archivo KML dice esto!
Turnerj

2
"Ninguna documentación para el archivo KML dice esto" es incorrecto. developers.google.com/kml/documentation/kmlreference#point "Una tupla única que consiste en valores de coma flotante para longitud, latitud y altitud (en ese orden)".
tmcw

28

El orden preferido es por convención latitude, longitude. Esto fue presumiblemente estandarizado por la Organización Marítima Internacional como se informa aquí . Google también usa este orden en sus Mapas y Tierra . Recuerdo este orden al pensar en el orden alfabético de latitude, longitude.


12
Excepto en archivos KML. Allí las coordenadas se almacenan como lng, lat, alt; probablemente porque eso se puede traducir a x, y, z
Wouter van Nifterick

23

El orden correcto es la longitud, latitud, en prácticamente todas las aplicaciones SIG profesionales, como lo es en las matemáticas convencionales (es decir, f(x ,y, z)). El estándar GeoJSON es bastante típico y sucinto:

The order of elements must follow x, y, z order
(easting, northing, altitude for coordinates in a 
projected coordinate reference system, or longitude,
latitude, altitude for coordinates in a geographic
coordinate reference system).

Lo mismo se aplica a los estándares primarios del Open Geospatial Consortium (WKT y WKB, y extensiones como EWKB). Del mismo modo, Google puede generar el pedido en Lat / Lon para que sea más familiar para los usuarios que crecieron con esa costumbre (es decir, a partir de estándares de navegación como IMO, en lugar de computacionales). Pero el estándar KML en sí es como prácticamente todos los demás sistemas SIG:

The KML encoding of every kml:Location and coordinate
tuple uses geodetic longitude, geodetic latitude, and
altitude (in that order).

Buena regla de oro: si usted sabe lo que es una tupla y se está programando, usted debe utilizar lon, lat. Incluso diría esto se aplica si el usuario final (por ejemplo un piloto o un capitán de barco) preferirán ver la salida en lat, lon. Puede cambiar el orden en su UI si es necesario, pero la gran mayoría de sus datos (shapefiles, geojson, etc.) estarán en el orden cartesiano normal.


44
Veo algunos desacuerdos aquí: I DOS opciones para elegir, ¡demasiadas!
Mikko Ohtamaa

66
Los lectores deben tener en cuenta que ISO 6709 establece explícitamente que siempre debe usar el formato [lat, lon] en cualquier interfaz de usuario y no es, como se puede inferir, simplemente una cuestión de preferencia personal.
Iain Collins el

9

Por convención en la "vida real", cuando se da una posición, la latitud (es decir, Norte / Sur) siempre se da primero, por ejemplo, 20 ° N 56 ° O (aunque esto no sigue la convención normal si se piensa en un cartesiano estándar cuadrícula); de manera similar, todas las coordenadas en Wikipedia siguen esta convención (por ejemplo, vea la ubicación de Southampton: http://en.wikipedia.org/wiki/Southampton ). Para evitar confusiones, especialmente cuando no se incluyen unidades, siempre recomendaría que la latitud se dé primero en una tupla.


9

Personalmente, nunca he visto nada más que latitud seguido de longitud.

Y, cuando se usa + y - en lugar de N y S, siempre ha sido + es N y - es S.

He observado variaciones al usar + y - para E y W. En general, + ha sido E y - ha sido W. Sin embargo, en aplicaciones más antiguas en las que se trataban de forma abrumadora con longitudes W, he visto que + es W y - es E .

Esperemos que no tenga que lidiar con aplicaciones tan antiguas.


Es fácilmente observable cuando trabaja con aplicaciones en todo el mundo.
Daniel Antunes Pinto

Simplemente escriba cualquier par de coordenadas de longitud y latitud en los mapas de Google y verá que lo interpreta como (largo, lat), no al revés. Ese es un ejemplo de un sistema muy utilizado.
cazort 01 de

2
@cazort Por cualquier razón, eso no sucede aquí. Por ejemplo, mi ciudad natal de Eugene, Oregón, está aproximadamente a N 44.1, W 123.1. Si en maps.google.com ingreso 44.1 -123.1, va a Eugene. Si ingreso -123.1 44, me dice que no puede encontrarlo. Sin embargo, es interesante que si ingreso 123.1 W 44 N, lo resuelve y va a Eugene, por lo que hay algo de flexibilidad. También reference.com/technology/… parece indicar que el orden preferido es lat / long. Además, por lo que vale, Google Earth usa lat / long.
Terry

5

Además de la especificación GeoJSON, que otros ya han mencionado, hay otros casos prácticos en los que se recomienda la longitud, el orden de latitide, incluso obligatorio, por ejemplo: indexación geoespacial en MongoDB . Si obtiene un pedido incorrecto allí, sus consultas devolverán resultados incorrectos, como si se realizara nuevamente un conjunto de datos transpuesto.


5

¡Entonces el orden preferido depende de la preferencia personal!

La latitud vino primero; el equinoccio se conoce desde hace milenios, como los días en que el "sol cruza el ecuador"; en marzo cruzando de S a N y septiembre de N a S. La única pregunta podría haber sido si el ecuador debería haber sido 0 o 90 grados. Al tomar 0 grados, el ángulo entre el cenit solar vertical y el mediodía en el equinoccio es la latitud de una ubicación, en todas partes del planeta. La primera latitud, o primer paralelo, se definió efectivamente.

La longitud solo puede ser por acuerdo. Gran Bretaña puso un premio de longitud. Gran Bretaña necesitaba sus barcos para saber dónde estaban y necesitaba mejores mapas. Harrison ( http://www.youtube.com/watch?v=T-g27KS0yiY ) produjo un cronómetro marino preciso; enviaron viajes de viaje de cartografía, por ejemplo, James Cook de 1770. Por lo tanto, Gran Bretaña reclamó el primer meridiano usando Greenwich como 000 grados para sus mapas. Después de 100 años de su uso, el primer meridiano fue aceptado internacionalmente, en 1884.

En la época de Cristóbal Colón, Latitud era el único número que tenían. La estrategia consistía en atravesar un paralelo antes de girar a la izquierda o derecha hacia el destino; observando nubes o pájaros. La medición de la velocidad en nudos cada hora era común, pero no tenía en cuenta las corrientes. Quizás el mayor logro de Colón fue volver a casa de las Indias Occidentales cuatro veces. Sin eso, la tierra que descubrió no podría agregarse a los mapas.

Leer "Longitud" de Dava Sobel (ISBN: 9780007214228)


1
Creo que quiere decir programáticamente y con una referencia técnica (pero podría estar equivocado). Sin embargo, la lección de historia fue interesante.
jww

1
Esto no está relacionado con la pregunta, pero definitivamente es interesante. Gracias :)
Mikko Ohtamaa

Pero tiene sentido, ya que si solo se usaran las coordenadas del mapa, sería indudable que el orden sería longitud, latitud, como en X, Y; la confusión solo existe debido a los cientos de años de precedencia de decir (y escuchar) latitud, longitud en todas partes.
Antti Haapala

5

ISO 6709 estandariza el listado del pedido como latitud y longitud por razones de seguridad. La explicación anterior de Graham también me parece correcta. Alguien sugirió que esta respuesta no está relacionada con la pregunta, absolutamente lo está, y explica por qué el orden a menudo se da como latitud, longitud.

Así es como se ha incluido en la lista por el tiempo que los navegadores han estado utilizando el sistema; cambiar eso ahora sería confuso y, como sugiere ISO, potencialmente peligroso. Los softwares SIG, como ArcMap, los enumeran al revés porque esa es la convención típica para pares de coordenadas x, y. La latitud es y, la longitud es x, así que Arc los enumera.


1

Longitud luego Latitud (lon, lat).

Cuando se proyecta a Mercator, la longitud define la dirección x y la latitud define la dirección y. La mayoría de las bibliotecas de geometría utilizan estrictamente este formato de (lon, lat), ya que es la forma más intuitiva de pensar en coordenadas geográficas en un plano 2D.


3
Entonces, si esa es la forma más intuitiva de pensar, ¿por qué el blog de Google Earth se llama Lat-Long Blog mientras usan lon-lat en KML?
theta

1
Básicamente, es que los navegadores han usado tradicionalmente el orden de lat-lon, por lo que si te equivocaste con ese orden, podrías arruinar tus navegaciones. Por lo tanto, Google está utilizando el tradicional para un blog y el plano 2D ordenando su estructura de datos. @mkennedy responde esto mejor en su respuesta a la misma pregunta: gis.stackexchange.com/questions/6037/…
David
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.