Pavement condition mobile mapping
Regional transport contractor · condition grading across 2,800 km of arterial roads · Python, PostGIS, Next.js
The situation.
Regional transport contractor responsible for condition grading of 2,800 km of arterial roads.
ScopeFusion of laser crack-measurement data, IMU-located imagery and IRI profiles into a per-100 m segment condition database with automated defect proposals (cracking, ravelling, potholes) and a review workstation for certified raters.
Network-wide condition refresh within 48 h of survey completion, defensible for maintenance budget hearings.
Three acquisition streams feed the platform: laser crack-measurement data, imagery located by the vehicle IMU, and IRI profiles. Ingestion normalises each stream onto the contractor's chainage referencing, then a fusion pass writes one row per 100 m segment into PostGIS with every stream's evidence attached. A proposal engine reads those segments and emits defect candidates (cracking, ravelling, potholes) for review. Certified raters work through the candidates in a Next.js workstation that puts each proposal beside its segment's evidence, and their adjudicated grades become the network condition database that budget-hearing exports draw from. Data flows one way: sensors to chainage-normalised segments to proposals to rater adjudication to certified grades.
Considered: Turning the proposal threshold down so raters saw fewer candidates
Chose: retraining the proposal filter on the contractor's own accepted grades
Because: generic detectors misread patched sections, and a low threshold traded defect catch for reviewer hours
Considered: letting the proposal engine grade directly, with raters doing spot checks
Chose: keeping proposals advisory with certified raters adjudicating every grade
Because: grades argued over in budget hearings need a certified human behind them
Considered: delivering three separate per-sensor condition products
Chose: one fused per-100 m segment database
Because: a hearing challenges a segment, not a sensor stream, so the evidence had to travel together
Considered: building a bespoke desktop review tool
Chose: a browser workstation in Next.js over the same PostGIS schema
Because: the review tool must read the certified segment rows directly, and a second store would have forked the truth
Python carries the fusion, classification and proposal work: the accepted-grade corpus is small enough to retrain in-process, and the point and image handling has mature library coverage. PostGIS holds the segment model because the deliverable is a chainage-keyed query that hearing exports, rater queues and the proposal engine all read live. Next.js covers the workstation because review is interactive and browser-delivered, while the segment evidence stays server-side in PostGIS where the export path can query it unchanged.
2,800 km of arterial roads graded as per-100 m segments. The proposal filter retrained on the contractor's own accepted grades: review load halved with recall held above 95%. Verified acceptance outcome: a network-wide condition refresh completed within 48 h of survey completion, defensible for maintenance budget hearings.
Discovery findings
The contractor is responsible for condition grading across 2,800 km of arterial roads. Three instruments already ride the survey vehicles: a laser crack-measurement system, imagery tied to position by the vehicle IMU, and an IRI profiler. The engagement inherited the streams with no network view between them: nothing joined the three signatures at a common segment key, and grading throughput rested on certified raters working from raw evidence. The acceptance bar set at discovery read: network-wide condition refresh within 48 h of survey completion, with grades defensible in maintenance budget hearings.
The hard problem
False positives concentrated in patched sections. Where crews had sealed cracks or laid binder patches, the crack-measurement signature of the repair resembled the defect it covered, and the proposal engine surfaced those repairs as candidates at a rate that swamped the rater pool. Proposals had to keep running in patched sections, because those sections age into the network's worst segments. The fix came from data the contractor already owned. Its raters had accumulated years of accepted grades, so we trained the proposal filter on that corpus. The filter learned the house distinction between a repair and a defect, review load halved, and recall on genuine defects stayed above 95%.
The build
Ingestion keyed every stream to the contractor's chainage referencing before anything else ran, so a 100 m segment carries its IRI trace, its imagery extent and its crack measurements under one key. The fusion pass writes segment rows into PostGIS with evidence attached, the proposal engine reads those rows and emits candidates, and the Next.js workstation puts each candidate beside its segment evidence for the rater to accept, reject or regrade. Adjudicated grades write back to the same segment rows the export reads. One schema carries acquisition evidence, proposals and certified grades, which is what makes an export line arguable in a hearing: the grade, the proposal that prompted it and the raw signatures sit on one row.
Verification
Verification ran against the acceptance bar set at discovery. A network-wide condition refresh completed within 48 h of survey completion, and every grade in the database traced to a certified rater's adjudication. Recall on the proposal filter was the number the contractor watched through the refresh: a filter that cuts review load by quietly dropping defects would resurface as missed maintenance in the next season's hearings. Grades went into budget hearings on their evidence chain, because the segment row carries the signatures behind the grade and a challenged segment is answered from data rather than a methodology memo.
Handover
Handover followed the studio's standard cycle: deployment, documentation, a walkthrough, and 30 days of post-launch support absorbing the first production questions. The contractor's raters work the proposal queue in the browser and leave certified grades in the same schema the hearing export reads. Maintenance planning now draws on a condition database that refreshes per survey, and the proposals stay anchored to the contractor's house grading because the corpus behind the filter is theirs.