Quick answer. A ride-hailing ETA is not a GPS answer — it is the output of a stack: raw GPS, filtering, map-matching to a road network graph, shortest-path (typically contraction hierarchies or A*), traffic adjustment (historical and live), and post-hoc calibration. The last stage exists because raw route estimates are systematically optimistic.

Stage 1: Raw GPS

Smartphone GPS has typical urban accuracy of 5–20 m. It is substantially worse in urban canyons (Hong Kong, parts of Yerevan old city, central London with high buildings). Raw GPS is noisy — you will not get a clean route trace by plotting points.

Stage 2: Sensor Fusion

Modern phones fuse GPS with accelerometer, gyroscope, magnetometer, and Wi-Fi/Bluetooth fingerprints. The resulting fused position is meaningfully better than GPS alone, especially in tunnels and garages.

Stage 3: Map-Matching

A map-matcher snaps the noisy fused trace onto a road graph. The canonical approach is Hidden Markov Model map-matching (Newson & Krumm 2009) — each observation is matched to the most probable road given prior state. This turns noisy points into a legal route on actual streets.

Stage 4: Routing

Given a start and end point, the platform needs a shortest-path (by time, not distance). At city scale this uses contraction hierarchies (precomputed road shortcuts) or customisable route planners — A* with good heuristics. Naive Dijkstra would not meet ride-hailing latency budgets.

Stage 5: Traffic Adjustment

Raw shortest-path ignores traffic. The router applies:

Historical traffic — typical speeds on this segment at this time of day and day of week.
Live traffic — recent observed speeds from active rides.
Incidents — known closures, accidents, or construction.

Stage 6: ETA Calibration

Raw routed ETAs are typically optimistic by 8–15% in most cities. Platforms apply a learned calibration (often a gradient-boosted model on features like time of day, weather, trip length). This is why your ETA may say “12 minutes” when the raw route suggests nine — it is a calibrated estimate, not a naive one.

Stage 7: Driver Dispatch

Dispatch is a separate system. Given a rider request, it evaluates candidate drivers by ETA to pickup, rating, acceptance rate, route compatibility, and cohort-level fairness considerations. Modern dispatchers are typically online matching algorithms with look-ahead.

Why Your ETA Is Sometimes Very Wrong

Incident not yet in the system (first-minute effect).
Weather not priced in (flash rain in Tbilisi collapses traffic speed).
Driver deviation from the proposed route.
GPS occlusion in tunnels delaying the next ETA update.

Emerging Markets Have Different Constraints

Map coverage in Kampala, Yerevan, and Accra is weaker than in London. Historical traffic data is sparse. Map-matching quality depends on a good base graph. Platforms operating in these markets often maintain their own map corrections and open-contribute to OpenStreetMap.

GeraRide Specifics

GeraRide uses a stack of open source (OSRM + OSM base map) plus proprietary calibration layers for each operating city. Map corrections from driver telemetry feed back into the open source graph quarterly.

Cross-Product Context

Routing engineering is close cousin to logistics engineering behind GeraEats delivery dispatch and cold-chain. Gera Prime subscribers can export anonymised routing logs. GeraCash handles the fare stream that routing optimisation affects on the revenue side.

Next Step

Next time your ETA is exactly right, thank a Hidden Markov Model. Book a ride and watch the calibration work.