Estou acostumado a ver o formato do local como latitude seguido de longitude, mas usando bibliotecas, acredito que entendo o MySQL para armazená-lo como POINT(LNG LAT)a ordem inversa. Minha biblioteca está errada ou esse é o formato real? Não consigo encontrar esse detalhe na documentação do MySQL.

Sintaxe do construtor

Procurando a referência da função espacial, você verá

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

Isso não está totalmente correto. Todas as implementações de GIS devem fazer (x,y)pelas coordenadas projetadas (long,lat). Mas, em sistemas de cordados geodídicos, há alguma discordância sobre o que fazer. MySQL (e SQL Server), (lat,long)mas PostGIS mantém em (long,lat)todos os lugares.

Isso é abordado no padrão de implementação OpenGIS® de especificação geográfica para informações geográficas - Acesso simples a recursos - Parte 2: opção SQL ,

• Para os SRC geodésicos que possuem um sistema de coordenadas elipsoidal 2-D, os eixos bidimensionais do sistema de coordenadas elipsoidais são latitude geodésica, norte positivo e longitude geodésica, positivos para leste. A direção do eixo deve ser 'norte' e 'leste', respectivamente.
• Para os SIR geodésicos com um sistema de coordenadas elipsoidal tridimensional, o nome e a abreviação dos eixos horizontais em uma coluna WKT devem seguir os requisitos em (ii). O nome do eixo vertical deve ser "altura elipsoidal"; a abreviação do eixo vertical deve ser 'h' e deve ser incluída quando as abreviações para os eixos horizontais forem incluídas.

Observe que as palavras acima são encontradas literalmente em Informações geográficas - representação de texto conhecida dos sistemas de referência de coordenadas

Mesmo na especificação 1.1,

Um sistema de referência espacial, também conhecido como sistema de coordenadas, é um sistema de coordenadas geográficas (latitude-longitude) , projetado (X, Y) ou geocêntrico (X, Y, Z).

Dito isso, parece que o PostGIS e o Oracle e muitas bibliotecas de terceiros mantêm (x,y,[z])para todos os tipos de pontos. Isso viola as especificações do WKT, mas é uma convenção bastante comum. Por exemplo, o GeoJSON também faz isso,

As coordenadas dos pontos estão na ordem x, y (leste, norte das coordenadas projetadas, longitude e latitude das coordenadas geográficas)

E, (lat, long), a ordem é explicitamente definida pelo EPSG para o SRSID 4326 ,.

Um sistema de coordenadas 2D ou 3D em que a posição é especificada por latitude geodésica, longitude geodésica e (no caso tridimensional) altura elipsoidal, usada em CRSs geográficos.

Você também pode consultar o blog de Paul Ramsey (capitão PostGIS) sobre esse assunto, intitulado "Let's Call the Whole Thing Off"

Nicidades

Como uma nota especial, o MySQL traz duas novas funções para o mix,

• ST_Longitude()
• ST_Latitude()

Estas funções ficar de lado a partir de ST_X(), e ST_Y()e requer um SRS geográficas ou eles lançar uma exceção e erro.

Armazenamento

Dos documentos

Internamente, o MySQL armazena valores de geometria em um formato que não é idêntico ao formato WKT ou WKB. (O formato interno é como WKB, mas com 4 bytes iniciais para indicar o SRID.)

O armazenamento é definido aqui .

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

Uma maneira fácil de verificar o pedido está saindo da latitude fora do intervalo:

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

Dá ERRO 3732 (22S03): Um parâmetro da função st_srid contém uma geometria com latitude 160.000000, que está fora do intervalo. Ele deve estar dentro de [-90.000000, 90.000000];

Lembre-se de que a ordem pode mudar dependendo das funções que você usa:

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