Чем прогнозы ESRI WKT отличаются от прогнозов OGC WKT?

9

Кто-нибудь знает точный список различий между строками формата проекции ESRI WKT и OGC WKT?

Я знаю, что существуют различные инструменты для преобразования ESRI WKT в OGC WKT, включая утилиты GDAL и различные сервисы веб-сайтов. Но мой вопрос не имеет практического характера, я просто хочу понять различия форматирования / синтаксиса, которые используют эти сервисы. Предыдущие вопросы Stackexchange говорили только о разнице в конкретных примерах или о доступных инструментах и ​​услугах.

Даже если вы просто знаете одно отличие, было бы здорово, если бы вы могли просто опубликовать его. Исходя из моего собственного опыта, должно быть лишь небольшое количество различий. Различия, о которых я знаю:

  • большинство текстовых элементов в определении esri использует подчеркивание, где ogc использует пробел.
  • текст, определяющий данные в esri wkt, совпадает с ogc wkt, за исключением того, что начинается с "D_".
  • иногда текстовые идентификаторы для некоторых предопределенных PROJCS, PROJECTION, GEOGCS и DATUM пишутся по-разному (например, «NAD83», в том числе «North_American_1983»). Я предполагаю, что единственный способ узнать, какие идентификаторы пишутся по-разному, - это иметь список или справочную таблицу, поэтому, пожалуйста, назовите любой, который, как вы знаете, отличается.
  • различные текстовые значения PARAMETER одинаковы, за исключением того, что у ogc каждое слово имеет верхний регистр, тогда как у esri все строчные. Тем не менее, я видел случаи, когда это правило не использовалось. Кто-нибудь знает, действительно ли заглавие имеет значение, когда речь заходит о программном обеспечении, которое пытается их загрузить?
  • тип UNIT записывается в верхнем регистре заглавных букв в ogc и в нижнем регистре в esri, например, «Степень» против «степень». В некоторых случаях я видел ogc как «метр» и «m» для «Метр», а в других случаях с французским правописанием «метр». Кто-нибудь знает, каково правильное соглашение для этих или любых других типов единиц для обоих форматов?
Карим Бахгат
источник

Ответы:

6

У меня нет такого списка, но прохождение кода GDAL поможет вам:

https://svn.osgeo.org/gdal/trunk/autotest/osr/osr_esri.py

https://trac.osgeo.org/gdal/browser/trunk/gdal/ogr/ogr_srs_esri.cpp

https://trac.osgeo.org/gdal/browser/trunk/gdal/ogr/ogr_srs_esri_names.h

https://trac.osgeo.org/gdal/browser/trunk/gdal/ogr/ogrspatialreference.cpp

Andrej
источник
2
В основном ESRI делают это по ходу дела :-)
Ian Turton
1
@iant Будучи первым, кто внедрил библиотеку кода в соответствии со спецификациями EPSG, у них почти не было выбора.
Винс
2
Мы были, вероятно, вторыми - поскольку спецификации GeoTIFF были доступны в то время. @ Я бы сделал несколько вещей по-другому, если бы мы создали новый движок Esri!
Mkennedy
Ладно, так что многое из этого выглядит очень неординарно, в особом порядке. на самом деле, судя по ссылочным документам, существуют сотни строк кода особых случаев в именных различиях и так далее. все из-за различных программных реализаций и, вероятно, отсутствия согласованных стандартов в то время: р
Карим Бахгат
Было бы очень полезно, если бы ESRI и GoeoTiff всегда добавляли кодовый номер EPSG в строку проекции WKT. QGIS создает дополнительный файл .qpj для шейп-файлов, чтобы сохранить этот параметр.
AndreJ
9

Вы поймали много различий. Esri никогда не принимал WKID для алгоритмов проекции карты или имен параметров, поэтому они все разные. Мы не согласились с тем, насколько тщательно определены определения параметров. Наши более обобщенные.

Мы не поддерживаем TOWGS84 и некоторые новые ключевые слова.

Когда мы сравниваем строки (имена), мы игнорируем подчеркивания, GCS_ и D_ и регистр. Это не может быть правдой в других парсерах. Наш синтаксический анализатор строг в отношении имен, но мы добавили некоторые синонимы и теперь ведем списки имен от различных поставщиков для сравнения.

Исходная спецификация системы координат от OGC не стала конкретной, когда речь шла об именах объектов. Существует новая спецификация OGC / ISO "Географическая информация - общеизвестный текст для стандарта систем координат", которая проходит через процесс стандартизации. Это гораздо более конкретно о том, какие имена должны быть (соответствуют реестру EPSG!). В будущем внедрение этого стандарта будет весьма увлекательным.

Раскрытие информации: я работаю в Esri, являюсь членом подкомитета, который ведет реестр EPSG, и был членом чернового комитета CRS WKT 2.0.

mkennedy
источник
Вау, это действительно интересно, особенно слышать некоторую внутреннюю информацию от кого-то, кто принимал участие в принятии решений. Новая спецификация OGC ISO звучит очень многообещающе. Как вы думаете, вероятно, что больше крупных поставщиков ГИС и форматов данных начнут сходиться к ее использованию? К сожалению, я подозреваю, что некоторые из старых различий будут сохраняться до тех пор, пока старые форматы данных остаются популярными (например, шейп-файл, геотиф).
Карим Бахгат,
Вы говорите, что не поддерживаете TOWGS84, но как все может работать без этого? Если WKT использует неизвестные имена (т. Е. Определяемые пользователем проекции / данные), система координат не может быть правильно настроена, когда смещение координат игнорируется. Или я что-то упустил?
PMF
Большинство лучших преобразований используют файлы сетки, а не метод с 3 или 7 параметрами. Группа преобразований также не использует WGS84. Это очень ограниченное решение. Вместо этого мы поздно связываем ... выбираем / устанавливаем преобразование во время преобразования.
Mkennedy
Если это неизвестно системе, используйте инструмент создания пользовательских географических преобразований. Новый CRS WKT также охватывает трансформации. Приходите Arron к программному обеспечению рядом с вами!
Mkennedy
0

В качестве потенциальной отправной точки для списка отличий может помочь мой новый пакет PyCRS , где я попытался создать класс для каждого элемента crs, параметра и имени datum / ellips / proj, а также их написания esri_wkt против ogc_wkt , Я также указал, как я вижу различия в разборе с точки зрения структуры wkt в целом в _from_wkt()функции в parser.pyподмодуле. Я надеюсь, что с помощью пользовательских вкладов эти различия могут быть дополнительно добавлены и / или исправлены.

https://github.com/karimbahgat/PyCRS

Карим Бахгат
источник