Мы с вами живем в трехмерном мире и не можем игнорировать третью компоненту координат в пространстве. Но в мониторинге транспорта исторически так сложилось, что высота зачастую игнорируется. Возможно, это наследие от мореплавателей, откуда и зародилась навигация, которым высота над уровнем моря казалась неизменной константой ;) У нас в системе до сих пор есть трекеры-"долгожители", которые шлют свою скорость в морских узлах.

Например, в экспертной статье от разработчиков СМТ Wialon про неверный пробег вообще не упоминается высота. При этом в разделе документации про основные счетчики указано, что высота все-таки учитывается, если ее разброс менее 500 (!) метров между телематическими сообщениями. На практике же зачастую учет высоты отключают из-за недостаточной точности его значения в данных от GPS-трекеров. В этой статье мы попробуем оценить разницу в пробеге с учетом высоты и без нее.

Высотомер или альтиметр - прибор, предназначенный для измерения высоты. По принципу устройства альтиметры делятся на:

• Навигационные. Измеряют высоту на основе сигналов от спутниковых навигационных систем. Для определения высоты требуется сигнал минимум от четырёх спутников (в отличие от широты и долготы, для которых достаточно трёх). Высота рассчитывается относительно эллипсоида WGS 84 (математической модели Земли) на основе полученных координат и известных орбит спутников. Типичная погрешность высоты — ±10–20 метров в реальных условиях.

• Барометрические. Основаны на измерении атмосферного давления, которое уменьшается с увеличением высоты. Барометрический датчик обеспечивает высокую точность для небольших изменений высоты (±1–5 м).

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

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

• Инерциальные. Используют акселерометры и гироскопы для расчёта изменений высоты на основе ускорений и положения объекта. Точность уменьшается при длительном использовании из-за накопления ошибок: ±1–10 м (с дрейфом инерциальных датчиков).

На практике чаще всего встречаются комбинированные альтиметры, которые используют несколько принципов для улучшения итогового результата. Примером могут стать смарт-часы, в которых используются спутниковая навигация с датчиком давления и инерциальным модулем (Inertial Measurement Unit, IMU), а также внутренние алгоритмы для программных поправок и фильтрации ошибок.

В автомобильных GPS-трекерах барометр практически не встречается, при этом в большинстве современных устройств присутствует акселлерометр, который используется для фильтрации "размотки" GPS-координат во время стоянок транспорта и для страховой телематики (контроль резких торможений, ускорений и поворотов). Поэтому для нашего датасета высота чаще всего является результатом комбинации ГНСС+IMU.

Как-то повлиять на точность высоты не представляется возможным, могу только рекомендовать выполнение "жесткого" монтажа навигационного блока к кузову автомобиля, чтобы он не болтался на стяжках притянутый к проводке ?, что сильно снижает полезность встроенного акселлерометра.

В качестве тестового маршрута возьмем дорогу от Джубги до Геленджика (от 44.317889; 38.698616 до 44.616193; 38.023142), т.к. между ними находится Михайловский перевал. Если верить Яндекс.Картам, то будет несколько перепадов высот в диапазоне между 35 и 280 метрами над уровнем моря. Выглядит внушительно, но насколько это повлияет на пробег?

Чтобы с телеметрией было удобнее работать, локально запустим Docker контейнеры с PostgreSQL и PgAdmin:

Создадим таблицу с аналогичными CSV-файлу столбцами:

И выгрузим в эту таблицу весь сжатый CSV-файл:

Теперь мы можем работать с данными более эффективно через РСУБД:

Мы работаем с геоданными и у нас PostgreSQL. Чего нам не хватает? Верно, PostGIS! В использованном Docker образе он уже предустановлен. И чтобы нам каждый раз не переводить широту и долготу в удобный для PostGIS формат, создадим еще один столбец нужного типа и пересчитаем его для всей телеметрии заранее:

Теперь мы можем выполнять любые встроенные функции PostGIS с алгоритмами ГИС. Например, мы прямо в PgAdmin можем нарисовать трек движения любого объекта за указанный интервал времени:

Отлично, песочница готова! Зачем мы все это делали в рамках изучения влияния учета высоты над уровнем моря в расчете пробега? Да чтобы не искать вручную из 600 объектов те, которые двигались хотя бы раз по нашему маршруту за весь 2024 год. Теперь мы можем очертить геозону вокруг нашего маршрута и найти все ТС, которые проезжали наш перевал.

Воспользуемся онлайн-сервисом geojson.io. Нарисуем в нем несложный полигон, который охватывает область нашего маршрута. Сервис позволяет экспортировать геоданные в формате WKT (Well-known text), который прекрасно “кушается” PostGIS:

Копируем текстовое представление геоданных WKT и, используя функцию PostGIS, получаем эту геозону в PgAdmin:

Теперь мы можем перебрать все треки объектов и найти те, которые пересекали нашу геозону на карте:

В итоге получаем список из 79 объектов, которые хотя бы раз въезжали в геозону нашего маршрута. Возьмем первый из списка и посмотрит на трек его движения за весь 2024 год:

Визуально оценим качество его трека в горной местности на местных серпантинах:

Качество нас устраивает, поэтому попробуем на этом объекте выделить часть пути в нашей тестовой области и сравнить с пробегом по Яндекс.Картам, 2ГИС и Google Maps. Возьмем даже участок большей длины, от Горячего ключа до Кабардинки (от 44.64181; 39.116113 до 44.639624; 37.984756). 

Какую же длину маршрута показывает популярные картографические провайдеры:

• Яндекс.Карты: 134 км в интерфейсе, 133 941 метра в ответе запроса.

• 2ГИС: 134 км в интерфейсе, 133 668 метра в ответе запроса.

• Google Maps: 134 км в интерфейсе, 133 868 метра в ответе запроса.

В итоге пользователь в любом из предложенных сервисов увидит 134 километра, но если посмотреть на метры, то получаем неплохой разброс: 133 941, 133 668 и 133 868 метров соответственно. Также стоит знать, что Google Maps и 2ГИС  используют для картографической подложки проекцию на сфероиде (EPSG:3857), а Яндекс.Карты - на эллипсоиде (EPSG:3395). При этом у нас нет никакой информации, какие алгоритмы для расчета длины маршрута используют эту сервисы. Я даже не смог найти однозначного ответа на вопрос: учитывают ли они высоту в расчетах… Но, скорее всего, нет.

Программный расчет пробега в PostGIS

Расширение для PostgreSQL для работы с геоданными PostGIS де факто является стандартом для ГИС баз данных.

Давайте посмотрим документацию основной функции для расчета расстояний ST_Distance. Перевод части документации: “Для типа geography по умолчанию возвращается минимальное геодезическое расстояние между двумя объектами в метрах, вычисляемое на сфероиде, определенном SRID. Если use_spheroid имеет значение false, используется более быстрый расчет на сфере.” Высота в официальной документации главного метода расчета расстояний даже не упоминается, к тому же сам тип geography не поддерживает высоту как параметр, исключительно широту и долготу.

Но в PostGIS есть функция ST_3DDistance, которая как раз использует 3-ю компоненту координаты, т.е. высоту над уровнем моря, но эта функция не работает с типом geography, а только с geometry, т.е. функция ST_3DDistance возвращает минимальное трехмерное декартово расстояние между двумя геометриями в проекционных единицах (SRID).

Давайте попробуем найти длинный подъем или спуск на Михайловском перевале из нашего тестового маршрута и оценить разницу в расстоянии с учетом высоты и без. Идеально подошел подъем по прямой длиной ровно 2 км (от 44.414019; 38.503813 до 44.428520; 38.488916). Высота меняется от 26 до 39 метров с несколькими перепадами (на скриншоте ниже под картой график высоты):

Интересный результат. При расчете с помощью специального типа geography стандартной функцией ST_Distance по сфероиду получаем 1999.91 метров, в более быстром и менее точном варианте этой функции по сфере получаем 2000.97 метров. При этом расчет с учетом высоты через функцию ST_3DDistance с переводом в локальную систему координат EPSG:32637 (WGS 84 / UTM zone 37N) дает 2000.25 метров. Это означает, что разница между значениями менее 0.01%, т.е. на 100 км пути мы получаем расхождение в 10 метров.

Стоит также учитывать, что для расчета в PostGIS с учетом высоты мы должны знать эту высоту в каждой точке трека. Показания высот от GPS-трекеров имеют погрешность даже в идеальных условиях. А если использовать готовую карту высот и получать ее по широте и долготе? Это дополнительная вычислительная сложность, которая скажется на общей производительности системы. Сюда еще следует добавить, что для корректного расчета расстояния функцией ST_3DDistance нужно использовать локальную систему координат для каждой точки, иначе погрешность будет внушительной, и это также увеличивает вычислительную сложность. А теперь вспомним, что у нас сотни тысяч точек трека в год только от одного объекта мониторинга.

Я думаю, сказанное выше объясняет, почему в транспортной телематике практически не встречаются ГИС-системы, которые обязательно учитывают высоту в пробегах. Чтобы "добить" эту тему, посмотрим на очень грубый аргумент из геометрии:

Если представить, что плоскоземельщики правы, то на 100 км пути при равномерном  подъеме на 1000 метров, мы получаем лишь 5 метров погрешности. 

Осталось только посмотреть на высоты в нашем датасете. Для начала узнаем какие объекты имеют показания высот и сколько их относительно общего числа телеметрии, т.к. не все трекеры присылают эти значения в своих коммуникационных протоколах:

566 объектов из датасета хотя бы раз присылали показания высоты. Давайте посмотрим распределение количества показаний высот к общему числу телеметрии каждого объекта:

Гистограмма очень похожа на, что мы получили для CAN показаний одометра. Используем такой же порог в 95%. Возьмем объект с большим числом телеметрии, у которого в каждой точке были показания высоты и посмотрим на график высот:

Чтобы понять масштаб разброса высот, посмотрим на стандартные величины из функции describe у DataFrame. Стандартное отклонение значения высоты равно 25-ти метрам. При этом у нас есть несколько выбросов, которые наверняка связаны с РЭБ:

Построим трек на карте с градиентом по высоте:

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

Теперь загрузим высоты для каждой точки трека по широте и долготе из какого-нибудь онлайн ГИС-сервиса, например, Open-Elevation API. Стоит учитывать, что ГИС системы также имеют ограниченную точность. Например, данные SRTM Data (Shuttle Radar Topography Mission), которые используются в Open-Elevation API, предоставляют высоты с точностью примерно ±10 метров на ровной местности и ±15–20 метров в сложных ландшафтах. 

Попробуем теперь проанализировать высоту над уровнем моря, полученных из разных источников: по ГНСС и из ГИС. Получаем следующие результаты:

В среднем один из источников занижает высоту на 9.16 метров относительно другого. В некоторых точках данные из двух источников отличаются более чем на 15 метров. При этом данные имеют слабую линейную зависимость между источниками, т.к. расчет этих значений имеет разную природу. Получается, что использование высоты по GPS или из доступных ГИС данных может гарантировать точность значений в диапазоне ±20 метров. Такая погрешность не позволяет использовать высоту в расчетах пробега, учитывая все ранее сказанное, и к тому же шумы в GPS-высоте будут “накручивать” ошибочный пробег при движении транспорта по ровным участкам.

На графиках также наблюдаются 4 интересных участка, где показаний высот из ГИС становится постоянными, а показания ГНСС проваливаются вниз и поднимаются обратно. Давайте возьмем первый из этого участка и рассмотрим его подробнее:

То есть данные ГИС утверждают, что высота там не изменяется, а ГНСС фиксирует перепад высоты с 80 до 160 метров на небольшом отрезке пути. Давайте взглянем на ландшафт в Google Earth, где я специально расставил маркеры с указанием высоты в каждой точке из базы Google:

А также посмотрим на топографическую карту высот в этой местности. Существенных перепадов высот в черте города не наблюдается:

Можно сделать вывод, что показания высот из ГИС базы более достоверны, чем по спутниковой навигации. Это связано с тем, что ГИС база имеет ограниченную точность, но ее погрешность укладываются в известный интервал, а вот точность высоты над уровнем моря по ГЛОНАСС может значительно отклоняться от действительной высоты. При этом VDOP (Vertical DOP), т.е. снижение точности в вертикальной плоскости по аналогии с HDOP для широты и долготы, отсутствует в коммуникационных протоколах практически всех известных мне автомобильных трекеров.

Возьмем бОльшую выборку телеметрии для анализа разницы высот по ГИС и GPS, чтобы убедиться в своих гипотезах. Возьмем 1 миллион случайных координат из нашего датасета и посмотрим, что получится:

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

Из всего вышесказанного можно сделать следующие выводы:

• точности высот по ГИС и ГНСС далеки от идеальных (в лучшем случае ±5 метров);

• высота по ГИС стабильнее за счет хранения в виде фиксированного датасета и отсутствия проблем, имеющихся у рассчитываемых в реальном времени спутниковых данных;

• высоту по ГНСС использовать можно в случаях, когда не требуется высокая точность и нежелателен рост вычислительной сложности, т.к. высота по спутникам уже доступна в телеметрии объектов мониторинга;

• если использовать высоту по ГИС и/или ГНСС в расчетах пробега, то вычислительная сложность возрастает и добавляется дополнительная погрешность самих данных о высоте в каждой точке.

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

А уже в следующей статье рассмотрим рассчитываемые на стороне ГНСС-устройства значения, а именно скорость и направление движения объекта мониторинга. Не переключайтесь ;)