Know the Conditions at the Incident, Not Just That There Is One

“Crash on I-80, right lane blocked.”

That sentence describes two completely different events. In one, it’s a dry afternoon, the lane clears in twenty minutes, and the right call is to hold the load and wait. In the other, the pavement is iced, visibility is down to a quarter mile, and the wind is gusting across an exposed grade — in which case the crash you can see is the least interesting fact on the screen, because the conditions that produced it are still there, and they are about to produce another one three miles up.

Every incident feed on the market gives you the first sentence. Almost none of them tell you which of the two events it actually is. Dispatch doesn’t respond to incidents. Dispatch responds to incidents in context — and the context has to arrive attached to the incident, at the moment it appears, or it arrives too late to change the decision.

The Context Already Exists, Sitting in a Different Feed

State DOTs have spent decades installing roadside weather stations — RWIS, in the trade — the instrumented poles that report air temperature, wind, visibility, humidity, precipitation type, and, critically, what the road surface itself is doing. Dry. Wet. Ice. Snow-covered.

Road511 currently normalizes 4,641 roadside weather stations across 32 states and provinces, alongside 9,887 road-condition segments across 21 — the latter being the DOT’s own segment-level assessment of a stretch of road, as opposed to a single station’s point reading.

The data is public, official, and already flowing. The problem is that it lives in a different layer from the incidents, on a different schema, keyed to different geometry. So the dispatcher gets an incident in one panel and a weather map in another, and does the spatial join in their head, under time pressure, at 3am. That join is the product.

Every Event Carries Its Own Weather

When a new incident lands in Road511 — a crash, a closure, a work zone — we immediately look for the nearest active weather station within 50 km and write down what it was reporting at that moment. That reading is stapled to the event, permanently. Here is a January crash on I-68, on the long grade over Big Savage Mountain in western Maryland:

GET /api/v1/analytics/event-weather/MD-crash-i68-mp42

{
  "event_id": "MD-crash-i68-mp42",
  "distance_km": 3.2,
  "temperature": 28.4,
  "temperature_c": -2.0,
  "wind_speed": 31.0,
  "wind_direction": "NW",
  "visibility": 0.4,
  "precipitation": "snow",
  "road_surface": "ice",
  "humidity": 91.0,
  "reading_recorded_at": "2026-01-14T09:12:00Z",
  "created_at": "2026-01-14T09:14:22Z"
}

Read that as a dispatcher rather than as a developer. A crash, on ice, in falling snow, at −2 °C, with visibility under half a mile and a 31 mph crosswind, reported by a station two miles away. Nothing in the incident text said any of that. The decision it supports — reroute the following three loads now, don’t just delay them — is not the decision you’d make from “right lane blocked.”

The distance_km field is doing real work there, and it’s the reason we return it. A station 3.2 km from the incident is describing the incident. A station 46 km away is describing a different valley, and you should discount it accordingly. We don’t hide that number behind a confidence score we made up — we give you the distance and let you decide what it’s worth.

From Anecdote to a Number You Can Argue With

“Bad weather causes accidents” is a thing everyone knows and nobody can put a figure on. Once every event carries a snapshot, the figure is a query. Group the incident history by what the road was doing and what was falling out of the sky:

GET /api/v1/analytics/weather-correlation?
  jurisdiction=WY&
  from=2025-11-01&to=2026-03-31

[
  {
    "precipitation": "snow",
    "road_surface": "ice",
    "event_count": 412,
    "avg_severity": 2.81,
    "avg_temp_c": -6.2,
    "avg_visibility": 0.6
  },
  {
    "precipitation": "rain",
    "road_surface": "wet",
    "event_count": 297,
    "avg_severity": 1.94,
    "avg_temp_c": 7.5,
    "avg_visibility": 3.8
  },
  {
    "precipitation": "none",
    "road_surface": "dry",
    "event_count": 1183,
    "avg_severity": 1.42,
    "avg_temp_c": 14.8,
    "avg_visibility": 8.9
  }
]

Dry pavement produces the most incidents, because dry pavement is most of the year — but the ones it produces are mild. Snow-on-ice produces a third as many at roughly twice the average severity. (avg_severity is a weighted score: critical counts 4, major 3, moderate 2, everything else 1.) That is the shape of a real operational argument: not “avoid winter,” but “an incident reported under these conditions is far likelier to be the kind that closes a road for hours, so treat it as one before it’s confirmed.”

Filter it by jurisdiction, by event type, by severity, or by date range, and you can answer the question your own lanes actually pose — which corridors punish ice, which ones shrug it off, and where the winter surcharge in your contract is earning its keep.

On the Route

Weather stations also ride the corridor. Send a route to POST /routing/route and the stations near the line come back in warnings[] as type: "weather", each carrying its readings and the time the truck is projected to reach it — the same channel that already carries bridge clearances and corridor hazards.

Be clear about what that is and isn’t. Those weather markers are surfaced at info severity, as observations. Road511 does not currently threshold them — there is no rule that escalates “road_surface: ice” to a warning, no wind-speed limit that trips a flag for a high-profile trailer. The reading is handed to you; the policy is yours, because the policy is genuinely yours: the wind speed that stops a loaded reefer is not the one that stops a flatbed, and we’d rather give you the number than guess your fleet’s tolerance.

And the segment-level road_conditions layer — the DOT’s own “this stretch is snow-covered” assessment — is not enriched onto routes today. It’s queryable as a layer over any bounding box or corridor you define, but it does not currently arrive attached to a route response. If route-level surface state is what you need, that’s a gap, and we’d rather tell you now than have you discover it in integration.

What You Can Build With It

• Triage that reads the conditions, not just the headline — auto-escalate an incident whose snapshot shows ice and sub-mile visibility, before a human has read the description.
• Winter corridor scorecards — rank your lanes by the severity they produce under the same conditions, and price or schedule accordingly.
• Post-incident review that isn’t guesswork — when a load is late or a claim is filed, the conditions at the event are already recorded, timestamped, and attributable to a named agency’s station.
• Driver-facing condition alerts — surface the observations along the route with your own thresholds applied, tuned to the trailer.
• Weather beside everything else on the corridor — conditions alongside work zones, planned construction, and closures in one schema.

Provenance, and the Honest Limits

These readings come from state DOT roadside stations — official instruments, not a modelled forecast and not crowd-sourced. That’s the strength, and it dictates the limits, which are worth stating plainly.

The snapshot is taken once, at the moment the event is created, and never refreshed. It answers “what were the conditions when this appeared,” which is the question that matters for triage and for later analysis. It does not track how the weather evolved over the life of a six-hour closure. For current conditions, query the station directly — /analytics/weather returns its reading time-series.

If no active station sits within 50 km, the event gets no snapshot at all. We do not reach further and pretend a reading from the next county describes this stretch of road. On a rural corridor, expect gaps; a missing snapshot is an honest absence, not a zero.

Readings pass through in the units the reporting agency publishes. Most US stations report Fahrenheit, miles, and miles per hour — but not all of them: British Columbia and, of all places, California publish Celsius. So temperature is the agency’s own number, and temperature_c sits beside it, normalized, for when you need to compare or average across jurisdictions. Where we haven’t established a feed’s unit, temperature_c is simply absent rather than guessed — and the correlation endpoint leaves those readings out of its average instead of blending them in. Wind and visibility are not normalized; compare them within one jurisdiction.

This is observation, not prediction. There is no weather forecasting here, and we’re not going to bolt a forecast model onto a road-data API and call it dispatch intelligence. What we do is guarantee that when an incident exists, the measured conditions at that incident exist next to it, in one schema, from 4,641 stations we keep parsed and current as their feeds drift — so that job isn’t yours.

Weather snapshots, the correlation endpoint, and the reading time-series are analytics-tier features (Pro and above). The underlying weather_stations and road_conditions layers are available on every plan, free trial included.

Try It

• API docs — the analytics surface, plus the weather_stations and road_conditions feature types
• Live map — see the station network and current road conditions
• Free API key — no credit card, 14-day trial