Отображение координат и входных данных в виде LatLon или LonLat?

72

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

Я думаю, что почти все произносят это как "LatLon".

Кто это начал?

Это потому, что это в алфавитном порядке по сравнению с "LonLat"?

Отображение Lat и Lon на декартову плоскость Lon - это «x», а Lat - «y», поэтому, так как мы говорим «(x, y)», его следует называть «LonLat». А теперь для отображения информации.

Должна ли строка состояния в картографическом приложении отображать La, Lo или Lo, Lat?

Должен ли он быть помечен как односторонний и позволить пользователю справиться с этим?

И то же самое с вводом, как правильно упорядочить поля?

Формат KML: Lon, Lat, Altitude. В то время как другие приложения - это Lat, Lon и другие должны быть очень бдительными при конвертации форматов.

Есть ли стандарт?

Вадим
источник
1
Лично я говорю Lat / Lon, но я всегда вхожу в X / Y. Когда я работаю с данными и получаю их от клиентов или удаляю их с веб-сайтов, вероятно, примерно в 90% случаев я получаю X / Y.
Tac194
1
ааа, это наверняка возвращает воспоминания ... blogs.msdn.com/b/isaac/archive/2007/12/27/…
Кирк Куйкендалл
1
Преобразование этого в Wiki, так как оно не имеет единственного правильного ответа, но, надеюсь, вызывает некоторое полезное обсуждение.
scw

Ответы:

38

Вы должны взглянуть на стандарт ISO 6709. Вот запись в Википедии: ISO 6709

Основным пунктом является то, что порядок всегда должен быть широтой и долготой.

Широта предшествует долготе

[редактировать сейчас, когда у меня есть копия 6709: 2008]

Для обмена данными используйте DD, но для обратной совместимости допустимо использование sexagesimal.

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

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

34 ° 05'09,76 "с.ш. 117 ° 02'01,23" в.д. 829,1 м

(Ха! Я начал писать пример и автоматически записал значение долготы первым)

mkennedy
источник
7
Это не значит, что стандарт самый лучший. Мои ученики путаются со смесью широта / долгота ... потом ты вводишь восток и север ... потом х / у. Я бы предпочел эту палку с математическим представлением координат, сферических или плоских, х / у, восток / север, длинный / широта ... возможно, движение может быть в движении
Мелита - вы точно знаете, что ISO 6709 - это стандарт. Но пересмотр ISO 6709: 2008 «... дополнительно определяет представление местоположения горизонтальной точки с использованием типов координат, отличных от широты и долготы». Не могли бы вы подробнее рассказать об этих аспектах стандарта для людей.
V Стюарт Фут
1
@Stuart, к сожалению, у меня нет доступа к ревизии 2008 года, и я не хочу платить 122 евро за эту привилегию! Кто-то здесь может иметь это; Я посмотрю, смогу ли я найти копию. Все еще есть проблемы с авторским правом на то, сколько я могу опубликовать
Mkennedy
@ Дэн, о, я полностью согласен, но движение имело место, и в итоге оно было пересмотрено на текущую широту, ТОГДА долготу. По x, y: к сожалению, не все равны x = восток, y = север! У Esri есть несколько запросов на расширение для поддержки изменения меток для осей, порядка замены и т. Д.
mkennedy
2
@Stuart, я отредактировал свой ответ, включив в него некоторую информацию из стандарта.
Mkennedy
14

Для представления позиции на глобусе требуется не два, а три значения, которые на земле обычно представлены (широта, долгота, высота). Компьютеры обычно работают в декартовых пространствах, как и наши бумажные карты, которые легче понять как (x, y) координаты, отсюда и конфликт.

Порядок следовал некоторому историческому соглашению для сферических координат, которые отображаются на географические координаты следующим образом:

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

Общее упорядочение (r, θ, φ) ( стандарт ISO в физическом сообществе, хотя и не рассматривается в другом месте ) упрощается до (θ, φ), когда вы предполагаете, что мы работаем над единичной сферой, и, следовательно, (широта, долгота).

Поскольку ГИС реализована в среде, в которой используются декартовы координаты, используемые в остальной части системы, у нас остался небольшой конфликт . Я думаю, что ключевой вопрос заключается в том, чтобы понять, что вы используете, и придерживаться его.

Лично я предпочитаю картезианские единицы из-за их общности в других местах, и хотя об академических связях со сферическими координатами не следует забывать, это не прагматичный выбор при внедрении новых систем. Форма (x, y) используется внутри большинства пространственных файловых форматов, таких как WKT, Shapefiles, GeoJSON и т. Д., Но если вы представляете данные непрофессионалам, то что правильно, зависит от того, что им легче понять ,

об.
источник
2
(+1) Там вне, однако, соглашение для ориентации системы координат . Согласно этому соглашению, например, (x, y) является положительным, а (y, x) отрицательным. На сфере, ( широта, долгота ) отрицательна, а (широта, широта) положительна (принимая западные долготы и южные широты за отрицательные числа, что кажется универсальным). Поэтому, если вы хотите использовать согласованную ориентацию для систем координат, вы будете использовать (восток, север) на своих картах и ​​(lon, lat) на сфере.
whuber
4

Предыдущие два ответа уже охватывают историю, вот только мои два цента о стандартах:

В целях обмена данными порядок координат определяется выбором 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.

мин
источник
Я не верю, что спецификации диктуют порядок хранения. Они диктуют порядок обмена / отображения. Это немного похоже на квантовую физику. Вы не можете (не должны) знать, что происходит, пока не наблюдаете это явление. Согласитесь на формат WKT. Esri добавила поддержку порядка осей при работе с серверами, но не в общем программном обеспечении.
Mkennedy
1
@mkennedy ты технически прав. В шейп-файле вы можете иметь любой заказ, который вам нравится. Но как только вы отправите этот шейп-файл кому-нибудь и опишите его как epsg: 4326, вы должны убедиться, что порядок (lat, lon). Я удалил «store» из ответа, чтобы было более понятно, что стандарт касается публикации данных.
mkadunc
3

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

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

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

tauren.kristich
источник
0

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

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

оборота Энененва Оквудили
источник