Przyzwyczaiłem się widzieć format lokalizacji jako szerokość i długość geograficzną, ale używając bibliotek, wydaje mi się, że rozumiem MySQL do przechowywania go POINT(LNG LAT)w odwrotnej kolejności. Czy moja biblioteka jest niepoprawna, czy jest to rzeczywisty format? Nie mogę znaleźć tego szczegółu w dokumentacji MySQL.

Konstruktor Składnia

Patrząc na odniesienie do funkcji przestrzennej, zobaczysz

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

To nie jest do końca poprawne. Wszystkie implementacje GIS muszą zrobić (x,y)dla współrzędnych rzutowanych, które są (long,lat). Jednak w systemach kordinianu geodezyjnego istnieje spór dotyczący tego, co należy zrobić. MySQL (i SQL Server) robią, (lat,long)ale PostGIS utrzymuje się (long,lat)wszędzie.

Zostało to poruszone w specyfikacji OpenGIS® Implementation Standard dla informacji geograficznych - Prosty dostęp do funkcji - Część 2: Opcja SQL ,

• W przypadku geodezyjnych CRS posiadających elipsoidalny układ współrzędnych 2-D, dwuwymiarowymi elipsoidalnymi osiami układu współrzędnych są szerokość geodezyjna, dodatnia północ i dodatnia długość geodezyjna dodatnia wschód. Kierunek osi powinien wynosić odpowiednio „północ” i „wschód”.
• W przypadku geodezyjnych KSR posiadających trójwymiarowy elipsoidalny układ współrzędnych nazwa i skrót osi poziomych w ciągu WKT muszą być zgodne z wymogami określonymi w ppkt (ii). Nazwą osi pionowej jest „wysokość elipsoidalna”; skrót na osi pionowej powinien być „h” i powinien być uwzględniony, gdy uwzględniane są skróty dla osi poziomych.

Uwaga: powyższe słowa znajdują się dosłownie w informacjach geograficznych - Dobrze znana tekstowa reprezentacja układów odniesienia za pomocą współrzędnych

Już w specyfikacji 1.1,

Przestrzenny układ odniesienia, zwany także układem współrzędnych, jest układem współrzędnych geograficznych (szerokość-długość) , rzutowanym (X, Y) lub geocentrycznym (X, Y, Z).

To powiedziawszy, wydaje się, że PostGIS i Oracle i wiele bibliotek stron trzecich utrzymuje (x,y,[z])dla wszystkich typów punktów. Jest to niezgodne ze specyfikacją WKT, ale jest dość powszechną konwencją. Na przykład GeoJSON również to robi,

Współrzędne punktu są w kolejności x, y (wschód, północ dla rzutowanych współrzędnych, długość i szerokość geograficzna dla współrzędnych geograficznych)

Oraz (szer długo) Zamawiający jednoznacznie zdefiniowane przez EPSG dla SRSID 4326 .

Układ współrzędnych 2D lub 3D, w którym położenie określa szerokość geograficzna, długość geodezyjna i (w przypadku trójwymiarowym) wysokość elipsoidalna, stosowany w geograficznych KSR.

Możesz także sprawdzić blog Paula Ramseya (Captain PostGIS) na ten temat zatytułowany „Let's Call the Whole Thing Off”

Nicości

Jako specjalną uwagę, MySQL wprowadza dwie nowe funkcje do miksu,

• ST_Longitude()
• ST_Latitude()

Funkcje te stoją poza ST_X(), a ST_Y()i wymagają geograficznej SRS albo wyjątek i błędów.

Przechowywanie

Z dokumentów

Wewnętrznie MySQL przechowuje wartości geometrii w formacie, który nie jest identyczny z formatem WKT lub WKB. (Format wewnętrzny jest podobny do WKB, ale z początkowymi 4 bajtami wskazującymi SRID.)

Przechowywanie jest zdefiniowane tutaj .

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

Łatwym sposobem sprawdzenia zamówienia jest przekroczenie szerokości geograficznej:

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

Daje BŁĄD 3732 (22S03): Parametr funkcji st_srid zawiera geometrię o szerokości 160,000000, która jest poza zakresem. Musi zawierać się w przedziale [-90.000000, 90.000000];

Uwaga: kolejność może ulec zmianie w zależności od używanych funkcji:

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