Отображение координат и входных данных в виде 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, но для обратной совместимости допустимо использование sexagesimal.

Там есть раздел под названием «Координаты широты и долготы не уникальны» с картинкой.

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

34 ° 05'09,76 "с.ш. 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), должно иметь координаты, выраженные как (широта, долгота). Вы можете проверить реестр 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 ( например, файл на сайтеrereference.org ), которые явно не указывают тот же порядок осей, что и EPSG, но, тем не менее, ссылаются на Код EPSG противоречит указаниям OGC.

Это общая проблема, вот еще одно предыдущее обсуждение:

• Почему некоторые системы координат определяют ось X как север, а некоторые как восток?

На http://wiki.osgeo.org/wiki/Axis_Order_Confusion очень подробное обсуждение.

@wwnick предоставил вышеуказанную информацию в качестве комментария к дублирующемуся вопросу

В течение многих лет это представляло для меня большую проблему на AutoCAD 2D, что усугублялось тем, что autocad считывает углы против часовой стрелки с 0 градусами, начиная с позиции 90d. Какое-то время мне нравилось верить, что я решил эту проблему, изменив UCS так, что x стал севернее, а y восточнее. Пока я продолжал создавать 2D-планы свойств, я никогда не сталкивался с моей ошибкой: ось z была указана неверно.

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