From a fuzzy GPS fix
to the right lane.
Phone-grade GPS puts a car about 10 m from where it really is: often on the wrong side of the street, sometimes on the wrong street. Watch four classic techniques close that gap one at a time on real San Francisco streets, each scored against ground truth.
Drive through SoMa
Every drive is a new route with fresh sensor noise. Pick the GPS conditions, then zoom from the whole neighborhood down to a single lane and watch the dashed lines from the true car to each estimate shrink as the stack adds each technique. Toggle stages in the table to compare them.
Roads, lanes and one-way rules are from OpenStreetMap (© OpenStreetMap contributors, ODbL). The drive and its sensors are simulated, which is what makes scoring against ground truth possible.
Each layer fixes a different error
Medians over 20 drives in urban-canyon GPS: 10.5 m raw, 8.5 m filtered, 6.4 m map-matched, 1.4 m against the landmark map, and 1.2 m on the lane map, in the right lane 97% of the time.
Kalman filter
Fuses 1 Hz GPS with 10 Hz wheel speed and gyro. It smooths the noise and coasts through the overpass dropout, but it inherits the GPS bias and has no idea where the roads are.
Map matching
A hidden Markov model over nearby road segments keeps only sequences a car could actually drive, then snaps the car onto the road it picks. Right street, 96% of the time.
SLAM landmark map
A mapping fleet locates roadside poles and signs with graph SLAM, averaging away each drive's GPS bias. Localizing against that map cuts along-the-street error from 5.6 m to under 1 m.
Lane map
A lane camera's solid and dashed markings pick the lane, and its in-lane offset places the car inside it. Right lane 97% of the time, with 0.6 m of lateral error.
Score it yourself, then deploy it
The estimators are plain NumPy and SciPy: an EKF, a Viterbi map matcher, a sparse Levenberg–Marquardt pose-graph solver, and a lane HMM. Run the offline scorer to reproduce the numbers above, or deploy the interactive demo with one command.
Swap the simulated drive for your own fleet's traces, or the SoMa extract for your own map, and the same stages apply.
chalk-ai/gps-lane-localizationgit clone https://github.com/chalk-ai/gps-lane-localization
cd gps-lane-localization
# Score every stage over 20 simulated drives, offline.
./evaluate.py --profile urban-canyon --drives 20
# Or deploy the interactive demo (CPU only) and print its URL.
chalk login
./deploy.pyWhat Chalk handles
The estimation is the interesting part. Everything around it is the part Chalk does for you.
Any Python, any hardware
This demo needs no GPU: two vCPUs run the whole stack. The same deploy call asks for an L4 when a workload needs one.
Under a second per drive
A three-minute drive goes through all four stages, including a sparse graph-SLAM solve, in about 0.9 seconds on two vCPUs.
Work done once, at startup
The replica simulates a 60-drive mapping fleet and builds the landmark map before it reports ready, so every visitor's drive uses a finished map.
Real streets
Routes, one-way rules and lane counts come from OpenStreetMap's SoMa extract, including the I-80 overpass where GPS loses its fix.
Runs in your cloud
The replica runs in your Chalk environment, next to your telemetry. Vehicle traces never pass through a third-party API.
Open source
The estimators, simulator, viewer and an offline scorer are Apache-2.0 on GitHub. Point them at your own traces and maps.
Put your vehicles in the right lane
Map matching, fleet mapping, and the features built on top of them. Talk to an engineer about running your localization stack in your own cloud.