Road Risk Monitor: A Deployable U.S. Road Incident Forecasting System with Live Weather and Road-Level Tiles

This paper introduces Road Risk Monitor, a deployable U.S. road-safety system that integrates historical crash data, live weather, and road geometry to generate nationwide incident forecasts served via live APIs, raster tiles, and a public web application.

The Gist

Imagine you want to build a system that predicts where car accidents are likely to happen across the entire United States. Most people would think the hardest part is building a "smart brain" (a machine learning model) to guess the future.

This paper argues that the real challenge isn't the brain; it's building the entire body that the brain lives in. It's like saying, "It's not enough to have a great engine; you need the chassis, the wheels, the fuel lines, and the driver's seat to make a car that actually drives."

Here is the "Road Risk Monitor" system, explained simply:

1. The Two-Layered Map (The "Brain" and the "Skin")

The system uses two different layers to look at the roads, kind of like looking at a map with a wide-angle lens and then a magnifying glass.

• Layer 1: The Big Picture (The H3 Baseline)
  Think of the US as a giant grid of honeycomb cells. This layer looks at the whole country and asks, "Based on history and typical weather, how dangerous is this general area right now?" It uses data on past fatal crashes and long-term weather patterns. It's a "safety blanket" that covers the whole country, ensuring there's always a prediction even if we don't have specific details for every single street.

  • The Result: It's very good at spotting general danger zones (scoring about 89% accuracy on a test year).

• Layer 2: The Street Level (The Road Segment Model)
  This layer zooms in. It takes the actual lines of the roads and chops them into tiny, manageable pieces (segments). It then asks, "Is this specific stretch of road dangerous right now?" It combines the road's shape with live weather (like rain or wind) to make a prediction for the next 24 hours.

  • The Result: The paper notes this layer got a "perfect" score on its internal test, but the authors are honest: that's because they tested it on the same data it learned from. It's a great diagnostic tool, but the real test is how it handles the messy real world.

2. The "Kitchen" vs. The "Restaurant"

The authors make a crucial distinction between training (cooking the meal in the kitchen) and serving (getting the food to the customer).

• The Kitchen (Offline): This is where they take raw data—like old police reports (FARS), weather logs, and road maps—and clean it up, chop it, and feed it to the computer models.
• The Restaurant (Online): This is the live system. It takes the "cooked" models and connects them to live weather feeds (like the National Weather Service). It then serves up predictions in a way people can actually use:
  • For Computers: APIs that other apps can talk to.
  • For Humans: A website with a map that shows colored tiles (like a heat map) updating every hour to show where the risk is highest.

3. The "Instruction Manual" (Reproducibility)

Usually, scientists publish a paper with a cool result and a few lines of code that are hard to run. This paper is different.

The authors published the entire instruction manual (the code repository). They didn't just say, "We built a car." They said, "Here is the blueprint, here is the list of parts, and here is the script to build the car yourself."

They proved this by running their own "rebuild" from scratch:

• They downloaded millions of data points.
• They cleaned up 322,000 crash records.
• They mapped over 4 million road segments.
• They generated the final "service bundle" that can be turned on and used immediately.

4. Why This Matters

The main point of the paper isn't just that they built a model that predicts accidents. It's that they built a complete, working system that goes from raw data to a live, usable website.

• The Analogy: If other researchers built a "predictive engine," this team built the whole car, including the tires, the steering wheel, and the instruction manual on how to drive it.
• The Claim: The paper claims that for road safety, the "systems problem" (connecting all the parts) is just as important as the "modeling problem" (the math).

Summary

The "Road Risk Monitor" is a blueprint for a national road-safety service. It combines historical crash data with live weather to predict danger. It uses a "wide view" for the whole country and a "close-up view" for specific streets. Most importantly, the authors didn't just keep the code in a lab; they packaged it so anyone can download it, rebuild it, and run it as a live service today.

Technical Summary

Technical Summary: Road Risk Monitor

Problem Statement

The paper identifies nationwide road-incident forecasting as a systems problem that precedes the modeling problem. While predictive accuracy is important, a usable national service requires the integration of heterogeneous data sources (historical incidents, live weather, road geometry), temporal and geographical alignment, handling of missing live inputs, precomputation of visual artifacts, and the exposure of predictions through a consumable application surface. The authors argue that a convincing national road-safety artifact must be evaluated as a "train-to-serve" system rather than solely as an offline leaderboard entry.

Methodology

The Road Risk Monitor system is a dual-scale, end-to-end pipeline built from public datasets and deployed via a FastAPI application.

1. Data Sources and Integration

The system ingests and processes data from five primary sources:

• FARS (Fatal Analysis Reporting System): Provides fatal crash labels for the baseline model.
• NOAA ISD-Lite: Supplies historical hourly weather and representative-station climatology.
• TIGER/Line: Provides nationwide road geometry for segmentation.
• US-Accidents: Offers denser incident history for road-segment modeling.
• NWS API (National Weather Service): Serves as the default live forecast source, with fallbacks to OpenWeather, Tomorrow.io, and climatology.

2. Modeling Architecture

The system employs two linked prediction layers:

• Nationwide H3 Baseline:
  • Granularity: H3 resolution 5 cells (30,141 candidate cells).
  • Training: Uses cleaned FARS fatal-crash data mapped to cells, expanded via neighboring cells, and enriched with weather climatology from 149 representative stations.
  • Features: 16 features including location, cyclical time encodings, historical counts, and weather covariates (temperature, dewpoint, wind, etc.).
  • Role: Guarantees national coverage and a stable weekly overlay even when live road-level signals are unavailable.
• Road-Segment Forecasting:
  • Granularity: 4,074,810 road segments derived from TIGER/Line geometry.
  • Training: Matches US-Accidents events to segments using BallTree retrieval and exact point-to-polyline distance.
  • Features: 26 features including static geometry, road class, temporal/historical counts, and live weather.
  • Role: Provides fine spatial resolution and live-weather adaptation for a rolling 24-hour forecast.

3. Serving and Runtime

• Application Surface: A FastAPI application exposes 14 public paths, including machine-oriented endpoints (point risk scoring, segment queries, tile endpoints) and human-facing pages (interactive map, about, contact).
• Artifacts: The system generates raster tiles (PNG), JSON road tiles, and timeline summaries.
• Runtime Packaging: Includes a build_runtime_bundle.sh script to stage code, models, and tiles into a runnable tarball, and service_startup.py to codify startup behavior.

Key Results

The authors performed a local rebuild of the entire pipeline from the published repository to validate reproducibility and system integrity.

• Data Scale: The rebuild processed 322,268 cleaned FARS incidents, 4,074,810 road segments, and 5,976,955 matched segment events across 49 states.
• Matching Quality: The point-to-road matching for US-Accidents events showed a median distance of 2.7 meters and a 95th percentile of 542.3 meters.
• Baseline Performance: The H3 baseline model achieved 0.894 AUROC and 0.715 Average Precision on a held-out year (2024), trained on 2018–2023 data.
• Segment Performance: The road-segment model reported 0.9999 AUROC and 0.715 Average Precision on an internal same-pipeline holdout.
  • Note on Metrics: The authors explicitly treat the segment metric as an engineering diagnostic rather than a scientific claim. They caution that the near-perfect score likely reflects task formulation (persistent segment identities and historical counts) and ease of separation in the specific train/eval split, rather than broad deployment validity.

Significance and Contributions

The paper's primary contribution is not a single isolated classifier with state-of-the-art accuracy, but an integrated, reproducible, and deployable road-risk service blueprint.

1. Systems Completeness: The repository spans the entire path from public data ingestion to a locally deployable service, including offline pipelines, live weather adapters, tile generation, and runtime packaging.
2. Dual-Scale Design: It successfully combines a coarse, stable national baseline with a fine-grained, live-adaptive road-segment model.
3. Operational Readiness: By providing runtime packaging scripts, service-startup utilities, and tested public routes, the work moves beyond "notebooks and checkpoints" to a production-ready artifact.
4. Reproducibility: The entire system can be rebuilt from the published code, generating the processed data, model bundles, and tile artifacts used for evaluation, rather than relying on pre-versioned outputs.

The authors conclude that for applied road-risk machine learning, this systems completeness is the defining contribution, enabling the transition from theoretical modeling to a functional, train-to-serve national safety tool.