DEV Community: Roman Kotenko

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.

Five Road-Data Problems Every North American Fleet Team Knows Too Well

Roman Kotenko — Wed, 08 Jul 2026 13:30:00 +0000

If you build routing, dispatch, or telematics software for North American trucking, your roadmap has a recurring tax line on it — road data. Not the routing algorithm, not the UI: the unglamorous job of knowing what's actually happening on the pavement, in fifty states and a dozen provinces that each run their own system their own way. Below are the five problems that come up in nearly every conversation we have with fleet and logistics-software teams. None of them are exotic. All of them quietly burn engineering time.

1. Fifty States, Fifty Dialects

There is no single "US traffic API." There are dozens of state and provincial 511 systems, and they agree on almost nothing — different formats (some JSON, some XML, some an ArcGIS layer, some a scraped map endpoint), different field names for the same concept, different authentication, different refresh rates, different ideas of what "severity" even means. A team that wants national coverage ends up writing and maintaining a separate integration per jurisdiction, then babysitting all of them as feeds silently change shape.

This is the problem that eats the most time, because it never finishes. A feed that worked in March drops a field in September; a state migrates its portal and the old endpoint 404s. We wrote up how we normalize 30+ of these systems into one schema — the short version is that the per-jurisdiction mess becomes one consistent events and features contract, and keeping the adapters alive becomes our problem instead of yours.

2. The Bridge Your Truck Doesn't Fit Under

A consumer nav app routes a 13′6″ trailer under a 12′8″ bridge without a second thought, because it has no idea a truck is driving. Low-clearance strikes are expensive, dangerous, and almost entirely preventable with the right data on the route — but that data is scattered across state bridge inventories and the federal National Bridge Inventory, in formats never meant for real-time routing.

The operational need isn't "a database of bridges." It's "tell me about the low ones on this corridor, before the driver gets there." That's a join between clearance data and the route geometry, and it's exactly the kind of thing teams underestimate until the first claim comes in. More on that in bridge clearances for fleet routing.

3. The Limits That Appear Every Spring

Seasonal weight restrictions — spring thaw load limits, frost laws — are one of the most under-served data problems in North American trucking. They're posted by states and counties on their own schedules, in their own formats, sometimes as a PDF, and they change as the ground does. A load that's legal one week is over the limit the next, on the same road.

For a planner, the cost of missing one is a fine, a forced reroute, or a refused load. For a software team, the cost is trying to track a hundred separate posting authorities by hand. We pulled this together so the restriction shows up as structured, queryable data alongside everything else — see spring load limits as an API.

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

Hours-of-Service compliance and the chronic truck-parking shortage are really one problem wearing two hats. Knowing a driver will hit the 11-hour driving limit at 6:40 PM is only half of it. The half that strands a truck is whether there's a legal place to stop when the clock runs out — and that answer needs both the HOS projection and live parking data on the same corridor.

Most teams solve the first half and discover the second half at the roadside. We tied them together: send the driver's clock with the route and get back every required break and stop, each paired with the parking reachable before the deadline and a feasible flag when none is. That's the subject of HOS break planning on the route.

5. The Data Is Stale the Moment You Cache It

Incidents, closures, and work zones are only useful while they're current. A closure feed you poll once an hour is a closure feed that's wrong for up to an hour — and a routing decision made on a stale closure is a driver sitting in a backup your system told them to enter. But polling every state's feed aggressively, parsing it, deduping it, and aging out the resolved events is its own piece of infrastructure that has nothing to do with your product.

The honest answer here isn't "real-time magic" — it's that the freshness and lifecycle work should already be done by the time you query. Events carry their own start and end times and move from active to archived on their own; you ask for what's current on a corridor and get the current answer, with the polling cadence handled upstream. Pair it with the camera feeds for visual confirmation (traffic camera feeds) and the dispatcher has eyes on the corridor without standing up a single scraper.

The Common Thread

Every one of these is the same shape of problem: the data exists, but it's fragmented across authorities, published in incompatible formats, 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 Road511: do that aggregation once, for everyone, and hand you one normalized API — events, features, bridge clearances, restrictions, routing with corridor hazards — instead of fifty integrations to keep alive. You spend your engineering time on the part that makes your product yours.

Try It

API docs — the events, features, and truck-routing surface in one reference
Live map — see the normalized data across states and provinces
Free API key — no credit card, 14-day trial

Originally published on road511.com.

Hours-of-Service Break Planning, Right on the Route

Roman Kotenko — Mon, 22 Jun 2026 10:00:44 +0000

A consumer nav app tells the driver where to turn. It will not tell the dispatcher where the 11-hour driving clock runs out — and, more importantly, whether there is legal parking when it does. That second question is the one that strands a truck at 11 PM on the shoulder of an off-ramp with every nearby lot already full.

Road511’s routing endpoint now answers it. Send the driver’s Hours-of-Service clock along with the route, and the response carries an hos[] array: every point on the corridor where the driver must take a break or stop driving under the selected regime, the projected time they reach it, the legal deadline, and — the part that matters operationally — the truck parking and rest areas actually reachable before that deadline.

How It Works

It rides the same call as everything else routing does: POST /api/v1/routing/route. You already send an origin, a destination, and a truck profile. To get the HOS projection, add an hos block inside the truck object describing the driver’s clock at departure.

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": 41.8781, "lng": -87.6298 },
    "destination": { "lat": 39.7392, "lng": -104.9903 },
    "departure_time": "2026-06-08T06:00:00Z",
    "truck": {
      "profile":  "tractor",
      "weight_t": 36.0,
      "height_m": 4.2,
      "axles":    5,
      "hos": {
        "ruleset":           "us",
        "drive_remaining_s": 39600,
        "duty_remaining_s":  50400,
        "since_break_s":     0
      }
    },
    "enrichment": {
      "include_features": ["truck_parking", "rest_areas"]
    }
  }'

That’s a Chicago→Denver run for a fresh driver on US rules: 11 hours of driving left (39600 s), a 14-hour duty window (50400 s), and zero driving time since the last break. Every counter is “seconds remaining” against the named ruleset’s limit.

The HOS Clock

The hos object is the driver’s state, not a fixed policy. Store only the ruleset on a reusable truck profile — the per-trip counters are supplied inline on each request and merge on top.

Field

Meaning

ruleset

The regime: us, canada_south, or eu. Empty defaults from the deployment region.

drive_remaining_s

Driving-limit budget left.

duty_remaining_s

On-duty window budget left.

since_break_s

Driving time accrued since the last qualifying break.

elapsed_remaining_s

Canada’s elapsed (wall-clock) window budget.

cycle_remaining_s

Weekly / cycle budget (60/70-hour US, 70/120-hour Canada, 56h/90h EU).

Any counter you leave out is read as “a fresh driver” — the ruleset’s full limit. The counters are pointers under the hood, so an explicit 0 (“out of hours right now”) is distinct from “not supplied.”

The Response

The HOS projection is attached to the primary route as an hos[] array, alongside the warnings[] and features[] you may already be using.

{
  "routes": [
    {
      "summary": { "distance_m": 1480200, "duration_s": 54600 },
      "geometry": { "type": "LineString", "coordinates": [ /* ... */ ] },
      "hos": [
        {
          "reason": "break_required",
          "distance_along_route_m": 642000,
          "projected_time":  "2026-06-08T14:00:00Z",
          "legal_deadline":  "2026-06-08T14:00:00Z",
          "feasible": true,
          "suggested_stops": [
            { "type": "rest_area", "name": "I-80 Walcott Rest Area",
              "distance_along_route_m": 631500, "capacity": 22,
              "geometry": { "type": "Point", "coordinates": [-90.7830, 41.5900] } },
            { "type": "truck_parking", "name": "I-80 Tipton Truck Parking",
              "distance_along_route_m": 612000,
              "capacity": 140, "available_spots": 31,
              "as_of": "2026-06-08T13:20:00Z",
              "geometry": { "type": "Point", "coordinates": [-91.1300, 41.7700] } }
          ]
        },
        {
          "reason": "drive_limit",
          "distance_along_route_m": 905800,
          "projected_time":  "2026-06-08T17:30:00Z",
          "legal_deadline":  "2026-06-08T17:30:00Z",
          "feasible": false,
          "suggested_stops": []
        }
      ]
    }
  ],
  "route_id": "rt_5d91c7e2"
}

Each stop carries a reason — the limit that trips there — the distance_along_route_m where it lands, the projected_time the driver reaches it, and the legal_deadline the rule allows. The four reasons:

Reason

What tripped

break_required

The driver hit the drive-time-since-break limit and owes a rest break.

drive_limit

The daily driving limit is exhausted — the driver must stop for the day.

duty_window

The on-duty window closed (or, in Canada, the elapsed window) before the driving limit did.

cycle_limit

The weekly/cycle budget ran out.

The Part That Matters: Reachable Parking

Projecting where the clock runs out is the easy half. The operationally useful half is whether the driver can actually stop there. Each hos stop attaches a suggested_stops[] list — the truck parking, truck rest areas, and rest areas reachable before the legal deadline, ordered closest-to-the-deadline first so the driver squeezes the most legal driving out of the day. That list is drawn from Road511’s own live 511 parking data, the same normalized feeds behind the rest of the API.

And the flag that no consumer navigation app surfaces: feasible. When it’s true, at least one legal stop is reachable in time. When it’s false — as on the second stop above — no legal parking is reachable before the deadline. That is a real compliance risk you want to see at dispatch time, not at the roadside. (feasible is omitted entirely if the parking lookup didn’t run, so a missing flag never reads as a misleading “false.”)

The Regimes

Four Hours-of-Service regimes ship today, each implemented against its actual regulation:

Ruleset

Regulation

Key limits

us

49 CFR 395 (FMCSA, property-carrying)

11h driving, 14h duty window, 30-min break after 8h driving, 10h daily rest

canada_south

SOR/2005-313 (south of 60°N)

13h driving, bounded by both a 14h duty window and a 16h elapsed window, 10h daily rest

canada_north

SOR/2005-313 (north of 60°N)

15h driving, 18h duty window, 8h daily rest

eu

Regulation (EC) No 561/2006

9h driving, 45-min break after 4.5h driving, 11h daily rest

The weekly/cycle caps (US 60/70-hour, Canada 70/120-hour, EU 56h/90h) are modeled when you supply cycle_remaining_s; left unset, the projection focuses on the daily limits. The European aetr regime is planned. If you don’t set a ruleset, the routing handler defaults it from the deployment region — but Canadian operators should set canada_south or canada_north explicitly.

Where It Fits

The HOS projection is computed on the route geometry that’s already in hand — it’s pure projection over the polyline, not a second round of routing. It runs for the primary route only, and it rides the routing call you’re already making: no separate endpoint, no separate charge beyond the routing request itself. Routing is a paid-plan feature (featured on Pro+) with a free 14-day trial, so you can wire HOS into a dispatch flow and try it end-to-end before committing.

Pair it with the corridor warnings[] (bridge clearances, weight restrictions, rail crossings, work zones) and the same request answers three questions at once: can this truck legally run this corridor, where will the driver have to stop, and is there parking when they do.

Try It

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

Plan the route, the legal stop, and the parking — in one call

Send the driver’s HOS clock with the route and get back every required break, every drive-limit stop, and the parking reachable before each deadline. Free 14-day trial. No credit card.

Get Free API Key Read the Docs

Normalizing DATEX II Across 30 European National Access Points

Roman Kotenko — Fri, 05 Jun 2026 11:37:15 +0000

EU Directive 2010/40/EU mandates that every Member State operates a National Access Point (NAP) that publishes real-time traffic, safety, and multimodal travel data in DATEX II. On paper, that means one standard, 27 publishers, one integration.

In practice, every NAP serves a different DATEX II profile, over a different transport, behind a different authentication flow, on a different cadence. "DATEX II compliant" is a checkbox each Member State ticks differently.

This is what we ran into building NAPSPAN, a unified API across EU 27 + UK + EFTA. Here's the architecture that lets us treat 30 incompatible DATEX II feeds as if they were one.

The Spec, Then Reality

DATEX II is a mature European standard maintained by datex2.eu and coordinated by NAPCORE. Each delegated regulation references it as the mandatory exchange format:

(EU) 2022/670 — RTTI: real-time events, speeds, road conditions
(EU) No 886/2013 — SRTI: free, open access to safety alerts
(EU) No 885/2013 — SSTP: safe and secure truck parking
(EU) 2017/1926 — MMTIS: multimodal travel information
AFIR Article 20 — live EV charging-station data

So the spec is clear. The implementation is anything but.

Where the NAPs Actually Diverge

"DATEX II compliant" hides at least five axes of divergence:

1. Profile

Each Member State publishes a national profile — a constrained subset of the DATEX II model. Germany's profile (German Traffic Data Profile) defines incidents, road works, and traffic flow on Autobahn + Bundesstraßen. France's transport.data.gouv.fr uses different sub-elements. The Netherlands' NDW publishes a tighter event taxonomy. The UK's NAP TDT wraps DATEX into TIH-specific containers. The DATEX II profiles directory lists them all — same root schema, every country a different shape.

2. Version

DATEX II v2.3 and v3.x are both in the wild. Some NAPs publish both. Some are mid-migration. The XML namespaces are different. Some elements were renamed between versions.

3. Transport

DATEX II is a payload format, not a transport. NAPs ship it over:

HTTPS pull — you GET an XML document on a schedule
HTTPS push (subscription) — you register an endpoint, the NAP POSTs to you
SOAP-over-HTTPS — envelope-wrapped pull
OCIT-C — the German telematics interface used by Mobilithek
WFS / GeoJSON — some city-level supplements (Hamburg, Düsseldorf)

4. Authentication

The matrix here is wide:

None — SRTI safety feeds are mandated free and open
Registered consumer (no key) — NAP whitelists your origin or service endpoint
Bearer / API key — standard token in a header
TLS client certificate (mTLS) — Germany's Mobilithek
OAuth2 — some operator portals

5. Cadence and freshness

Some publications update every 30 seconds (motorway flow). Others refresh nightly (planned road-work calendars). Some sit behind a CDN that lies about freshness via stale Last-Modified headers. Adaptive backoff matters.

The Format Zoo, in DATEX II Form

Here's roughly the same incident from three different NAPs:

Mobilithek (DE) — OCIT-C envelope wrapping a v2.3 SituationPublication:

<d2:payloadPublication
    xsi:type="d2:SituationPublication"
    xmlns:d2="http://datex2.eu/schema/2/2_0">
  <d2:situation id="DE_BAB7_4711">
    <d2:situationRecord
        xsi:type="d2:Accident"
        id="DE_BAB7_4711_R1">
      <d2:probabilityOfOccurrence>certain</d2:probabilityOfOccurrence>
      <d2:groupOfLocations xsi:type="d2:Point">
        <d2:pointByCoordinates>
          <d2:pointCoordinates>
            <d2:latitude>53.5511</d2:latitude>
            <d2:longitude>9.9937</d2:longitude>
          </d2:pointCoordinates>
        </d2:pointByCoordinates>
      </d2:groupOfLocations>
    </d2:situationRecord>
  </d2:situation>
</d2:payloadPublication>

NDW (NL) — v3.x with a tighter VmsTablePublication-style envelope, JSON-LD permitted:

{
  "@context": "https://datex2.eu/schema/3/jsonld",
  "publicationCreator": { "country": "nl", "nationalIdentifier": "NDW" },
  "situation": [{
    "id": "NDW_2026_05_01_42",
    "situationRecord": [{
      "@type": "Accident",
      "severity": "high",
      "groupOfLocations": {
        "locationContainedInGroup": [{
          "pointByCoordinates": { "latitude": 52.0907, "longitude": 5.1214 }
        }]
      }
    }]
  }]
}

UK NAP TDT — DATEX wrapped in a TIH container with a per-publisher feed envelope:

<tih:feed xmlns:tih="https://nap.tdt.gov.uk/tih">
  <tih:publisher>National Highways</tih:publisher>
  <d2:payloadPublication xsi:type="d2:SituationPublication">
    <d2:situation id="NH-INC-9001">...</d2:situation>
  </d2:payloadPublication>
</tih:feed>

Same regulation. Same standard. Three different parsers required.

The Architecture

The solution is the same one we use on the North American side: an adapter registry with one function signature.

type FetchFunc func(ctx context.Context, sr SourceResource) (*FetchResult, error)

type FetchResult struct {
    Events        []TrafficEvent
    Features      []Feature
    ResponseBytes int
}

Every NAP adapter — whether it's pulling Mobilithek's OCIT-C broker, polling NDW's v3 JSON-LD, or unwrapping a TIH envelope — implements this one interface. It takes a source-resource config (URL, credentials, country code, profile version) and returns normalized events and features.

Registration happens at init time:

func init() {
    Register("mobilithek", "events",         fetchMobilithekSituations)
    Register("mobilithek", "afir_charging",  fetchMobilithekAFIR)
    Register("mobilithek", "parking",        fetchMobilithekParking)
    Register("ndw",        "events",         fetchNDWSituations)
    Register("ndw",        "vms",            fetchNDWVMS)
    Register("uk_tdt",     "events",         fetchUKTDTSituations)
    Register("transport_data_gouv_fr", "events", fetchFRSituations)
    // ... 30 NAPs, ~120 (adapter, resource) registrations
}

The scheduler doesn't know or care which DATEX II profile, version, or transport each adapter handles. It just calls Fetch() and gets back normalized events and features.

The Normalized Model

Everything converges into two tables:

traffic_events — time-bounded incidents with lifecycle tracking:

type TrafficEvent struct {
    ID                 string
    Source             string      // "mobilithek", "ndw", "uk_tdt"
    Jurisdiction       string      // "DE", "NL", "GB"
    Type               EventType   // incident, construction, closure, weather
    Severity           Severity    // minor, moderate, major, critical
    Status             EventStatus // active, archived
    Title              string
    Description        string
    AffectedRoads      []string
    Direction          string
    LanesAffected      string
    Latitude, Longitude float64
    StartTime          time.Time
    EndTime            *time.Time
    EstimatedEndTime   *time.Time
    RoadClass          string      // motorway, trunk, primary, secondary
    Metadata           json.RawMessage // DATEX-II-specific fields preserved
}

features — a generic table for everything else. Cameras, VMS signs, weather stations, parking sites, EV charging stations, truck-route segments, bridge clearances — all use the same table with a feature_type discriminator and type-specific fields in a JSONB properties column. Adding a new resource type requires zero schema migrations.

The Hard Parts

1. Profile Field Mapping

The German profile uses locationDescriptor with roadName. The Dutch v3 profile uses a top-level roadInformation structure. The UK feeds bury the road name three levels deep inside tih:routeContext. Each adapter has a small mapping function that knows where its profile keeps each canonical field. Where a profile has nothing to map to, the field is left empty — we don't synthesize data we don't have.

2. Lifecycle Tracking

A DATEX II SituationRecord has a situationRecordVersion and a situationRecordVersionTime. Each new pull may bring a new version of the same record. Some NAPs increment the version on every minor metadata change; others only on substantive updates.

The solution: diff the current state against the previous fetch. Track every change in an event_history table — severity changes, description updates, lane changes, archival. This enables analytics like clearance time percentiles and corridor reliability across borders.

3. Coordinate Reference Systems

Most NAPs publish WGS84 (EPSG:4326). Some German state feeds publish ETRS89 / UTM zones. A few city feeds use the local cadastral system. PostGIS handles transformation, but each adapter has to know what it's receiving.

4. Rate Limiting at Scale

30 NAPs, each with multiple resource types (events, VMS, parking, EV charging, weather), each polling on a 30 sec to 5 min cadence. The scheduler uses per-server semaphores with configurable concurrency limits and request gaps. Circuit breakers back off on repeated failures. Adaptive backoff increases poll intervals when a NAP is slow or returning errors — important when a single NAP can otherwise drag down a whole region's freshness.

5. Schema-Free Feature Types

When we started on the North American side, we had separate tables for cameras, VMS, parking. Every new data type meant a migration. The pivot to a generic features table with JSONB properties was the best architectural decision in the project. On the EU side, that decision pays off again the moment AFIR EV charging data comes online — zero schema changes, just a new feature_type.

The API

After all that normalization work, the API is straightforward:

Get active incidents in Germany:

curl "https://api.napspan.com/api/v1/events?jurisdiction=DEU&type=incident&status=active" \
  -H "X-API-Key: your_key"

{
  "data": [
    {
      "id": "de_mobilithek_4711",
      "jurisdiction": "DEU",
      "type": "incident",
      "severity": "major",
      "title": "Verkehrsunfall A7 Richtung Hamburg",
      "affected_roads": ["A7"],
      "direction": "Hamburg",
      "lanes_affected": "2 of 3 lanes closed",
      "latitude": 53.5511,
      "longitude": 9.9937,
      "start_time": "2026-05-01T08:15:00Z",
      "estimated_end_time": "2026-05-01T12:00:00Z"
    }
  ],
  "total": 142,
  "limit": 100,
  "offset": 0,
  "has_more": true
}

Get traffic cameras in the Netherlands as GeoJSON:

curl "https://api.napspan.com/api/v1/features/geojson?type=cameras&jurisdiction=NLD" \
  -H "X-API-Key: your_key"

Drop the response directly into Leaflet, Mapbox, or any GeoJSON-compatible tool.

Query a cross-border box (Berlin to Amsterdam):

curl "https://api.napspan.com/api/v1/events?status=active&\
bbox=4.90,52.37,13.40,52.52" \
  -H "X-API-Key: your_key"

One call, two NAPs (Mobilithek + NDW), one consistent response shape — a bounding box spans the border with no per-country fan-out. (For events tied to an actual driven path rather than a box, POST /routing/route returns them as ranked warnings[].)

What's in the Data

Once normalized, the dataset includes:

Real-time RTTI events — incidents, road works, traffic flow
SRTI safety alerts (free, open under 886/2013)
VMS dynamic message-sign content with current displayed text
SSTP safe and secure truck parking with availability
AFIR Article 20 EV charging-point status
Traffic cameras with image URLs (where the NAP exposes them)
RWIS-style weather-station readings
TEN-T core network corridor metadata
Bridge clearances and weight restrictions per Member State

Tech Stack

Go — chi router, pgx v5, slog, encoding/xml + custom DATEX schema parsers
PostgreSQL + PostGIS — spatial queries, GeoJSON generation, corridor intersection
Redis — response caching, feature detail caching, rate-limit counters, webhook idempotency (mandatory — the API and worker refuse to start if Redis is unreachable)
Vue 3 + Leaflet — live traffic map

Try It

The API is live with a free tier (no credit card):

Live map — explore the data visually
API docs — full endpoint reference
Developer portal — sign up and get an API key

If you're building anything on European mobility data — logistics, fleet routing, navigation, urban-mobility dashboards — we'd love to hear which NAPs and which DATEX II profiles you most need normalized first. The hardest part isn't the parsing; it's knowing which Member State publishes which data on which transport behind which auth flow. After 30 NAPs, we've built a pretty good map of that.

Ready to try NAPSPAN?

Free 14-day trial. No credit card. EU 27 + UK + EFTA, normalized.

Get Free API Key Explore the Map

DEV Community: Roman Kotenko

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

Try It

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

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

The Data Exists — in Two Forms

What a Parking Stop Needs to Tell You

Putting It on the Corridor

Where Parking Meets the HOS Clock

What You Can Build With It

Provenance, and the Honest Limits

Try It

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

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

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

2. The Toll Bill Changes at Every Border

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

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

5. Charging an Electrifying Fleet, Across the Gaps

The Common Thread

Try It

Five Road-Data Problems Every North American Fleet Team Knows Too Well

1. Fifty States, Fifty Dialects

2. The Bridge Your Truck Doesn't Fit Under

3. The Limits That Appear Every Spring

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