Смена датума

Question

Пролистал все что есть по вопросу на сайте: вроде бы тем много, но звучит в них примерно одно и то же: 1) ошибка за счет датума порядка 100 метров 2) датум при переходе от WGS к СК-42 надо корректировать 3) Projection Utility с датумом работает неправильно, и лучше применять отдельное приложение datum.avx, задавая параметры преобразоваания вручную. Проработал вопрос в рамках ArcView, в общем-то все получилось, но... хочется поделиться своим мнением и задать вопрос знатокам уже о деталях преобразования.

Поделиться вот чем: как известно, Projection Utillity мало того, что содержит явные недоделки, но еще и ошибочные параметры СК-42. Изменить их сложно, и, получается, пользоваться продуктом для смены датума нельзя. По крайней мере, из WGS в другой датум преобразования НЕ происходит.

В datum.avx, прилагаемый как образец от ESRI, можно вставить любые параметры преобразования. Что интересно, не раз в форуме звучало, что datum.avx некорректно работает, но ничего более конкретного. В связи с этим рекомендовалась исправленная версия от Янко Чукански. Мне эта некорректность не встретилась, но тем не менее опробовал разные версии avx... Параметры брал те, что используются в GPS. Для сопославления произвел эти самые преобразования еще и GPS-программой DNR Garmin, по методике GIS-Lab. Кому интересно, там детальная дискуссия о источниках параметров, в т.ч. ошибочных, алгоритмах расчета и т.п. Результаты сопоставления на рисунке. Для простоты показаны только преобразованные варианты линии с большим увеличением, а сам исходный трек расположен на 100 примерно метров западнее, как и должно быть.



Результат получился неожиданный: преобразования, сделанные модулем datum.avx, совпадают с преобразованиями, сделанными DNR Garmin! Я-то ожидал заметного расхождения... всё-таки разные разработчики... Тем не менее разница не более полметра, да и то при применении для datum.avx округленных параметров преобразования. Когда ввел более точные, дробные, как и в DNR, то остались жалкие первые миллиметры - на рисунке их не видно, эти линии совпадают. Похоже, алгоритм преобразования Молоденского запрограмммирован и в AV и в DNR адекватно. Этой адекватности, похоже, можно доверять - пересчет датума непосредственно прибором GPS дает те же результаты - а это уже третий разработчик. 

 

Также пока не заметил никаких ошибок в своей версии datum.avx - немного неудобно, но и только, работает стабильно. Этого нельзя сказать про последнюю версию Янко Чукански, datum2.avx, выложенную на его сайте - как видно, она "ошибается" почти на два метра: похоже, в этой версии Янко перестарался и алгоритм "задел" ненароком. Впрочем, его первый вариант, datum1.avx преобразует правильно. Найти его удалось не сразу, большое спасибо S.E.

Пара слов насчет ArcMap. Там много разных алгоритмов преобразоваания датума, есть и Молоденского, но... все они выдают результат, расположенный примерно на 10 метров "выше" рисунка. Это настораживает: ни о каком совпадении с алгоритмами Garmin в таком случае говорить не приходится... Впрочем, в AM я не успел протестировать все версии, только восьмерку, да и то бегло.

И наконец, вопрос: я в общем-то только принялся разгребать эту проблему, наверняка кто-то много работал с датумом: коллеги, какой софт, методы применяете для AV: неужели используются только вышеперечисленные средства, или что-то еще? Свои наработки? Как-то это все не выглядит удобно, с ходу хочется брать и улучшать (однако пример Чукански настораживает :)

Другой вопрос: как быть с Arcmap? Там по умолчанию стоит совсем не Молоденский, а геоцентрический метод преобразования датумов. Кто-нибудь изучал эти методы преобразования, их разброс, пробовал что-либо из штатного набора или создавал свои? Какие мнения насчет AM кроме того, что "там все классно"?

Answer 1

Привет, коллеги!

Спасибо за замечания. Приятно общаться с умными людьми. Буду с интересом наблюдать к чему придет это высоконаучное обсуждение. Это не ирония - кроме шуток. У самого до такого руки не доходят, а знать нужно.

Мне вот только интересно, какая практическая цель у всего этого? Откуда взялись в Москве и Тюмени данные на эллипсоиде WGS84? Скорее всего кто-то поехал в поле с GPS прямо с заводскими настройками. Наверное еще и в милях измеряли?

Нас пока-что устраивает та система работы, о которой я написал. Тем более, что критерием оценки все равно является изданная карта.

Если есть сильное желание можно поинтересоваться методикой работы высокоточных навигаторов Trimble. Насколько я знаю, там "российская система" встроена сразу. А вот почему Garmin этого не сделал - вопрос. Зачем, если и так покупают?

Извиняюсь, если я опять что-нибудь сморозил :-)

Успехов.

Answer 2

Ваша ирония понятна - вы редко встречаете данные WGS. У нас их полно - данные от "совместных" заказчиков в том числе и векторные, космические снимки  - ландсат, SRTM, Iconos да мало ли еще? Детальность этого растет, и если для ландсата было не зазорно компенсировать датум подбирая сдвиг, то дальше - больше.

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

 

 

Answer 3

Попробуйте поискать Trimble Geomatics Office Software.

Я, правда, смотрел на нее всего 5 минут. По рассказам - оффис предназначен не только для скачивания с этого навигатора, но и для пересчета любых введенных точек. По каждой точке можно получить три вида координат (плоскость, референц-эллипсоид и WGS) простым выбором Radio Button.

Answer 4

Может я что-то не понимаю, но почему нельзя пересчитать данные из WGS-84 в географические координаты (простой скрипт на Avenue), а потом просто спроецировать в Пулково-42. Или я не прав?

Answer 5

Спасибо, поищу. Есть у кого поспрашивать... Правда, прибор Trimble нам не светит, но, возможно, данные с него придется обрабатывать.

2PAS: Речь в теме идет о преобразовании не проекций, а датумов, т.е. систем координат. Причем координаты и WGS и Пулково имеются в виду географические (в общем случае). Но разные - в разных системах ведь. О датумах читайте здесь.

Answer 6

У нас и прибор Trimble есть, и Trimble Geomatics Office Software. Вот только геодезисты у нас не достаточно квалифицированны, чтобы с вопросами поднятыми в этой теме разобраться:(((

Answer 7

    Кратко опишу метод использованный мной при 1:50 000 геологической с`емке:
-Точки и треки были конвертированы в SHP (датум wgs84)
-Растр топоосновы (сделан в Pu42) был привязан в wgs84:
*Карта привязана по сетке в Pu42
**Не трудно посчитать, что для каждого конкретного места (в пределах 1000-го листа) метровые координаты для датумов wgs84 и Pu42 различаются на постоянные dX и dY (wgs84-Pu42)```
***В файле привязки растра топоосновы из координат (они в Pu42) вычитаются (прибавляются) dX и dY
****В результате растр привязан в wgs84
-В свойствах вида ставим (эллипсоид-wgs84) и тд
-Точки и треки и растр= в одном датуме-wgs84? отображаются корректно.
-При необходимости создаем новую тему (AV_3.2)-она автоматически будет в wgs84 и рисуем
Эту тему заливаем в GPS и выходим куда планировали

``` Параметры преобразований- 3-х параметрические, Для датума Pu42 они находились посредством Exel-евской таблицы "нахождение оптимальных параметров преобразования wgs84-Pu42"

А если возникает необходимость представить координаты точек wgs84 в Pu42, то используя ГОСТ-овские (или те же полученные "..оптимальные параметры"):
-файл с точками (координатами) в wgs84 припомощи, скажем "Geographic Calculator" от Blue Marble Geographics, конвертируем в Пулково.

Answer 8

Давайте, такой эксперимент проведем:

Имеется точка с координатами в Пулковском датуме 42 г. : 

61 в.д. и 57 с.ш.

Ее координаты в проекции ГК для 11 зоны (цм 63 градуса) будут:

х=11378463,6      у=6321803,8 м

(На самом деле в проекции ГК координаты Х и У надо менять местами, но здесь будем писать в том виде, как их понимает ArcView).

 

Рассчитайте с помощью Exel-овского  алгоритма, каковы будут координаты этой точки в WGS84 и чему будут равны сдвиги dx, dy в метрах...

 

 

Answer 9

karel говорит разумные вещи. Трюк с привязкой топокарты используется, и очень удобен в том случае, если базовых растров немного, а треки идут потоком - чтобы не преобразовывать последние каждый раз в ГК.

Однако расчет dx, dy - вопрос отдельный от привязки, растры ведь можно сажать и традиционным ГИС-способом - берется сетка ГК, её датум меняется одним из вышеописанных способов (Project Utility, datium.avx, DNR  garmin) на WGS, притом что проекция остается ГК. Это нужно сделать всего ОДИН раз на весь ваш район. Потом к этой сетке вяжутся растры, далее понятно. Обычный туристский способ, профессионалам, возможно, такое покажется нарушением канонов :)

 

Метод с dx и dy интересен тем, что пересчет в обе стороны уже имеющихся координат упрощается донельзя, и круг средств расширяется - годятся любые ГИС-редакторы, CAD-средства и тп. Для коррекции неизвестного датума мы в свое время тоже с успехом использовали просто сдвиг, рассчитав его, однако, по сеткам (они изначально имелись в двух версиях). На территорию примерно 100 на 100 км для разных узлов сетки сдвиг был все же разный, пришлось dx и dy осреднять. Ошибка получилась до метра для краев, что для наших GPS  в ту пору было несущественно.

Answer 10

Ну, по сути это та же задача, как вы правильно заметили, только задом наперед. Но тут ИМХО есть одно слабое место - подгоняя те же треки под растр точность будет зависть от точности самого растра. Если мы взяли зеленку 50000, то ее точность 1 мм, то есть 50 м. А как показывает вышеприведенная дискусия, варьируя разными поправками мы за 50-метровую точность и так не вылазим, тут цена вопроса уже идет на первые десятки метров, а их уже растром не отловить (точность привязки растра, точность снятия координат GPS - ведь не секрет, например, что записав трек по дороге в одну сторону, а потом в обратную идеальной сходимости треков мы не получим).