Разработка трекинга передвижения транспорта в мобильном приложении

Мы решаем проблему точного трекинга транспорта в реальном времени

Наши инженеры сталкивались с ситуацией, когда GPS-трекер на автобусе показывал маршрут, прыгающий по параллельным улицам, а диспетчер не мог понять, где машина на самом деле. Водитель уже проехал остановку, а на карте — только подъезжает. Это не проблема железа, а ошибка фильтрации и map matching. Мы разрабатываем системы трекинга, которые используют данные аппаратных трекеров (Teltonika, Queclink, Galileosky) или GTFS Realtime, и накладывают их на карту с учётом скорости, маршрута и рельефа. Опыт работы с парками от 50 до 1000 машин позволяет нам гарантировать точность позиционирования с погрешностью не более 5 метров.

Какие источники данных мы используем?

Для логистических компаний и управления парком транспортное устройство — это аппаратный GPS-трекер (Teltonika FMB920, Queclink GV350, Galileosky), а не телефон водителя. Трекер отправляет пакеты по MQTT или HTTP-протоколу на сервер. Приложение выступает только как визуализатор данных, не как источник.

Если задача — показывать общественный транспорт по данным GTFS Realtime (стандарт Google), то источник — открытые API городских транспортных операторов. Формат — Protocol Buffers (transit_realtime.FeedMessage), парсинг через библиотеку gtfs-realtime-bindings.

Для приложений с телефоном водителя (такси, корпоративный транспорт) — тот же стек, что у курьерского трекинга, но с поправками на скорость движения.

Таблица сравнения типов трекеров

GPS-фильтрация на высоких скоростях: как убрать дрейф?

На скорости 80-120 км/ч горизонтальный GPS-дрейф меньше, чем в городе с многоэтажками, но другая проблема: при резких поворотах маркер может «обгонять» реальное положение машины из-за задержки обновления. Калман-фильтр сглаживает эту задержку.

Простая реализация фильтра Калмана для координат на Kotlin:

class KalmanFilter(private var accuracy: Float = 1f) { private var lat = 0.0 private var lon = 0.0 private var variance = -1f fun process(lat: Double, lon: Double, accuracy: Float, timestamp: Long): LatLng { if (variance < 0) { this.lat = lat; this.lon = lon; variance = accuracy * accuracy } else { val dt = (timestamp - lastTimestamp) / 1000f variance += dt * 3f * 3f // скорость изменения 3 m/s val k = variance / (variance + accuracy * accuracy) this.lat += k * (lat - this.lat) this.lon += k * (lon - this.lon) variance *= (1 - k) } lastTimestamp = timestamp return LatLng(this.lat, this.lon) } private var lastTimestamp = 0L } 

На iOS аналогичная реализация в Swift или использование CLLocationManager с CLActivityType.automotiveNavigation — Apple применяет собственный фильтр.

Map Matching: какой сервис выбрать?

Рейсовый автобус едет по фиксированному маршруту — GPS-точки между остановками должны лежать строго на этом маршруте, а не прыгать на параллельную улицу. Map matching: берём последовательность GPS-точек и «прижимаем» их к ближайшему участку дорожного графа.

OSRM self-hosted: GET /match/v1/driving/{coordinates}?radiuses={radiuses}&geometries=geojson. Возвращает matched-трек с waypoints. Согласно документации OSRM, latency при self-hosting составляет < 20 мс, что приемлемо для реального времени.

Google Roads API snapToRoads — проще в интеграции, но платно (5$ за 1000 вызовов) и ограничено 100 точками за запрос.

Сравнение OSRM vs Google Roads API

Вывод: для частого использования (1000+ машин) OSRM self-hosted в 250 раз дешевле и в 5 раз быстрее.

Как обеспечить плавную анимацию движения?

Маркер автобуса/грузовика — кастомный PNG или SVG с поворотом по направлению движения. Направление в градусах: atan2(dLon, dLat) * 180 / PI. На Android — BitmapDescriptorFactory.fromBitmap(rotatedBitmap) с поворотом через Matrix.postRotate(). На iOS — GMSMarker с iconView, поворот через CGAffineTransform(rotationAngle:).

Маршрут — полилиния. Google Directions API для расчёта или заранее сохранённый GTFS shapes.txt. На карте — GMSPolyline / Polyline с кастомным цветом и толщиной. Пройденный участок — другой цвет (например, серый вместо синего).

Анимация движения — интерполяция между точками. Интервал обновления GPS-трекера обычно 30-60 секунд, а не 5. Это означает, что маркер должен плавно двигаться 30 секунд от одной точки к другой, а не прыгать. ValueAnimator на Android с LinearInterpolator, CADisplayLink на iOS.

Серверная часть: как обеспечить масштабирование?

Для парка из 50-200 машин — Socket.IO или WebSocket на Node.js. Сервер хранит актуальные позиции в Redis с TTL. Клиент подписывается на канал fleet/updates и получает обновления всех машин пачкой каждые 10-15 секунд вместо индивидуальных событий — экономит трафик на 80%.

Для больших парков (1000+ машин) — MQTT broker с топиками vehicle/{id}/gps. Клиент подписывается только на интересующие машины.

Историческое хранение маршрутов: PostgreSQL + PostGIS для геопространственных запросов («покажи все машины, проехавшие через зону X вчера»), TimescaleDB для time-series метрик (скорость, топливо).

Что входит в работу?

• Аудит источника данных: трекер/телефон/GTFS — определяем тип и протокол.
• Проектирование серверной шины и выбор стека (MQTT/WebSocket/Redis).
• Реализация мобильного клиента: маркеры, маршруты, анимация, состояния.
• Интеграция map matching (OSRM self-hosted или Google Roads).
• Нагрузочное тестирование с эмуляцией трафика до 1000 машин.
• Документация по API и настройке.
• Обучение диспетчеров (1 час).
• Поддержка 2 недели после запуска.

Срок разработки — от 2 до 6 недель в зависимости от источника данных, количества платформ и масштаба парка. Сертифицированные инженеры с опытом 5+ лет гарантируют стабильную работу. Средняя стоимость внедрения для парка из 20 машин — от 500 000 рублей. Оценим ваш проект бесплатно — напишите нам! Закажите разработку трекинга — свяжитесь с нами для консультации.