DEV Community: Roman Kotenko

"In Betrieb" Is Not "Free". Live Connector Status Across Five European Countries.

Roman Kotenko — Thu, 15 Oct 2026 15:10:53 +0000

Every European country now publishes where its public charge points are. That was the easy half, and the Alternative Fuels Infrastructure Regulation is the reason it happened: since April 2024 operators owe machine-readable data about publicly accessible recharging points, and the national access points duly carry it.

So a planner asks “is there a charger at the depot turn-off?” and gets a confident yes. Then the driver arrives and both connectors are occupied, and the answer was worthless — not wrong, worthless. It answered a question about concrete.

The Field That Looks Like an Answer and Isn’t

Germany is the cleanest illustration, because its registry is genuinely good. We hold 154,210 active German charging records, and 141,083 of them carry a status field. On 116,422 it reads In Betrieb.

That word means the station is registered and commissioned. It is a fact about paperwork and hardware, and it does not change when a van pulls up. Zero of those 116,422 In Betrieb records carry any availability field at all. A fleet system that reads status and colours the pin green has not made a small error — it has answered a different question and presented it as this one.

Germany did start publishing live state in mid-September — 0 stations on 10 September, 327 on 3 October, 3,424 on 15 October. But it does not arrive on the registry record. It arrives over the AFIR dynamic channel as a separate record, and 2,863 of those 3,424 sit within 30 metres of a registry record that still carries no state. The same charger can therefore appear twice: once saying In Betrieb, once saying whether the cable is free. We do not merge the two yet, so filter on availability_status rather than on the registry row.

The distinction matters because the two fields look interchangeable, and only one of them answers the driver’s question.

Where Live Status Actually Exists, and How Much of It

Measured in one transaction against production on 15 October 2026, 15:04 UTC: of 415,272 active charging records we serve across Europe, 121,988 carry a live availability status, and 121,956 of those carry it per connector rather than per site. That is 323,765 individual connectors whose state is published.

It is five countries, and they arrive over four national channels — Germany and Lithuania share the AFIR dynamic one:

Jurisdiction	Stations with live status	Channel
Netherlands	79,051	`nl_ocpi`
France	22,079	`fr_irve_dynamique`
Switzerland	13,755	`ch_oicp`
Lithuania	3,679	`afir_dynamic`
Germany	3,424	`afir_dynamic`

Read that table twice before building on it. Five countries out of the thirty-six we carry — 29.4% of our charging rows, not “Europe”, and the German line is 2.2% of the German records. Anyone selling you continental live charging coverage today is rounding up.

At that same moment the network read: 99,659 available, 10,251 full, 9,470 unknown, 2,608 out of service.

Those last two categories are the ones that get flattened by careless code. Unknown is not full, and out of service is neither — a charger that is broken will still be broken in twenty minutes, which is a different routing decision from one that is merely busy now. We keep the four states separate for exactly that reason.

Per Connector, Because a Station Is Not a Unit

A site with two connectors is not half-free or fully-free; it is one cable in use and one cable open, and those two facts have different owners, different power ratings and different timestamps. The array comes back as it is published — here one Dutch station as it read on 10 September:

curl -H "X-API-Key: $KEY" \
  "https://api.napspan.com/api/v1/features?type=ev_charging&jurisdiction=NLD"

{
  "id": "NLD-ev-ALL-NLLOC016859",
  "name": "NL, Van der Meerstraat 20, 3863 AG Nijkerk",
  "latitude": 52.21755,
  "longitude": 5.472011,
  "properties": {
    "network": "Allego",
    "ports": 2,
    "connector_type": "IEC_62196_T2",
    "availability_status": "available",
    "available_points": 1,
    "occupied_points": 1,
    "unavailable_points": 0,
    "reported_points": 2,
    "availability_source": "nl_ocpi",
    "availability_updated_at": "2026-09-10T15:28:24Z",
    "refill_points": [
      { "id": "NLALLEGO0134202", "state": "occupied",  "status": "CHARGING",  "updated_at": "2026-09-10T15:28:24Z" },
      { "id": "NLALLEGO0134201", "state": "available", "status": "AVAILABLE", "updated_at": "2026-09-09T14:26:19Z" }
    ]
  }
}

Look at the two updated_at stamps in that array. They are the same station, and they are a day apart. The connector someone is actively using reported twenty seconds ago; its neighbour last said anything the previous afternoon. That is not a defect in the feed and it is not one in our ingestion — a connector reports when its state changes, so a quiet cable is a stale cable. It is, however, exactly the sort of thing a dashboard will average into a single meaningless “last updated” if nobody looks.

Three Things to Know Before You Build on It

Freshness is uneven, and one country cannot be aged at all. Of the 121,988 live rows, 107,160 carry an availability_updated_at. Only 18,112 of those — 17% — are inside the last hour; 90,968 are inside 24 hours; and the oldest stamp in the set is from 14 October 2023, a three-year-old reading that is still, technically, a live status field. Set your own staleness threshold and enforce it. Switzerland’s 13,755 stations publish no timestamp whatsoever, so they cannot be aged by us or by you; treat them accordingly.

The per-connector status strings are not normalised, on purpose. Across 323,765 connectors the same state arrives in three casings — AVAILABLE 141,719, available 49,731, Available 15,156 — unknown arrives in three as well, occupied in two. We normalise the station-level availability_status into four values and pass the array through as the operator wrote it, because collapsing a vendor’s string is how you silently lose a state nobody anticipated. Case-fold before you compare.

This is a live reading, not a reservation. An available connector is available to whoever reaches it first. Nothing in AFIR, OCPI or any national feed holds a bay for your driver, and a charger that was free when the route was planned is a probability by the time the vehicle arrives, not a promise.

The Same Call as Everything Else on the Corridor

Charging state is not a separate product. It arrives in the same /features schema, under the same jurisdiction filters, as the live truck-parking occupancy that answers the parallel question for diesel fleets, the cross-border truck bans and VMS signs, and the vehicle-class toll costs for the same corridor. One key, one schema, one set of jurisdiction codes — ISO 3166-1 alpha-3, so NLD and FRA, never NL or FR.

The point of normalising four national channels into one field set is not tidiness. It is that nl_ocpi, fr_irve_dynamique, ch_oicp and afir_dynamic are four different documents with four different vocabularies, and a fleet that wants “is the connector free” should not have to learn all four to find out — nor to discover, the hard way, that another country answers a different question in a field with a similar name.

What This Does Not Do

It is not European coverage. Five countries carry live status; thirty-one do not. Germany, the largest registry we hold, carries it on 3,424 separate records — none of its 116,422 In Betrieb registry records has it.
It does not reserve anything. See above; this is worth repeating because it is the assumption that costs a driver an hour.
It does not tell you the price. Tariff data is a separate and much messier problem; the fuel side of it is covered in per-station fuel prices.
An absent availability field means unknown, never free. The 293,284 records without one are not empty car parks; they are stations whose operator publishes nothing about state.

Figures measured against production on 15 October 2026, 15:04 UTC, in a single transaction so they stay mutually consistent; the JSON example is one real record as it read on 10 September, when this article first ran. Charging availability moves by the minute — the counts above describe that moment, and the shape of the finding rather than the numbers is what will still be true next week.

Try It

API docs — /features with type=ev_charging, filtered by jurisdiction
Live map — the network as it stands right now
Free API key — no card, 14-day trial

Originally published on napspan.com.

The Truck's Actual Toll Bill, Returned With the Route

Roman Kotenko — Thu, 08 Oct 2026 13:30:00 +0000

The fastest route and the cheapest route are rarely the same line on the map. The difference is usually tolls — and a passenger car’s toll rate has almost nothing to do with what a 5-axle, 36-tonne, placarded tractor-trailer pays at the same plaza. If your dispatch math uses a car estimate and a fudge factor, the invoice is going to surprise you.

Road511’s routing endpoint returns the toll cost computed for the truck you’re actually moving. Opt in on a route request and you get back two things: a per-currency total for the whole trip, and a per-section breakdown naming each toll system and the fare that applies to your vehicle class.

Opt In With `include`

Toll pricing is opt-in, because computing it has an upstream cost — you only pay for it when you ask. Add "tolls" to the include array on POST /api/v1/routing/route:

curl -X POST "https://api.road511.com/api/v1/routing/route" \
  -H "X-API-Key: your_key" \
  -H "Content-Type: application/json" \
  -d '{
    "origin":      { "lat": 40.7128, "lng": -74.0060 },
    "destination": { "lat": 39.9526, "lng": -75.1652 },
    "currency": "USD",
    "truck": {
      "profile":  "tractor",
      "weight_t": 36.0,
      "height_m": 4.2,
      "axle_count": 5,
      "hazardous": ["flammable"]
    },
    "include": ["tolls"]
  }'

That’s New York City→Philadelphia for a 5-axle placarded tractor. The currency field (ISO 4217) controls what the fares are reported in; the truck profile you already send is what makes the price the truck’s price.

The Response

Two places carry toll data. The route summary gets a toll_costs array — one entry per distinct currency, because a single trip can cross systems billed in different currencies (think a US–Canada run mixing USD and CAD). Each route section gets a tolls array naming the systems charged on that stretch and the fares within them.

{
  "routes": [
    {
      "summary": {
        "distance_m": 153400,
        "duration_s": 7320,
        "toll_costs": [
          { "currency": "USD", "value": 38.75 }
        ]
      },
      "sections": [
        {
          "distance_m": 92100,
          "duration_s": 4080,
          "summary": "I-95 S via New Jersey Turnpike",
          "tolls": [
            {
              "system": "New Jersey Turnpike",
              "fares": [
                { "name": "Class 5 (5 axles)",
                  "price": { "currency": "USD", "value": 31.40 },
                  "payment_methods": ["transponder"],
                  "transponders": ["E-ZPass"],
                  "counted": true },
                { "name": "Class 5 (5 axles)",
                  "price": { "currency": "USD", "value": 39.25 },
                  "payment_methods": ["videoToll"] }
              ]
            }
          ]
        },
        {
          "distance_m": 61300,
          "duration_s": 3240,
          "summary": "Delaware River bridge crossing",
          "tolls": [
            {
              "system": "Delaware River Port Authority",
              "fares": [
                { "name": "5-axle truck",
                  "price": { "currency": "USD", "value": 7.35 },
                  "payment_methods": ["transponder"],
                  "transponders": ["E-ZPass"],
                  "counted": true }
              ]
            }
          ]
        }
      ],
      "geometry": { "type": "LineString", "coordinates": [ /* ... */ ] }
    }
  ],
  "route_id": "rt_a17f93c0"
}

The fares under one toll system are alternatives, not line items — don’t add them up. Each is the same charge under a different payment method (payment_methods: transponder, videoToll, …) or time window (applicable_times), and the driver pays exactly one of them. summary.toll_costs has already picked one fare per system — the transponder tariff where one exists, otherwise the cheapest payment group — and marks it counted: true. That total is the number you’d quote a customer or drop into a lane-cost model; the sections[].tolls[] detail is where you see which authority charges what, and what the same stretch costs without a transponder.

Priced for the Vehicle, Not a Sedan

This is the whole point. The fare you get back is keyed to the truck profile on the request — axle count, gross weight, height, and the hazmat flag all factor into the classification the toll engine prices against. A 5-axle combination doesn’t get a 2-axle rate; a heavy load doesn’t get a light-vehicle rate. The fares[].name echoes the class that was applied (e.g. “Class 5 (5 axles)”) so you can confirm the truck was rated the way you expected.

Routing Around Tolls

Sometimes the answer is to skip the toll road entirely. That’s a different field: put "toll_road" in the avoid array and the engine routes around toll facilities where it can. The avoidance applies to every route in the response, so on its own it only shows you the detour.

To see the trade-off, ask for it instead: add "toll_alternative" to include (it implies "tolls"). You get the fast tolled route as usual, plus a second, toll-free route on toll_alternative with its extra distance and time set against the toll dollars it saves — the decision made explicit instead of a guess.

{ "origin": { /* ... */ }, "destination": { /* ... */ },
  "truck": { /* ... */ },
  "include": ["toll_alternative"] }

It computes two routes, so it is billed as two routing calls. Full shape in the API docs.

What to Expect From the Data

A few honest notes so the numbers behave the way you expect:

Major corridors are well covered — Interstate turnpikes, major bridges and tunnels, express lanes, and Canadian facilities like the 407 ETR price reliably for trucks.
Coverage thins on the margins. Some secondary or rural toll facilities are known to the engine but may return a system name with no priced fare for a given vehicle class — treat a missing price as “not priced,” not “free.”
Send departure_time for an exact figure. Some tolls change by time of day. Without a departure time the engine can’t resolve which window applies, and the total is the worst case for the chosen payment method rather than an optimistic one.
It’s a planning estimate. Toll pricing is computed at request time for the route and vehicle class; it’s built for dispatch and quoting, not for reconciling a transponder statement to the cent.
No tolls, no array. A toll-free route, or a request that didn’t opt in, simply omits toll_costs and section tolls — the response shape stays stable.

One Call, the Whole Trip

Toll pricing rides the same POST /api/v1/routing/route as the corridor hazard warnings[] and the Hours-of-Service break planning. A single request can hand back a drivable truck route, the clearances and restrictions on it, where the driver must legally stop, and what the trip costs in tolls — the operational picture a dispatcher actually needs before the truck rolls. Routing is on every paid plan from Starter up, and the free 14-day trial includes it.

Try It

API docs — full request and response reference for POST /api/v1/routing/route
Truck routing with live hazard warnings — the corridor enrichment in the same call
Free API key — no credit card, 14-day trial

Originally published on road511.com.

The Stop Your Route Never Mentions: 126,002 At-Grade Crossings

Roman Kotenko — Tue, 29 Sep 2026 13:30:00 +0000

A placarded load does not get to treat a rail crossing as scenery. Under 49 CFR 392.10, a vehicle carrying placarded hazardous materials, a cargo tank — loaded or empty — or passengers must come to a full stop within 50 feet of the nearest rail, look and listen, and only then proceed. Not slow down. Stop.

The rule has an exception that decides everything: it applies to at-grade crossings. If the road goes over the track on a bridge, or under it, no stop is owed. So the operative question on a route is not “is there a crossing ahead” — it is which of the crossings ahead are at grade. That is a data question with a data answer, and most routing products do not carry the field at all.

What the Inventory Actually Says

Road511 normalizes the federal highway-rail grade crossing inventory into the same features schema as everything else. Measured against our North American production database on 20 August 2026:

Reading	Count	What it means for a placarded load
Public crossings carried	162,284	Across 50 states; the inventory we serve is public crossings only
… of which at grade	126,002	A stop is owed at each one
… grade separated (road over or under)	36,282	No stop owed — and no reason to slow a schedule for one
Carrying a warning-device code	129,610	What physically protects the crossing
Carrying no device code at all	32,674	The inventory does not say — treat as unknown, never as “none”
With a whistle ban in force	5,047	A quiet zone: the horn you would have heard is not coming
With an emergency contact number	155,510	The number to call when a vehicle is stopped on the tracks

Roughly one crossing in five carries no device code, and among the 129,610 that do, 58,355 — 45% — are passive-only: crossbucks, a stop sign, or nothing that moves. Passive is not a defect in the data; it is the condition of the crossing, and it is exactly the condition where the driver’s stop is the last control in the system.

On the Route

Crossings ride the same single call to POST /api/v1/routing/route that returns the truck-aware route and its corridor warnings. What the route returns depends on what you are hauling:

With hazardous set on the truck profile, every public at-grade crossing on the corridor comes back as a critical warning citing 49 CFR 392.10. Every one — not a filtered selection, because the rule is not selective.
Without it, the noise would be intolerable, so only crossings that are operationally interesting surface: those the inventory reports at 20 or more trains a day (20,840 of them nationally), plus any a source reports as humped, where a low trailer can ground out on the crest.

A dispatcher planning a placarded run gets a count of mandatory stops before the truck leaves — which is a schedule input, not a safety poster. Twenty stops on a lane is roughly twenty times a full deceleration and re-acceleration for a 36-tonne combination, and it is the difference between an ETA that holds and one that does not.

Query It Directly

The same records are on /features, filterable by jurisdiction and bounding box:

GET /api/v1/features?type=rail_crossings&jurisdiction=IN&limit=5

Each record carries the USDOT crossing number, the railroad, the road name, the grade position, the warning device, day and night through-train counts, track counts, the highway AADT the inventory holds, the maximum timetable speed for the track, and where published, the emergency contact number posted at the crossing.

What This Data Is Not

Four limits, stated plainly, because a compliance feature that oversells itself is worse than none:

It does not know whether a train is coming. Train counts are inventory averages — how much traffic the crossing normally sees, not a live movement. Nothing in this feed is a real-time train position, and no product should imply one.
It is an inventory, not a sensor. Records are maintained by railroads and state agencies and change on their schedule, not by the minute. Treat the device, track and traffic figures as the last thing the agencies published.
Private crossings are out. We carry public crossings; the industrial and agricultural ones are excluded, so a facility approach road may hold a crossing this data does not describe.
An absent field is unknown, never zero. The 32,674 crossings without a device code are not 32,674 unprotected crossings. If your UI colours them, colour them grey.

The stop itself is also not ours to grant or excuse: 392.10 carries its own exceptions — a streetcar crossing, an industrial switching track, a crossing directed by a flagman or a police officer, one protected by a functioning gate or signal showing clear. The data tells you the crossing is at grade and what protects it. The driver, and the carrier’s policy, decide the rest.

Provenance

The crossing inventory is the federal highway-rail grade crossing inventory published by the US Department of Transportation, in the public domain. Coordinates and road names come with it. Everything above is a count you can reproduce against the live API.

Try It

API docs — features, routing, and the GeoJSON variants in one reference.
Live map — crossings alongside the rest of the normalized 511 data.
Free API key — 14-day trial, no credit card.

Originally published on road511.com.

The Dates DOTs Publish Aren't the Dates They Hit

Roman Kotenko — Thu, 17 Sep 2026 12:28:32 +0000

You did the responsible thing. Before quoting the haul you checked the corridor, found the ramp closure scheduled to start August 3, and planned around it. Three weeks later the truck arrives and the ramp is open — the job was pushed to August 24. Nobody lied to you. The DOT revised its own estimate eleven days ago, published the revision, and your copy of the date was simply the one you took a snapshot of.

This is the failure mode that survives even after you solve the hard part. Getting forward-looking schedules into one queryable schema answers what is planned. It does not tell you how much that plan is worth — and a start date with no track record behind it is a number, not information.

A Date Field Is a Snapshot. You Need the Record.

Every planned-construction record we carry has an estimated_start_time and an estimated_end_time. Read them today and you get the agency’s current intent. Read them tomorrow and you may get a different answer, with nothing in the payload to tell you it changed, how far it moved, or whether this is the fourth time.

So we keep the change log. Every time a source republishes a project with a different projected start or end, we record the old value, the new value, and when we saw it. That log is a first-class, queryable dataset — not an internal audit trail — and it converts a static date into something with a history you can weigh.

Eleven Weeks of Watching Dates Move

Here is what the log actually holds as of 17 September 2026, on live North American data — not an illustration. These are readings, not constants: run the queries yourself and you will get today’s numbers, which is the point of the thing being an endpoint.

Across the 2,269 active planned-construction projects we carry (Virginia 910, Delaware 775, West Virginia 257, New Jersey 247, North Carolina 77, and three in New Brunswick), we have recorded 21,289 date revisions in the window running 3 July to 17 September 2026 — 12,307 revisions to a projected start, 8,982 to a projected end. Those revisions land on 4,414 distinct projects, 289 of which are still on the board right now.

The single most useful thing in that pile is the direction. Of the 21,289 revisions, 21,128 moved a date later and 161 moved one earlier. Schedule drift is not noise scattered around a central estimate; it is a one-way ratchet. A published date is, in practice, a floor.

The size of the moves is where planning slack actually comes from:

How far a projected start moved, per revision	Revisions
Exactly one week	3,438
More than a week	2,752
Two to six days	2,376
Under a day (or pulled earlier)	2,147
Exactly one day	1,594

The median revision moves a start seven days; the average is 5.8, pulled down by the sub-day nudges and the handful of moves that went the other way. The largest single revision we have on record pushed a ramp closure on I-81S at mile marker 291.2 from July 15 to September 14 — 61 days in one edit, published on 13 September. And 1,657 separate projects have taken at least one start revision larger than a week.

None of that is knowable from a date field. All of it is knowable from the log.

Querying It

The change log is one endpoint. Filter it by what changed, on what kind of feature, over what window:

GET /api/v1/analytics/feature-history?
  feature_type=future_construction&
  change_type=estimated_start_time_change&
  limit=2

{
  "data": [
    {
      "id": 174240967,
      "feature_id": "VA-fcon-WZSW4664041-08182026-3",
      "source": "VA",
      "feature_type": "future_construction",
      "change_type": "estimated_start_time_change",
      "changed_field": "estimated_start_time",
      "old_value": "2026-09-15T10:30:00Z",
      "new_value": "2026-09-18T10:30:00Z",
      "recorded_at": "2026-09-17T11:26:47.870007Z"
    },
    {
      "id": 174240964,
      "feature_id": "VA-fcon-WZSW4638782-06152026-5",
      "source": "VA",
      "feature_type": "future_construction",
      "change_type": "estimated_start_time_change",
      "changed_field": "estimated_start_time",
      "old_value": "2026-09-11T11:00:00Z",
      "new_value": "2026-09-18T11:00:00Z",
      "recorded_at": "2026-09-17T11:26:47.870007Z"
    }
  ],
  "total": 12307,
  "limit": 2,
  "offset": 0,
  "has_more": true
}

Swap change_type for estimated_end_time_change to watch completion dates instead, add feature_id to pull the full history of one project you care about, or bound it with from and to and poll for what moved since your last run. The same endpoint carries created, deactivated and reactivated entries, so a project quietly dropped from an agency’s feed shows up as an event too, rather than just vanishing from your result set.

Entries are newest-first. The change log is analytics-tier (Pro and up); the future_construction records themselves are on every plan, free trial included.

Two Things Look Identical and Mean Opposite Things

This is the part worth internalizing before you wire an alert, because the naive version of this monitor will page you every night.

The most-revised project in our data is VA-fcon-WZNO4585395-12252025-137 — work on the I-66E Express Lanes between mile markers 43 and 65. Between July 3 and September 16 its dates were revised 118 times (59 starts and 59 ends, in lockstep). That sounds like a project in freefall. It isn’t. Read the log and the pattern is unmistakable:

estimated_start_time  2026-07-02T13:00Z → 2026-07-03T13:00Z
estimated_start_time  2026-07-03T13:00Z → 2026-07-04T13:00Z
estimated_start_time  2026-07-04T13:00Z → 2026-07-05T13:00Z
estimated_start_time  2026-07-05T13:00Z → 2026-07-06T13:00Z
                              ... every night ...

Same eight-hour window, rolled forward by exactly one day, every day. That is not a job slipping — it is a recurring daily closure published as a single record whose window always points at the next occurrence. (The one break in the rhythm is instructive too: on July 11 the record went inactive, came back July 12, and jumped three days instead of one. It skipped the weekend.)

Now contrast a genuine slip. 810 Virginia projects took between three and five start revisions that add up to a net move of more than two weeks — distinct edits, days apart, each one pushing a real start date further out. The worst of them moved 75 days across four edits between 21 July and 14 September. Same endpoint, same change_type, completely different operational meaning.

The rule that separates them is simple and worth building into whatever you wire on top: a stream of uniform one-day moves is a schedule shape; a few irregular multi-day moves is a schedule failing. The 1,594 exactly-one-day start revisions in the table above are mostly the former. The 2,752 start revisions over a week are the ones that should reach a human.

What This Is Worth Downstream

Pad the quote with evidence, not superstition. If the corridor’s projects historically move seven days later and roughly one start revision in five moves more than a week, that is a number you can put in a bid instead of a gut feeling.
Watch the jobs on your lanes. Poll feature-history with from set to your last check and get told when a date on a corridor you run has moved — before the truck finds out.
Re-check permits that were issued against a moved date. An oversize permit written around an August closure window is worth revalidating when the closure walks into September.
Rank your sources honestly. A project revised once and executed is a different planning risk from one revised six times, and the log is the only place that difference exists.
Filter the noise out of your own alerts. Rolling nightly windows are a real slice of raw revisions but not the bulk of them — moves of exactly 24 hours are 1,568 of the 12,307 start revisions, about one in eight. Knowing which slice you are looking at up front is the difference between a useful monitor and one everybody mutes.

The Honest Limits

Four of them, and they matter more than the headline numbers.

Today this signal is Virginia. All 21,289 revisions in the window come from VDOT’s feed — every last one. Delaware, New Jersey, West Virginia, North Carolina and the rest published zero date revisions over the same eleven weeks — not because their projects run on time, but because those feeds don’t republish a revised date on the same record; a changed plan tends to arrive as a new record instead. We would rather say that plainly than average six jurisdictions together and imply a continental drift statistic we cannot support. As more sources start revising in place, the same query picks them up with no change on your side.

The window is eleven weeks, not six years. The change log’s oldest entry of any kind is May 20, 2026, but construction date revisions only start on July 3 — that is the baseline behind every number above, and quoting the earlier date would overstate it. These are real observations over a short window — enough to characterize how dates move, not enough to claim a seasonal or multi-year pattern. It deepens every day.

We record what the agency published, not why. A revision tells you the date moved and when we saw it move. Whether that was weather, utilities, a contractor, or a clerical fix is not in any feed we consume, and we won’t invent a reason field to make the data look richer than it is.

An estimate remains an estimate. The point of the log is not to replace the DOT’s forecast with ours. It is to tell you how much that forecast has moved so far, which is the only honest input to how much slack you should carry.

The Same Mechanism, Beyond Construction

Schedule drift isn’t unique to roadwork — it is a property of anything published with an expected end. The same log carries 25,107 revisions to the projected end of weather alerts across 12,281 alerts, which is what a warning being extended hour by hour looks like when you record it instead of overwriting it. Any time-bounded feature type we carry — alerts, special events, seasonal restrictions — leaves the same trail, reachable with the same feature_type filter.

That is the general shape of the thing: not a new dataset, but the refusal to throw away the previous value. Most of the road-data problems we write about in the five road-data problems every NA fleet team hits come down to a feed telling you only about now. Keeping the record is what makes a plan auditable.

Try It

API docs — /analytics/feature-history, plus the future_construction surface and its scheduled-window filters
Planned construction, end to end — how the projects themselves are queried
Free API key — no credit card, 14-day trial

Originally published on road511.com.

What a Large-Vehicle Router Cannot Know

Roman Kotenko — Tue, 15 Sep 2026 09:56:20 +0000

Google Maps Platform took Large Vehicle Routing to GA last month — height, weight, length, width, axle count and hazmat class in the Routes API, US-wide. If you have ever had to explain to a dispatcher why a consumer routing API sent a 13'6" trailer under an 11'9" bridge, this is good news, and it makes truck-legal routing a commodity. Everyone will have it.

So here is the part that does not become a commodity.

A router avoids a low bridge because somebody published a height for it. That is the whole mechanism. And the layer underneath is much thinner and much messier than a rendered map suggests.

I aggregate US and Canadian DOT feeds for a living. On the morning of 15 September 2026 our store held 715,434 active bridge-clearance records from 53 state and provincial sources. Of those, 105,479 — 14.7% — carry a vertical clearance value at all.

The other 85% are not corrupt. They are federal NBI structural inventory: structure_number, deck_area_sqm, year_built, last_inspection_date, scour_critical. The registry knows the bridge exists and when it was last inspected. It was never designed to record what fits underneath.

Twenty-seven names for one measurement

Where a height does exist, it arrives under 27 different property names across those sources. There are 30 clearance-related keys in all; three of them are horizontal clearances, a different measurement that must not be pooled in.

key	rows
`clearance_m`	92,473
`clearance_ft`	91,964
`deck_clearance_ft` / `deck_clearance_m`	10,908 each
`vertical_clearance_m`	5,307
`vertical_clearance_under_ft`	3,850
`vertical_clearance_ft`	2,516
`vertical_clearance_label`	2,127
`lane_1_clearance` … `lane_9_clearance`	1,881 – 2,050 each
`posted_height`	2,038
`posted_clearance_ft` / `posted_clearance_in`	645 each
`left_` / `center_` / `right_clearance_in`	645 each
`vertical_clearance_raw`	509
`vertical_clearance_on_ft` / `_over_ft` / `_deck_ft`	30 – 243 each

Normalizing names is tedious but mechanical. This is the one that is not — a real record, unedited:

{ "clearance_m": 4.45, "clearance_ft": "14.6" }

One measurement, one object, two JSON types. The metric value is a number; the imperial value of the same physical distance is a string. Across the store that split is total and consistent: every one of the 92,473 rows with clearance_m has it as a number, and every one of the 91,964 rows with clearance_ft has it as a string.

That is the kind of thing that passes a schema check, passes a null check, passes a range check, and then silently fails a comparison in a language where 4.45 < 4.6 and "14.6" < "4.6" are both true and mean different things. If your clearance test is one careless comparison away from that, it will be correct in staging for months.

It is not just clearances

Same shape, every layer a truck actually cares about — active rows and distinct jurisdictions, same snapshot:

layer	rows	jurisdictions
truck restrictions	1,477,809	63
bridge clearances	715,434	53
rail crossings	162,284	50
weight restrictions	22,498	7
weigh stations	975	46
tunnel clearances	580	45

Posted weight restrictions: seven jurisdictions. Not seven that have weight limits — seven that publish them in a feed anyone can consume, and that is our ingestion coverage rather than a census of the law. Spring load restrictions apply across most of the northern half of the continent; they are machine-readable in a handful of places.

The point

The ceiling on any large-vehicle router — Google's, HERE's, mine — is publisher coverage, not routing quality. The routing converges. The data does not, and it is the part that decides whether a legal-looking route is actually legal.

If you are building on top of one of these APIs, the useful design question is what your system does with an absence. A blank is a legitimate answer and it should reach the driver as a blank. The failure mode is interpolating one — filling a missing clearance from a neighbouring structure, or defaulting a missing weight limit to "no limit". We leave it empty. A blank is a blank.

(I build Road511, a road-data API over US and Canadian 511 systems. The counts above are our own normalized store; the underlying feeds are public agency data, and the numbers move — these were pulled on the morning of 15 September 2026.)

Originally published on road511.com.

561/2006 Tells You When to Stop. It Doesn't Tell You If the Bay Is Free.

Roman Kotenko — Thu, 10 Sep 2026 13:18:40 +0000

Regulation (EC) 561/2006 is arithmetic. Four and a half hours of driving, then a 45-minute break. Nine hours a day, eleven twice a week, a daily rest of at least eleven hours. Every planning tool worth the name can compute where the clock runs out, and ours does it too.

The regulation says nothing about whether there is anywhere to put the truck.

That is the part dispatchers actually lose sleep over, because the failure mode is not a fine — it is a driver at 21:30 standing in the entrance of a full lorry park, choosing between the hard shoulder and driving on illegally. And it is a genuinely hard problem to plan around, because the map is misleading in a very specific way: the lot does not disappear when it fills up. Every static inventory keeps showing it, at full size, all night.

“Is There a Lorry Park?” Is the Wrong Question

Take Austria, where we have bay-level truth to check the map against.

The static inventory says the ASFINAG motorway and expressway network carries 244 truck-parking sites with 9,185 truck bays. That is the number a coverage map shows, and it is correct. It is also useless after dark, because it describes the concrete, not the availability.

Of those, 85 sites — 5,835 truck bays — publish live occupancy, which we poll every 60 seconds. We have been recording every change for those sites since 30 June 2026: 293,334 observations as of 10 September 2026, of which 127,387 fall inside the trailing thirty days the trend endpoint reads. Bucketing that history by hour of day produces the curve that the static map cannot show you — measured here over the thirty days to 10 September 2026:

Local time (Austria, CEST)	Truck bays occupied	Avg. free bays per site
08:00 – 14:00	~39%	~41
17:00	52.4%	31.9
19:00	68.4%	21.2
21:00	76.6%	15.7
21:00 – 04:00 (plateau; peak 77.0% at 01:00)	~76–77%	~16
00:00 – 04:00	~75–77%	~16

Network-wide occupancy doubles between late morning and nightfall — 38.4% at 11:00 local, 76.6% at 21:00 — and then holds on that plateau until about four in the morning, peaking at 77.0% around 01:00, before it falls away to 57.5% by six. Read as a fleet average, that still sounds survivable: 77% occupied means 23% free, and 16 open bays per site is not nothing.

One arithmetic note, because getting it wrong moves that column by twenty points. Those percentages are truck bays occupied, computed against each site’s truck_spaces. Divide the same free-bay counts by each site’s total capacity instead and the network reads 68–88% occupied all day, which is not a busier network — it is a numerator and a denominator that count different things. 84 of the 85 reporting Austrian sites are mixed sites where the two differ.

That average is the trap. Occupancy does not distribute itself politely across the network; it concentrates, and individual lots go hard to zero:

40 of the 86 sites observed in the thirty-day window hit zero free bays at some point.
At 23:00 local, 22 of the 85 sites observed in that hour had been completely full at least once during the window — at 21:00, 33 of them had, and at 07:00, three. Eight lots record a zero in every single hour from 18:00 to 23:00.
Take one ordinary lot — Wiener Neustadt, 40 truck bays. Average free bays at 07:00 local: 22.0. At 20:00 local: 5.7. Every hourly bucket from 18:00 to 23:00 local has a recorded minimum of 0.

Wiener Neustadt is not an exceptional site. It is a normal one, and for the entire second half of the evening its honest answer to “can my driver stop here?” is probably not, and you should have known that at dispatch.

Meanwhile the same network at 14:47 local on 10 September looked almost relaxed: zero of 85 sites full, and exactly one lot down to its last two bays. Arnoldstein at the Italian border was sitting at 8% occupancy with 366 of its 402 truck bays open. Both pictures are true. They are six hours apart. A number that is right in the afternoon and wrong at bedtime has to be read live, or it is not worth reading.

Live Occupancy, in the Same `/features` Call as Everything Else

ASFINAG publishes this as two DATEX II documents: a static ParkingTablePublication describing the sites, and a dynamic ParkingStatusPublication carrying free-space counts. Neither is usable alone — the status document has no geometry, and the table has no occupancy. We join them on parkingRecordReference and publish one feature per site with the live counts folded in:

curl -H "X-API-Key: $KEY" \
  "https://api.napspan.com/api/v1/features?type=truck_parking&jurisdiction=AUT"

{
  "data": [
    {
      "id": "AUT-tp-PARK000064",
      "source": "AUT",
      "jurisdiction": "AUT",
      "feature_type": "truck_parking",
      "name": "Arnoldstein Zollamt",
      "latitude": 46.540813,
      "longitude": 13.670096,
      "is_active": true,
      "properties": {
        "truck_parking": true,
        "capacity": 431,
        "truck_spaces": 402,
        "available_spots": 366,
        "occupied_spots": 36,
        "occupancy_pct": 8,
        "occupancy_status": "spacesAvailable",
        "opening_status": "open",
        "occupancy_updated": "2026-09-10T12:33:34Z"
      },
      "last_updated": "2026-09-10T12:36:35Z"
    }
  ]
}

Three details in that payload matter more than they look:

truck_spaces is the denominator, not capacity. Arnoldstein has 431 spaces of which 402 take a lorry, and available_spots counts truck bays only. Divide by capacity and you will quietly under-report how full the truck side is at every mixed site on the network — and that is 84 of the 85 Austrian sites that report. The rule generalises with one branch: use truck_spaces where the feed publishes it, and capacity where it does not. Austria stamps truck_spaces on all 244 of its sites; the German federal feed stamps it on none, because its lorry-parking records are truck-only and capacity already is the truck figure.
available_spots: 0 is a fact, not a gap. It means known full. A site with no live feed omits the field entirely. Those two states must not collapse into one in your code — treat “absent” as unknown and “0” as closed to you.
occupancy_updated is the count’s own timestamp, separate from last_updated, so you can age out a stale reading on your own threshold rather than trusting our poll cycle.

And the jurisdiction code is ISO 3166-1 alpha-3. ?jurisdiction=AUT, never AT — the two-letter form is not an alias, it returns an empty result set.

The Trend: “Is This Lot Typically Full at My ETA?”

A live count answers a question about now. Dispatch plans a stop for six hours from now, when the live count will have changed. That gap is what the per-hour history is for, and it comes back on the feature-detail endpoint:

curl -H "X-API-Key: $KEY" \
  "https://api.napspan.com/api/v1/features/AUT-tp-PARK000402/details"

{
  "data": { "id": "AUT-tp-PARK000402", "name": "Wr. Neustadt", ... },
  "availability_trend": [
    { "hour": 5,  "avg_available": 22.0, "avg_capacity": 71, "samples": 77, "low_samples": 0 },
    { "hour": 12, "avg_available": 15.2, "avg_capacity": 71, "samples": 72, "low_samples": 0 },
    { "hour": 18, "avg_available": 5.7,  "avg_capacity": 71, "samples": 41, "low_samples": 0 },
    { "hour": 20, "avg_available": 2.0,  "avg_capacity": 71, "samples": 22, "low_samples": 0 }
  ]
}

Twenty-four buckets, built from the trailing thirty days of recorded occupancy for that specific lot. It is the difference between “there are two bays free right now” and “this lot has been down to single digits every evening for a month” — and only the second one is actionable at 14:00 when you are deciding where the driver sleeps.

Three things to know before you plot it. Hours are UTC; Austria ran at UTC+2 across this window, so bucket 18 is 20:00 on the driver’s dashboard clock — localize before you show it to a human. samples is there to be read: buckets are recorded on change, so a thin bucket deserves less confidence than a fat one. We publish the count rather than smoothing it away.

And the third is the one that will silently skew a chart: avg_capacity is the site’s total capacity, while avg_available counts truck bays only. Wiener Neustadt has 40 truck bays inside 71 total spaces, which is why every bucket above reads avg_capacity: 71. Computing 1 - avg_available / avg_capacity is therefore not this lot’s truck occupancy — it mixes the two counts and reads about twenty points too full. Take the denominator from the feature’s truck_spaces and use avg_capacity only for what it is: the size of the whole site. It is the same trap as the live payload, one field name further along, and the fact that the two numbers sit side by side in the same object is exactly what makes it easy to miss.

Where It Actually Belongs: On the Route, Next to the Break

Querying a lot by id is the debugging path. The one that changes an evening is that occupancy arrives already attached to the route, and to the break the regulation demands.

Send a normal truck route to POST /api/v1/routing/route with include_features: ["truck_parking"], and parking comes back in the features[] channel — distinct from hazard warnings[], opt-in, and costing nothing when you do not ask for it:

{
  "features": [
    {
      "type": "truck_parking",
      "name": "Wr. Neustadt",
      "distance_along_route_m": 184000,
      "detour_m": 240,
      "side": "right",
      "available_spots": 3,
      "capacity": 40,
      "as_of": "2026-07-30T18:02:11Z",
      "source": "AUT",
      "geometry": { "type": "Point", "coordinates": [16.2, 47.8] }
    }
  ]
}

Then add an hos block with the driver’s clock and ruleset: "eu_561", and the response gains an hos[] projection: where the break falls, and which parking is reachable before the limit rather than after it. Where a feed publishes live occupancy, two things follow that a static inventory can never do:

Reachable parking is ordered by open spaces, so the first suggestion is the one most likely to still have room, not merely the nearest concrete.
The stop is flagged feasible: false when every reachable lot reports full. That is the alert worth having. It fires at planning time, in an API response, hours before it would otherwise arrive as a phone call from a lay-by.

It rides the same request as the corridor’s truck bans and VMS signs, its toll costs, its border queues, and the 561/2006 break plan itself. One call returns a drivable truck route, the rules that would stop it, what it costs, where the driver must legally rest — and whether there will be a bay there when they arrive.

What This Data Does Not Do

The honest limits are part of the product, so here they are without decoration.

Most national feeds publish inventory, not occupancy. Slovenia, the Netherlands, Bavaria and Latvia all hand us sites and capacities with no availability whatsoever, and the same is true of most of the general parking feeds. Two feeds are the exception, and the larger one is German: the federal motorway lorry-parking layer carries live counts on 1,759 of its 1,858 sites, twenty times Austria’s reporting network, and it is live in the API in the same truck_parking schema. This post is built on Austria anyway, for a reason worth stating plainly: ASFINAG’s terms are a confirmed CC BY 4.0, while the German federal licence variant is still being verified, and we would rather anchor a worked example on the layer whose redistribution terms we have finished checking. Query both; weigh the German one accordingly until we can say more.
Even in Austria it is 85 of 244 sites. The other 159 are real lots that appear with capacity and no counts. Your UI needs a third state — free / full / not reporting — and the absence of available_spots is what selects it.
Thirty days of history is thirty days, and it is a moving window. The Austrian series starts 30 June 2026 — 293,334 observations by 10 September — but the trend endpoint reads only the trailing thirty days, so the record has already outgrown the window and what you get back today is a summer month, not the whole series. The difference is not academic: in the thirty days to 30 July, 57 of the 86 lots had hit zero free bays and 47 of the sites observed at 23:00 had been full at some point; in the thirty days to 14 August those figures are 40 and 29, and in the thirty days to 10 September, 40 and 22. Same network, same endpoint, weeks apart. Use the trend as a base rate for the season you are in, and re-pull it rather than caching a number from last month.
A free bay is not a reserved bay. Nothing here books anything. It tells you what the operator reported and when, which is what you need to choose between two lots — not a guarantee that the space survives the next twenty minutes.
The trend is a prior, not a prediction. An hour-of-day average over thirty days is a solid base rate and it is blind to the specific Thursday your driver is having. Use it to rank candidates and to know when the network tightens; use the live count for the final call.

The Common Thread

This is the same shape as the five road-data problems every cross-border European fleet hits. The information exists. A public authority publishes it, properly, under an open licence. It arrives split across two DATEX II documents that have to be joined on a reference key, in a national profile, on its own cadence — and doing that once per country, forever, is a maintenance commitment that competes with the product you actually sell.

NAPSPAN does that join once. Austrian bay counts arrive in the same truck_parking schema as every other parking feed in the system, filterable by jurisdiction, carried on the route beside the tolls and the rest breaks, served from Europe, and licence-classified before it ships. The Austrian data is published by ASFINAG under CC BY 4.0 — Datenquelle: ASFINAG — licensed under CC BY 4.0 — and that credit travels with every record we hand you.

Try It

API docs — /features with type=truck_parking, /features/{id}/details for the trend, and POST /routing/route with include_features
Live map — the Austrian network as it stands right now
Free API key — no card, 14-day trial

Originally published on napspan.com.

One Bridge, Two Border Waits — and Only One of Them Is Yours

Roman Kotenko — Sat, 05 Sep 2026 11:58:08 +0000

A cross-border load has one place where the plan reliably falls apart, and it isn’t traffic. It’s the primary inspection lane. Everything upstream — the route, the hours, the appointment at the consignee — is built on an ETA that assumes the truck rolls through the plaza. Twenty-five minutes in the commercial queue is a missed dock window; ninety is a reset of the whole day.

The wait is published. Both governments publish it, in fact — and that is exactly where it gets interesting, because they publish different halves of it. Here is the Blue Water Bridge between Port Huron, Michigan and Point Edward, Ontario, as our North American production database held it shortly after 07:00 UTC on 8 August 2026 — 3 a.m. in Michigan, the quietest hour of the day:

Direction	Publisher	Commercial wait	Reported at
Into the US (northbound plaza, Port Huron)	U.S. Customs and Border Protection	`0`	“At Midnight EST”
Into Canada (Point Edward)	Canada Border Services Agency	`25 minutes`	2026-08-08 02:22 EDT

Same bridge. Same minute. Zero one way, twenty-five the other — and neither agency publishes the other one’s direction. CBP’s feed covers arrivals into the United States. CBSA’s covers arrivals into Canada; in that same snapshot, its US-bound commercial column read -- at all 29 of its offices, because that isn’t CBSA’s number to report. If your app looked up “the Blue Water Bridge wait” from one source, there was a coin-flip chance it was quoting a queue your truck will never sit in.

Both Halves, One Field, On the Route

Road511 polls both feeds every five minutes and normalizes them into the same border_crossings feature type. On a truck-aware route they arrive as warnings[] entries of type: "border_crossing" — the same array that already carries bridge clearances, work zones and weigh stations, from the same single call to POST /api/v1/routing/route.

Here are the two sides of that bridge exactly as the routing enrichment renders them, from the property blobs quoted above (abridged — distance_along_route_m and projected_arrival_time depend on your own route):

{
  "type": "border_crossing",
  "severity": "warning",
  "title": "Blue Water Bridge",
  "description": "Commercial border wait ~25 min.",
  "status": "open",
  "as_of": "2026-08-08T07:03:04Z",
  "source": "CBSA",
  "properties": {
    "commercial_wait_minutes": 25,
    "commercial_canada_bound": "25 minutes",
    "commercial_us_bound": "--",
    "location": "Point Edward, ON/Port Huron, MI",
    "last_updated": "2026-08-08 02:22 EDT"
  }
}

{
  "type": "border_crossing",
  "severity": "info",
  "title": "Port Huron - Bluewater Bridge",
  "description": "Commercial border wait ~0 min.",
  "status": "open",
  "as_of": "2026-08-08T07:10:43Z",
  "source": "CBP",
  "properties": {
    "commercial_wait_minutes": 0,
    "wait_trend": "steady",
    "hours": "24 hrs/day",
    "port_status": "Open",
    "commercial": {
      "delay_minutes": 0, "status": "no delay", "trend": "steady",
      "lanes_open": 2, "max_lanes": 9,
      "fast_status": "Lanes Closed", "update_time": "At Midnight EST"
    },
    "passenger": { "delay_minutes": 0, "lanes_open": 1, "max_lanes": 10 }
  }
}

One field means the same thing on both: commercial_wait_minutes, an integer, commercial lanes, always minutes. Underneath it the raw agency shapes are passed through untouched, so nothing is lost if you want to read CBP’s lane counts or CBSA’s own wording.

Note that there are two clocks here, and they are different clocks. as_of is our observation time — when we last confirmed this record in an upstream poll, minutes old on a five-minute cycle. The agency’s own stamp is a separate field kept in properties: CBSA’s last_updated (“2026-08-08 02:22 EDT” above) and CBP’s update_time (“At Midnight EST”), each in the agency’s own wording and timezone. A fresh as_of means we are certain the feed still says this; it does not mean the agency re-measured the queue a minute ago. If your logic needs to know how old the reading is rather than how old the fetch is, read the agency field.

Severity is keyed on the commercial wait, because this is a truck API and the passenger queue is not your problem: info below 15 minutes, warning from 15, critical past 45 minutes or whenever the port is reported closed. That makes the whole thing filterable with the knob you already have — "min_severity": "warning" returns only the crossings on your route that are actually going to cost you time.

The direction caveat, stated up front

We do not yet resolve which side of the crossing your truck is on. When both directions are known, the warning carries the larger of the two — deliberately, so a route never under-warns — which means a southbound run into Michigan can read a Canada-bound figure. Resolving direction from the route heading is the next iteration of this feature. Until it ships, treat commercial_wait_minutes as “the worst commercial wait reported at this crossing right now”, and read the per-direction fields underneath it if you need to be exact. We would rather write that sentence than let you discover it on a load.

Two Vocabularies for One Number

The two agencies do not merely publish different directions — they publish different kinds of thing. CBP sends a structured integer per lane group. CBSA sends free text. Across the 29 CBSA offices in that snapshot the Canada-bound commercial column held No Delay (21 offices), four actual figures (3 minutes, 5 minutes, 12 minutes, 25 minutes), Not Applicable (3), and Temporarily closed (1).

Normalizing that is the boring part of the job and the part that has to be right:

No Delay → 0. A real, published zero.
25 minutes → 25.
--, N/A, Not Applicable, empty → no number at all. Not zero.

That last line is the one that matters. “This agency does not report this direction” and “there is no queue” are opposite facts, and collapsing them into 0 is how a dispatch board ends up confidently green in front of a two-hour queue. When nothing parseable is there, the warning stays info and says "Border crossing on route." — a crossing you should know about, with no wait claimed:

{
  "type": "border_crossing",
  "severity": "info",
  "title": "Sumas",
  "description": "Border crossing on route.",
  "status": "open",
  "as_of": "2026-08-08T07:05:42Z",
  "source": "CBP"
}

“No Delay” With Two Lanes Open

Look again at the Port Huron block: "lanes_open": 2, "max_lanes": 9. The zero-minute wait is true — and it is true of a plaza running two of its nine commercial lanes at three in the morning. Detroit’s Ambassador Bridge in the same snapshot: 2 of 13 commercial lanes open, no delay. Buffalo’s Peace Bridge: 4 of 8, no delay.

A wait figure is a measurement of the trucks that are there now. Lane capacity is the thing that decides what happens when the morning wave arrives, and it is in the payload for exactly that reason. If you are building an arrival-time model rather than a dashboard light, lanes_open against max_lanes is the more interesting series of the two.

Closed Is a State, Not an Absence

In that snapshot, 27 of the 81 CBP ports were reported closed — 24 of them on the Mexican border, where limited hours are normal (54 of the 81 ports run 24 hrs/day; the rest keep windows like 6 am-10 pm or 8 am-4 pm). Laredo’s World Trade Bridge, a commercial-only crossing, was shut: it was 2 a.m. in Texas and its published hours are 7 am-Midnight.

A closed port comes back as critical, with the closure in the title:

{
  "type": "border_crossing",
  "severity": "critical",
  "title": "Laredo - World Trade Bridge — closed",
  "description": "Border crossing reported closed.",
  "status": "closed",
  "as_of": "2026-08-08T07:00:15Z",
  "source": "CBP"
}

And it stays in the data while it is closed. That is a deliberate design rule and worth stating, because the obvious implementation gets it backwards: if a crossing disappeared from the API the moment it shut, a dispatcher planning a 4 a.m. departure would see nothing on the corridor and read that as “no border crossing here” rather than “the gate is down until seven.” Silence is the one answer a routing API must never give to that question. A closed port is still a port, it has published hours, and it will open.

How Much of It Is Actually Populated

Now the part most vendors leave out. In that same snapshot, of the 81 CBP ports, 17 carried a commercial delay figure. The other 64 were Update Pending (36), Lanes Closed (15) or N/A (13). On the CBSA side, 21 offices reported No Delay, three Not Applicable, one Temporarily closed, and four reported an actual number. FAST-lane figures — which we surface as fast_lane_wait_minutes and a derived fast_lane_savings_minutes when they are published — existed at exactly one port. (That last figure in particular is an artefact of the hour, and we come back to it below.)

Some of that is the hour: a plaza with its commercial lanes closed overnight has no wait to report, and the numbers thicken as the border wakes up. But the shape is the point — a border-wait API is mostly a “no figure right now” API, and a client that assumes every crossing has a live number will be wrong most of the time. Ours tells you which case you are in, on every single crossing, rather than smoothing it into a plausible-looking integer.

The Same Query at Ten in the Morning

“Some of that is the hour” is the kind of hedge that deserves a measurement rather than a promise, so here is one. Everything above is a 3 a.m. reading. We re-ran the identical queries against the same production database on 14 August 2026 at 13:57 UTC — 09:57 Eastern, mid-morning on a working Friday. The difference is large enough that you should not size your integration on the overnight figures:

	3 a.m. ET, 8 Aug	10 a.m. ET, 14 Aug
CBP ports carrying a commercial delay figure	17 of 81	35 of 81
CBP ports reported closed	27	3
Highest commercial wait anywhere	5 min	30 min
Ports publishing a FAST figure	1	11
CBSA offices publishing a US-bound wait	0 of 29	0 of 27

Two of those rows carry a lesson each. The population rate roughly doubles and the closures nearly vanish — so a coverage number quoted from an overnight sample understates the daytime product badly, and one quoted from a daytime sample overstates the overnight one. Whichever direction you are being sold, ask what hour the sample came from. The FAST count moved by a factor of eleven, which is the honest correction to the paragraph above: FAST is not a feature that exists at one port, it is a feature CBP populates when the FAST lanes are staffed. At mid-morning it was publishing FAST at eleven ports, and at Laredo’s Colombia Solidarity bridge the FAST lane read 5 against a standard 30 — a genuine 25-minute saving, and exactly the case an enrolled carrier wants surfaced.

And the last row is the one that did not move. Every one of CBSA’s 27 offices still had -- in its US-bound commercial column at ten in the morning, just as all 29 did at three. That asymmetry is structural, not a nocturnal quirk — it is the design fact this whole post is built on, and it is stable at every hour we have looked.

The lane-capacity story sharpens in daylight too. Detroit’s Ambassador Bridge had gone from 2 of 13 commercial lanes to 5 of 13, and had picked up a 5-minute wait doing it — more lanes and a longer queue, at the same time, which is precisely why the wait figure alone is a poor arrival-time input. Port Huron ran 4 of 9 with a 2-minute wait. Best of all, Laredo’s World Trade Bridge — the commercial-only crossing that was shut at 2 a.m. Texas time in the earlier snapshot — was open with 11 of its 19 lanes running and no delay at all. The closed record you saw overnight had turned into the busiest commercial plaza in the dataset, without ever leaving the API.

The northern border, meanwhile, was quiet: the Peace Bridge, the Ambassador, the Windsor Tunnel, Alexandria Bay, Sweetgrass and Blaine all sat at 5 minutes or under. The 30-minute figures were both on the Mexican border, at Laredo’s Colombia Solidarity and Pharr. If your lanes are Canadian, budget your expectations accordingly — and if they are Mexican, note that the busiest reading in this dataset is still a half-hour, not the horror stories.

The wider inventory works the same way, and it is the coverage number to plan against. As of 14 August 2026 we hold 197 active border crossings across North America; 108 of them — 81 CBP ports and 27 CBSA offices — sit behind a live wait feed. The remaining 89 come from provincial and state 511 map layers — Manitoba (32), Saskatchewan (24), Alberta (12), New Brunswick (6), Québec (5), Newfoundland (4), British Columbia (4) and California (2) — and are location records: they tell you a crossing exists and where, and they publish no wait at all, ever. They still ride your route as info, never with an invented number.

Read that ratio before you design around this: 45% of the land border crossings we know about have no wait feed behind them at any hour, and no amount of waiting for daytime will change it — unlike the Update Pending case above, this is a permanent absence rather than a temporary one. Note also that the CBSA office count itself drifts: it was 29 on 8 August and 27 on 14 August, because the agency’s own list of reporting offices changes. Don’t hard-code it.

What We Don’t Do

No history, no “typical Thursday.” We publish the live reading and a poll-over-poll wait_trend (rising / falling / steady, moving on a ±5-minute threshold so a two-minute wobble doesn’t flap). There is no border-wait time series behind this endpoint yet, so no hour-of-day base rate — and we would rather say so than dress a single reading up as a pattern.
No modelled waits. Every figure is the agency’s own, or there is no figure. No crowd-sourced estimate, no inference of a queue from silence.
No bypass or clearance claims. FAST is surfaced when CBP publishes it. Whether your carrier is enrolled, and what that means at primary, is between you and the program.

The Same Field on the Other Side of the Atlantic

The schema is not North-America-shaped by accident. Our European deployment runs the identical border_crossing warning over Ukraine’s electronic queue at the EU external frontier, where commercial waits are measured in days rather than minutes — the same commercial_wait_minutes integer, rendered as “4 d 3 h” instead of “25 min”. If you run both continents, it’s one integration. That story is on the NAPSPAN blog.

Try It

API docs — the full warnings[] reference, including border_crossing severity bands and properties
Free API key — no credit card, 14-day trial
Truck routing with hazard warnings — how the whole corridor warnings[] channel works
Data sources — every feed behind the API, with its licence

Wait times from U.S. Customs and Border Protection (US public domain) and the Canada Border Services Agency. Contains information licensed under the Open Government Licence – Canada, © Canada Border Services Agency. Crossing coordinates are geocoded from OpenStreetMap data (© OpenStreetMap contributors, ODbL). Figures in this post come from two snapshots of our production database: the overnight one taken shortly after 07:00 UTC on 8 August 2026 (03:00 Eastern), and the mid-morning comparison taken at 13:57 UTC on 14 August 2026 (09:57 Eastern). Each was correct at that moment only, and every section states which one it is drawing on — query the API for the live picture.

Originally published on road511.com.

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

Roman Kotenko — Thu, 27 Aug 2026 08:06:53 +0000

“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, icy, snow-covered. Each agency says that in its own words rather than a shared vocabulary, which turns out to matter a great deal and which we come back to in detail below.

Road511 currently carries 4,082 active roadside weather stations across 37 states and provinces, alongside 8,132 active road-condition segments across 20 — the latter being the DOT’s own segment-level assessment of a stretch of road, as opposed to a single station’s point reading. (Counts measured 27 August 2026, active records only. Stations come and go as agencies retire hardware, so treat these as this month’s figure rather than a constant.)

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 an actual record, pulled from the production database as this post was last revised — a Pennsylvania crash on I‑70 from the afternoon of 16 August 2026, verbatim:

GET /api/v1/analytics/event-weather/PA-evt-348347

{
  "id": 2188447,
  "event_id": "PA-evt-348347",
  "distance_km": 1.7816931,
  "temperature": 80.1,
  "temperature_c": 26.722221,
  "wind_speed": 3.6,
  "wind_direction": "SW",
  "visibility": 12.43,
  "precipitation": "No Precipitation",
  "road_surface": "Dry",
  "humidity": 83,
  "reading_recorded_at": "2026-08-16T17:00:10.704866Z",
  "created_at": "2026-08-16T17:04:39.913287Z"
}

The event itself reads CRASH on I-70 Eastbound at ramp from PA 51 South. All lanes disrupted. Read the weather as a dispatcher rather than as a developer. Dry pavement, no precipitation, a visibility of 12.43 — miles, on this feed — almost no wind, from a station 1.8 km away, recorded four minutes before the incident was written. That is a hold the load and wait incident, and you knew it without reading the description. Flip three of those fields — a road surface the agency has flagged for ice, visibility under a mile, a crosswind on an exposed grade — and the same incident text supports the opposite decision: reroute the following three loads now, don’t just delay them. The value here is not that the conditions are dramatic. It is that they are present, on the incident, at the moment it appears, in one call.

The distance_km field is doing real work there, and it’s the reason we return it. A station 1.8 km from the incident is describing the incident. A station 46 km away is describing a different valley, and you should discount it accordingly. Across the whole archive the average snapshot sits about 16 km out, so this is a filter you will actually use. 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.

What those field values actually look like

Notice that precipitation reads "No Precipitation" and road_surface reads "Dry" — capitalised, spelled out, in the reporting agency’s own words. These are not normalized enums, and you must not code against them as though they were. Across the archive the same two columns hold None, none, No Precipitation, not available, Unknown, light rain, rain moderate and 0 mm for precipitation; Dry, dry, Wet, Trace Moisture, Trace Wet, Moist, wet and dry, Ice Watch, Ice Warning, Snow Warning and Slushy for road surface. A handful of feeds leak raw sensor codes into the field — you will find literal 4.0 and 65535 values in there.

Two consequences worth internalising before you build on this. First, match case-insensitively and on substrings, and treat anything you don’t recognise as unknown rather than as safe. Second, and less obvious: some agencies publish their ice-detection subsystem’s alarm state in this field rather than an observation, which is why Ice Watch turns up on a Virginia road at 30 °C in August. Ice Watch means a sensor is armed, not that there is ice. If you are going to escalate on a surface value, escalate on it together with the temperature, never on the string alone. We pass the agency’s word through rather than mapping it to a tidy enum, because the mapping would have to guess at exactly the cases where guessing is most expensive — but that means the interpretation is genuinely yours to do.

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 an event carries a snapshot, the figure becomes 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=OH

[
  { "precipitation": "None",    "road_surface": "",
    "event_count": 7348, "avg_severity": 1.95, "avg_temp_c": 22.0 },
  { "precipitation": "None",    "road_surface": "Dry",
    "event_count": 5806, "avg_severity": 1.95, "avg_temp_c": 24.8 },
  { "precipitation": "None",    "road_surface": "Unknown",
    "event_count": 2000, "avg_severity": 1.94, "avg_temp_c": 24.7 },
  { "precipitation": "Unknown", "road_surface": "",
    "event_count": 1709, "avg_severity": 1.98, "avg_temp_c": 21.9 },
  { "precipitation": "Other",   "road_surface": "",
    "event_count": 1229, "avg_severity": 1.96, "avg_temp_c": 23.4 },
  { "precipitation": "None",    "road_surface": "Wet",
    "event_count":  530, "avg_severity": 2.05, "avg_temp_c": 22.0 },
  { "precipitation": "Other",   "road_surface": "Unknown",
    "event_count":  470, "avg_severity": 2.00, "avg_temp_c": 24.3 },
  { "precipitation": "Unknown", "road_surface": "Unknown",
    "event_count":  461, "avg_severity": 2.02, "avg_temp_c": 27.1 },
  { "precipitation": "Rain",    "road_surface": "",
    "event_count":  445, "avg_severity": 2.04, "avg_temp_c": 19.0 },
  { "precipitation": "Rain",    "road_surface": "Wet",
    "event_count":  256, "avg_severity": 2.09, "avg_temp_c": 21.9 }
]

That is the real response for Ohio on 16 August 2026 — the top ten rows exactly as returned, in the order returned — and it is worth showing you exactly because it is not the tidy result a marketing example would invent. Three things in it are the honest state of this endpoint today, and you should know all three before you build on it.

The severity spread is currently tiny. 1.95 on dry, 2.05 on wet, 2.09 in rain — the ordering is the one you would predict, but the whole range spans about a seventh of a single severity step, and further down the same response Trace Wet sits at 1.79, below dry. Treat that as a gradient thin enough that one unusual month could erase it, not as a finding. (avg_severity is a weighted score: critical counts 4, major 3, moderate 2, everything else 1.) We are not going to tell you we have measured that ice doubles incident severity, because in this archive, so far, we have not. What we have built is the instrument; the reading it currently gives on most lanes is “no strong effect yet.”

The archive is young. Weather snapshots begin on 10 April 2026. There is no winter in this data at all yet, which is the single biggest reason the ice story above cannot be told from it — the interesting conditions have not happened during the archive’s lifetime. A date range starting before April 2026 returns an empty array, so don’t write one and conclude the endpoint is broken. The first real winter of this dataset is the 2026–27 one.

Most rows have an empty road_surface. Of the 646,539 snapshots in the archive on 27 August 2026, 118,860 carry a road-surface string and 133,766 a precipitation string; only 22,964 — about 3.6% — carry surface, precipitation, wind and visibility all four. Most stations report a subset, and the grouping key you most want is the one most often absent. Ohio is better than that average, at roughly half its rows carrying a surface string, and it still leads with an empty one: that top row is not a bug, it is 7,348 events whose nearest station published a temperature and nothing about the pavement.

Filter by jurisdiction, by event type, by severity, or by date range, and you can put the question your own lanes actually pose to the data — which corridors punish ice, which ones shrug it off. Just budget for the answer being “not enough observations yet” on a lot of them, and check event_count before you believe an avg_severity. We would rather hand you a thin dataset labelled thin than a thick one we smoothed.

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. When you write that policy, apply the two cautions above — the surface strings are the agency’s vocabulary rather than an enum, and wind and visibility carry no unit — because a threshold is exactly where an unnormalized field does its damage.

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 a freezing temperature and an icy surface string, before a human has read the description. (Both halves: the surface string alone will fire on a summer sensor alarm.)
Winter corridor scorecards — rank your lanes by the severity they produce under the same conditions. The endpoint for this exists today; the archive to fill it starts accumulating its first winter in November 2026.
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 — roughly a quarter of snapshots carry it — and the correlation endpoint leaves those readings out of its average instead of blending them in.

Temperature is the only field we normalize. Wind and visibility are not. This matters more than it sounds: in the same visibility column you will find 12.43 from a Delaware station reporting miles and 621 from a Virginia one that plainly is not. There is no unit field to tell them apart. Compare visibility and wind within a single jurisdiction and never across them, and put a sanity bound on the value before you feed it to anything that makes a decision. If you need one cross-jurisdiction number, temperature_c is the one field that is safe to average.

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, whatever the nearest station measured exists next to it, in one schema, from 4,082 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

Originally published on road511.com.

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

Roman Kotenko — Tue, 11 Aug 2026 10:16:35 +0000

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 before a single cone is placed — but how far before depends entirely on the agency, and that variation is the first thing to plan around. Delaware’s pipeline carries start dates booked into 2030; Virginia’s layer is overnight lane work on a roughly three-day horizon, with a median window of eight hours. Same feature type, two very different horizons: bound your query window rather than trusting the field to mean the same thing everywhere. What these records do carry, and live feeds lack, is 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 caveats on that example. total is a live reading, not a constant — run the query rather than quoting the number. And Virginia is the short-horizon case described above: it publishes overnight lane work about three days out, so the same query aimed at a month further ahead returns almost nothing. That is a property of the agency, not of the API. For a long-horizon pipeline, run it against jurisdiction=DE, whose records carry start dates years out.

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.

Your ETA Assumes the Border Takes an Hour. It Can Take Four Days.

Roman Kotenko — Sat, 08 Aug 2026 08:19:40 +0000

Inside Schengen, a border is a road sign. You cross it at motorway speed and your ETA never notices. Twenty years of that has trained every routing engine, every TMS, and every dispatcher's intuition to treat a European frontier as a rounding error.

Then a load runs to the EU's external frontier, and the rounding error becomes the trip.

On the morning of 16 July 2026, the loaded-truck queue at Yahodyn–Dorohusk — the main Ukraine–Poland freight crossing — was reporting a wait of 5,964 minutes. That is four days and three hours, with 1,006 trucks physically in the queue. The queue for empty trucks at the same crossing was worse: 6,555 minutes, or four days and thirteen hours, with 1,334 trucks waiting.

No amount of clever road-network routing tells you that. It isn't a traffic condition, it isn't congestion, and it will not resolve in twenty minutes. It is a queue with a length, and the only way to know about it is to read the queue.

Why "Average Border Wait" Is a Useless Number

The instinct is to reach for an average and pad the ETA. The live data says don't bother.

Across the 38 truck checkpoints on Ukraine's EU-facing frontier that morning, the distribution wasn't a bell curve. It was two clusters and nothing in between: 21 checkpoints reported a wait of exactly zero, and the rest ran from about ten hours to four and a half days. There was essentially no middle.

That shape is the whole planning problem. A border crossing is either flowing — in which case it costs you nothing and needs no padding — or it is a multi-day parking lot. An average across those two states describes no crossing that actually exists, and a fixed buffer is either wasted margin or nowhere near enough. The only useful question is binary and current: is this specific crossing, for this kind of truck, moving right now?

The Queue Is Published. It Just Isn't in Your Stack.

Ukraine runs an electronic queue system for border crossings — єЧерга (eCherha) — operated by the State Customs Service. Trucks book and hold a place in it, and it publishes the live state of every checkpoint: how long the queue is taking, and how many vehicles are in it. The underlying dataset is open data, published under CC BY 4.0.

NAPSPAN normalizes it into the same border_crossings feature type that carries the CBP and CBSA land-border waits on the North American side, so it answers to the same /features call as everything else:

curl -H "X-API-Key: $KEY" \
  "https://api.napspan.com/api/v1/features?type=border_crossings&jurisdiction=UKR"

{
  "data": [
    {
      "id": "echerga-truck-1",
      "source": "UKR",
      "jurisdiction": "UKR",
      "feature_type": "border_crossings",
      "name": "Ягодин – Дорогуськ (для вантажівок ≥ 7,5 тонн)",
      "latitude": 51.1880897,
      "longitude": 23.8105033,
      "is_active": true,
      "properties": {
        "source_feed": "echerga",
        "vehicle_type": "truck",
        "queue_type": "dynamic",
        "wait_time_minutes": 5964,
        "vehicles_in_queue": 1006,
        "neighbor_country": "Польща",
        "is_paused": false
      },
      "last_updated": "2026-07-16T09:40:00Z"
    }
  ],
  "total": 68, "limit": 100, "offset": 0, "has_more": false
}

The whole frontier is in there. That call returns 68 queues facing five neighbours — Poland, Slovakia, Hungary, Romania, and Moldova — each with a live wait and a live queue depth, refreshed on a ten-minute poll. 38 of them are truck queues; the rest are the coach queues the same system publishes. vehicle_type tells them apart, and it's the field to filter on — a coach queue says nothing about your freight lane.

The Part That Changes Dispatch: It Rides the Route

Querying the frontier by jurisdiction is the manual path. The one that changes a dispatcher's day is that the queue comes back attached to the route. Send a normal truck routing request to POST /api/v1/routing/route, and any border crossing on the corridor arrives in the warnings[] channel — no second call, no spatial join on your side:

{
  "warnings": [
    {
      "type": "border_crossing",
      "severity": "critical",
      "title": "Ягодин – Дорогуськ (для вантажівок ≥ 7,5 тонн)",
      "description": "Commercial border wait ~4 d 3 h. 1006 trucks in queue.",
      "status": "open",
      "as_of": "2026-07-16T09:40:00Z",
      "distance_along_route_m": 288000,
      "projected_arrival_time": "2026-07-16T14:05:00Z",
      "source": "UKR",
      "source_id": "1",
      "geometry": { "type": "Point", "coordinates": [23.8105033, 51.1880897] },
      "properties": {
        "commercial_wait_minutes": 5964,
        "vehicles_in_queue": 1006
      }
    }
  ]
}

A few deliberate choices in that object are worth calling out, because they are what make it usable rather than merely present:

The wait reads like a wait. description renders as 4 d 3 h, not ~5964 min. Nobody can act on 5,964 minutes. The machine-readable commercial_wait_minutes stays in minutes so your own thresholds keep working — the humanising is presentation, not data loss.
Queue depth comes with it. vehicles_in_queue is the figure that makes the wait concrete. "Four days" is abstract; "a thousand trucks are in front of you" is a decision.
Severity is banded for a truck. info under 15 minutes, warning from 15, critical past 45 or whenever the crossing is closed. Set min_severity: "warning" and a flowing border stays silent while a jammed one shouts.
Only the truck queue counts. The feed publishes each checkpoint once per vehicle type. A ninety-minute coach queue at the same crossing never bands your freight route — we key severity on the truck queue alone.
You get the crossing before the driver does. distance_along_route_m and projected_arrival_time place it on the corridor, so this is a decision made at dispatch — reroute to a quieter checkpoint, re-sequence the load, warn the customer — not a surprise found at hour ninety.

It rides the same request as the corridor's truck restrictions and VMS signs, its toll costs, and 561/2006 break planning. One call returns a drivable truck route, the rules that would stop it, where the driver must legally rest, what it costs — and now how long the frontier will hold it.

What to Expect From the Data

A few honest notes, so the coverage behaves the way you expect:

This is the external frontier, not every EU border. Intra-Schengen crossings do not queue, so there is nothing to report and no warning to give. The live queue layer covers Ukraine's EU-facing checkpoints, which is where the EU's freight border problem actually lives. Other external frontiers do not yet have an equivalent live feed wired — we will say so plainly rather than pad the map.
One physical crossing publishes several queues. Yahodyn–Dorohusk reports loaded trucks, empty trucks, and certain cargo categories as separate rows at the same coordinates, and they diverge — on 16 July the empty-truck queue ran ten hours longer than the loaded one. Read the checkpoint name; don't assume one number per border post.
Paused checkpoints drop out. When the operator suspends a queue, the feed flags it and we mark the crossing inactive, so it stops generating warnings rather than reporting a stale wait as live. Ten of the 38 were paused that morning.
Some checkpoints are scheduled, not live. Where a checkpoint runs on booked slots instead of a live queue, there is no wait to report — it stays info and we publish no invented number.
It's a planning input. The queue is authoritative about the queue. It is not a promise about customs, paperwork, or what the officer at the window decides.

The Common Thread

This is the same shape as the five road-data problems every cross-border European fleet hits: the information exists, a public authority publishes it, and it is in a national format that nobody's routing stack speaks. Solving that once per country is a permanent maintenance commitment that competes with the product you actually sell.

NAPSPAN does that aggregation once. The Ukrainian electronic queue arrives in the same border_crossings schema as a US CBP lane wait, filterable by jurisdiction, attached to your route on the same request as the tolls and the rest breaks, served from Europe, and licence-classified before it ships — this feed under CC BY 4.0, credited on every record.

Try It

API docs — /features with type=border_crossings, plus POST /routing/route
Live map — the frontier, as it stands right now
Free API key — no card, 14-day trial

Originally published on napspan.com.

Truck Parking Availability on the Route, Before the Clock Runs Out

Roman Kotenko — Fri, 24 Jul 2026 07:31:59 +0000

It's 2am and a driver's 11-hour clock has maybe 30 minutes left on it. The rest area at the next exit is full — trucks are already lined up on the on-ramp shoulder. The next public lot is 40 miles ahead, which the clock won't cover, and nobody knows whether it has room either. So the driver does what tens of thousands do every night: parks somewhere they shouldn't, or keeps rolling past the legal limit. Truck parking consistently ranks among the trucking industry's top concerns year after year, and the reason it stays unsolved at the cab level is simple — a legal break is worthless if there's nowhere to stop, and the driver finds out too late to do anything about it. That last part is the part software can fix.

Finding a Space Is a Planning Problem, Not a Luck Problem

The shortage is real and structural — there are far more trucks needing overnight rest than there are legal spaces for them. But a huge share of the daily pain isn't the raw shortage; it's the information gap. The driver can't see which lots are full until pulling in, and the dispatcher planning the load has no parking picture at all. A stop that looks fine on a map at 9am dispatch is a gravel shoulder by the time the truck arrives at midnight.

Turning that into a planning decision needs two things the route already implies: where the parking is along the corridor, and how much of it is actually open when the truck will be there. The first has existed for years. The second is finally becoming available — in pieces — and that's the part that changes the workflow.

The Data Exists — in Two Forms

Truck-parking data comes from two complementary public sources, and they answer different questions:

The national inventory — where parking exists. A federal facilities dataset catalogs public rest areas and known truck-parking sites across the country, with locations, capacity, and basic attributes. This is your map of where a truck can legally stop — comprehensive in coverage, but static: it tells you a site has 60 spaces, not how many are free right now.
Live availability — how many spaces are open. A growing number of state DOTs run Truck Parking Information Management Systems (TPIMS) — the in-pavement sensors and roadside signs you've seen reading "REST AREA — 12 SPACES." Those same counts are published as data. Coverage is still a handful of states rather than the whole map, but where a site is instrumented, you get a live, refreshing count of open spaces.

The catch is the one that shows up everywhere in this domain: these are separate feeds in separate formats from separate agencies, each on its own schema and refresh cadence — the same per-source integration tax we wrote about in the five road-data problems every NA fleet team knows. Stitched together and normalized, though, they become one answer: the full map of where to stop, with live counts layered on wherever a state publishes them.

What a Parking Stop Needs to Tell You

A parking feature is only useful to a planner when it answers the operational questions, not just "there's a rest area here":

Where, and which side — the exact location and the direction of travel it serves, so a northbound truck isn't routed to a southbound-only lot.
What kind, and how big — public rest area versus known truck stop, and the total truck-space capacity.
How many are open right now — the live available-space count where the site is instrumented, with the timestamp of the last update so stale data is obvious rather than misleading.
What's there — amenities that decide whether a stop is viable for a 10-hour reset versus a quick 30-minute break.

Putting It on the Corridor

The operational need isn't "a database of rest areas." It's "show me the truck parking on this route, with whatever live counts exist, before the driver commits to a stop." Once the inventory and the TPIMS feeds are normalized into one schema, /truck/corridor buffers the straight line between two points and returns every truck-related feature that intersects it — parking among them — instead of a fan-out across federal and state sources:

GET /api/v1/truck/corridor?
  from_lat=41.88&from_lng=-87.63&
  to_lat=39.10&to_lng=-94.58&
  buffer_km=5

{
  "features": [
    {
      "id": "tpims-IL00055IS002210",
      "feature_type": "truck_parking",
      "name": "I-55 NB Rest Area (Lincoln)",
      "jurisdiction": "IL",
      "road_name": "I-55 NB",
      "latitude": 40.71, "longitude": -89.62,
      "properties": {
        "capacity": 62,
        "available_spaces": 9,
        "occupancy_pct": 85,
        "data_updated": "2026-06-26T06:18:00Z",
        "amenities": ["Vending Machines"],
        "open": true,
        "_distance_km": "1.20"
      }
    },
    {
      "id": "BTS-tp-4471",
      "feature_type": "truck_parking",
      "name": "US-67 Truck Parking",
      "jurisdiction": "IL",
      "road_name": "US-67",
      "latitude": 39.80, "longitude": -90.20,
      "properties": {
        "capacity": 40,
        "county": "Morgan",
        "milepost": "12.4",
        "truck_parking": true,
        "_distance_km": "3.80"
      }
    }
  ],
  "total": 2
}

One call, the Chicago–Kansas City corridor, every known parking site on it, each stamped with _distance_km off the line. Where a state runs TPIMS, the site carries a live available_spaces / occupancy_pct and a data_updated timestamp; where it doesn't, the site still shows up from the national BTS inventory with capacity only and no available_spaces key at all — an honest "we know it's here, we don't have a live count" instead of a false promise. That distinction is the whole point: a planner can prefer instrumented sites near the deadline and fall back to known lots everywhere else. (/truck/corridor is a paid-plan endpoint; the same features are on /features?type=truck_parking&bbox=… for an area query.)

Where Parking Meets the HOS Clock

Parking and hours-of-service are the same problem looked at from two ends. The clock decides when the truck has to stop; the parking data decides whether it can. On its own, a list of nearby lots is useful; tied to the driver's remaining hours, it becomes a go/no-go answer.

That's exactly how it connects to HOS break planning on the route: send the driver's clock with the route, and each required break and drive-limit stop comes back with the truck parking reachable before the deadline — and a feasible flag when nothing legal is in range. Layer live availability on top and "reachable" sharpens into "reachable and likely to have room," so dispatch can move the stop earlier while there's still slack in the clock, instead of discovering the lot is full when there's no clock left to spend.

What You Can Build With It

With truck parking in the same schema as everything else on the route, the integrations get short:

Dispatch that plans the overnight, not just the delivery — place the rest stop at load planning, with capacity and live counts in view, not at 2am.
Driver alerts as the clock winds down — surface the next few viable lots ahead, instrumented ones flagged, while there are still hours to reach them.
Honest ETAs — a reset has to happen somewhere; planning the actual stop makes the arrival estimate real instead of optimistic.
Corridor risk and compliance views — parking alongside bridge clearances, work zones, and incidents in one layer (see truck routing with corridor hazard warnings).

Provenance, and the Honest Limits

Parking data comes from official sources — the federal facilities inventory and state DOT TPIMS feeds — which is what makes it authoritative rather than crowd-guessed. We don't overstate it. Live counts exist only where a state has instrumented a site, so most of the map is still inventory-only; capacity and amenity detail vary by source; and a live count is only as fresh as the feed behind it, which is why every count carries its update timestamp. This is information, not a reservation — the public feeds tell you what's open, not hold a space for you; booking lives in separate private systems. The job we take on is keeping the federal inventory and each state's TPIMS feed parsed, current, and in one shape as they grow and drift — so it's not yours.

Try It

API docs — the features and corridor surface, including truck_parking
Live map — see truck-parking sites and live counts where states publish them
Free API key — no credit card, 14-day trial

The next legal stop, with room — before the clock runs out

The national truck-parking inventory plus live space counts where states publish them, normalized into one schema and queryable along any corridor — and tied to the HOS clock so the break is planned, not gambled. Free 14-day trial. No credit card. Get a free API key or read the docs.

Originally published on road511.com.

Five Road-Data Problems Every Cross-Border European Fleet Hits

Roman Kotenko — Sun, 12 Jul 2026 07:18:21 +0000

If you build routing, dispatch, or telematics software for European trucking, the routing algorithm is rarely what slows the roadmap down. The road data is. A truck plan from Rotterdam to Bucharest crosses a dozen jurisdictions, and each one publishes what's happening on its roads — incidents, tolls, restrictions, charging — its own way, on its own schedule, under its own rules. Below are the five problems that come up in nearly every conversation we have with European fleet and logistics-software teams. None are exotic. All of them quietly burn engineering time.

1. Twenty-Seven Countries, Twenty-Seven Access Points

The EU ITS Directive did get every Member State to stand up a National Access Point (NAP) publishing road data, mostly as DATEX II. That sounds like a solved problem until you actually connect to a second country. The standard leaves room, and the NAPs use all of it — different DATEX profiles and versions, different authentication, different update cadences, different ideas of what a given field means. And plenty of operationally useful data never travels as DATEX II at all: it sits on municipal open-data portals or in national feeds that predate the plumbing.

So a team that wants genuine continental coverage ends up writing and maintaining a separate integration per country, then babysitting all of them as feeds quietly change shape. This is the problem that eats the most time, because it never finishes. We wrote up how we normalize DATEX II across the European NAPs and how the non-DATEX sources fold into the same schema — the short version is that the per-country mess becomes one consistent events and features contract, and keeping the adapters alive becomes our problem instead of yours.

2. The Toll Bill Changes at Every Border

There is no single European toll. There are vignettes, distance-based schemes, per-axle HGV charges, urban congestion fees, and tunnel and bridge tolls — each country with its own model, its own vehicle classes, and its own emission-class surcharges. A route that looks cheapest on distance can be the most expensive once the tolls land, and the difference between a 5-axle Euro VI rig and a smaller van is real money on every leg.

For a planner, an estimate that ignores vehicle class is an estimate that's wrong at invoice time. For a software team, pricing a cross-border route by hand means modelling a dozen national toll systems and keeping them current as rates change. We pulled this together so a route comes back with a vehicle-class-aware toll breakdown per country — see vehicle-class-aware toll costs across Europe.

3. Where the Clock Runs Out — and Whether There's Parking

EU Regulation 561/2006 driving-time rules and the chronic shortage of secure truck parking are really one problem wearing two hats. Knowing a driver will hit the daily driving limit at 18:40 is only half of it. The half that strands a truck — or forces an unsafe roadside stop — is whether there's a legal, reachable place to take the break when the clock runs out, and that answer needs both the driving-time projection and live parking data on the same corridor.

Most teams solve the first half and discover the second half at the lay-by. We tied them together: send the driver's clock with the route and get back every required break, each paired with the parking reachable before the deadline and a feasible flag when none is. That's the subject of break planning under EU 561/2006.

4. The Ban You Didn't Know About Until the Border

Cross-border trucking runs on a patchwork of national restrictions that no consumer map knows about: weekend and night driving bans, sectoral and sector-specific bans on Alpine corridors, low-emission zones in city centres, country-by-country weight and dimension limits, and seasonal restrictions. A plan that's legal in one country can be illegal across the line at the same hour — and the penalty for finding out the hard way is a fine, a forced wait, or a turned-back load.

The operational need isn't "a list of every rule in Europe." It's "tell me about the restrictions and variable-message signs on this corridor, before the driver gets there" — restrictions and signage from the official national feeds, normalized into the same queryable features the rest of the API speaks, filterable by country and bounding box. One schema for a German night ban and an Austrian sectoral ban means you check one place instead of twenty-seven.

5. Charging an Electrifying Fleet, Across the Gaps

As fleets electrify, "where can this vehicle actually charge on the corridor" becomes a routing input, not a nice-to-have. The EU's AFIR regulation obliges charge-point operators to publish charging data through the NAPs, and where a Member State carries a native EV feed we serve it. But AFIR rollout is uneven, and several countries don't expose a mature EV feed yet — so most of our EV coverage comes from an openly-licensed registry rather than from live per-connector telemetry.

That registry gives you coordinates, connector standards, and power ratings, and where a source publishes its own last-checked time we pass it through as properties.source_updated_at so you can judge how fresh an entry is — typically days to months, because a community registry is not live telemetry. See folding open data into one European API.

The Common Thread

Every one of these is the same shape of problem: the data exists, but it's fragmented across national authorities, published in incompatible formats, governed by different licenses, and only useful once it's joined to a route and kept fresh. Each one is solvable in-house — and each one, solved in-house, becomes a permanent maintenance commitment that competes with the product you actually sell.

That's the entire premise of NAPSPAN: do that aggregation once, for everyone, and hand you one normalized API — events, features, tolls, restrictions, charging, routing with corridor hazards — instead of twenty-seven integrations to keep alive. The data is served from Europe, every source is license-classified before it ships, and you spend your engineering time on the part that makes your product yours.

Try It

API docs — events, features, routing, and the ?jurisdiction= / ?type= filters in one reference
Live map — see the normalized data across the European NAPs
Free API key — no card, 14-day trial

One API instead of twenty-seven integrations. Continental coverage — incidents, tolls, truck restrictions, EV charging, and routing — normalized into one GeoJSON schema and served from Europe. Free 14-day trial. No card. Get a free API key or read the docs.

Originally published on napspan.com.

DEV Community: Roman Kotenko

"In Betrieb" Is Not "Free". Live Connector Status Across Five European Countries.

The Field That Looks Like an Answer and Isn’t

Where Live Status Actually Exists, and How Much of It

Per Connector, Because a Station Is Not a Unit

Three Things to Know Before You Build on It

The Same Call as Everything Else on the Corridor

What This Does Not Do

Try It

The Truck's Actual Toll Bill, Returned With the Route

Opt In With include

The Response

Priced for the Vehicle, Not a Sedan

Routing Around Tolls

What to Expect From the Data

One Call, the Whole Trip

Try It

The Stop Your Route Never Mentions: 126,002 At-Grade Crossings

What the Inventory Actually Says

On the Route

Query It Directly

What This Data Is Not

Provenance

Try It

The Dates DOTs Publish Aren't the Dates They Hit

A Date Field Is a Snapshot. You Need the Record.

Eleven Weeks of Watching Dates Move

Querying It

Two Things Look Identical and Mean Opposite Things

What This Is Worth Downstream

The Honest Limits

The Same Mechanism, Beyond Construction

Try It

What a Large-Vehicle Router Cannot Know

Twenty-seven names for one measurement

It is not just clearances

The point

561/2006 Tells You When to Stop. It Doesn't Tell You If the Bay Is Free.

“Is There a Lorry Park?” Is the Wrong Question

Live Occupancy, in the Same /features Call as Everything Else

The Trend: “Is This Lot Typically Full at My ETA?”

Where It Actually Belongs: On the Route, Next to the Break

What This Data Does Not Do

The Common Thread

Try It

One Bridge, Two Border Waits — and Only One of Them Is Yours

Both Halves, One Field, On the Route

The direction caveat, stated up front

Two Vocabularies for One Number

“No Delay” With Two Lanes Open

Closed Is a State, Not an Absence

How Much of It Is Actually Populated

The Same Query at Ten in the Morning

What We Don’t Do

The Same Field on the Other Side of the Atlantic

Try It

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

The Context Already Exists, Sitting in a Different Feed

Every Event Carries Its Own Weather

What those field values actually look like

From Anecdote to a Number You Can Argue With

On the Route

What You Can Build With It

Provenance, and the Honest Limits

Try It

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

Planned Work Is a Different Dataset Than Active Work

Where the Dates Come From

Asking the Question Directly

Two details worth knowing

The Dates Move. That’s the Interesting Part.

What You Can Build With It

Provenance, and the Honest Limits

Try It

Your ETA Assumes the Border Takes an Hour. It Can Take Four Days.

Why "Average Border Wait" Is a Useless Number

The Queue Is Published. It Just Isn't in Your Stack.

The Part That Changes Dispatch: It Rides the Route

What to Expect From the Data

The Common Thread

Opt In With `include`

Live Occupancy, in the Same `/features` Call as Everything Else