Can a dashcam pass replace a survey vehicle? Not yet, and here is how we know

11 September 2026 · Analitik

RoadAsset already ingests a lot of GoPro footage. Operators drive their network, the video lands, and an assessor scrubs through it. The question we have been testing is whether that same footage is worth more than it is currently being asked to deliver - specifically, whether a single pass can produce a georeferenced orthophoto mosaic of the road surface rather than just a video someone watches.

The short answer is that it produces something useful, and it is not a survey. This note is about how we established which is which, because that distinction is where this kind of project usually goes wrong.

Why it is tempting

Road imagery programmes are expensive for reasons that have little to do with imagery. The cost is the crew, the calibrated rig, the lane closure and the scheduling around all three. If usable surface imagery falls out of footage an operator is already collecting, the marginal cost of a network-wide visual record drops to roughly zero.

That is a large enough prize to make wishful thinking very easy, which is the actual engineering risk.

What it currently supports

Visual reference. Seeing the surface, comparing the same stretch across dates, giving an office-based assessor something better than a video scrubbed by hand.

What it does not support

There is no established accuracy figure, no absolute metric scale, and no measured crown. If the deliverable is a measurement someone will rely on, this is not the tool.

We are stating that as a property rather than a disclaimer. A mosaic that looks precise invites measurements it cannot support, and a regular grid drawn over an image is the most persuasive thing in the whole output. Grid spacing is not accuracy.

The verification is the interesting part

The mosaic is the easy half. Knowing whether to trust it is the work.

Deterministic rebuild. Every bake reproduces from its inputs. The baseline manifest is generated by script rather than hand-written, and re-verification exits non-zero on drift.

The part that matters: we confirmed it fails on deliberately planted drift. A check that has only ever been observed to pass has not been tested - it has been assumed. Most “verified” pipelines are in exactly that state.

Pixel-exact replay. Tiles are hash-checked and decoded and the full base-zoom raster is reproduced exactly - tens of millions of pixels, not a sampled spot-check.

Provenance gaps are named rather than omitted. Where an input is estimated instead of measured, the record says so. One height in our reference build is a photo estimate, never taped, and it is recorded that way. Where an extraction step predates the runner and its exact command was not captured, that is recorded too.

A provenance record containing only good news is not a provenance record.

What it refuses to do

The decision engine holds rather than guesses:

• Uncertainty holds and never classifies. A stationary run is equally a traffic queue; wide pass separation is equally multipath. Ambiguous input yields a hold, not a confident label.
• An unknown clock mapping is refused, not repaired. Wall-clock time is never substituted for video time to make a run processable.
• A provider error holds as retryable, never as missing data. A failed fetch must not become a finding about the road.

Each rule discards runs a less careful pipeline would have happily processed. That is the intended trade. At network scale, a system that sometimes says “I cannot tell you” is worth considerably more than one that is confidently wrong.

One failure worth repeating

A good GPS stream with unusable timing was reporting gps_missing - which tells an operator “the camera had GPS off, re-record the run”. The correct message was gps_unknown_clock: the telemetry is fine, change a capture setting.

Opposite operator actions, from the same input.

Neither module was wrong on its own. The generic empty-input guard simply ran before the specific one, and the component upstream empties its sample list when it refuses - so the specific reason was already gone by the time anything looked for it. The fix was ordering the guards most-specific-first.

The general lesson has nothing to do with orthophoto: a generic guard placed ahead of a specific one reports the wrong reason, and reports it confidently. If a producer signals refusal by emptying its output, every downstream emptiness check becomes a liar. Test the seam between components, not just the components.

What would have to be true to ship it

Metric validation against a controlled corridor, which is a separate programme of work and has not been done. Until then this is a visual-reference capability that we are honest about, rather than a survey product we are optimistic about.