Wyświetlanie współrzędnych i danych wejściowych jako LatLon czy LonLat?

Staram się zrozumieć, czy jest to problem dla innych, czy każde wejście / wyjście powinno być oznaczone, aby użytkownik nie był zdezorientowany i po prostu sobie z tym poradził?

Myślę, że prawie wszyscy wymawiają to jako „LatLon”.

Kto to zaczął?

Czy to dlatego, że jest w kolejności alfabetycznej w porównaniu do „LonLat”?

Mapowanie Lat i Lon na płaszczyznę kartezjańską Lon to „x”, a Lat to „y”, więc ponieważ mówimy „(x, y)”, należy to powiedzieć jako „LonLat”. A teraz do wyświetlania informacji.

Czy pasek stanu w aplikacji do mapowania powinien wyświetlać La, Lo lub Lo, Lat?

Czy powinien to być oznaczony jako jeden sposób i pozwolić użytkownikowi sobie z tym poradzić?

Podobnie jest z danymi wejściowymi, jaki jest właściwy sposób zamawiania pól?

Format KML to Lon, Lat, Altitude. Podczas gdy inne aplikacje to Lat, Lon i dlatego muszą być bardzo czujni podczas konwersji formatów.

Czy istnieje standard?

Powinieneś spojrzeć na normę ISO 6709. Oto wpis w Wikipedii: ISO 6709

Najważniejsze jest to, że porządek powinien zawsze mieć szerokość i długość geograficzną.

Szerokość geograficzna jest ważniejsza niż długość geograficzna

[edytuj teraz, gdy mam kopię 6709: 2008]

Do wymiany danych używaj DD, ale dla kompatybilności wstecznej obowiązuje funkcja sexagesimal.

Istnieje sekcja o nazwie „Współrzędne szerokości i długości geograficznej nie są unikalne” wraz ze zdjęciem.

Istnieje bardzo mocne sformułowanie dotyczące kolejności wyświetlania współrzędnych (nie wymiany). Mówi, że nawigatorzy tradycyjnie używali kolejności szerokości i długości geograficznej, a zmiana kolejności mogłaby zagrozić bezpieczeństwu. Używaj symboli płciowych, kierunkowych zamiast +/- itd. Wartości Z podążają za długością geograficzną. Wartości siatki / płaszczyzny powinny używać kolejności określonej w definicji CRS.

34 ° 05'09.76 "N 117 ° 02'01.23" W 829,1m

(Hah! Zacząłem pisać próbkę i najpierw automatycznie zapisałem wartość długości geograficznej)

Reprezentacja pozycji na kuli ziemskiej wymaga nie dwóch, ale trzech wartości, które na Ziemi są ogólnie reprezentowane przez (szerokość, długość, wysokość). Komputery zwykle działają w przestrzeniach kartezjańskich, podobnie jak nasze mapy papierowe, które są łatwiejsze do zrozumienia jako współrzędne (x, y), stąd konflikt.

Kolejność była zgodna z pewną historyczną konwencją dla współrzędnych sferycznych, które mapują się na współrzędne geograficzne w następujący sposób:

geographic spherical   symbol
---------- ---------   ------
longitude  azimuth       φ
latitude   inclination   θ 
elevation  radius        r

Wspólne uporządkowanie (r, θ, φ) ( standard ISO w społeczności fizyków, choć nie ustalony gdzie indziej ) upraszcza (θ, φ), gdy zakładamy, że pracujemy na kuli jednostkowej, a zatem (szerokość geograficzna, długość geograficzna).

Ponieważ GIS jest zaimplementowany w środowisku używającym kartezjańskich współrzędnych używanych w pozostałej części systemu, pozostaje nam trochę konfliktu . Myślę, że kluczową kwestią jest wyjaśnienie, czego używasz, i trzymanie się tego.

Osobiście wolę jednostki kartezjańskie ze względu na ich powszechność w innych miejscach i chociaż nie można zapominać o akademickich powiązaniach ze sferycznymi współrzędnymi, nie jest to pragmatyczny wybór przy wdrażaniu nowych systemów. Formularz (x, y) jest używany wewnętrznie w większości formatów plików przestrzennych, takich jak WKT, Shapefiles, GeoJSON itp. - ale jeśli prezentujesz dane laikom, to, co jest właściwe, zależy od tego, co jest dla nich najłatwiejsze do zrozumienia .

Dwie poprzednie odpowiedzi dotyczą już historii, oto moje dwa centy na temat standardów:

Do celów wymiany danych kolejność współrzędnych jest określana przez wybór CRS , zgodnie z zaleceniami OGC w ich wytycznych dotyczących polityki zamówień w ramach osi .

Jeśli przyjrzysz się uważnie, każdy EPSG CRS określa kolejność osi, której należy przestrzegać w każdym ładunku wskazanym do korzystania z CRS. Na przykład wszystko, co publikuje dane w formacie epsg: 4326 (WGS 84 geograficzne 2D), powinno mieć współrzędne wyrażone jako (lat, lon). Możesz samodzielnie sprawdzić rejestr EPSG (wyszukaj kod 4326 i zajrzyj pod Ellipsoidal CS / Axes).

Innym szeroko stosowanym sposobem określania CRS jest WKT projekcji (sekcja 7; dostępna również tutaj ), która również określa kolejność. Na przykład

...
AXIS["Lat",NORTH],
AXIS["Lon",EAST],
...

W OSI są opcjonalne jednak i domyślne, według niniejszego opisu, są

AXIS["Lon",EAST],AXIS["Lat",NORTH].

to sprawia, że ​​cały problem jest dość mylący, ponieważ oznacza to, że wiele plików .prj tam odnoszących się do epsg: 4326 ( np. ten na spatialreference.org ), które nie określają wyraźnie tej samej kolejności osi co EPSG, ale mimo to odnoszą się do Kod EPSG jest sprzeczny z wytycznymi OGC.

Jest to powszechny problem, oto kolejna poprzednia dyskusja:

• Dlaczego niektóre układy współrzędnych definiują oś X jako północy, a inne jako wschód?

Bardzo wyczerpująca dyskusja znajduje się na stronie http://wiki.osgeo.org/wiki/Axis_Order_Confusion

@wwnick podał powyższe informacje jako komentarz do duplikatu pytania

Przez lata stanowiło to dla mnie duży problem w programie AutoCAD 2D, a dodatkowo fakt, że autocad odczytuje kąty w kierunku przeciwnym do ruchu wskazówek zegara z 0 stopniami, zaczynając od pozycji 90d. Przez pewien czas lubiłem wierzyć, że rozwiązałem go, zmieniając LUW w taki sposób, że x stał się północny, a y wschodni. Tak długo, jak kontynuowałem tworzenie planów właściwości 2D, tak naprawdę nigdy nie spotkałem się z moim błędem: oś Z była źle ustawiona.

Oczywiście mój tekst wymiaru zwykle czyta od prawej do lewej, ale czułem, że zapłacenie za prawidłowe czytanie kąta i więcej do rzeczy było niewielką ceną, umieszczając xiy w ich intuicyjnych miejscach (zgodnie z Northing / Easting, Lat./Lon , konwencje). Następnie ukończyłem studia w Autocad Civil 3d i spróbowałem ponownie wykonać lewę i stanąłem twarzą w twarz z dolną linią: y to północ / lat, a x to wschód / długi. Zaakceptuj to.