GPS Map Matching — Snapping a Noisy Trace to the Road

Trace Controls

GPS noise σ 3.0 m

Vehicle speed 6.0 u/s

Heading weight 0.45

Live Readouts

Raw GPS scatter (avg)

0.0 m

Matched-point error (avg)

0.0 m

Correct-road rate

GPS fixes taken

How it works

A phone's raw GPS fix is never exactly on the road — multipath reflections and receiver error scatter it a few metres to either side. Every turn-by-turn app runs a map-matching step that snaps each noisy fix back onto the actual street before drawing the blue dot or announcing a turn.

For a fix at point p, every nearby road segment [a,b] is scored and the best one wins:

foot = clamp_project(p, a, b)         // perpendicular projection
d    = |p - foot|                     // distance to candidate road
distScore    = exp(-d² / 2σ_d²)
headingScore = |dot(dir(a,b), heading)|   // 0..1, road-vs-course alignment
continuity   = 1.0 if same road as last fix
             = 0.6 if road connects to it at a shared junction
             = 0.15 otherwise
score = distScore · (1 − w_h + w_h·headingScore) · (0.4 + 0.6·continuity)

The segment with the highest score is the match; the vehicle's blue dot is drawn at its foot point, not at the raw fix. This is a simplified, per-fix version of the Hidden-Markov-Model matcher used by real routing engines (OSRM, Valhalla) — continuity plays the role of the HMM's transition probability, distance and heading play the role of the emission probability.

GPS noise σ — how far raw fixes scatter from the true position (bigger city buildings ⇒ bigger σ).
Heading weight — how much the device's compass course counts versus raw proximity; 0 = distance-only nearest-road snapping (fails at parallel streets), 1 = heading-only.
Correct-road rate — the fraction of fixes the algorithm actually snapped onto the road the vehicle was really driving on.

Raw noisy GPS fix Map-matched trace Vehicle (true position)

⚠ Couldn't load the 3D engineThree.js failed to load from the CDN. Check your connection and reload.