You're driving. A road ahead turns red. Normal enough. But then you notice something else: a small icon sitting right on that road. Roadwork. Or an accident. Or a lane closure.
You didn't report it. Nobody in front of you stopped to file a report. There isn't a camera operator somewhere manually updating a map. Yet Google Maps apparently knows that something specific is happening on that particular stretch of road.
That's a stranger problem than the traffic one.
Knowing that a road is slow is one thing. Knowing why it's slow is another. And the answer involves a pipeline that starts with millions of imperfect sensor readings and ends, somehow, with a small icon on your screen.
The Raw Material Is Messy
Everything starts with location data, and location data is never clean.
A phone's GNSS position estimate carries uncertainty. Signals from satellites travel through the atmosphere, bounce off buildings, and arrive at your phone from multiple reflected paths simultaneously. This multipath interference can shift your reported position by tens of metres. Tall buildings can block satellites entirely. Updates aren't continuous. There are gaps.
So the system isn't working with a clean, precise trajectory of every device on every road. It's working with a stream of noisy observations, each carrying some amount of uncertainty about where that device actually was at that moment.
Device
ā
Position observations over time
ā
Each observation has uncertainty
ā
Approximate trajectory
Everything downstream is built on top of that imperfect foundation.
Which Road Is the Device Even On?
Before the system can say anything useful about a road, it needs to answer a more basic question: which road is this device travelling on?
A GPS coordinate that falls fifteen metres from a road, or between two parallel streets, doesn't answer that question by itself. This is the map matching problem.
Map matching uses more than just the current position. It uses the sequence of previous positions, the direction of movement, the estimated speed, and the geometry of nearby road segments to infer the most likely road. A point that falls ambiguously between two roads becomes much less ambiguous when you factor in that the device has been moving north for the past thirty seconds and the next observation is also consistent with the northbound road.
Noisy location
ā
Candidate road segments
ā
Current position + direction + trajectory
ā
Most likely road segment
Only once a device is assigned to a road segment can the system start making inferences about what is happening on that road.
Speed Comes From Movement
With a device matched to a road segment, consecutive position observations give you a rough speed estimate. Distance between two positions divided by elapsed time. Simple in principle, noisy in practice.
A single device moving at 8 km/h might be stuck in traffic. It might also be a delivery driver stopped at a red light, someone walking with their phone, or a GPS update that arrived late and made the device look slower than it was. One measurement from one device doesn't tell you much.
This is where aggregation becomes the key idea.
Many Phones Reveal What One Phone Can't
Imagine several devices on the same road segment, all travelling in the same direction, observed around the same time:
Device A ā 11 km/h
Device B ā 9 km/h
Device C ā 13 km/h
Device D ā 10 km/h
Device E ā 12 km/h
Individually, each reading is uncertain. Together, they can form a much stronger signal. The noise in individual measurements doesn't disappear, but independent measurement errors are less likely to produce the same spatial pattern across many devices. When reasonably independent observations agree on the same location and time window, that agreement itself becomes evidence.
Modern navigation systems can aggregate observations across many devices to estimate the prevailing conditions on a road segment. When those observations are sufficiently independent and consistent, confidence in the estimate can increase. This is the core idea behind distributed sensing: many imperfect sensors, observing the same thing independently, can produce a result that no single sensor could.
Slow Doesn't Automatically Mean Unusual
Here's where it gets more interesting.
A road moving at 20 km/h isn't necessarily in trouble. On a narrow urban street, that might be perfectly normal. On a motorway that typically flows at 100 km/h, it's a serious anomaly.
The system needs a baseline to make sense of current conditions. Navigation systems can compare what they're observing right now against historical patterns for that road, at that time of day, on that day of the week.
Expected speed for this road at this time: 80 km/h
Current estimated speed: 15 km/h
Large deviation
ā
Something unusual is happening here
This comparison is what transforms a raw speed observation into anomaly detection. The road isn't flagged because phones are moving slowly. It's flagged because phones are moving much more slowly than they usually do at this time, in this place.
Detecting Slow Traffic Is Not the Same as Knowing Why
This is the distinction that matters most.
Movement data can tell you that something unusual is happening on a road. It cannot, by itself, tell you what. A persistent slowdown that doesn't match normal congestion patterns is a signal. But a signal of what?
An accident and a burst water main and an unexpected road closure can all look similar from the movement data alone: traffic slows, the slowdown persists, vehicles behave differently than expected. The anomaly is detectable. The cause isn't directly observable from GPS trajectories.
Identifying the cause requires additional evidence. Modern navigation systems can incorporate various sources of information alongside movement data: user-submitted reports, officially published roadwork schedules, partner data from transport authorities, information from the map itself about known road features. Google publicly acknowledges using multiple data sources for Maps, though the exact weighting and classification logic is proprietary. When multiple independent signals point to the same location and tell a consistent story, the system can make a more confident classification.
Anomalous movement pattern
+
User reports of roadwork at this location
+
Known construction schedule for this road
ā
Likely classification: roadwork
One signal raises a flag. Multiple signals agreeing help determine what the flag means. And when signals conflict or are absent, the system has to sit with uncertainty rather than guess.
The Map Is Never Finished
All of this happens continuously.
New observations arrive. Position estimates update. Road segment assignments update. Speed estimates update. Anomaly scores update. Additional evidence gets incorporated. The map reflects the current best estimate of what is probably happening on the road network.
A road can shift from green to orange to red as conditions change. An incident icon can appear as evidence accumulates and disappear as conditions normalise. The map isn't showing you a fixed picture. It's showing you the most recent output of a continuously running estimation process.
Detecting and Predicting Are Different Problems
There's one more distinction worth making.
Detecting what is happening right now and predicting what is likely to happen next are related but separate problems. Current observations combined with historical patterns and road network structure can help forecast how conditions might evolve: whether a slowdown is likely to spread, how long an incident typically affects a particular junction, when a congested road usually clears.
Detection asks what the evidence says is happening now. Prediction asks what is likely to happen next. Both feed into what appears on your screen.
That small icon on your map, sitting on a red road, looks like a simple piece of information.
Behind it is a chain that starts with noisy GPS readings from phones you'll never meet, runs through map matching and speed estimation and aggregation and anomaly detection, pulls in external signals from reports and data sources, and arrives at a classification that might be right, might be slightly wrong, and will be revised the moment new evidence arrives.
Google Maps doesn't observe the road. It builds a continuously updated reconstruction of what is probably happening on it, from evidence that is always imperfect and never complete.
The icon is the conclusion. The engineering is everything that had to happen first.
