Road Inspection & Pavement Condition Intelligence in GIS

What problem does this solve?

Pavement maintenance is usually decided on the weakest evidence in the asset portfolio. A road network of several thousand kilometres is inspected on a cycle that the team cannot actually complete, using visual assessment that varies by inspector and by how hot the afternoon was. Between formal surveys the real inputs are complaints, incident reports and the personal knowledge of two or three engineers. The result is a programme that is defensible in a meeting but not in an audit, and that reacts to failures rather than preventing them.

Roads deteriorate non-linearly, which is what makes weak data expensive. A surface caught at the point where sealing or a thin overlay still works costs a fraction of the same section after water has reached the base and the failure has spread. Missing the intervention window on a few dozen kilometres each year quietly converts preventive budget into reconstruction budget. Meanwhile potholes reported by the public arrive as text descriptions and approximate locations, are logged in a separate system, and cannot be related back to the condition of the segment they sit on.

Commercial pavement survey vehicles solve part of this and introduce their own constraints. They are expensive to hire, so surveys are annual at best, and the deliverable often arrives as a report or a proprietary dataset rather than as features in the authority's own geodatabase. The scores cannot be traced back to the underlying observations, they do not update between surveys, and they do not connect to the road furniture inventory, the work-order history or the complaint records that would put them in context. The authority ends up with a number per segment and no way to interrogate it.

How the solution works

The practical approach is to separate capture, detection, scoring and action, and to keep all four inside systems the authority owns. Capture can be as simple as a camera and GNSS receiver mounted in an existing inspection or operations vehicle, recording geolocated frames along the network on whatever frequency the fleet already drives; higher-specification setups add multiple cameras, an IMU for better positioning and LiDAR for profile and rutting. Every run is recorded with a survey ID, date, speed and lane, because a score without provenance cannot be defended.

Detection uses deep learning models trained on locally captured, locally labelled frames to find potholes, longitudinal and transverse cracking, alligator cracking, ravelling, patching, edge failure and, in the same pass, road furniture — signs, markings, lighting columns, guardrails and drainage covers. Detections are located along the road centreline using linear referencing, then aggregated per segment into a condition index on a 0–100 scale using defect density and severity weighting, following the structure of standard pavement condition indices such as ASTM D6433 while making the weighting explicit and configurable rather than hidden. Scores land as feature classes in the enterprise geodatabase, an engineer reviews the segments that changed most and a sample of the rest, and confirmed results drive the programme: prioritised treatment lists, budget scenarios, and work orders raised in IBM Maximo or SAP PM with the defect evidence attached. Swedish Technology builds these pipelines as custom development on top of ArcGIS, the client's existing maintenance system and locally trained models, and hands over the models, training data, scoring configuration and code.

1. 1
   Input Define the network to survey against the road centreline and segmentation or linear referencing system, set the target survey frequency, and register the capture vehicles with their camera geometry and calibration.
2. 2
   Capture Vehicle-mounted cameras record geolocated frames with GNSS and, where fitted, IMU and LiDAR; each run stores a survey ID, timestamp, speed and lane. Public and field-app pothole reports are captured into the same pipeline as a separate source.
3. 3
   Processing Frames are quality-filtered (blur, occlusion, exposure), the detection model classifies and localises defects and road assets with confidence scores, and detections are projected from image space to ground coordinates and snapped to the centreline by linear referencing.
4. 4
   Integration Detections are deduplicated across overlapping frames and repeat passes, aggregated per segment into defect density and severity, and combined into a configurable condition index; results are joined with traffic, surface age, treatment history and complaint records.
5. 5
   Action Engineers review flagged segments and a QA sample in a map application, confirm or correct findings, and approved results generate a prioritised treatment list and work orders in the maintenance system with photographs and locations attached.
6. 6
   Reporting Network condition, deterioration trend per segment, backlog and budget scenarios are published to dashboards; each score keeps links to its survey run, detections, model version and reviewer for audit.

Reference architecture

The pipeline has to work at network scale and stay auditable, so each stage writes its own persistent output rather than passing data through in memory.

Deployment options: Capture hardware is off-the-shelf and vehicle-mounted. Processing and storage run on-premise on GPU-equipped servers or in a UAE-region private cloud, sized around survey frequency and network length. Imagery stays inside the authority's environment; only derived features and scores need to reach dashboards and the maintenance system.

Key capabilities

Integrations

The value is in what happens after scoring, so integration into the maintenance and reporting systems is designed at the same time as the detection pipeline, not afterwards.

Industry use cases

Implementation approach

1. 1
   Scoping (1–2 weeks) Agree the network extent, segmentation or linear referencing basis, the defect classes that matter to your treatment decisions, and how condition currently drives the programme.
2. 2
   Data and baseline review Assess the centreline quality, existing condition records, treatment history and complaint data; a poor centreline is the most common hidden blocker and is fixed before detection work starts.
3. 3
   Capture pilot (2–4 weeks) Mount cameras and GNSS on one or two vehicles, survey a representative 20–50 km sample across road types and conditions, and validate positioning accuracy against known points.
4. 4
   Model development Label defects on locally captured frames, train and tune the detection model, and measure precision and recall per class on a held-out section — reported honestly, including the classes that do not work well.
5. 5
   Scoring calibration Configure the condition index weighting and compare scored segments with your engineers' own assessment of the same sections until the ranking is credible to them.
6. 6
   Review workflow and integration Build the engineer review application, the audit fields and the work-order integration into Maximo or SAP, including the return path for completed repairs.
7. 7
   Production rollout Scale capture to the full network, schedule ingestion, detection, scoring and publication, and set the survey frequency per road class.
8. 8
   Hand-over and retraining plan Deliver models, training data, scoring configuration, code and runbook; agree the retraining cadence for when cameras, vehicles or surface conditions change.

Security & deployment

Road imagery contains vehicles, number plates and people, so the pipeline includes automatic blurring of faces and plates at ingestion where the authority requires it, and access to raw frames is restricted to the processing service and named reviewers. All storage and inference run on-premise or in a UAE-region private cloud under the authority's own retention policy, with imagery lifecycle rules — typically keeping full frames for a defined window and detection crops for longer as evidence. Detections, scores and work orders carry a full audit chain: survey run, model version, reviewer and timestamp, which matters when a condition score supports a spending decision or a contractual claim. Integration with Maximo or SAP goes through a service layer holding credentials in a vault, and role-based access in the portal limits each engineer to their own area.

Limitations & prerequisites

• Camera-based detection assesses the visible surface only; structural capacity, base condition and layer thickness still require deflection testing, coring or ground-penetrating radar.
• Detection quality depends on capture conditions — night driving, heavy rain, blown sand, glare, wet surfaces and high speed all reduce reliability, so survey timing matters.
• Fine cracking is harder to detect than potholes and needs higher resolution and slower capture; expect different accuracy per defect class rather than one headline number.
• Positional accuracy is limited by GNSS quality; urban canyons and tunnels need IMU support or map-matching, and a poor road centreline will corrupt segment assignment regardless of detection quality.
• A condition index derived from surface imagery is not identical to a formally surveyed ASTM D6433 PCI, which includes measurements imagery cannot provide; it should be presented as a comparable, documented index and calibrated against engineer assessment.
• Training data must be captured locally with the same camera setup; models trained elsewhere or on a different mounting geometry do not transfer reliably.
• The pipeline produces prioritised evidence, not decisions — treatment selection still depends on engineering judgement, budget and coordination with other works.
• Storage and processing costs scale with network length and survey frequency; continuous capture across a large network needs planned storage sizing and retention rules.

Visual inspection vs survey vehicle contract vs owned camera pipeline

The choice is mainly about frequency, traceability and who owns the resulting data.

These are not mutually exclusive. Many authorities keep a periodic specialist survey for structural measurement and formal reporting, and add an owned camera pipeline for continuous surface condition, asset inventory and complaint correlation between those campaigns.

FAQ

Related topics & solutions

• GeoAI Object Detection with ArcGIS
• ArcGIS – IBM Maximo Integration
• ArcGIS Experience Builder Custom Widgets
• ArcGIS Python Toolbox & ArcPy Automation
• ArcGIS – SAP Integration (PM/EAM, S/4HANA)
• Smart Inspection
• RASM ÔÇô Digital Twin
• AI Products Portfolio