RTKlib/постпроцессинг

-1

-1

Да вот уже умельцы программку продают, за 2000р, физ. лицам без всякого встроенного первого отдела, и программка чудненько МСК пересчитывает.
Повторюсь еще раз - нет в геодезических миллиметрах никакой стратегической секретности, есть только коммерческая. В смысле потенциальных проблем на свою голову - сложно сказать сходу, что более чревато: наступить на довольно абстрактные стратегические интересы (или параноидальный бред на эту тему) или на вполне конкретные коммерческие.
Но соображение мое такое: риск велик, если есть, что делить. Тот же ОСМ существует “ортогонально” к российской картографии - данные не соответствуют никаким ГОСТам и не могут быть к ним приведены принципиально, а потому какая бы у них точность не случилась, официально как “настоящая карта” они использованы быть не могут. Простым же гражданам на ГОСТы плевать, от того им все это использовать ничто не мешает.

Документация по плейсхолдерам пути выскакивает, если в окошке FTP Option нажать на знак вопроса над полем для пути (японский минималистический интерфейс меня местами удивляет), в PDF-документации они не описаны.
Я поступил проще - натравил на rtknavi программку filemon и поискал в логе “sp3”. Нашел: искало оно igu17342_06.sp3.Z (06 потому что я раньше логи писал чем сообщение, так что 12 мне было слишком поздно).

Оказалось, что rtknavi из системной переменной %TEMP% путь к временному каталогу брать не хочет, а хранит путь в конфиге: Options - Files - FTP/HTTP Local directory. И было там C:\Temp , которой у меня не было. Создал, файлик появился и распаковался, в процессе работы rtknavi индикатор третьего входа correction красным мигать перестал, светился зеленым. Правда, на форме кривой это в итоге не сказалось (визуально, по крайней мере). Режим - тот же: PPP Static.
Получается, что данные эфемерид не особо помогают, или режим все же неправильный?

usm78-gis
BushmanK

Извините, не хотелось скатываться на подобный тон, но вы обозвали меня параноиком: не буду спорить с вами про МСК т.к. для меня это просто аксиома, уж не помню почему. Если мне захочется уточнить этот вопрос - спрашивать я буду не на этом форуме, а у профессиональных геодезистов.

Что касается вопросов лицензирования. Мне известен случай когда человек просто рисовал карту для Навитела, возможно указал то что неположено. В один прекрасный день к нему пришли из нацбезопасности и посоветовали заняться чем-нибудь другим. Если у вас железные яйца и вы уверены в своей правоте - можете гулять по запретным объектам с GPS-приемниками.
Когда увижу вашу общественную, открытую для всех станцию с миллиметровыми координатами - поверю. А сотрясать воздух на форуме я тоже умею.

chnav, вас лично параноиком не обзывали.
Если переходить на личности, то вы просто путаете (смешиваете) интересы безопасности и коммерческие интересы, возможно - из-за отраслевых стереотипов. По сути же, оскорблением это не является.

При этом никто тут не отрицает, что вояки и чиновники при любом удобном случае стараются сохранить советский status quo, дабы придать себе важности, сохранить грозный вид, и прикрыть свои коммерческие интересы от свободной конкуренции, обложив все лицензиями, разрешениями и дутыми секретами. (Правда, пока к ним не нагрянет “шпион переодетый в грибника из соседней деревни”, они даже забор вокруг супер-стратегических складов ГСМ не удосуживаются починить последние лет 20.)

И, как следствие, никто не отрицает, что если создать им тот самый “удобный случай”, они постараются отыграться так, как смогут. И любой судья, услышав со стороны обвинения мутные рассуждения об угрозе нац. безопасности, других аргументов слышать уже не будет - это очевидно.

Речь идет не о том, что определение координат с высокой точностью “законно и ни чем не чревато для тех, кто это делает”, речь о том, что оно само по себе никакой угрозы нац. безопасности не несет - несет только авторитету чиновников. Потому не надо риторики в духе детского сада “а вам слабо”. Подставляться под чей-то произвол - глупо и ни к чему общественно-полезному точно не ведет. Но в то же время, пренебрегать сравнительно простой технической возможностью было бы трусливым поступком.

Именно по этой причине я и пишу тут о том, что у меня получается и не получается. Если всё получится - каждый, кому это интересно, сможет это воспроизвести. Чем доступнее технология, тем меньше необоснованного страха она вызывает.
Помните, как еще лет 13 назад бытовой GPS воспринимался как “шпионское устройство”? А как CB-радиостанции и мобильные телефоны должны были быть зарегистрированы и разрешение нужно было носить? А как сканирующие широкополосные приемники считались всеми поголовно СТС (и я даже знаю одного человека, у которого есть разрешение ФСБ на его покупку и использование, при том что знаю еще несколько сотен человек, которые об этих разрешениях даже не слышали, но приемники имеют и используют)? И как волосы дыбом у имеющих отношение к авиации становились и как они говорили “да как же это можно” при виде сайта flightradar24, а особенно - при виде ресивера размером с USB-накопитель, который служит для приема этих самых сообщений с координатами от самолетов.

-1

-1

Миллиметровая - геодезистам, субметровая-метровая - для речной навигации. Была бы точность - применение найдётся.

Используя записанный вчера лог UBX-протокола, как данные ровера и SP3-файл с сервера, как данные коррекции, в RTKNAVI сделал следующее:

  1. Посмотрел в процессе обработки статусное окно (RTK Monitor, которое вызывается по нажатию на квадрат над кнопкой Start):
    строка Precise Ephemeris time/# of Epoch говорит “— (0)”, аналогично - прочерки стоят в строках Precise Ephemeris download time, Precise Ephemeris file

  2. В Options - Output - Debug trace поставил level=5 и получил очень объемный трейс-лог, в котором в начале значится процесс открывания файлов, включая SP3.

А вот дальше - судить сложно, т.к. вообще в логе очень много чего есть.
Некую часть там занимают вещи вроде:

3 decode_ubx: type=0210 len=256
4 decode_rxmraw: len=256
4     0.125: updatesvr: ret=1 sat= 0 index=0
3 sortobs: nobs=10
5 input_raw: format=4 data=0xb5
5 input_ubx: data=b5

Далее встречаются вот такие:

3 pntpos  : tobs=2013/04/02 10:51:13.095 n=10
3 satposs : teph=2013/04/02 10:51:13.095 n=10 ephopt=0
4 ephclk  : time=2013/04/02 10:51:13.020 sat= 2
4 seleph  : time=2013/04/02 10:51:13.095 sat= 2 iode=-1
4 eph2clk : time=2013/04/02 10:51:13.020 sat= 2
4 satpos  : time=2013/04/02 10:51:13.019 sat= 2 ephopt=0
4 ephpos  : time=2013/04/02 10:51:13.019 sat= 2 iode=-1
4 seleph  : time=2013/04/02 10:51:13.095 sat= 2 iode=-1
4 eph2pos : time=2013/04/02 10:51:13.019 sat= 2
4 kepler: sat= 2 e= 0.01223 n= 3 del= 2.887e-15
4 eph2pos : time=2013/04/02 10:51:13.020 sat= 2
4 kepler: sat= 2 e= 0.01223 n= 3 del= 2.887e-15
4 ephclk  : time=2013/04/02 10:51:13.015 sat= 4
4 seleph  : time=2013/04/02 10:51:13.095 sat= 4 iode=-1
4 eph2clk : time=2013/04/02 10:51:13.015 sat= 4
4 satpos  : time=2013/04/02 10:51:13.015 sat= 4 ephopt=0
4 ephpos  : time=2013/04/02 10:51:13.015 sat= 4 iode=-1
4 seleph  : time=2013/04/02 10:51:13.095 sat= 4 iode=-1

И такие:


4 ionocorr: time=2013/04/02 10:51:13.095 opt=1 sat= 2 pos=55.488 37.864 azel=276.442 16.491
4 tropcorr: time=2013/04/02 10:51:13.095 opt=1 pos=55.488 37.864 azel=276.442 16.491
4 sat= 2 azel=276.4 16.5 res=-845796.643 sig=4.629
4 ionocorr: time=2013/04/02 10:51:13.095 opt=1 sat= 5 pos=55.488 37.864 azel=314.211 17.766
4 tropcorr: time=2013/04/02 10:51:13.095 opt=1 pos=55.488 37.864 azel=314.211 17.766
4 sat= 5 azel=314.2 17.8 res=-840312.392 sig=4.544

Интерпретировать это мне сложно.

Ровно ту же самую фигуру позиции я получил, скормив исходный UBX-файл (предварительно сконвертированный через rtconv в OBS и NAV) и вчерашний SP3-файл на вход RTKPOST.

Блин, кажется я сообразил, в чем может быть проблема (сколько же в rtknavi настроек…).
В Options - Settings1 есть настройка Satellite/Ephemeris clock где по умолчанию значится Broadcast. Эту настройку, предполагаю, и нужно менять на Precise, но если так сделать, rtknavi ругается на sat ant file read error, и правильно делает - нет у меня этого самого PCV/ATX файла.

Есть: Options->Files стр. 38 в manual, в папке data.

Да, обнаружил, прописал в Options - Files и ATX (пробовал оба) и PCV. Выбирал и антенну None и какие-то случайные - при запуске rtknavi секунды две думает и пишет в статусной строке “(1) end”, так никакого solution и не изобразив.

Так, а вот RTKPOST отреагировал на все те же самые настройки (igs08.atx, ngs_abs.pcv, тип антенны - none, Position mode - PPP Static, Satellite Ephemeris/clock - Precise). Нарисовал очень похожую траекторию, но все же несколько отличающуюся, при том смещенную на полтора метра в сторону.

BushmanK PPP Static надо проверять на пункте с известными координатами в WGS84.

В конечном счете - да, и я это и так понимаю, т.к. сравнение между собой двух измерений неизвестного качества не дает ответа об абсолютной величине ошибки и т.п.
Однако сравнение между собой результатов обработки одного и того же лога разными средствами, тем не менее, кое-какие ответы может давать. Пока у меня нет возможности поставить эксперимент на эталонной точке, но это не значит, что любой эксперимент лишен смысла. Например, воспроизводимость результата по измерениям в разные дни вполне себе показатель того, что всё работает более или менее как должно.

А так - я бы был благодарен присутствующим за помощь в интерпретации этих самых результатов, чтобы понять, каков вклад различных настроек и режимов в итоговый результат. Например, мне неизвестно, каков вообще должен быть характер и порядок вклада обработки в режиме Ephemeris - Precise относительно обработки с Ephemeris - Broadcast. А то если, скажем, его положительное влияние должно сказываться только при измерениях с сантиметровой точностью с использованием БС, то значит, я несколько забежал вперед и этот режим нужно отложить на будущее.

Если есть возможность использовать базовую станцию с известными координатами в WGS84, то нужно начинать с DGPS режима.

В закладках обнаружил http://www.navgeocom.ru/base_stations.php , думаю стукнуться туда, станция GISH - поблизости.

Добыл я данные с местной базовой станции.
Rinex 2.1, 13n и 13o. Скормил их RTKPOST вместе со сконвертированным в Rinex через RTKCONV записанным логом. За одно - добавил sp3-файл эфемерид. Позицию базовой станции взял в XYZ-формате из o-файла (автоматом она не подцепилась). Прогнал в разных режимах: dgps, static, ppp-static не меняя остальные настройки.
Результат:

зеленое - DGPS, синее - static, фиолетовое - ppp-static.
Улучшения картинки области дрейфа позиции относительно ppp-static без данных БС не наблюдается, хотя длина самого трека получилась в разы меньше, т.е. дрейф стал медленнее.
UPD: В Options->Output->Solution for static mode стояло All а не Single.

на самом деле, на практике, точные эфемериды важны в двух случаях

  1. PPP;
  2. Слишком длинные базы;
    Во всех остальных случаях точные эфемериды практически ни на что не влияют, особенно в одночастотном режиме, т.к. все ошибки устраняются разностным методом.

В ринексах указана координата с точностью обычного GPS (то что посчитал сам базовый приёмник), иногда округленная. Точные координаты базы надо спрашивать у поставщика услуг, либо самому считать относительно пунктов IGS.

(added)
А ещё не очень понятно почему в режимах static получается трек, ведь режим static - это съёмка точки.
Видимо из-за этого:

видимо первое решение базируется на данных первой эпохи,
второе решение - эпохи 1,2

N-е решение - эпохи 1-N, оно же финальное для режима static.

Но по документации это непонятно…