Estoy acostumbrado a ver el formato de ubicación como latitud seguido de longitud, pero usando bibliotecas, creo que entiendo MySQL para almacenarlo como POINT(LNG LAT), el orden inverso. ¿Mi biblioteca está equivocada o este es el formato real? Parece que no puedo encontrar este detalle en la documentación de MySQL.

Sintaxis del constructor

Al buscar la referencia de la función espacial, verá

Point(x, y)
Constructs a Point using its coordinates

Esto no es del todo correcto. Todas las implementaciones de SIG deben hacerlo (x,y)para las coordenadas proyectadas, que es (long,lat). Pero, en los sistemas de cordinización geodídica, existe cierto desacuerdo sobre qué hacer. MySQL (y SQL Server) sí, (lat,long)pero PostGIS se mantiene en (long,lat)todas partes.

Esto se refirió a la especificación de implementación OpenGIS® estándar para la información geográfica - Acceso Simple - Parte 2: opción de SQL ,

• Para los CRS geodésicos que tienen un sistema de coordenadas 2-D elipsoidal, los ejes del sistema de coordenadas elipsoidales bidimensionales son latitud geodésica, positiva hacia el norte y longitud geodésica, positiva hacia el este. La dirección del eje será 'norte' y 'este' respectivamente.
• Para los CRS geodésicos que tienen un sistema de coordenadas elipsoidales tridimensionales, el nombre y la abreviatura de los ejes horizontales en una cadena WKT seguirán los requisitos en (ii). El nombre del eje vertical será 'altura elipsoidal'; la abreviatura del eje vertical debe ser 'h' y debe incluirse cuando se incluyen abreviaturas para los ejes horizontales.

Tenga en cuenta que las palabras anteriores se encuentran textualmente en Información geográfica: representación de texto bien conocida de sistemas de referencia de coordenadas

Incluso desde la especificación 1.1,

Un sistema de referencia espacial, también conocido como sistema de coordenadas, es un sistema de coordenadas geográficas (latitud-longitud) , proyectadas (X, Y) o geocéntricas (X, Y, Z).

Dicho esto, parece que PostGIS y Oracle y muchas bibliotecas de terceros mantienen (x,y,[z])todo tipo de puntos. Esto viola las especificaciones de WKT, pero es una convención bastante común. Por ejemplo, GeoJSON también hace esto,

Las coordenadas de los puntos están en orden x, y (este, norte para coordenadas proyectadas, longitud y latitud para coordenadas geográficas)

Y, (latitud, longitud) de pedido se define explícitamente por EPSG para SRSID 4326, .

Un sistema de coordenadas 2D o 3D en el que la posición se especifica por la latitud geodésica, la longitud geodésica y (en el caso tridimensional) la altura elipsoidal, utilizada en los CRS geográficos.

También puede considerar visitar el blog de Paul Ramsey (Capitán PostGIS) sobre este tema titulado "Vamos a dejar todo"

Nicities

Como nota especial, MySQL trae dos nuevas funciones a la mezcla,

• ST_Longitude()
• ST_Latitude()

Estas funciones se destacan, aparte de ST_X()y ST_Y()y requieren un SRS geográficas o que lanzan una excepción y error.

Almacenamiento

De los documentos

Internamente, MySQL almacena valores de geometría en un formato que no es idéntico al formato WKT o WKB. (El formato interno es como WKB pero con 4 bytes iniciales para indicar el SRID).

El almacenamiento se define aquí .

Table 11.1 WKB Components Example

Component       Size    Value
Byte order      1 byte  01
WKB type        4 bytes 01000000
X coordinate    8 bytes 000000000000F03F
Y coordinate    8 bytes 000000000000F0BF

Una manera fácil de verificar el pedido es pasar la latitud fuera del rango:

SELECT ST_Longitude(ST_SRID(POINT(45, 160), 4326));

Da ERROR 3732 (22S03): un parámetro de la función st_srid contiene una geometría con latitud 160.000000, que está fuera de rango. Debe estar dentro de [-90.000000, 90.000000];

Tenga en cuenta que el orden puede cambiar según las funciones que utilice:

SELECT ST_Longitude(ST_SRID(POINT(45, 90), 4326));
SELECT ST_Longitude(ST_GeomFromText('POINT(45 90)', 4326));