Відображення координат та входів як LatLon чи LonLat?

Я намагаюся зрозуміти, якщо це питання для інших або кожен вхід / вихід повинен бути позначений етикеткою, щоб користувач не плутався, а просто піти з ним?

Я думаю, майже всі вимовляють це як "LatLon".

Хто це почав?

Це тому, що це в алфавітному порядку порівняно з "LonLat"?

Зіставлення Lat і Lon на декартовій площині Lon - це "x", а Lat - "y", тому оскільки ми говоримо "(x, y)", це слід сказати як "LonLat". А тепер для відображення інформації.

Чи повинно відображатися рядок стану на додатку для відображення La, Lo чи Lo, Lat?

Чи слід це просто позначати як один із способів і дозволити користувачеві займатися цим?

І те саме з введенням, який правильний спосіб замовити поля?

Формат KML - Lon, Lat, Altitude. У той час як інші програми є Lat, Lon і тому потрібно бути дуже пильними при перетворенні форматів.

Чи є стандарт?

Слід поглянути на стандарт ISO 6709. Ось запис у вікіпедії: ISO 6709

Головне, що порядок завжди повинен бути широтою довготи.

Широта виходить перед довготою

[редагувати зараз, коли у мене є копія 6709: 2008]

Для обміну даними використовуйте DD, але для зворотної сумісності справедливий підхід.

Там є розділ під назвою "Координати широти та довготи не унікальні", доповнений зображенням.

Є дуже чітке формулювання порядку координат для відображення (а не обміну). У ній йдеться про те, що навігатори традиційно застосовують порядок широти широти і зміна порядку може поставити під загрозу безпеку. Використовуйте сексуальні знаки, символи напряму, а не +/- тощо. Значення Z відповідають довготі. Значення сітки / площини повинні використовувати порядок, визначений у визначенні CRS.

34 ° 05'09,76 "N 117 ° 02'01,23" з 829,1м

(Так! Я почав виписувати зразок і спочатку автоматично записав значення довготи)

Представлення позиції на земній кулі вимагає не двох, а трьох значень, які на землі в основному представлені (широта, довгота, висота). Комп'ютери, як правило, працюють в декартових просторах, як і наші паперові карти, які легше зрозуміти як (x, y) координати, отже, конфлікт.

Упорядкування слідувало деякому історичному умові щодо сферичних координат, які відображаються на географічні координати наступним чином:

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

Загальне впорядкування (r, θ, φ) ( стандарт ISO у фізичному співтоваристві, хоча в іншому місці не встановлено ) спрощується до (θ, φ), якщо ви припускаєте, що ми працюємо над одиничною сферою, а отже (широта, довгота).

Оскільки ГІС реалізований у середовищі, яке використовує декартові координати, використовуються у всій решті системи, у нас залишився невеликий конфлікт . Я думаю, що головне питання - зрозуміти, що ви використовуєте, і дотримуватися цього.

Я особисто віддаю перевагу декартовим одиницям через їх спільність в інших місцях, і хоча академічні зв’язки зі сферичними координатами не слід забувати, це не прагматичний вибір при впровадженні нових систем. Форма (x, y) використовується внутрішньо у більшості просторових форматів файлів, таких як WKT, Shapefiles, GeoJSON тощо), але якщо ви представляєте дані для широкої аудиторії, то те, що правильно, залежить від того, що їм найпростіше зрозуміти. .

Попередні два відповіді вже висвітлюють історію, ось лише два мої центи про стандарти:

Для обміну даними порядок координат визначається вибором CRS , як це сприяє OGC у своєму керівництві щодо наказів щодо наказу щодо осі .

Якщо придивитися уважно, будь-який EPSG CRS вказує порядок осей, який слід дотримуватися в будь-якій корисній навантаженні, позначеній для використання CRS. Наприклад, усе, що публікує дані в epsg: 4326 (WGS 84 geographic 2D), має мати координати, виражені у вигляді (lat, lon). Ви можете перевірити реєстр EPSG самостійно (шукайте код 4326 і подивіться під Ellipsoidal CS / Axes).

Інший широко використовуваний спосіб визначення CRS - це Projection WKT (розділ 7; також доступний тут ), який також призначає порядок. Наприклад

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

Однак параметри AXIS необов’язкові, а за замовчуванням відповідно до цієї специфікації є

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

це робить всю проблему досить заплутаною, тому що це означає, що багато файлів .prj там посилається на epsg: 4326 ( наприклад, на просторовому.org ), які чітко не вказують той самий порядок осі, що і EPSG, але, тим не менш, посилаються на Код EPSG, суперечить інструкції OGC.

Це поширена проблема, ось ще одна попередня дискусія:

• Чому деякі системи координат визначають вісь x як північ, а деякі як схід?

Існує дуже вичерпна дискусія на веб- сайті http://wiki.osgeo.org/wiki/Axis_Order_Confusion

@wwnick надав вищевказану інформацію як коментар до повторного запитання

Це створювало велику проблему для мене на AutoCAD 2D протягом багатьох років, ускладнене тим, що автокадра зчитує кути проти годинникової стрілки з 0 градусів, починаючи з положення 90d. Якийсь час мені подобалося вірити, що я вирішив це, змінивши UCS таким чином, що x став північним, а y східним. Поки я продовжував розробляти 2D плани власності, я ніколи насправді не стикався зі своєю помилкою: вісь z була вказана неправильним шляхом.

Звичайно, мій текст розмірності зазвичай читався праворуч ліворуч, але я відчував, що це була невелика ціна, яку потрібно заплатити за правильне читання кута, і більше до точки, поставивши x і y в свої інтуїтивні місця (відповідно до Northing / Easting, Lat./Lon Конвенції). Потім я закінчив Autocad Civil 3d і спробував виконати трюк ще раз і зіткнувся віч-на-віч із нижньою лінією: y - північ / лат і x - схід / довга. Прийміть це.