This is the central problem in detecting road work from cameras, and it is a problem of noise rather than of vision. Recognizing a cone is solved. Knowing which cones constitute road work is not, and a system that pins every cone it sees onto a map has handed a department of transportation a dataset it cannot act on.
The other half of the problem is the paperwork
Permit systems are supposed to answer this. A permit says work will happen at a location on a date, so in principle the authority already knows.
In practice a permit says work was expected to begin on the 20th and the road says something else. The gap between what is happening on the roads and what the permit systems hold is what customers describe when they explain why they are looking.
That is reported from those conversations rather than measured, and it carries no percentage behind it, so read it as the problem being described rather than as a finding.
What gets built instead of pins
The Work Zones product aggregates scattered object detections into the road segments those objects affect, assembling a work zone as a segment rather than leaving isolated markers on a map. The detections that feed it are the physical furniture of road work: drum cones, arrow message boards, road blockage.
Two mechanisms sit under that.
Detection thresholds are set per object class, using the precision and recall curve from the model's training to pick the operating point for each class. The threshold gates what gets uploaded at all, not merely what gets displayed, which is why the raw feed is already filtered before anyone applies their own filter to it. Users can then trade precision against recall themselves by filtering on the model's confidence score. That exposed number is a raw model confidence rather than a calibrated precision figure, and it should be read as such.
Every detection is indexed into H3 hexagons, a standard grid that divides the map into equal hexagonal cells, and map-matched onto OpenStreetMap so it lands on the right road rather than near it. Repeat sightings from different vehicles aggregate at H3 resolution 12, which is how the same cone seen twenty times becomes one object.
Only we know
A detection stays on the live view only while cameras keep re-seeing it. When the network stops seeing it, the detection disappears.
The honest reading of that is the interesting part. A work zone vanishing from the map means one of two things: the cones came down, or the vehicles stopped driving past. Those are not the same event, and no amount of model accuracy separates them, because the evidence for the second one is an absence.
Anyone selling live road data who does not volunteer that distinction has not thought about their own denominator. Absence of a detection is not evidence of absence on the road, and the difference matters most in exactly the places where coverage is thinnest.
Two clocks
Objects expire on a schedule tuned to how transient they are. A work zone object defaults to a 24 hour lifetime if it is not seen again. A road sign is kept for 30 days. Road work moves; a stop sign does not.
The live view and the curated products also run at different speeds. A live detection appears within seconds of the camera seeing it, with the image following within minutes. The curated products run weekly. Fast and provisional, or slower and aggregated. Both are the same underlying observations, processed with different tolerance for being wrong.
Why it can run at all
The AI inference happens on the camera rather than in the cloud, which is what makes a live feed possible in the first place. Both consumer and fleet cameras run it.
Each detection ships with the frame that produced it, and customers treat that image as the visual evidence for the detection. Mapping teams use the same imagery to update their own map data after a road has changed. Access is available through a web interface and through APIs.
Curation applies to signs as well. Crunching many individual sign detections together, above a minimum confidence per detection, produces better positioning and better reading of what the sign means than any single detection gives.
Work zone feeds are commonly requested in the Work Zone Data Exchange format, the federal interchange spec that state DOTs and navigation apps have standardized on. The value of a sensor-based feed against that spec is ground-truth: a WZDx feed built from lane closure permits reflects what was planned, and an on-the-ground feed reflects what is happening. Both matter, and they answer different questions.
Limits
Coverage follows the recording fleet, so a road nobody drove is a road with no detections, and the map cannot distinguish that from a clear road. The confidence value is model confidence rather than a calibrated precision. Object lifetimes are defaults rather than measured durations of real road work. No coverage percentage, city count or detection volume appears in this piece, because none is established.
Measured, not imagined. And when the measurement stops, the map says so.