Смена датума

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

В том-то и дело, что я не знаю, как соотносятся. Я только проиллюстрировал, что

1) есть ряд программ, которые работают ОДИНАКОВО - datum.avx, datum1.avx, DNR Garmin, к ним еще добавьте сам прибор Garmin и еще его родную программу MapSource. Весь этот софт дает результаты, которые отличаются на миллиметры, т.е. практически одинаковые (разумеется, при одинаковых параметрах преобразования).

 

2) ВРОДЕ БЫ, судя по фрагментарным описаниям, косвенным признакам и общим соображениям, там везде применяется самый простой и популярный алгоритм Молоденского, трехпараметрический.

 

3) никакие другие программы, включая ArcMap с применением (ТОГО ЖЕ МОЛОДЕНСКОГО 3-параметрического!!!) не дают сколько-нибудь сходных результатов.

 

СЛовом, НЕ О ТОЧНОСТИ РЕЧЬ, и не том, какая программа правильней считает, пусть геодезисты выясняют. А нам, мне кажется, стоит думать о том, чем вообще адекватно можно пользоваться в гис для датума. ЧЕМ????? Подскажитя!!! Я, например, готов уже для своего региона  пользоваться просто сдвигом для коррекции датума, это можно легко настроить и в GPS, и в проекциях, плевать, лишь бы

 

а) туда-сюда не давало никакого разброса, чтоб не шло накопление ошибки.

б) ну и не сильно отличалось от сложных эллиптических расчетов. Если разброс методов коррекции датума даёт метров 30, то при плоской коррекции на регион обычно набегает ошибка метров 5-10, вот и сойдет. Лишь бы адекватно!!!

 

Поясню еще примером, а то чувствую, опять не в кассу. Если я, например, применю молоденского в ArcMap (туда), а обратно мне исполнитель применит datum.avx, поскольку у него только AV 3.x,  то поработав месяц-другой в таком цикле, мой шейп уедет метров на 300-500. Значит, мне нужно либо запретить исполнителям вообще играться с датумом, либо велеть им применять строго только ArcMap. В корректности последнего я пока не уверен, хотя бы потому, что по умолчанию там стоит геоцентрический метод (это для Пулкова-то!!!).  Первое тоже не проходит, исполнители люди продвинутые и воспримут запрет как оскорбление личности. Значит, я вынужден, работая в ArcMap, и всем рекомендовать и сам применять datum.avx!!!!!!! Или левый DNR. Или даже Garmin GPS через ком-порт :)))

Answer 2

А зачем датумы туда-сюда гонять? Вы правильно пишите, что может получиться как в песне: "Шаг вперед и два назад...".

Я, например, проблему с датумами вижу по большому счету только одну - корректо перегнать данные из GPS в AV...

Answer 3

Вот меня-то тут сильно беспокоит именно корректность этих (хотя-бы) преобрахований координат. Дело в том что геодезистов-то здесь видимо нет почти. То есть не используют они в основном продукты ESRI.  Тут и вопросы сертифицируемости с т зр Российского использования в картографии не вполне ясны - представители Даты+ так ине окликнулись. А думаю, этот как раз их компетенция - ведь они представляют ESRI именно в России и вопросы хотя бы рекомендаций по использованию датумов и их преобразований для нас критичны. Нет этого только и на их сайте и др местах(напр документации поставляемой вместе с ПО). Мб они есть - но дайте тогда ссылку. А так мы будем экспериментировать - и прав geologic тогда... сами разберемся, конечно в конце-концов.-  Но вот мне бы хотелось получить ответ также и от Даты и по методлич рекоменд использования преобразований координат и ответ по сертифицируемости ПО в России.

Answer 4

2 Nickolay  

5 баллов!!! Солидарен, хотелось бы послушать "начальника транспортного цеха"

Answer 5

насчет туда-сюда поясню... Конечно, можно закрыть глаза на то, что СК-42 у вас без датума. Но ежели вы работаете с пронзительными партнерами, а они, например, для построений используют наши карты, то разница в 100 метров становится очевидна. Мы с этим столкнулись впервые неск. лет назад, когда работали в 25К масштабе, в т.ч. с полевыми исследованиями. GPS тут лишь один из факторов за, ведь нарисовав карту по российской топографии вы тоже "попадаете" в датум, и при переходе к WGS это надо учитывать.

Итак, если у вас тематические слои создаются по топокарте, а заготовка для них - например, в Iconos, то вы должны либо перепроецировать всё, включая растры, в одну проекцию, либо "бороться" с датумом при редактировании шейпов. Первое не так уж невозможно, но растров обычно немало в современном проекте, и поступают все новые и новые версии. Второе проще - перепроецируются лишь рабочие вектора. Однако цикл работ предполагает многочисленные редакции... Пока мы с этим рахобрались, у нас стихийно (благодаря Projection Utility) возникло три проекции вместо двух: UTM, СK42 c датумом, и СК42 без датума. Без никакого участия GPS. Притом что они продолжали плодиться, т.к. одни исполнители добровольно компенсировали датум, а другие двигали контура руками... :)

 

Но последнее это уже просто неаккуратность, а мы тут о геодезии. А все первое именно о ней. Впрочем, тем кто работает один над двумя листочками, могут себе ппозволить более простые варианты решений.. Вплоть до привязать топокарты БЕЗ датума, по сдвинутой сетке. Я думал и об этом "для личной" топографии.

Answer 6

S.E..

В моей практике с датумами:

- (так как вы пишете) правильно перегнать из  GPS в AV

- проверить куда все-таки попадают намерянные ранее геодезистами-профессионалами для Заказчика несколько точек в WGS-84, при том что мы у себя на это все смотрим в Пулково-42 (и при этом как назло кто-то жалуется на эти точки геодезистов по сравнению с GPS измерениями, что мол не точны они то на 50 метров, то на 30, то на 200м). Вот и рассуди (судить геодезистов не возьмусь никогда, но хоть сориентироваться что-к чему надо бы)

И последнее - преобразование датумов проводим не внешними утилитами а помощью ReturnProjected и returnUnprojected в avenue.

И внешними утилитами упомянутыми тоже иногда пользуемся. Вот ведь беда какая - разберись что использовать среднебезопасно...

Беда...

Answer 7

Сегодня в коллективе повспоминали дни борьбы с "тюменским датумом". Пожалуй, я немного слукавил. Основная проблема тогда была в том, что мы ориентировались на ArcView (который датум никак не имитирует), и на Project Utility, который гонит шейпы лишь в одну сторону. Если б делать сейчас в AM, подумали мы, наверно не стали б париться: как он делает по умолчанию при переходе в СК42 и обратно, так бы и пусть. Хоть ба и геоцентрически :) GPS гнать можно тем же путем. Вопрос бы скорее стоял - что делает MapInfo  (знаменитая проекция "Широта-Долгота Пулково 42")!?

С другой стороны, "западный" упрощенный алгоритм Молоденского выдерживается в софте - вот что пишут на http://gis-lab.info/qa/gps-dnrgarmin.html про DNRGarmin:

 

"Получаемые таким образом данные до 6 знака после запятой [координаты] соответствуют пересчету проводимому самим прибором GPS (то что он, собственно показывает на экране) и пересчету в пакете Arcinfo Workstation c такими настройками перепроектировки, что говорит об отсутствии ошибок в данной ситуации и о том, что программе можно доверить данную операцию. Используемое преобразование для GPS, DNR Garmin и Arcinfo Workstation одинаково - 3-х параметрическое преобразование Молоденского."

Answer 8

Опять к вопросу о датумах.

 

Здесь уже неоднократно говорилось, что мы геологи и не являемся специалистами в таких вопросах. У меня лично почти сразу голова начинает трещать и совершенно нет желания вдаваться в проблему. Тем не менее уже два-три года подряд мы ее так или иначе решаем. Последний раз пришли к "сухому остатку" (как в Гис-Лабе) в 2005 году.

Чтобы иметь хоть какую-то точку отсчета мы использовали официальные русские таблицы пересчета координат из градусов в проекцию Гаусса-Крюгера (метры). Они обычно есть у топографов и, я думаю, являются хорошим эталоном.

Итак, в прошлом году мы изучали:

Основные вопросы для изучения:

 

I. - Гис-программа ArcView по разному преобразует координаты  через Вид и через Проекционную утилиту.

II. - Параметры пересчета dX=28, dY=-130, dZ=-95 являются неправильными.

III. - Нужно ли умножать 0.000000480795 на 10000.

 

Проверка расчетов координат в ArcView.

I. Первый вопрос решился достаточно быстро. При одних и тех же исходных данных пересчет координат из десятичных градусов в проекцию Гаусса-Крюгера производится с разницей в доли миллиметров (на местности!). Таким образом разница несущественна.

 

 

Исходные данные (в десятичных градусах) NUM,LAT,LONG	Проверочные данные по таблицам Гаусса-Крюгера: (со смещением +500000 м)
1,56.00,95.50 2,56.00,95.75 3,56.333333,95.50 4,56.333333,95.75	1,56.000000,95.50,655966.0,6211493.4 2,56.000000,95.75,671558.3,6212086.1 3,56.333333,95.50,654620.4,6248595.6 4,56.333333,95.75,670178.1,6249185.4

 

Заявленная точность таблиц 0.2 м.

 

Результаты вычислений

Вариант №1 - через Вид.

(Поперечная Меркатора, Осевой меридиан 93.0, с

Answer 9

Возражу, коллега: вообще-то ArcView НЕ умеет работать с датумом, об этом как раз речь и идет в теме. Вот простой пример: берем некую подмосковную линию в географических координатах, про которую заведомо известно, что она отснята в датуме WGS (к слову сказать, это не важно, можно принять любую точку как данное). Преобразовываем ее в Пулково 42 так, как мы все умеем - через Transverse Mercator, эллипсоид естественно Красовского, ц. меридиан 39 и т.п. О датуме, заметим, по дороге мы не видим никакого упоминания, будто его и нету. Получаем некую другую линию уже сразу в прямоугольных метрах - толстая синяя линия на рисунке.

Как ее проверить? Берем Projection Utility, там датум выставлен по умолчанию, WGS_84_TO_PULKOVO_42, пусть с не совсем верными параметрами, неважно. Еще раз преобразуем исходный файл. Получаем полное соответствие с первым преобразованием - синяя линия средней толщины лежит на толстой. Что это, доказательство? Отнюдь нет. Делаем простой ход - преобразовываем третьим путем, также через Projecion Utility, но... отменив преобразование датума (GEOTRANSFORMATION_UNSET). Получаем третий шейп-файл, который... совпадает с первыми двумя - тонкая голубая линия на двух первых.

Черной точкой отмечены координаты вертекса, которые можно получить через GPS или MapSource, если настроить их на датум, как описано на ГИС-ЛАБ. Разница с исходной линией - 120 метров на ВЮВ, как и должно быть. Зеленая линия - преобразование исходного шейпа произведено программой datum.avx. Аналогичный результат дает, кстати, DNR garmin.

Приходится признать, что ArcView не умеет преобразовывать датум. Собственно, в ESRI этого и не скрывали никогда. Открываем help, находим два места про датум, одно - чисто теоретическое описание, в другом читаем: "So while ArcView has no knowledge of datums per se..." т.е. "поскольку ArcView НИЧЕГО не знает о датумах как таковых..."

Остальные разделы help о датумах относятся к Project Utility. Но почему последний-то не может  ничего сделать, ведь он и был задуман как дополнение для этих дел!!! Однако он выдает ОДИНАКОВЫЙ результат и С, и БЕЗ указания преобразования, почему??? Остается загадкой, баг это или фича. Может быть, я просто не умею запускать преобразование, или версия у меня не та. Но к моей и его чести, обратное преобразование, ИЗ пулковского датума в WGS Project Utility делает... Хотя "в одну сторону" оно мало кого интересует.

И последнее: правая зеленая линия на рисунке подтверждается еще и через ArcMap (удалось-таки настроить). По умолчанию преобразование датума там опять-таки выключено, хоть и стоит как geocentric. Но задав свое как "Abriged Molodensky" с теми же параметрами, что и все вышеописанные, получаем точно такую же зеленую линию. Ну не точно, разница в 0,6 метра все-таки имеется. На рисунке ее, естественно, не видно :)

Answer 10

To SV_P:

С таблицами Гаусса-Крюгера я в свое время проделывал подобные эксперименты и вполне удовлетворился результатами. AV дает даже более точные координаты по сравнению с таблицами, так как в последних точность, как вы правильно отметили, 0,2 м. То есть AV корректно пересчитывает координаты из географических в прямоугольные (сфера - плоскость). Это факт. Пример пересчета Мастером проекций лишний раз подтверждает это.

К сожалению, geologic прав. Это не приближает нас к решению вопроса преобразований между датумами (сфера - сфера).

 

>>>>>> ПРИМЕР с GPS:

Техника работы: сначала задаем локальные параметры (пользовательские настройки), потом создаем точку, например 56.0 град с.ш. и 95.50 град. в.д. (десятичные).

При этом настройки User Grid должны быть такими: Long..Origin E93.0, Scale 1.0000000, False E 500000.0, False N 0.0.

(Раньше мы вводили масштаб 1.0000006, компенсируя неправильно введенный параметр dF = 0.00000048).<?:NAMESPACE PREFIX = O />

 

Например для точки №1 результаты таковы: 655966 в.д. и 6211493 с.ш., т.е. соответствуют табличным.

>>>>>>>>>>>>>> 

 

Этот пример говорит лишь о том, что GPS тоже корректно пересчитывает координаты по типу "сфера - плоскость". И пользовательские поправки тут совершенно ни при чем. В этом легко убедиться на простом примере. Выполните все вышеописанные действия, задав на начальном этапе другие параметры преобразования между датумами, например от ESRI, а не "сухой остаток". Потом дальше по вашей же схеме - задаем точку 56; 59,5, потом устанавливаем центральный меридиан 93 и т.д. Смотрим прямоугольные координаты точки: 655966 в.д. и 6211493 с.ш., т.е. ноль-в-ноль с вашими, хотя поправки другие. Потому что с какими бы поправками вы не задали точку 56; 59,5 - результаты пересчета "сфера -плоскость" всегда совпадут. А вот "сфера - сфера" будут в наших случаях отличаться.

 

>>>>>>>>>>>>>

Попытка ввести в GPS параметры, используемые в программе ArcView (dX=28, dY=-130, dZ=-95 ), приводят к несоответствию координат в десятки метров........

>>>>>>>>>>>>>>

это понятно, ведь вы поменяли настройки перехода "сфера - сфера" и точка 56-59,5 у вас уплыла. Верните ее в круглые координаты и получите идентичный результат...