WKT формат и численное задание датума

Добрый день, есть небольшой вопрос/уточнение к формату задания датума в формате WKT. В качестве версии возьмем для примеру эту (вроде последнюю). В табличке Е.4 есть пояснение:

Собственно, вопрос в чем .. как я понял формулировка геодезического преобразования/датума по методу Бурса-Вольфе в программах предусматривает использование обратных параметров матрицы поворота осей координат (ωx, ωy, ωz) относительно формулировки по Гельмерту. То есть классический датум EPSG:5044 выглядит по-Гельмерту так - TOWGS84[23.57,-140.95,-79.8,0.00000000,-0.35000000,-0.79000000,-0.22], а вот по Бурса-Вольфе будет уже так: TOWGS84[23.57,-140.95,-79.8,0.00000000,0.35000000, 0.79000000,-0.22]
Собственно ... текстовое описание датума одинаково но как простите программа понимает в какой формулировке он записан? Нафиг тогда писать в таблице E.4 эти 2 поддерживаемых способа если будет восприниматься только один? QGIS например явно поддерживает формудировку по Бурса-Вольфе, а AutoCAD Civil 3D по Гельмерту ....
Вопрос в том - верно ли я понимаю разность знаков в этих типах записи датумов? (научной стороны их выведения и различия я специально не касаюсь). И практичней ли тогда использовать все таки выражение через Бурса-Вольфе?

 

Числа одни. Чем практичнее? Это же множители. Действие одно.

 

Тут вопрос скорее в том, чтобы как-то прописать в этом коде какой именно тип используется (при вставке кода WKT в иное ПО где заведомо неизвестно как он считывает эти параметры) - чтобы не возникло погрешностей. Или в современной версии по дефолту всё читается только по Бурса-Вольфе? Я сильно оторван от ГИС-ПО кроме Autodesk и QGIS ... как оно там в другом воспринимается

 

towgs84 имеет в виду абсолютно однозначное преобразование - а именно те формулы которые
имплементированы в исходниках "классической" библиотеки proj4,
поэтому "формулировки" - результат непонимания и путаной документации.

 

Но WKT то более универсальным считается? Мне честно PROJ больше импонирует что он короче
Я вообще интересовался с мыслью сконвертировать имеющиеся определения в черт-пойми-чем во что-то адекватное и WKT мне мыслится очень универсальным ...

 

потому что TOWGS84 это костыль, proj уже перешёл на WKT2
https://gis-lab.info/forum/viewtopic.php?f=3&t=26515&p=175851#p175851

 

То есть практичнее уже делать в данном формате описания проекций?
Я, правда, не нашел сходу - а есть где-то спецификация поддерживаемых определений проекций?

Код:

METHOD["Transverse Mercator

- типа такого, именно формулировки с позиции орфографии, чтобы конечная программа верно идентифицировала коды.И надо ли
оформлять проекции Гаусса-Крюгера как Поперечная Меркатора? В старой WKT начала 2010х так вроде можно было, не знаю как сейчас? Потому что тот же QGIS ругался на нее .. Интересуюсь другими типами проекций чтобы для пробы попробовать сделать перевод для проекции Ламберта, к примеру ...

 

http://docs.opengeospatial.org/is/18-010r7/18-010r7.html

 

Раскрыть Спойлер Свернуть Спойлер

С этими обратными знаками разворота осей всегда были проблемы (у американцев и европейцев разные соглашения), поэтому в морской практике заказчик всегда представляет параметры перехода с обязательным образцом/примером координат в WGS84 и выбранном датуме. Слышал историю от коллег (ОБС), что ещё в 80-е наши сейсмики работали на шельфе Сахалина в датуме WGS72 и промахнулись со знаками перехода, в результате ошибочные параметры кочевали из проекта в проект (вынужденная преемственность). И так получается, что у каждой нефтяной компании в одном и том же регионе может использоваться свой датум.
Чтобы хоть как-то упорядочить этот бардак нефтяниками была создана база EPSG (European Petroleum Survey Group), которая позднее оказалась удобной и в других применениях, только мало уже кто помнит, кто зачинщик )))

 

Оффтоп

Программы для пересчета координат

 

Уже не совсем в тему...
Попробовал перевести XML-библиотеку систем координат Civil3D в тот же WKT2
Чето QGIS не хочет кушать его
Выглядит это безобразие так:

Код:

BOUNDCRS[SOURCERS[PROJCRS"Russia-MSK26-Zona1",BASEGEOGCRS["Unknown datum based upon the Krasovsky-SK42/95 ellipsoid",DATUM["RUSSIA-REF-SK42",ELLIPSOID["Ellipsoid Krasovsky SK-42/95 GOST 32453-2017_4.2.2",6378245,298.30000000,LENGTHUNIT["metre",1,ID["EPSG",9001]]]],PRIMEM["Greenwich",0,ANGLEUNIT["degree",0.0174532925199433],ID["EPSG",8901]]],CONVERSION["Russia-MSK26-Zona1",METHOD["Transverse Mercator",ID["EPSG",9807]],PARAMETER["Latitude of natural origin",40.98333333333,ANGLEUNIT["degree",0.0174532925199433],ID["EPSG",8801]],PARAMETER["Longitude of natural origin",0,ANGLEUNIT["degree",0.0174532925199433],ID["EPSG",8802]],PARAMETER["Scale factor at natural origin",1,SCALEUNIT["unity",1],ID["EPSG",8805]],PARAMETER["False easting",1300000,LENGTHUNIT["metre",1],ID["EPSG",8806]],PARAMETER["False northing",-4511057.63,LENGTHUNIT["metre",1],ID["EPSG",8807]]],CS[Cartesian,2],AXIS["(E)",east,ORDER[1],LENGTHUNIT["metre",1,ID["EPSG",9001]]],AXIS["(N)",north,ORDER[2],LENGTHUNIT["metre",1,ID["EPSG",9001]]]]],TARGETCRS[GEOGCRS["WGS 84",DATUM["World Geodetic System 1984",ELLIPSOID["WGS 84",6378137,298.257223563,LENGTHUNIT["metre",1]]],PRIMEM["Greenwich",0,ANGLEUNIT["degree",0.0174532925199433]],CS[ellipsoidal,2],AXIS["geodetic latitude(Lat)",north,ORDER[1],ANGLEUNIT["degree",0.0174532925199433]],AXIS["geodetic longitude(Lon)",east,ORDER[2],ANGLEUNIT["degree",0.0174532925199433]],ID["EPSG",4326]]],ABRIDGEDTRANSFORMATION["Reference ellipsoid SK-1942 Datum from GOST_32453-2017",METHOD["Coordinate Frame rotation(geocentric domain)",ID["EPSG",9607]],PARAMETER["X - axis translation",23.57,LENGTHUNIT["metre",1.0],ID["EPSG",8605]],PARAMETER["Y - axis translation",-140.95,LENGTHUNIT["metre",1.0],ID["EPSG",8606]],PARAMETER["Z - axis translation",-79.8,LENGTHUNIT["metre",1.0],ID["EPSG",8607]],PARAMETER["X - axis rotation",0.00000000,ANGLEUNIT["arc - second",4.84813681109535E-06],ID["EPSG",8608]], PARAMETER["Y - axis rotation",-0.35000000,ANGLEUNIT["arc - second",4.84813681109535E-06],ID["EPSG",8609]],PARAMETER["Z - axis rotation",-0.79000000,ANGLEUNIT["arc - second",4.84813681109535E-06],ID["EPSG",8610]],PARAMETER["Scale difference",-0.22,ID["EPSG",8611]]]]

QGIS ругается так:

Что ему надо, не пойму((
И название указал метода, и единицы измерения (коих не было к слову на gis-lab), и пробелы вроде убрал везде, и параметров 7 штук.. фиг знает :(
Делал по примеру описания СК для г. Москва отсюда. Также ориентировался на http://docs.opengeospatial.org/is/18-010r7/18-010r7.html
Если не нравится МСК 26 Зона 1 во вложении остальные 389 (?) проекций для России .... все равно материал из открытых источников весь. Не наказуемо ?
P.S. Обработку делал в Visual Studio

 

Во всю биографию, при передаче уточняющих параметров даю контрольный пример. Жгуче плюсую под вашим постом!!

 

Эк Вас, батенька, занесло! Там для Вашего случая другой пример на основе любой проекции на датуме "Pulkovo 1942". Держите определение WKT 2 для МСК26 зона 1:

Код:

PROJCRS["Pulkovo 1942 / MSK26 zone 1",
    BASEGEOGCRS["Pulkovo 1942",
        DATUM["Pulkovo 1942",
            ELLIPSOID["Krassowsky 1940",6378245,298.3,
                LENGTHUNIT["metre",1]]],
        PRIMEM["Greenwich",0,
            ANGLEUNIT["degree",0.0174532925199433]],
        ID["EPSG",4284]],
    CONVERSION["MSK26 zone 1",
        METHOD["Transverse Mercator",
            ID["EPSG",9807]],
        PARAMETER["Latitude of natural origin",0.1,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8801]],
        PARAMETER["Longitude of natural origin",40.9833333333333,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8802]],
        PARAMETER["Scale factor at natural origin",1,
            SCALEUNIT["unity",1],
            ID["EPSG",8805]],
        PARAMETER["False easting",1300000,
            LENGTHUNIT["metre",1],
            ID["EPSG",8806]],
        PARAMETER["False northing",-4500000,
            LENGTHUNIT["metre",1],
            ID["EPSG",8807]]],
    CS[Cartesian,2],
        AXIS["northing (X)",north,
            ORDER[1],
            LENGTHUNIT["metre",1]],
        AXIS["easting (Y)",east,
            ORDER[2],
            LENGTHUNIT["metre",1]],
    USAGE[
        SCOPE["unknown"],
        AREA["Europe - Russia - MSK26 zone 1"],
        BBOX[44.30,40.84,46.14,42.48]]]

Трансформацию выберите "Pulkovo 1942 to WGS 84 (20)" и установите её по умолчанию.

 

Мне не нужна такая интерпретация системы координат на родном эллипсоиде - нужно именно свести ее к WGS-84. Упрощенно, мне нужна четкая связь между данной СК на N-эллипсоиде с WGS-84, где будет использоваться ABRIDGEDTRANSFORMATION с нужными параметрами.
.... Тут я что-то недопонимаю как включить в определение WKT эту трансформацию тогда... Ваш блок то есть вставить в конструкцию?
BOUNDCRS[SOURCECRS[...ваш блок], TARGETCRS[..трансформация?]]

 

В базе данных EPSG системы координат ассоциированы с наборами трансформаций. Нужная Вам трансформация там уже есть и привязана к "Pulkovo 1942". Она называется EPSG:5044 "Pulkovo 1942 to WGS 84 (20)"
Когда открываешь данные на датуме "Pulkovo 1942", программа спрашивает, какую трансформацию использовать. По умолчанию предлагает "Pulkovo 1942 to WGS 84 (16)". Выберите вместо неё двадцатую (20) и внизу справа поднимите флажок "установить по умолчанию".
Вот здесь об этом с картинками.

 

А если в конечном приложении вообще нет готовой базы данных или этой трансформации? Как себя максимально обезопасить включив это в WKT или лучше тогда создать именно отдельное описание трансформации в WKT?
QGIS один из примеров только .. это что угодно может быть
PS Или если это преобразование отсутствует в EPSG ... как тогда в этом случае?

 

Всё немножко наоборот. Многие коммерческие программы давно перешли на EPSG: ArcGIS, BMG Geographic Calculator и др. Так что проблемы с использованием стандартного датума нет. Скорее интересно, научилась ли такая программа понимать WKT 2.

Другое дело, когда программе, понимающей WKT 2, надо скормить нестандартную трансформацию. Об этом второй пример.

 

Вооооот, тут и начинается интерес - на статье в gis-lab нет единиц для параметров трансформации, когда как в спецификации 18-010r7_WKT тот же Scale difference может быть как "parts per million" или части единицы (если мас. коэф >0, то 1+ m/10^6; если меньше - то 1-m/10^6) ... также и для угловых параметров вращения - то в arc-seconds то в радианах ... то есть корректней все таки указывать на единицы же? Странно почему тогда в статье на gis-lab этого нет
PS И почему тогда сама трансформация там называется (..) если в спецификации это Coordinate Frame rotation (geocentric domain) Простите, увидел и такой вариант для неподтвержденных случае

 

Можно же создать свою на основе этой, как раз введя отличные от вшитых коэффициенты.
Но знаки да - приходится перепроверять.

 

Очень хорошо! Наконец-то появился человек, который во всём этом разберётся и разъяснит!