Plan Around Next Month’s Closure, Not Today’s

Every traffic API on the market answers the same question: what is closed right now? That question is worth answering. It is also the wrong one for most of the decisions a planner actually makes. The oversize load ships in three weeks. The seasonal lane is being quoted for August. The construction crew is scheduling a detour route for a job that starts after Labor Day. Nobody planning that work cares what is coned off this morning — they care what will be dug up when the truck gets there, and a live incident feed structurally cannot tell them.

So the planner does the thing the tooling forces: opens six state DOT project pages in six browser tabs, reads six different PDF schedules, and writes the dates into a spreadsheet that is stale within a week. The data exists. It is published. It just isn’t queryable as data.

Planned Work Is a Different Dataset Than Active Work

It’s tempting to assume that future construction is just a work zone with a start date in the future, and that whatever feed carries today’s lane closures will carry next month’s too. It doesn’t, and the distinction matters operationally.

Active work zones — the ones we wrote about in work zones along a route — come from real-time feeds describing conditions that exist right now. They appear when the cones go out and disappear when the crew leaves. Their whole design assumes you are asking about the present.

Planned construction comes from somewhere else entirely: the agency’s project pipeline. A DOT’s capital program, its STIP project list, the “upcoming closures” page maintained by the district office. These records exist months before a single cone is placed, and they carry the thing planners need and live feeds lack — a projected start and end date. They also carry the property that makes them awkward to consume: those dates are estimates, and they move.

Where the Dates Come From

Road511 now normalizes planned-construction records from eight states and provinces into one future_construction feature type — 3,442 projects as of today, each with whatever schedule the agency published. Virginia’s upcoming-closures layer is the deepest by a wide margin (2,176 records), followed by Delaware’s project portal (764), New Jersey’s STIP project locations (247), and North Carolina’s future-closures feed (99), with Idaho, New Brunswick, Nevada, and Newfoundland contributing the rest. West Virginia publishes its planned work as events carrying status=planned rather than as a project record — another shape, same question.

Eight jurisdictions is not fifty, and we won’t pretend otherwise. But it’s the corridors where DOTs actually publish forward-looking schedules as machine-readable data, and each one arrives on its own schema, its own date format, and its own idea of what “start” means. Folding them into a single feature type with a single pair of timestamps is the work.

Asking the Question Directly

Once every project shares one schema, “what will be under construction on this corridor in August” stops being a spreadsheet exercise and becomes a query. The /features endpoint now takes four scheduled-window filters — starts_after, starts_before, ends_after, ends_before — each accepting an RFC3339 timestamp or a plain YYYY-MM-DD date.

Bound the window from both ends and you get overlap: every project whose scheduled dates intersect the period you care about, whether it starts inside the window, ends inside it, or spans straight through.

GET /api/v1/features?
  type=future_construction&
  jurisdiction=VA&
  starts_before=2026-09-01&
  ends_after=2026-08-01

{
  "data": [
    {
      "id": "VA-fcon-WZCE4646650-07062026-4",
      "source": "VA",
      "jurisdiction": "VA",
      "feature_type": "future_construction",
      "name": "the ramp to SOUTH,295,NORFOLK,ROCKY MOUNT,NC at MM 86 and at MM 85",
      "road_name": "I-95S",
      "latitude": 37.673611,
      "longitude": -77.448752,
      "is_active": true,
      "estimated_start_time": "2026-08-14T23:00:00Z",
      "estimated_end_time": "2026-08-17T11:00:00Z",
      "last_updated": "2026-07-09T11:18:26Z"
    }
  ],
  "total": 1,
  "limit": 100,
  "offset": 0,
  "has_more": false
}

That is the whole ask: one call, one corridor, one month, every project that will be in the way. Add bbox or lat/lng/radius_km to narrow it to the geography the load actually travels, or hit /features/geojson to drop the same result straight onto a map.

Two details worth knowing

The filters match on the planned dates where an agency publishes them and fall back to actual dates where it doesn’t — so a source that reports only a real start time stays queryable on the same parameters, and you don’t need to know which kind of source you’re talking to.

And a project with a known start but no published end is treated as open-ended: it matches ends_after, because a job with no end date certainly might still be running in August. It never matches ends_before, because nothing about it promises it will be finished. A record with no dates at all — a project the agency has announced but not scheduled — drops out of window queries entirely rather than quietly padding your results. Those two rules are the difference between a date filter you can plan against and one that lies to you at the edges.

The Dates Move. That’s the Interesting Part.

A planned start date is a forecast, and forecasts slip. Utility work runs long, a bridge job waits on steel, the whole thing gets pushed a season. Any planner who has been burned once knows not to treat estimated_start_time as gospel — and the useful response is not to distrust the data but to watch it change.

So we keep the history. Every time an agency revises a project’s projected start or end, the change is recorded — old value, new value, when we saw it — and it’s queryable:

GET /api/v1/analytics/feature-history?
  change_type=estimated_start_time_change

That turns a static schedule into a signal. A project that has been rescheduled four times is telling you something a single date field never could. At the jurisdiction level, /analytics/scorecard aggregates the same underlying record into construction overrun and reschedule averages, so you can calibrate how much slack a given DOT’s published dates historically need. Both live behind the analytics tier (Pro and up); the future_construction records themselves are available on every plan, free trial included.

What You Can Build With It

• Permit and oversize-load planning — check the corridor for the delivery week, not for today, and catch the lane restriction that lands between quote and haul.
• Seasonal lane and contract pricing — know which corridors carry scheduled disruption during the months you’re quoting, before the rate is locked.
• Detour design that doesn’t collide — route around a work zone without routing into the one starting next week two miles over.
• Schedule-drift monitoring — watch the projects on your key corridors and get told when the dates move, instead of rediscovering it on arrival.
• Planning views that pair with the present — planned construction beside live work zones, bridge clearances, and seasonal load limits in one schema, on one corridor.

Provenance, and the Honest Limits

These records come from the DOTs’ own project pipelines — official, attributed, and refreshed on our poll rather than transcribed by hand. The limits are real and worth stating plainly. Coverage is eight states and provinces, not the whole map, because forward-looking schedules are the least consistently published data a DOT produces. Every date is an estimate, published by the agency and subject to revision without notice; that is a property of construction, not of the feed, and the change log exists precisely because of it. Detail varies — some sources give a full project description and route, others give a name and a pair of dates. And a planned closure is a plan: it tells you what an agency currently intends, which is the best information that exists three weeks out, and still not a promise.

The job we take on is keeping eight project pipelines parsed, normalized, and current as they drift — so it isn’t yours. This is the same integration tax we described in the five road-data problems every NA fleet team hits, applied to the one dataset that lets you get ahead of the problem instead of reacting to it.

Try It

• API docs — the features surface, including future_construction and the scheduled-window filters
• Live map — see planned construction alongside live conditions
• Free API key — no credit card, 14-day trial