DEV Community: Roman Kotenko

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

Truck Routing That Warns You Before the Bridge Does

Roman Kotenko — Sat, 30 May 2026 10:55:44 +0000

A routing API will happily hand a truck the fastest line between two points. What it usually won't tell you is that the line runs under a 4.0 m overpass with a 4.2 m load on the trailer, crosses an at-grade rail line you're legally required to stop at with placarded hazmat, or threads a county road that's posted closed for construction this week.

Flow APIs — HERE, TomTom, INRIX — are excellent at speed: where traffic is moving, how long the trip takes. That's congestion data. It is not infrastructure data. The overpass height, the bridge weight rating, the truck-restricted segment, the rail crossing, the active work zone — those live in 57 different state and provincial 511 systems, and a flow API doesn't read them.

That gap is what Road511's routing endpoint closes. We take the route geometry from HERE, then enrich the corridor from our own live traffic database — the same normalized 511 data behind the rest of the API — and return the hazards as a structured warnings[] array scored against your truck's dimensions.

How It Works

One call to POST /api/v1/routing/route. You send an origin, a destination, and — required — a truck profile. The profile is what makes a clearance "critical" instead of trivia: a 4.2 m height flags the 4.0 m overpass; a 36-tonne gross weight flags the posted 30-tonne bridge; a hazardous flag turns public at-grade rail crossings into mandatory-stop warnings.

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": 47.6062, "lng": -122.3321 },
    "destination": { "lat": 47.6588, "lng": -117.4260 },
    "truck": {
      "profile":  "tractor",
      "weight_t": 36.0,
      "height_m": 4.2,
      "width_m":  2.6,
      "length_m": 21.0,
      "axle_count": 5,
      "hazardous": ["flammable"]
    },
    "alternatives": 1,
    "avoid": ["toll_road"],
    "enrichment": {
      "buffer_m": 100,
      "clearance_pad_m": 0.15,
      "min_severity": "warning",
      "include_features": ["truck_parking", "rest_areas"]
    }
  }'

That's Seattle to Spokane for a 4.2 m, 36-tonne, placarded tractor-trailer. The truck object accepts profile (tractor, straight, or box), weight_t, height_m, and optional width_m, length_m, axle_count, and hazardous. You can add waypoints, request up to 3 alternatives, and avoid any of tolls, ferries, or tunnels.

The Response

You get back a routes[] array. Each route carries a summary, a GeoJSON geometry (a LineString you can drop straight onto a map), and the part that matters — a warnings[] array. Every warning is positioned: a type, a severity (info, warning, or critical), a distance_along_route_m, a projected_arrival_time, a source, its own geometry, and type-specific properties.

{
  "routes": [
    {
      "summary": { "distance_m": 449300, "duration_s": 16980, "has_tolls": false },
      "geometry": {
        "type": "LineString",
        "coordinates": [ [-122.3321, 47.6062], [-120.5, 47.4], [-117.4260, 47.6588] ]
      },
      "warnings": [
        {
          "type": "bridge_clearance",
          "severity": "critical",
          "title": "Bridge clearance below truck height",
          "description": "I-90 over Snoqualmie Pass on-ramp clearance 4.11m; your truck is 4.20m.",
          "distance_along_route_m": 38200,
          "projected_arrival_time": "2026-05-29T15:12:00Z",
          "source": "nbi",
          "source_id": "WA-000000000123456",
          "geometry": { "type": "Point", "coordinates": [-121.97, 47.51] },
          "properties": {
            "clearance_m": 4.11,
            "truck_height_m": 4.2,
            "facility_carried": "I-90",
            "feature_crossed": "Snoqualmie Pass on-ramp"
          }
        },
        {
          "type": "rail_crossing",
          "severity": "critical",
          "title": "Mandatory hazmat stop — 49 CFR 392.10",
          "description": "Public at-grade crossing; hazmat carrier must stop.",
          "distance_along_route_m": 201400,
          "projected_arrival_time": "2026-05-29T17:41:00Z",
          "source": "fra",
          "source_id": "094821X",
          "geometry": { "type": "Point", "coordinates": [-119.85, 47.20] },
          "properties": {
            "at_grade": true,
            "public": true,
            "railroad": "BNSF",
            "crossing_type": "At Grade"
          }
        },
        {
          "type": "traffic_event",
          "severity": "warning",
          "title": "Construction on US-2 EB",
          "description": "US-2 EB right lane closed for paving",
          "distance_along_route_m": 372600,
          "projected_arrival_time": "2026-05-29T19:08:00Z",
          "source": "wa",
          "source_id": "wsdot-4471822",
          "geometry": { "type": "Point", "coordinates": [-118.20, 47.45] },
          "properties": {
            "sub_type": "construction"
          }
        }
      ],
      "features": [
        {
          "type": "truck_parking",
          "name": "Ritzville Rest Area",
          "distance_along_route_m": 250100,
          "capacity": 28,
          "geometry": { "type": "Point", "coordinates": [-118.38, 47.13] }
        }
      ]
    }
  ],
  "route_id": "rt_8f3c2a1b"
}

The route geometry is HERE's. Everything in warnings[] and features[] is Road511's enrichment of the corridor.

The Warning Types

A warning is only emitted when the corridor actually contains the hazard — and for the dimension-checked types, only when your profile would violate it.

Type	What it flags
`bridge_clearance`	Overpass clearance vs your `height_m` + `clearance_pad_m`. Critical — the one that ends loads.
`truck_restriction`	A segment your profile is barred from. Critical, per violated dimension.
`weight_restriction`	Posted or seasonal weight limit your gross weight exceeds. Critical.
`rail_crossing`	Public at-grade crossing. Critical for placarded hazmat (49 CFR 392.10 mandatory stop); `info` for high-volume otherwise.
`traffic_event`	Live incident, closure, or construction on the corridor.
`future_construction`	Planned work zones the route passes through.
`special_event`	Scheduled events affecting nearby roads.
`weigh_station` / `inspection_station`	Scale houses and inspection sites along the route.
`alert`	Jurisdiction-issued advisories on the corridor.
`weather`	Conditions reported near the route.

Each warning's properties are type-specific: a bridge_clearance reports the measured clearance_m and your truck_height_m. The data is only as fresh as the underlying feed — clearances come from inventories that refresh on the order of days, while traffic_event warnings ride the live incident feed.

Tuning the Enrichment

The enrichment object controls how aggressively the corridor is scanned:

buffer_m — how far off the line to look, 10–1000 m (default 100).
clearance_pad_m — safety margin added to your height before a clearance flags, 0–1 m (default 0.15).
min_severity — drop everything below info, warning, or critical.
exclude_types — suppress warning types you don't care about.
skip_temporal_filter — include time-bounded items outside their active window.
max_distance_m — cap how far along the route enrichment runs.
include_features — opt into a separate features[] channel of truck_parking, truck_rest_areas, and rest_areas near the route.

Saved Routes, Re-Evaluation, and Monitoring

Every routing call is auto-saved for 30 minutes under the route_id. Refetch with GET /api/v1/routing/route/saved/{id} inside that window and the warnings are re-evaluated against current conditions — a closure that popped up since you planned shows up on the refetch. Refetches do not consume routing quota.

To keep a route past the 30-minute TTL, call POST /api/v1/routing/route/saved/{id}/persist. Persisted routes count against your plan's saved-route slots, and they can be put under webhook monitoring — so when a new critical warning lands on a route you've already dispatched, you get notified instead of polling.

Quota and Access

Routing is a paid-plan feature, featured most heavily on Pro+. The Free 14-day trial includes a small daily cap so you can try it. Quota is a monthly routing-call bucket; FIFO top-up packs add calls on top. Refetching a saved route is free.

Why This Is Different

HERE and TomTom sell you flow — how fast the road is moving. Road511 adds the infrastructure — what your specific truck physically and legally can't do on that road. The routing endpoint puts both in one response: a drivable HERE geometry, plus a corridor scan against the live 511 data that flow APIs were never built to read.

Try It

Fuel Price API for Fleet Cost Planning

Roman Kotenko — Thu, 21 May 2026 10:00:00 +0000

Fleet fuel costs are the second-largest operating expense after labor. Having state-level fuel price data in the same API as your truck routes, bridge clearances, and corridor restrictions means you can estimate total route costs in one integration.

Road511 now serves weekly US state-level and monthly Canadian province-level fuel prices from government sources.

The Sources

US — EIA (Energy Information Administration)

Weekly retail prices for all 50 states
Regular, midgrade, premium gasoline + diesel
USD per gallon
Updated every Monday

Canada — Statistics Canada

Monthly retail prices for 12 provinces/territories
Regular, premium gasoline + diesel
CAD cents per litre
Updated monthly

Both are official government data, free, and unrestricted.

Get Latest Prices

curl "https://api.road511.com/api/v1/fuel-prices?country=US&fuel_type=diesel&latest=true" \
  -H "X-API-Key: your_key"

{
  "data": [
    {
      "jurisdiction": "CA",
      "country": "US",
      "fuel_type": "diesel",
      "price": 4.892,
      "currency": "USD",
      "unit": "gallon",
      "period_date": "2026-04-07",
      "frequency": "weekly",
      "source": "eia"
    },
    {
      "jurisdiction": "TX",
      "country": "US",
      "fuel_type": "diesel",
      "price": 3.241,
      "currency": "USD",
      "unit": "gallon",
      "period_date": "2026-04-07",
      "frequency": "weekly",
      "source": "eia"
    }
  ],
  "total": 50,
  "has_more": false
}

Historical Trends

Track how prices change over time:

curl "https://api.road511.com/api/v1/fuel-prices?jurisdiction=CA&fuel_type=diesel&from=2025-01-01&to=2026-04-10" \
  -H "X-API-Key: your_key"

Returns every weekly data point for California diesel over the past 15 months.

Cross-Border Queries

Get both US and Canadian prices in one response:

curl "https://api.road511.com/api/v1/fuel-prices?fuel_type=diesel&latest=true&limit=100" \
  -H "X-API-Key: your_key"

Note: US prices are in USD/gallon, Canadian in CAD cents/litre. Convert as needed for your application.

Combine with Corridor Data

The real value is combining fuel prices with Road511's other data:

Plan the route — check bridge clearances and weight restrictions via /truck/corridor
Estimate fuel cost — get diesel prices for each state the route crosses via /fuel-prices
Check conditions — verify road conditions and active incidents via /events

All from one API, one key, one integration.

Use Cases

Fleet fuel budgeting — forecast costs based on state-level price trends
Route cost optimization — factor fuel price differences into route selection
Rate calculations — logistics platforms adjusting freight rates by fuel cost
Analytics — correlate fuel prices with traffic patterns, delivery frequency

Try It

Comparing Traffic Data APIs: Road511 vs HERE vs TomTom vs INRIX

Roman Kotenko — Tue, 19 May 2026 10:00:00 +0000

If you’re building an app that needs traffic data, you have a few options. The big names — HERE, TomTom, INRIX — dominate the market. But they all sell the same thing: traffic flow from probe data (GPS traces from phones and connected vehicles).

Road511 is different. It aggregates infrastructure data from government 511 systems that the big providers don’t touch.

What Each Provider Actually Offers

Two notes before the table, because a comparison table is only as honest as its column definitions. The Road511 figures are active row counts measured against our North American production database on 14 August 2026 — not lifetime totals, which run considerably higher because retired hardware and expired records stay in the archive. And the other three columns mean one specific thing: “sold as a queryable, source-attributed data feed you can pull.” Several of the “map attribute” entries below are in HERE’s and TomTom’s map data — they are what makes their truck routing avoid a low bridge — but they are baked into a routing engine rather than exposed as an inventory you can query, list, and attribute to the agency that published it. That distinction is the whole point of this page, and it cuts both ways.

Data Type	Road511	HERE	TomTom	INRIX
Traffic flow (speed/congestion)	Limited — travel times & segment speeds, select states	Yes (core product)	Yes (core product)	Yes (core product)
Traffic events/incidents	61 jurisdictions reporting	Yes (own sources)	Yes (own sources)	Yes
Live cameras (50,493)	Yes, 59 jurisdictions	No	No	No
DMS sign messages (12,668)	Yes, 45 jurisdictions	No	No	No
Bridge clearances (662,529)	Yes, 53 jurisdictions	Map attribute for routing	Map attribute for routing	No
Truck routes (489,091 STAA segments)	Yes, 52 jurisdictions	Map attribute for routing	Map attribute for routing	No
Weight restrictions (22,273)	Yes, 6 jurisdictions	Map attribute for routing	Map attribute for routing	No
Spring load limits	Yes	No	No	No
Road conditions (8,119 segments)	Yes, 20 jurisdictions	No	No	Limited
RWIS weather stations (3,877)	Yes, 36 jurisdictions	No	No	No
Rest areas & truck parking (4,220)	Yes, 52 jurisdictions	No	No	No
EV charging (116,149 stations)	Yes	Yes (own product)	Yes (own product)	No
Fuel prices (state-level)	Yes (EIA + StatCan)	Yes (own product)	Varies by product	No
Event lifecycle history	Yes	Varies by product	Varies by product	Yes (historical products)
GeoJSON native	Yes	Varies by API	Varies by API	Varies by API
Webhook notifications	Yes	Via HERE Platform	Varies by product	Varies by product

Where a cell reads “varies by product” we mean it literally: these are large vendors with wide catalogues that change, and we are not going to assert a flat “no” about a product line we do not buy. If a specific capability decides your build, check it on their own documentation rather than on ours — and hold us to the same standard, which is why every Road511 number above is a count you can reproduce against the live API.

Pricing

Provider	Entry Price	What You Get
Road511	$0 (14-day trial) / from $29/mo	Full API access, high daily request volume
HERE	~$200/mo	Traffic flow + incidents, limited calls
TomTom	~$150/mo	Traffic flow + incidents
INRIX	~$50K/year	Enterprise only, negotiated

Road511 sits well below HERE/TomTom for comparable request volumes — and covers data categories they don’t sell as feeds. Treat the other three rows as order-of-magnitude only: they are approximate entry list points, they were approximate when this post was written, and enterprise pricing at all three is negotiated rather than published. Do not plan a budget from this table — price your actual call volume with each vendor. Our live plan tiers and quotas are on the pricing page, where they are the real numbers rather than an estimate.

When to Use Which

Use HERE / TomTom if you need:

Real-time traffic flow (speed, congestion, travel times)
Turn-by-turn routing with live traffic
Global coverage (Europe, Asia, etc.)

Use Road511 if you need:

Camera feeds, DMS messages, road conditions
Bridge clearances, truck routes, weight restrictions
Cross-state normalized 511 data
Event lifecycle analytics (clearance times, trends)
EV charging station data
Fuel prices by state

Use both if:

You’re building a fleet management platform — HERE/TomTom for routing, Road511 for truck restrictions, bridge clearances, fuel prices, and camera verification.
You’re building a comprehensive navigation app — traffic flow from one, infrastructure data from the other.

The Real Differentiator

HERE, TomTom, and INRIX compete with each other on the same data: traffic flow from probe traces. They spend hundreds of millions collecting it, and they are good at it. Nothing on this page is an argument that they aren’t.

What Road511 aggregates is a different class of data from a different origin — government 511 systems rather than phone probes. As of 14 August 2026 that is 50,493 live cameras, 662,529 bridge clearances, 489,091 STAA truck-route segments, 12,668 dynamic message signs, 8,119 road-condition segments and 3,877 roadside weather stations, normalized across 64 US states and Canadian provinces and territories, plus federal datasets from FHWA, the National Bridge Inventory and the FRA. Those are active-record counts, and you can reproduce every one of them against the live API without a key: /stats returns the per-type totals and /jurisdictions the coverage list. Two things to know before you check, so that the numbers agreeing or disagreeing tells you something. The counts above are a dated reading and they move — cameras stood at 54,814 on 20 August, six days after this snapshot — so expect drift, not equality. And /jurisdictions returns 101 rows, not 64: the extra 37 are source rows rather than places you can filter by (30 WZDx feeds, plus CBP, CBSA, StatCan, NWS, Environment and Climate Change Canada, NRL and a continental OSM row). The 64 are the two-letter US and Canadian codes.

The data is complementary, not competitive. If your product already uses HERE or TomTom for flow and routing, Road511 slots in beside it for everything those feeds leave out. We do not resell anyone’s probe data, and a flow provider is not something we replace.

Try It

API docs — events, features, bridge clearances, truck data, and the GeoJSON variants in one reference.
Live map — see the normalized 511 data across all 64 jurisdictions.
Free API key — 14-day trial, no credit card.

Originally published on road511.com.