RoadWatch: Predicting Road Problems, Improving Decisions
Inspiration
Road maintenance is often reactive. A pothole gets reported, an authority investigates it, and repairs are arranged after the problem has already affected road users. We wanted to explore whether historical data could help authorities anticipate where to look first, rather than simply respond to the latest complaints.
That led us to RoadWatch, a predictive road-inspection system built around a simple question: can we use real-world data to decide which roads should be inspected first?
We focused on Brooklyn, New York, where publicly available street-condition reports, road-network data and historical weather observations provided an opportunity to investigate this problem using real evidence rather than a simulated dataset.
How we built it
We began by collecting historical pothole reports from NYC Open Data, matching them to Brooklyn street blocks using road geometry, coordinates and street-name information, and combining them with historical weather and road attributes. We built a reproducible Python pipeline to download, validate and store the data, with checks designed to detect incomplete downloads, unexpected schemas and missing observations.
Turning these records into a reliable prediction dataset was one of our biggest challenges. Many reports had no coordinates, while intersection reports could plausibly refer to several neighbouring blocks. We therefore developed explicit matching rules, tracked ambiguous assignments and treated periods with insufficient location information as unknown rather than incorrectly assuming that no report meant no problem.
We then constructed weekly features, including historical report frequency, recency, nearby reporting activity and static road characteristics. These were used to train and compare statistical and machine-learning models. Rather than relying on a random train-test split, we evaluated the system chronologically, with monthly retraining, so each historical prediction used information that would have been available at the time.
The selected LightGBM model uses historical reporting patterns and road attributes to rank blocks by their likelihood of receiving a pothole report in the following seven days. Weather features were tested, but they did not improve inspection-ranking performance sufficiently to justify including them in the selected model.
Finally, we built a decision engine and interactive dashboard. Users can select a historical forecast week, set an inspection capacity, explore ranked blocks and their supporting evidence, compare alternative prioritisation policies, and export an inspection worklist. The aim is to turn predictions into an actionable next step, not merely display a risk score.
What we learned
Backtesting showed that the model provides useful information beyond simply ranking roads by their historical reporting rates. On the held-out test period, the strict single-block LightGBM model achieved 9.5% precision at a 1% inspection capacity, compared with 6.6% for the historical-rate baseline. Under the fractional expected-report-capture definition, the model captured 13.5% of qualifying reports, compared with 8.4% for the baseline.
These results measure reported pothole activity, not confirmed physical defects. That distinction became one of the most important lessons of the project.
Our independent audit also uncovered how strongly the apparent value of an inspection policy depends on what counts as a captured report. A policy that avoids inspecting neighbouring blocks can appear better when any possible candidate location counts as a success, yet perform worse when ambiguous locations are treated fractionally. We changed how we presented these results rather than hiding the disagreement.
The March 2026 reporting surge taught us another lesson: a model can rank locations usefully while still failing to anticipate a sudden increase in overall reporting volume. Our separate volume forecast did not reliably outperform simple baselines, so we retained configurable inspection capacities instead of pretending that the forecast could determine the correct resource budget.
What comes next
RoadWatch is a historical evaluation and decision-support prototype, not a deployed municipal system. To establish whether it could improve real maintenance outcomes, we would need verified inspection results, more reliable historical data-publication timestamps, better evidence about location uncertainty, and measurements of inspection and repair costs.
With those additions, future versions could evaluate whether risk-based inspections find more confirmed defects per unit of effort and whether particular interventions actually prevent subsequent problems.
Building RoadWatch taught us that useful prediction is not just about choosing an algorithm. It requires understanding how data was collected, testing assumptions, measuring performance against simple alternatives, and being honest about uncertainty. Most importantly, a prediction becomes valuable when it helps someone make a better-informed decision.
