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 nine states and provinces into one future_construction feature type — 2,161 projects as of today, each with whatever schedule the agency published. Virginia’s upcoming-closures layer is the deepest (927 records), with Delaware’s project portal close behind (774), then New Jersey’s STIP project locations (247), West Virginia’s project records (162) and North Carolina’s future-closures feed (42), with Idaho, New Brunswick, Nevada, and Prince Edward Island contributing the rest. West Virginia also publishes planned work as events carrying status=planned — another shape, same question.

Treat that total as a reading, not a constant. Virginia’s layer is a rolling window that drops records once their dates pass: it stood at 2,176 in early July and 927 today, which is the feed working as designed rather than coverage being lost. Feeds also go quiet — Manitoba, Newfoundland, Nevada and Prince Edward Island are each returning nothing at the moment, so on any given day the number of jurisdictions actually publishing is smaller than the number we can parse. Query it rather than quoting it.

Nine 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-WZNO4585395-12252025-298",
      "source": "VA",
      "jurisdiction": "VA",
      "feature_type": "future_construction",
      "name": "On I-66W Express Lanes from mile marker 65 to mile marker 43",
      "road_name": "On I-66W Express Lanes from mile marker 65 to mile marker 43",
      "latitude": 38.886177,
      "longitude": -77.221801,
      "is_active": true,
      "estimated_start_time": "2026-08-12T02:00:00Z",
      "estimated_end_time": "2026-08-12T09:00:00Z",
      "last_updated": "2026-08-11T08:43:55Z"
    }
  ],
  "total": 801,
  "limit": 100,
  "offset": 0,
  "has_more": true
}

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 asks the same question of a wider pool — how far does an agency move the end dates it publishes? — so you can calibrate how much slack a given DOT’s published dates historically need. It rolls up event-modelled roadwork rather than the future_construction records above, and it reports only the jobs whose revisions we can still see, so read the two as complementary views of the same habit rather than one number. 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 nine states and provinces, not the whole map, because forward-looking schedules are the least consistently published data a DOT produces — and as noted above, on any given day fewer than nine are actually returning records. 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 nine 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

---

Originally published on road511.com.