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

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

Наши инженеры сталкивались с ситуацией, когда 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 рублей. Оценим ваш проект бесплатно — напишите нам! Закажите разработку трекинга — свяжитесь с нами для консультации.

Карты и геолокация в мобильных приложениях: Google Maps, MapKit, геофенсинг, трекинг

Мы интегрируем геолокацию и картографические сервисы в мобильные приложения — это не просто «добавить карту». Это настройка разрешений, управление точностью и энергопотреблением, учёт особенностей iOS и Android. Трекер доставки, приложение для бега, карта магазинов — каждый случай требует своего подхода. Оценим ваш проект за 2 часа — напишите нам.

Разрешения: один из самых частых источников плохих отзывов

На iOS разрешение на геолокацию — самое чувствительное после микрофона и камеры. С iOS 14 система показывает индикатор в статусбаре при использовании геолокации в фоне — пользователи это замечают. NSLocationWhenInUseUsageDescription и NSLocationAlwaysAndWhenInUseUsageDescription должны содержать честное объяснение, иначе приложение отклонят на ревью. Запрашивать always разрешение сразу при старте — верный способ получить отказ от 80–90% пользователей. Правильная схема: сначала whenInUse, а always — только когда пользователь дошёл до функции, которая его требует, с объяснением зачем.

На Android с API 29+ ACCESS_BACKGROUND_LOCATION — отдельное разрешение, которое нельзя запросить вместе с foreground. Сначала запрашиваете foreground разрешение, потом отдельным шагом — background. Google Play требует обоснования для background location в questionnaire при публикации. Если обоснование слабое — приложение могут отклонить или потребовать убрать background location. За 5 лет работы мы провели более 20 успешных ревью, ни одно приложение не было отклонено по этой причине.

Точность и энергопотребление: как не разряжать аккумулятор

Постоянный GPS на максимальной точности потребляет 100–150 мВт — аккумулятор садится за 4–6 часов. Для большинства задач это избыточно.

На Android FusedLocationProviderClient (Google Play Services) объединяет GPS, Wi-Fi и сотовую сеть, выбирая оптимальный источник. LocationRequest.Builder с приоритетами:

• PRIORITY_HIGH_ACCURACY — GPS включён, для навигации
• PRIORITY_BALANCED_POWER_ACCURACY — точность ~100 метров, Wi-Fi + сотовая
• PRIORITY_LOW_POWER — точность ~10 км, только сотовая
• PRIORITY_PASSIVE — координаты от других приложений, без активного запроса

Для трекера пробежки в активном режиме — HIGH_ACCURACY с интервалом 2–5 секунд. Для геофенсинга фоновых уведомлений — PASSIVE или LOW_POWER, система сама разбудит по событию. Википедия: GPS — авторитетный источник по точности.

На iOS CLLocationManager с desiredAccuracy (kCLLocationAccuracyBest, kCLLocationAccuracyHundredMeters, etc.) и distanceFilter — минимальное смещение в метрах перед следующим обновлением. Для трекинга маршрута с сохранением батареи: desiredAccuracy = kCLLocationAccuracyNearestTenMeters, distanceFilter = 10 — получаем обновления только при реальном движении.

Significant Location Changes — режим iOS, который работает на уровне ОС без активного GPS: обновления при смене сотовой вышки, расход батареи минимален. Точность ~500 метров — подходит для логирования «где был пользователь сегодня», не для навигации.

Как выбрать картографический SDK? Сравнительный анализ

Google Maps SDK — выбор по умолчанию для большинства проектов: знакомый UI, хорошая документация, Directions API, Places Autocomplete. Ограничение — зависимость от Google Play Services (проблема для Huawei) и ценовая политика при высоких объёмах запросов (свыше 28 000 запросов/мес — платно).

Mapbox предпочтительнее, когда нужен кастомный стиль карты (корпоративный брендинг, тёмная тема), офлайн-карты для работы без сети, или доступность на устройствах без GMS. MapboxNavigation SDK — полноценная навигация с голосовыми инструкциями, перепрокладкой маршрута, lane guidance. Mapbox рендерит полигоны в 2 раза быстрее при загрузке 500+ маркеров по сравнению с Google Maps — это подтверждают наши нагрузочные тесты.

Для Flutter — google_maps_flutter (официальный), flutter_map (OpenStreetMap + MapLibre, полностью open-source), mapbox_maps_flutter (после выхода официального SDK).

Пример выбора: приложение с офлайн-картами и геозонами на 100+ точек

Клиент — сеть розничных магазинов. Требование: карта с offline-режимом и push-уведомлениями при входе в магазин. Выбрали Mapbox — он поддерживает загрузку регионов целиком и офлайн-геокодинг. Результат: 0 отказов из-за сети, снижение расхода батареи на 30% за счёт PASSIVE-режима.

Почему геофенсинг срабатывает с задержкой?

Геофенсинг — запуск события при входе/выходе из географической зоны (круг заданного радиуса). На практике задержка может составлять 1–3 минуты — это плата за энергоэффективность.

На Android — GeofencingClient из Google Location Services. Добавляем Geofence объекты с setTransitionTypes(GEOFENCE_TRANSITION_ENTER | GEOFENCE_TRANSITION_EXIT) и PendingIntent на BroadcastReceiver. Ограничение: максимум 100 активных геофенсов на приложение, минимальный радиус ~150 метров (на практике из-за точности), срабатывание с задержкой до нескольких минут в целях экономии батареи.

На iOS — CLCircularRegion + CLLocationManager.startMonitoring(for:). Лимит: 20 регионов на приложение. ОС управляет когда проверять — разработчик не контролирует задержку. Для более точного геофенсинга с маленьким радиусом — iBeacon (CLBeaconRegion) или CLVisit для мест, где пользователь провёл время.

Если нужно больше 20 (iOS) или 100 (Android) зон — нужна серверная логика: периодически отправляем координаты на сервер, сервер проверяет попадание в зоны и отправляет push. Менее точно по времени, но масштабируется на тысячи зон. Википедия: Геозона — подробнее о принципах работы.

Трекинг маршрутов и фоновая геолокация

Трекинг маршрута пробежки или маршрута курьера в фоне — технически разные задачи.

На iOS фоновая геолокация работает через UIBackgroundModes: location в Info.plist. Без этого ключа при уходе приложения в фон CLLocationManager получает несколько минут и засыпает. С ключом — работает постоянно, но система может приостановить при критически низком заряде.

Для трекера пробежки на iOS паттерн: startUpdatingLocation при старте тренировки, координаты пишем в Core Data каждые 5 секунд, на паузе — stopUpdatingLocation, но оставляем startMonitoringSignificantLocationChanges чтобы приложение не «потерялось» совсем.

На Android для курьерского трекинга нужен Foreground Service с FOREGROUND_SERVICE_TYPE_LOCATION (обязательно с API 29). Foreground service показывает постоянное уведомление — это требование платформы, не баг. Без него Android Doze убьёт обновления геолокации. WorkManager для фоновых задач здесь не подходит — он не гарантирует непрерывность.

Алгоритмическая часть трекинга маршрута: сырые GPS-координаты зашумлены. Для сглаживания — алгоритм Ramer-Douglas-Peucker для упрощения трека или Kalman Filter для фильтрации шума в реальном времени. Без фильтрации трек выглядит как случайные зигзаги, а расчётное расстояние на 20–30% больше реального.

Как мы внедряем карты и геолокацию: пошаговый процесс

1. Анализ сценариев — определяем, нужен ли foreground/background, точность, количество геозон, необходимость офлайн-режима.
2. Выбор SDK и архитектуры — сравниваем Google Maps, Mapbox, HERE, MapKit по критериям проекта (наше сравнение выше — используйте как базу).
3. Интеграция и настройка разрешений — прописываем Info.plist / AndroidManifest.xml, тестируем ревью-чеки (App Store Review Guidelines Section 4.2/5.1, Google Play policy).
4. Реализация трекинга/геозон — добавляем CLLocationManager / GeofencingClient, настраиваем фильтры и энергосбережение.
5. Юнит- и интеграционное тестирование — на реальных устройствах (эмулятор не симулирует задержки и поведение Doze/App Nap). Проверяем не менее 50 сценариев.
6. Нагрузочное тестирование — симулируем 500+ маркеров, движущиеся объекты, проверяем FPS и расход батареи.
7. Деплой и мониторинг — выкладываем через TestFlight / Firebase App Distribution, собираем логи crashlytics, отслеживаем количество отказов разрешений.

Сроки и что входит в работу

Что вы получите в любом случае:

• Исходный код с комментариями (Swift, Kotlin, Dart, TypeScript)
• Интеграцию с вашим бэкендом (REST/GraphQL/WebSocket)
• Поддержку 1 месяц после сдачи (исправление багов, помощь с ревью сторов)
• Инструкцию по публикации в App Store и Google Play (включая обоснование для background location)
• Сертификаты code signing, provisioning profiles, ключи Google Maps/Mapbox

Наши компетенции: 10+ лет опыта в мобильной разработке, 50+ проектов с геолокацией, сертифицированные разработчики Apple и Google (Google Associate Android Developer). Каждое приложение проходит тройной код-ревью и нагрузочное тестирование.

Закажите внедрение карт и геолокации под ключ — свяжитесь с нами, чтобы получить консультацию и предварительную оценку вашего проекта в течение 2 часов.