Development of Vehicle Transport Tracking in a Mobile Application
Vehicle tracking differs from courier tracking in several key aspects: movement speeds are different, GPS noise at high speed has different characteristics, routes are often known beforehand (scheduled transport), and data comes not from the driver's smartphone but from GPS tracker via MQTT/Wialon protocol or Teltonika FMB devices.
Data Sources: Not Just Smartphone
For logistics companies and fleet management, the transport device is a hardware GPS tracker (Teltonika FMB920, Queclink GV350, Galileosky), not the driver's phone. The tracker sends packets via MQTT or HTTP protocol to server. App serves only as data visualizer, not source.
For showing public transport from GTFS Realtime data (Google standard), the source is open APIs of city transport operators. Format — Protocol Buffers (transit_realtime.FeedMessage), parsing via gtfs-realtime-bindings library.
For apps with driver phone (taxi, corporate transport) — same stack as courier tracking, but with adjustments for movement speed.
GPS Filtering at High Speeds
At 80-120 km/h, horizontal GPS drift is less than in city with skyscrapers, but different problem: on sharp turns, marker can "overtake" real vehicle position due to update delay. Kalman filter smooths this delay.
Simple Kalman filter implementation for coordinates in 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 // velocity change 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
}
On iOS equivalent implementation in Swift or use CLLocationManager with CLActivityType.automotiveNavigation — Apple applies own filter.
Map Matching for Routed Transport
Scheduled bus follows fixed route — GPS points between stops must lie strictly on that route, not jump to parallel street. Map matching: take sequence of GPS points and "press" them to nearest road graph segment.
OSRM self-hosted: GET /match/v1/driving/{coordinates}?radiuses={radiuses}&geometries=geojson. Returns matched track with waypoints. Latency < 20 ms on self-hosting, acceptable for real time.
Google Roads API snapToRoads — simpler integration, but paid ($5 per 1000 calls) and limited to 100 points per request.
Transport Display: Markers and Route
Bus/truck marker — custom PNG or SVG rotated by direction. Direction in degrees: atan2(dLon, dLat) * 180 / PI. On Android — BitmapDescriptorFactory.fromBitmap(rotatedBitmap) with rotation via Matrix.postRotate(). On iOS — GMSMarker with iconView, rotation via CGAffineTransform(rotationAngle:).
Route — polyline. Google Directions API for calculation or pre-saved GTFS shapes.txt. On map — GMSPolyline / Polyline with custom color and width. Traveled section — different color (e.g., gray instead of blue).
Movement animation — interpolation between points. GPS tracker update interval usually 30-60 seconds, not 5. This means marker should move smoothly for 30 seconds between points, not jump. ValueAnimator on Android with LinearInterpolator, CADisplayLink on iOS.
Server Part
For fleet of 50-200 vehicles — Socket.IO or WebSocket on Node.js. Server stores current positions in Redis with TTL. Client subscribes to fleet/updates channel and receives all vehicle updates in batches every 10-15 seconds instead of individual events — saves traffic.
For large fleets (1000+ vehicles) — MQTT broker with topics vehicle/{id}/gps. Client subscribes only to interested vehicles.
Historical route storage: PostgreSQL + PostGIS for geospatial queries ("show all vehicles that drove through zone X yesterday"), TimescaleDB for time-series metrics (speed, fuel).
Workflow
Data source audit: tracker/phone/GTFS. Server bus and storage design. Mobile client implementation: markers, routes, animation, states. Map matching integration if needed. Traffic emulation testing.
Timeline: from two to six weeks depending on data source, number of platforms, and fleet scale.