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

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?

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

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.

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.

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.

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.

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.

¡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)

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.

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.