pp2web

Что это?

pp2web (post-processing to web) — серверное веб-приложение для постобработки данных сырых сессий, например записанных мобильным приложением rawX, в режимах:

  • Single
  • Статический
  • Кинематический
  • Stop&Go (новое)

Как им пользоваться?

После регистрации по адресу solutop@gmail.com можно запросить пробную (на срок) или бессрочную активацию. Получив учётные данные, войдите по этой ссылке.

pp2web позволяет:

  • выбрать режим постобработки (Single, статический, кинематический, Stop&Go)
  • загрузить сырой файл ровера в формате .ubx (Single, статический, кинематический)
  • загрузить файл RINEX базовой станции в формате .YYo или .obs (только статический, кинематический и Stop&Go)
  • загрузить файл с интервалами Stop и Go ровера в формате .csv (только Stop&Go)
  • ввести LLE, если известны точные географические координаты стояния базы (только статический, кинематический и Stop&Go)
  • обработать загруженные файлы
  • показать точки на карте OSM
  • скачать zip-архив с файлом .csv и отчётом в формате PDF, свёрстанным в LaTeX
  • перезапустить приложение для повторного использования

Относительное позиционирование

Сделаем небольшой шаг назад и разберёмся, что такое относительное позиционирование.

Говоря о постобработке GNSS, имеют в виду методы относительного позиционирования, которые позволяют определить разность координат (базовую линию) между двумя или более точками, одновременно занятыми несколькими приёмниками, способными принимать и код, и фазу.

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

Примечание

Вычисления выполняются в постобработке (отложенно, то есть не в реальном времени) по сырым данным, записанным приёмниками. Статический режим позволяет достичь относительной точности порядка 0,5–1 см и применяется для построения сетей базовых линий при создании геодезической основы или при наблюдении за деформациями.

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

_images/pos_relativo1.png

Рис.1 Метод относительного позиционирования GNSS

На рисунке выше два приёмника в один и тот же момент наблюдают одни и те же спутники. Затем эти наблюдения обрабатываются для оценки базовой линии (трёхмерного вектора) между приёмниками.

Подсказка

Метод измерений ровером определяет технику позиционирования. GNSS часто используют как «чёрный ящик»: измерение записывают, не зная его ограничений, поэтому стоит потратить немного времени и разобраться, как работает эта техника позиционирования.

Точность зависит:

  • от типа приёмников (какие наблюдения они могут получать)
  • от расстояния между приёмниками (от < 10 км до > 500 км)
  • от методики съёмки (времени стояния на точках)
  • от способа обработки данных (реальное время, постобработка)
  • 1–2 м (относительное по кодам в реальном времени) — применяется в навигации
  • несколько сантиметров (две частоты, быстрая статика) — геодезия и съёмки для ГИС
  • миллиметры (две частоты, длительная статика с уравниванием) — наблюдение за деформациями земной коры

Памятка

  • постобработка применяется к съёмкам, выполненным методом относительного позиционирования
  • для каждой точки съёмки необходимы фазовые измерения (их называют также наблюдениями), а кодовые измерения желательны.
  • необходимы сведения об орбитах навигационных спутников (файлы brdc с параметрами орбит и файлы sp3 с траекториями орбит)
  • измерения должны выполняться одновременно на одном или нескольких пунктах с известными координатами и на снимаемых точках
  • целочисленная фазовая неоднозначность разрешается программой обработки
  • время стояния имеет решающее значение для разрешения целочисленной неоднозначности
  • время стояния зависит от типа приёмника, длины базовой линии, геометрии спутников и наличия источников многолучёвости

Stop&Go

Режим Stop&Go — методика съёмки двумя геодезическими приёмниками GNSS (одним неподвижным и одним подвижным), использующая фазовые измерения несущей для получения очень точных координат.

Примечание

В отличие от статического режима, в котором ровер стоит на каждой точке по 10–30 минут, в Stop&Go ровер задерживается на точке лишь ненадолго (10–30 секунд) — после начального этапа разрешения неоднозначностей.

Этапы работы

a. Инициализация (разрешение неоднозначностей)
  • Начинают с известной или контрольной точки.
  • Ровер стоит на месте 2–5 минут, чтобы программа разрешила целочисленные неоднозначности (целое число циклов несущей между спутниками и приёмниками).
  • Когда решение получено (режим «fixed»), можно переходить к съёмке следующих точек.
b. Переход между точками (Go)
  • Оператор переходит к новой точке, не выключая и не прерывая работу приёмника, сохраняя непрерывность наблюдений.

Предупреждение

  • Крайне важно не терять сигнал и решение fixed. В тоннелях, под густыми кронами или при ином перекрытии обзора спутников решение может быть потеряно.
c. Съёмка точек (Stop)
  • На каждой интересующей точке ровер устанавливают и удерживают неподвижно около 10–30 секунд.
  • За это время собираются данные GNSS для вычисления координат с сантиметровой или субсантиметровой точностью.
  • Записывают идентификатор точки, время стояния и примечания.

Совет

  • Полезно вернуться на некоторые уже измеренные точки для контроля точности (замыкание хода, проверка повторяемости).
  • Если решение fixed потеряно, инициализацию нужно повторить на известной точке.
_images/stop&go2.png

Рис.2 Съёмка в кинематическом режиме Stop&Go

Преимущества

  • Высокая точность (от миллиметров до сантиметров).
  • Больше гибкости, чем у чисто статического режима.
  • Быстрее классической статической съёмки.

Недостатки

  • Требуется непрерывная видимость спутников и сигнала от базы.
  • Требуется начальный этап разрешения неоднозначностей и внимание, чтобы не потерять фазовый захват.

Оборудование

  • База GNSS (неподвижная): устанавливается на известной точке, записывает данные RINEX или передаёт поправки RTK.
  • Ровер GNSS (подвижный): принимает спутниковые данные и поправки от базы.
  • Веха с уровнем: для вертикальной установки над точкой.
  • Двунога: для удержания вехи в вертикальном положении
  • Контроллер с полевой программой: для записи точек и метаданных.

Применение

  • Кадастровые и высокоточные съёмки.
  • Мониторинг сооружений и окружающей среды.
  • Сети геодезической основы.
  • Районы без радиопокрытия (горы, острова, удалённые территории).

Порядок работы

На рисунке ниже показан главный экран, который открывается при переходе в веб-приложение по приведённой выше ссылке

_images/p1.png

Рис.1 Экран при запуске веб-приложения

Затем выбирается режим обработки сырых данных: single, статический, кинематический или stop&go, как на экране ниже

_images/p2.png

Рис.2 Выбор режима обработки

Подтвердите режим и укажите:

  • файл ровера в формате .ubx
  • файл базовой станции в формате .YYo или .obs
  • файл с интервалами stop и go (только режим stop&go)
  • высоту прибора в метрах, если она нужна (только режимы single, статический и кинематический)
  • координаты базы, если они у вас есть, как на рис. 3

Обратите внимание: процесс последовательный, поэтому нарушить порядок действий невозможно, как показано на рис. 3

Примечание

Отметим, что режим single обрабатывает только файл ровера в формате .ubx: файл базы для него не нужен, поскольку выполняется одиночное решение (точность порядка метра). Он может пригодиться, например, чтобы узнать приблизительные координаты записанной точки в географической системе WGS84 (L, L, E)

_images/p3.png

Рис.3 Загрузка файлов и выбор географических координат

Примечание

Если при статической или кинематической постобработке у вас есть виртуальные файлы RINEX, вводить LLE вручную не нужно: в заголовке файла RINEX базы координаты уже точные, а не приближённые.

Ниже пример файла RINEX, скачанного, например, с постоянной базовой станции; обратите внимание на строку заголовка «APPROX POSITION XYZ», выделенную ниже:

     2.11           OBSERVATION DATA    M (MIXED)           RINEX VERSION / TYPE
teqc  2016Apr1      OGS/CRS             20160608 12:19:48UTCPGM / RUN BY / DATE
Linux 2.4.21-27.ELsmp|Opteron|gcc|Linux x86_64|=+           COMMENT
BIT 2 OF LLI FLAGS DATA COLLECTED UNDER A/S CONDITION       COMMENT
UDI1                                                        MARKER NAME
12719M002                                                   MARKER NUMBER
David Zuliani       OGS/CRS                                 OBSERVER / AGENCY
618-01139           TPS NET-G3A         4.1 May,31,2013     REC # / TYPE / VERS
24204               ASH701945E_M    SCIT                    ANT # / TYPE
  4317305.9964  1016832.9984  4568261.5793                  APPROX POSITION XYZ
        0.0083        0.0000        0.0000                  ANTENNA: DELTA H/E/N
     1     1                                                WAVELENGTH FACT L1/2
     5    L1    L2    C1    P2    P1                        # / TYPES OF OBSERV
     1.0000                                                 INTERVAL
Forced Modulo Decimation to 1 seconds                       COMMENT
 SNR is mapped to RINEX snr flag value [0-9]                COMMENT
  L1 & L2: min(max(int(snr_dBHz/6), 0), 9)                  COMMENT
pseudorange smoothing corrections not applied               COMMENT
  2016     6     8    11     0    0.0000000     GPS         TIME OF FIRST OBS
    17                                                      LEAP SECONDS
                                                            END OF HEADER

Обратите внимание: приведённые координаты геоцентрические.

После загрузки файлов и, при необходимости, географических координат базы обработка запускается нажатием кнопки «Обработать»: расчёт выполняется со стандартными параметрами, редактировать их в этой версии пока нельзя. Сообщения об ошибках выводятся на экран, а кнопка обработки становится красной, блокируя следующие этапы, как на рисунке 4

_images/p4.png

Рис.4 Обработка загруженных файлов

После завершения обработки следующий шаг — отображение точек на карте OSM, что позволяет быстро визуально проверить обработанные данные. Этот этап выполняется автоматически вслед за предыдущим

_images/p5.png

Рис.5 Результат обработки на карте

По окончании и этого этапа результаты можно скачать в виде zip-архива, содержащего:

  • файл в формате .csv только с координатами решения fix для всех эпох в режимах single и статическом, а также единственную координату для статического режима, полученную как средневзвешенное всех координат с решением fix
  • файл в формате .pdf с подробным отчётом, описанным в следующем разделе

Итоговый отчёт

Итоговый отчёт в целом описывает результаты обработки и содержит:

  • Наблюдения и метаданные (Observation Metadata)

    • Общую продолжительность наблюдений
    • Период, выраженный во времени UTC
    • Режим
    • Используемые частоты
    • Параметры: минимальный угол возвышения, ионосферные поправки, тропосферные поправки, эфемериды
    • Долю решений
    • Использованные спутники
    • Высоту прибора (только режимы single, статический и кинематический)

  • Кинематическую траекторию (GRD Track)

  • Временной ряд координат (Position Time Series)

  • Сводку данных (Data Summary)

Кинематическая траектория

Ниже на рисунке 6 пример графика, показывающего путь приёмника GNSS во время наблюдений. Он наглядно показывает перемещение устройства на карте (если она есть) или последовательность записанных координат в UTM с автоматическим выбором зоны.

_images/grd.png

Рис.6 График планового решения в E, N

Приводимые данные:

  • Географические координаты: широта, долгота и высота приёмника
  • Изменения положения во времени
  • Качество решения (Fix/Float и т. д.)
  • Возможное графическое сопоставление с картой местности

Назначение:

  • Анализ траектории и проверка маршрута с учётом окружающей обстановки

Временной ряд

Ниже на рисунке 7 пример графика, представляющего подробный временной ряд координат, записанных приёмником GNSS во время наблюдений.

_images/position.png

Рис.7 График решения в E, N, H

Приводимые данные:

  • Метка времени: каждому положению соответствует определённое время в UTC
  • Координаты: широта, долгота и высота (в метрах)
  • Точность: средние квадратические отклонения в плане (SDH) и по высоте (SDV)
  • Качество решения: каждое положение помечено как Fix (высокая точность) или Float (более низкая точность)

Назначение:

  • Подробный анализ качества измерений во времени и устойчивости системы.

Сводка данных

Ниже на рисунке 8 приведена часть примера общей сводки наблюдений и обработки. В ней представлены все эпохи, секунда за секундой, независимо от качества точки.

_images/summary.jpg

Рис.8 Сводка обработанных эпох

Приводимые данные:

  • Общая статистика: полная продолжительность сессии с координатами по каждой эпохе в LLE (град.)
  • Общая точность: средние значения и стандартные отклонения измерений в плане и по высоте, а также решение по каждой эпохе

Назначение:

  • Краткая оценка работы системы и использованных настроек

Примечание

Текущая версия не позволяет выполнять «настройку параметров» — выбирать группировки, задавать параметры ионосферы и тропосферы, угол отсечки и т. д., — а ради простоты использует стандартный файл конфигурации и преобразует сырые файлы ровера с шагом в одну секунду

В режиме stop&go в Data Summary добавляется столбец с высотой прибора, как на рис. 9 ниже:

_images/p6.png

Рис.9 Сводка с точками, зафиксированными в режиме stop&go

Работа с метками времени

Шкала Описание Пример
UTC Всемирное гражданское время, включает високосные секунды 14:40:32
GPST Непрерывное время системы GPS, отсчитывается с 6.01.1980, без високосных секунд 14:40:50

Текущая разница: GPST = UTC + 18 с (значение действует с 1.01.2017).

В сообщениях UBX приёмник MS2 всегда передаёт поле leapS с текущими 18 секундами, поэтому программа-получатель может выполнить преобразование сама.

┌─────────────────────────┐
│   Ricevitore  MS2       │
│  rcvTow + week + leapS  │
└────────────┬────────────┘
             │  stream binario UBX
             ▼
┌─────────────────────────┐                ┌──────────────────────┐
│   App Android  rawX     │   eventi       │   CSV Stop&Go        │
│                         ├───────────────►│   Timestamp UTC      │
│                         │                │   (orologio telefono)│
└────────────┬────────────┘                └──────────┬───────────┘
             │ raw bytes                              │
             ▼                                        │
┌─────────────────────────┐                           │
│   File  .ubx  (GPST)    │                           │
└────────────┬────────────┘                           │
             │                                        │
╔════════════▼════════════════════════╗               │
║  pp2web — post-processing           ║               │
║  (motore RTKLIB)                    ║               │
║                                     ║               │
║   UBX → RINEX (GPST)                ║               │
║   ↓                                 ║               │
║   PPK con out-timesys = utc         ║               │
║   ↓                                 ║               │
║   File .pos  (UTC) ◄── conversione  ║               │
║                       GPST→UTC      ║               │
║   ↓                                 ║               │
║   modulo Stop&Go                    ║◄──────────────┘
║   confronta CSV (UTC) con .pos (UTC)║
║   sulle finestre Stop→Go            ║
╚════════════════════╤════════════════╝
                     │
                     ▼
┌──────────────────────────────────────────┐
│  *_events_filtrato.csv                    │
│  *_events_media.csv  ← coordinate finali  │
└──────────────────────────────────────────┘

Данные взяты из реальной полевой сессии 19.06.2025.

# Modalità: Stop&Go
Point,Timestamp,Action,Height
1A,2025/06/19 14:40:32.925,Stop,2.07
1A,2025/06/19 14:41:32.945,Go,2.07
2A,2025/06/19 14:43:12.162,Stop,2.07
2A,2025/06/19 14:43:14.008,Go,2.07

Время записано в UTC по часам телефона.

Поле Значение
rcvTow 398 450,981 с (от начала недели GPS)
week 2371
leapS 18
Восстановленное GPST 2025-06-19T14:40:50.981
UTC после вычитания leapS 2025-06-19T14:40:32.981
UTC GPST
Метка времени из CSV 14:40:32.925 —
Метка времени, восстановленная из UBX 14:40:32.981 14:40:50.981
Разница в UTC +56 мс  
Разница в GPST   −18 056 мс

−18 секунд — это в точности високосные секунды, а −56 мс — небольшой уход часов Android относительно времени GPS.

pp2web выполняет три внутренних этапа, используя RTKLIB в качестве расчётного ядра:

Файл .ubx преобразуется в наблюдения RINEX. На этом этапе время всё ещё в шкале GPS: файл наблюдений не переведён в UTC.

Здесь происходит главное преобразование. Внутренняя конфигурация pp2web передаёт RTKLIB параметр out-timesys = utc: ядро читает високосную секунду, полученную от приёмника, и создаёт файл .pos, эпохи которого уже в UTC. С этого момента время однородно: та же шкала, что и в CSV с событиями.

pp2web берёт окна Stop → Go из CSV и для каждого из них выбирает в файле .pos все эпохи, метки времени которых попадают в интервал. По этим эпохам вычисляется средневзвешенное координат (широта, долгота, высота) с весами, обратными квадратам стандартных отклонений, после чего вычитается высота прибора для точки. Оба потока (CSV и эпохи .pos) уже в UTC, поэтому поправка на високосные секунды не применяется.

«Хитрость» в том, что каждый элемент цепочки выполняет свою задачу только один раз:

  1. rawX ничего не знает о GPS и пишет гражданское время UTC.
  2. Приёмник MS2 пишет время GPS и прикладывает високосную секунду.
  3. pp2web (через RTKLIB) — единственный элемент, который переводит одну шкалу в другую, и делает это один раз, при формировании файла .pos.
  4. Этап объединения с событиями Stop&Go работает только в UTC, с двумя уже согласованными потоками.

Иначе говоря, ответственность за преобразование GPST↔UTC сосредоточена в pp2web и определяется одной строкой внутренней конфигурации (out-timesys = utc).

Признак Вероятная причина Где искать
Точки из .pos не попадают в окна CSV (расхождение около 18 с) в конфигурации pp2web задана неверная шкала времени файл конфигурации обработки PPK
Стоянки отбрасываются с сообщением «не менее 2–3 секунд» слишком короткий обратный отсчёт в rawX настройка обратного отсчёта в приложении
Разница CSV и UBX больше 1 секунды в UTC часы Android рассинхронизированы настройки телефона → автоматические дата и время
Все решения Q5 (одиночная точка) файл RINEX базы не покрывает сессию временной охват базовой станции
  • 18 високосных секунд не нужно применять вручную: их учитывает pp2web через свою внутреннюю конфигурацию (out-timesys = utc, передаваемую RTKLIB).
  • Файл .csv из rawX изначально в UTC (часы Android, NTP).
  • Файл .pos, создаваемый pp2web, оказывается в UTC после внутреннего преобразования.
  • Итоговое объединение событий Stop&Go сравнивает UTC с UTC: рассогласование исключено.
  • Остаётся лишь уход часов телефона, обычно в несколько десятков миллисекунд, — для Stop&Go со стоянием от 2 с это несущественно.

Видеоуроки

В этом разделе работа с веб-приложением показана в видеоуроках, подробно раскрывающих отдельные функции и итоговые результаты.