DEV Community: Roman Kotenko

Your Fuel Plan Uses One Diesel Price. Europe Publishes 42,323.

Roman Kotenko — Thu, 29 Oct 2026 14:30:00 +0000

Diesel is the largest variable cost on almost every European haul, and it is the one a planner can actually move. Tolls are set by the route. Driver hours are set by 561/2006. Fuel is set by where the truck stops — and that decision is usually made against a single national average published once a week.

That average is not a price. It is a statistic computed over prices, and no station in Europe charges it. The gap between the statistic and the pump is where the money is, and it is bigger than most planning tools assume.

Everything below was measured in a single query against NAPSPAN production at 10:11 UTC on 29 October 2026. Fuel prices move daily, so treat the figures as a dated observation and re-run the queries yourself — each one is a live API call, not a number we are asking you to trust.

Three Countries Publish the Pump. Thirty-Five Publish the Building.

NAPSPAN carries 138,283 active fuel stations across 39 European countries. Of those, 42,323 carry an actual price, and they come from exactly three national registers:

Country	Stations in NAPSPAN	Carrying a price
Italy	24,142	21,652
Spain	11,418	11,371
France	9,821	9,300
The other 36 countries	~92,900	0

That is the honest shape of European per-station fuel data, and it is worth internalising before anyone scopes a project around it. Everywhere else — Germany, Poland, the Netherlands, the Nordics, the whole of the Balkans — a European fuel layer means locations. Where the forecourt is, what brand is on the sign, sometimes the opening hours. Not what it costs. We say why further down, because the reason is not technical.

Why the Average Hides the Decision

Take the base diesel grade in each of the three priced countries at the snapshot moment. Not the cheapest headline, not the outliers — the 10th percentile, the median and the 90th percentile of every priced station in the country:

Country	Priced diesel pumps	10th pct	Median	90th pct
Spain (`gasoleo_a`)	11,199	€1.739	€1.935	€2.019
Italy (`gasolio_self`)	20,289	€2.190	€2.249	€2.349
France (`gazole`)	8,993	€2.250	€2.399	€2.478

One note on the Spanish column before anyone plans a route with it: the Canary Islands, Ceuta and Melilla sit well below the peninsula and are not reachable by road from anywhere in this post. Their effect on the figure is small — drop the Canaries and the Spanish 10th percentile moves from €1.739 to €1.759 — but it is the kind of thing worth knowing you have in your denominator.

Read the medians across the rows and the first lever appears: €0.464 per litre between the French and Spanish medians. On a 600-litre fill that is €278, decided entirely by which side of a line the driver stops on.

National medians are still an abstraction, though, so narrow it to the regions on either side of the Pyrenean crossings:

Region	Priced diesel pumps	Median diesel
Navarre (`ESP-NC`)	231	€1.861
Catalonia (`ESP-CT`)	1,443	€1.899
Aragon (`ESP-AR`)	418	€1.935
Basque Country (`ESP-PV`)	341	€1.989
Nouvelle-Aquitaine (`FRA-NAQ`)	1,077	€2.389
Occitanie (`FRA-OCC`)	952	€2.395

Occitanie to Navarre is €0.534 per litre — roughly €320 on a 600-litre fill, over a distance a truck covers inside a single driving period. No weekly national figure on either side of the border contains that fact.

And there is a second lever that sits entirely inside one country. French stations are tagged with the road class they sit on. At the snapshot:

429 French stations on the autoroute network — median gazole €2.481.
8,564 French stations off it — median gazole €2.399.

An €0.082 per litre motorway premium, or about €49 a fill. A truck routed down an autoroute passes the expensive 429 by default; the cheaper 8,564 are the ones you have to deliberately look for, which requires knowing where they are and what they charge before dispatch, not after the fuel card statement arrives.

One `/features` Call, Prices Included

Per-station prices arrive in the same fuel_stations feature type as every other forecourt in the system, filtered the same way as any other layer:

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

{
  "data": [
    {
      "feature_type": "fuel_stations",
      "jurisdiction": "FRA-IDF",
      "name": "180 Rue d'Herblay, Taverny",
      "properties": {
        "city": "Taverny",
        "region": "Île-de-France",
        "highway_type": "R",
        "prices": {
          "gazole": {
            "value": 2.179,
            "unit": "litre",
            "currency": "EUR",
            "label": "Gazole",
            "updated": "2026-08-27T07:32:05+00:00"
          },
          "sp95": { "value": 2.059, "unit": "litre", "currency": "EUR", "label": "SP95", "updated": "2026-08-27T07:32:05+00:00" },
          "sp98": { "value": 2.1,   "unit": "litre", "currency": "EUR", "label": "SP98", "updated": "2026-08-27T07:32:05+00:00" }
        },
        "fuels_available":   ["Gazole", "SP95", "SP98"],
        "fuels_unavailable": ["E85", "GPLc", "E10"]
      }
    }
  ]
}

Note fuels_unavailable in passing: the French register also states which grades a station is currently out of, which is a different and occasionally more urgent fact than what it charges.

Three things about that payload will save you a week each.

1. There is no `diesel` key

Diesel is gazole in France, gasoleo_a in Spain, and gasolio_self in Italy — and those are just the base grades. Across the three registers the snapshot counts 130 distinct grade keys: 6 in France, 14 in Spain, and 110 in Italy, where branded premium diesels are reported as separate products under their marketing names. Any integration that looks up a hard-coded "diesel" field returns nothing in all three countries.

We keep the national keys rather than flattening them, because flattening loses information you need — a premium diesel is not the same product as the base grade, and pricing a fleet fill against the wrong one is a real error. Map the base grades once, ignore the rest, and you are done.

2. In Italy the same pump has two prices

12,875 Italian stations publish both a self-service and an attended diesel price, and the median difference between them is €0.200 per litre — with a maximum, at one site, of €0.806. That is €120 on a 600-litre fill riding on which of two keys you happened to read.

It is the most expensive misreading this dataset makes available, and it is invisible if you assume one station means one price. gasolio_self and gasolio_servito are different products at the same address.

3. Freshness is not uniform, and we do not paper over it

Each price carries its own updated stamp where the source publishes one, separate from when we polled. That matters because the three registers do not move at the same speed. At the snapshot:

France — all 8,993 priced diesel pumps carry a per-price timestamp. The median observation was from 27 October 15:55 UTC, under two days before the snapshot; 4,971 of them had been updated within 48 hours.
Italy — all 20,289 carry a timestamp. The newest read 29 October 10:35 and the median 28 October 13:31, both Italian local time (see the format note below), so the median Italian price was about a day old and 15,231 of the 20,289 were inside 48 hours. In September the same register ran two to three days behind, with under 1% inside 48 hours — so do not hard-code a lag in either direction; read the stamp.
Spain — publishes no per-price timestamp at all. You know when we last polled and nothing about when the operator last changed the number.

So read updated and age the value out on your own threshold. Italian and French prices are typically a day or two old, and the cadence has shifted between snapshots; a Spanish one is undated and must be treated accordingly. We would rather hand you the stamp and let you decide than stamp everything with our poll time and imply a freshness we did not measure.

One caveat on that field, since it is the kind of thing that silently breaks an alert: the French stamps track the source's own publication clock, not true UTC. At this snapshot 144 of the 8,993 French stamps sat in the future relative to our wall clock, the furthest ahead by 17 minutes. Compare these timestamps to each other, and do not build a “stale if older than n minutes” rule that assumes they are synchronised with yours.

Querying by place

And one more that costs an afternoon if you meet it in production: the stamp is not the same format in both countries that publish one. France emits ISO 8601 with an offset (2026-08-27T07:32:05+00:00); Italy emits 25/08/2026 08:02:02 — day-first, space-separated, no timezone at all. We hand both through as the register wrote them rather than silently reinterpreting a date we cannot verify the zone of, so a parser pointed at ISO will throw on all 20,289 Italian rows. Parse per country, and read an Italian stamp as local time.

France and Spain are keyed by region — 14 French and 19 Spanish subdivision codes carry priced stations (FRA-OCC, ESP-CT, and so on). Italy is a single national code, ITA. The bare country codes FRA and ESP are separate jurisdiction rows of their own, not parents, and they do not roll up their regions. At the snapshot, ESP held a single record of its own, unpriced, and FRA held 5 records of which 4 carried a price. That second number is the dangerous one: a query on jurisdiction=FRA returns four priced stations out of the country’s 9,300, so it neither errors nor comes back empty — it comes back looking like it worked. Use the regional codes, or skip codes entirely and ask spatially:

curl -H "X-API-Key: $KEY" \
  "https://api.napspan.com/api/v1/features?jurisdiction=FRA-OCC&type=fuel_stations&lat=43.60&lng=1.44&radius_km=50"

Where It Belongs: On the Route

Querying a region is the analysis path. The one that changes a fuel bill is prices arriving already attached to the route the truck is driving.

Fuel stations are a dense layer — mapped at essentially every interchange — so they ride a dedicated, lazy endpoint rather than the synchronous routing call. Compute a truck route, then ask for what is on it:

curl -H "X-API-Key: $KEY" \
  "https://api.napspan.com/api/v1/routing/route/saved/$ROUTE_ID/features?types=fuel_stations&buffer_m=300"

{
  "route_id": "01HKZ9P5XJVQ6NB8E2RTH4FMW7",
  "features": [
    {
      "type": "fuel_station",
      "name": "180 Rue d'Herblay, Taverny",
      "distance_along_route_m": 56200,
      "detour_m": 120,
      "side": "left",
      "source": "FRA-IDF",
      "properties": {
        "city": "Taverny",
        "highway_type": "R",
        "prices": { "gazole": { "value": 2.25, "currency": "EUR", "updated": "..." } }
      }
    }
  ]
}

Every match carries distance_along_route_m (how far along the route it sits), detour_m (how far off the line it is) and side (left or right of the direction of travel) — the three fields that turn a list of nearby stations into a refuelling plan, because a cheap pump on the wrong carriageway is not cheap. The station's full properties, prices included, pass through untouched. The call does not re-run the routing engine and does not count against routing quota.

It rides the same corridor as the toll cost, the truck bans and VMS signs, the live parking occupancy and the border queues. One route, and the answer to what will this trip cost and where does it stop comes back with it.

What You Cannot Get, and Why It Is Not a Coverage Gap

The obvious question about a three-country fuel layer is why it is only three countries. The answer is worth publishing, because the constraint is legal rather than technical and every team that scopes this project discovers it the expensive way.

Per-station prices exist in most of Europe. Reusing them commercially mostly does not:

Germany — prices are collected by the official market-transparency unit for fuel. Redistributing them requires authorisation as a consumer information service under German competition law. That is an application, not an API key, and until it exists Germany stays a roadmap item.
Austria — the public price service is shaped by regulation to return only the five cheapest stations per query, with no national bulk endpoint. A complete per-station layer is not merely restricted; it is impossible by design.
Portugal — per-station prices are published on a portal whose terms prohibit commercial use. The openly licensed distribution of the same dataset carries locations and metadata, without the prices.
Croatia — prices are shown on a ministry website; a formal request for a machine-readable open-data release was refused.
Lithuania — the national energy agency publishes strong daily per-station data and marks it all rights reserved.
Switzerland and Iceland — no government per-station feed exists at all. What circulates is a motoring-club product in one case and a community scrape of oil-company sites in the other. Neither is licensed for redistribution.

A handful are genuinely open and simply not built yet — Cyprus publishes under a share-alike licence, Slovenia publishes without stating one, and Denmark's per-brand publication became a legal obligation on 1 January 2026. Those are engineering work. The list above is not.

We would rather show you that map than colour in a continent and let you find out at integration time. A vendor claiming European per-station fuel coverage is either doing something we have concluded we cannot lawfully do, or is showing you locations and calling them prices.

The Honest Limits

Three countries. That is the coverage. France, Spain, Italy. The other 36 countries in the fuel layer are locations only. If your corridor is Rotterdam–Warsaw, this feature does nothing for you today, and we would rather say so now.
Not every station in those three is priced. Italy is 21,652 of 24,142 and France 9,300 of 9,821; Spain 11,371 of 11,418. In these three countries the station list now comes from the national registers alone, so an unpriced record is a register station with no current price, not a gap in the map. The absence of a prices object means unpriced, never free. Your code needs that third state.
Italian prices are about a day old. The median stamp was roughly 22 hours behind at the snapshot, after running two to three days behind in September. Good enough to choose between two regions, not good enough to promise a driver a number at the pump.
Spanish prices carry no observation time. You have our poll time and nothing else.
These are retail posted prices. They are not your fuel-card contract price, and no register publishes negotiated fleet rates. The spread between regions and road classes is a real signal about where to buy; the absolute figure on your invoice will be your own.
A price is a snapshot, not a forecast. The medians above are what 29 October looked like. Re-pull before you rely on them — and if a number in this post matters to your decision, the API call that produced it is printed above precisely so you can check whether it still holds.

The Common Thread

This is the same shape as the five road-data problems every cross-border European fleet hits, and as the useful road data that lives outside the National Access Points. Three governments publish something genuinely valuable, properly, under open licences. They publish it in three different schemas, with three different words for diesel, on three different cadences, with three different attribution obligations — and one of them counts the same pump twice on purpose. Doing that join once per country, and then keeping it working, is a permanent maintenance commitment that competes with whatever you actually sell.

NAPSPAN does the join once. The prices are open data and the credit travels with every record we hand you: French data under Licence Ouverte, with the Ministères économiques et financiers as licensor; Spanish data as Origen de los datos: Ministerio para la Transición Ecológica y el Reto Demográfico; Italian data as Dati: Ministero delle Imprese e del Made in Italy (MIMIT) — Osservaprezzi Carburanti, under the Italian Open Data Licence 2.0. Station locations outside the priced registers come from OpenStreetMap under ODbL. Every source is licence-classified before it ships, and the ones that fail that check are the countries listed above — which is why they are absent rather than quietly included.

Try It

API docs — /features with type=fuel_stations, and /routing/route/saved/{id}/features with types=fuel_stations
Live map — the priced networks as they stand right now
Free API key — no card, 14-day trial

Originally published on napspan.com.

When the Season Turns, “Is the Road Passable” Has 21 Different Answers

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

It is the middle of September and every winter feed we carry says the roads are fine. Illinois reports clear on 9,639 segments. Alberta and Saskatchewan say bare dry. California has 1,009 chain-control checkpoints live and every single one reads R-0 — no restriction in force. That is the correct answer today, and it is exactly why this is the right week to wire the layer, not the second week of November when a dispatcher is refreshing six DOT pages by hand at 5 a.m.

Because from October the thing that ruins a run usually is not an incident. It is a condition. Nothing is closed, nothing is crashed, there is no event to query — the road is simply covered, and the question is whether your driver should be on it. That question lives in a different dataset from the one your incident feed reads, and it is the least standardized dataset in North American road data.

Conditions Are Not Incidents, and They Are Not in Your Events Feed

An incident feed answers what happened at this point. A conditions feed answers what this stretch is like right now — which is a property of a segment, published on its own cadence, usually by a different part of the same agency. If you are reading only events, a corridor with 200 miles of snow-covered pavement and no crashes on it looks identical to a corridor in July.

We carry that layer as road_conditions. Here is what it actually holds, read from production on 17 September 2026, 12:42–13:02 UTC — a single snapshot, and a deliberately off-season one:

17,407 active condition segments across 21 states and provinces — Illinois 9,246, Alberta 1,237, Wisconsin 1,175, North Dakota 750, Ontario 546, Montana 544, South Dakota 542, Alaska 496, Québec 446, Nevada 434, Arkansas 393, Manitoba 366, West Virginia 276, Idaho 237, Yukon 156, Newfoundland & Labrador 156, Utah 145, Colorado 100, New Brunswick 87, Northwest Territories 59, Washington 16.
7,608 of them carry a LineString, so they are real stretches of road you can intersect with a route rather than pins on a map; 17,287 of 17,407 carry geometry of some kind.
All 21 sources were polled within a 20-minute window at that snapshot — oldest reading 12:42:05, newest 13:02:10. This is a live layer, not a nightly dump.

Six Field Names, Twenty-Seven Words, One Question

Here is the part that makes this a normalization problem rather than a plumbing one. Twenty-one agencies describe the same physical thing, and they do not agree on what the field is called, let alone what goes in it. Across the layer the condition text arrives under six different property names:

Property key	Who publishes it	Segments
`condition`	19 of 21 sources	16,216
`conditions` (in addition to `condition`)	Ontario, Colorado	646
`condition_category`	North Dakota	750
`condition_code`	Québec	446
`surface_conditions`	Alaska (part of its rows)	164
`road_condition`	Washington	16

And inside those fields, 27 distinct condition strings across the 19 sources that publish one. Some of them are the same state of the world wearing four different coats:

bare dry          1,275   (Alberta, Saskatchewan)
dry                 687   (3 sources)
bare and dry        309
3 - dry              75

Others are not descriptions at all. North Dakota publishes Green — a colour on its own scale, 750 segments of it. Québec publishes Ds and Dm, 309 and 137 segments, which mean something precise to Transports Québec and nothing to a dispatcher in Indiana. Several agencies offer good, fair and open, which are judgements rather than observations.

We do not flatten these into a severity score. That is a deliberate decision and it is worth stating plainly: inventing a five-point scale would mean deciding that Ontario’s normal_seasonal and Alberta’s bare dry are the same number, and we have no basis for that beyond our own opinion. You get the publisher’s own words, in one schema, on one endpoint, plus the jurisdiction that said them — so you can map the vocabulary to your own risk policy once, in one place, instead of writing 21 scrapers and then doing it anyway.

What the Layer Says Today, Off-Season

A conditions feed in September is mostly a feed reporting that it is September. That is the honest reading, and the distribution shows it:

Condition, as published	Segments	Sources
clear	9,639	2
no report	1,715	8
bare dry	1,275	2
seasonal conditions	750	1
dry	687	3
normal_seasonal	546	2

The interesting rows are the small ones, and they are all in the north, in September: 24 segments already read closed — Manitoba 11, Northwest Territories 11, Alberta 2. Alaska publishes no winter maintenance on 9. Yukon and Alaska carry difficult on 13 between them, and the Northwest Territories caution on 5. The season does not start everywhere on the same day, and the feed knows that before the calendar does.

no report is not clear. Those 1,715 segments across 8 sources mean nobody has filed an observation, which is a different fact from a road that has been looked at and found fine. Any rule you build on this layer has to treat the two separately, and we keep them separate rather than collapsing silence into good news.

Chain Control Is the One That Is Actually Actionable — and California Is the Only State Proven in Winter

Conditions tell you what the road is like. Chain control tells you what you are legally required to do about it, which is the only part of winter data that changes a driver’s next ten minutes rather than a planner’s afternoon.

We carry 1,009 California chain-control checkpoints, the only dedicated checkpoint feed in the set. Every one carries a complete record — chain_status, chain_control_active, elevation, county and district are populated on all 1,009 rows, which is a fill rate almost nothing else in North American road data achieves. On 17 September every checkpoint read R-0: no requirement in force.

This is also the one winter type that surfaces on a route. Ask for a truck route and an active chain control on it comes back as a warning in the response, keyed off chain_control_active. The R-1/R-2/R-3 escalation on Donner Pass in January is a real operational signal and it is wired end to end.

**Update, 15 October 2026:* this section first said chain control was one state. Since 11 October we also read the chain and traction requirement that Nevada, Idaho, Utah, Colorado and Washington publish on their road-condition segments — NV 434, ID 237, UT 145, CO 100, WA 16, so 1,941 rows across six states with California. Every row carries chain_control_active, and every row in the five new states keeps the operator’s own words in source_restriction_text. Measured on 15 October, 16:02 UTC: 0 active anywhere.*

Read that carefully before you lean on it. These five are not checkpoint feeds like California’s; they are a restriction field on the same segments listed above. Today they say “No Report”, “Dry”, “No restrictions” or a Colorado surface code, which proves only that the quiet case parses. Their winter wording has not been seen yet — it cannot be until it snows — and a phrase that names neither chains, traction nor a known code would read as inactive. The text is kept on every row so you can check it yourself, and we will re-measure after the first active row outside California. Oregon is enabled and has published no rows yet. For I-70 west of Denver or I-90 over Snoqualmie this layer now carries the segment; it has not yet proven it carries the requirement.

**Update, 22 October 2026 — the season has turned.* Measured 07:03 UTC. The first active row outside California arrived overnight: Nevada’s SR-431, the Mt. Rose Highway, reads “Chains Required, All Vehicles except 4-wheel drive with Snow tires” and parses as active, so the Nevada wording is now proven for that phrase — Idaho, Utah, Colorado and Washington still are not. In California five checkpoints have left R-0 for ROAD CLOSED: the seasonal closures over Sonora, Ebbetts and Monitor passes and the Tioga gate at Crane Flat. Those come back with chain_control_active set, which is a closure carried on the chain field rather than a chain requirement — read chain_status before you tell a driver to chain up. Across the conditions layer the vocabulary has grown from 27 distinct strings to 37, and Alaska now reports snow or ice on 353 of its 497 segments. The September figures above stay as they were measured; this paragraph is the October reading.*

Querying It

One feature type, one endpoint, filtered the same way as everything else we carry:

GET /api/v1/features?
  type=road_conditions&
  jurisdiction=MT&
  limit=2

Swap type for chain_controls to get the chain-control rows, drop jurisdiction to sweep all 21, or pass a bounding box to take a corridor rather than a state. The response carries the publisher’s condition text in properties under whichever of the six keys that agency uses, alongside the normalized fields — jurisdiction, geometry, last_seen_at — that are the same for every type in the system. The road_conditions and chain_controls layers are on every plan, free trial included.

The Honest Limits

Four of them, and as with everything else we publish they matter more than the headline count.

Wisconsin publishes no condition text at all. Its 1,175 segments arrive with segment and area_name and nothing else — a list of stretches with no state attached to them. They are in the layer because the segment list itself is useful and because the field may start arriving; they are not in it because we can tell you what those roads are like. That is 1,175 of 17,407 rows, and a naive count of “segments covered” would quietly include them.

Road conditions do not enrich a route. Chain controls do; conditions do not. Ask for a route today and you will get work zones, hazards, weigh stations, border crossings and chain controls shaped into warnings — and no road-condition warning, because the spatial rule for “this 40-mile segment is snow-covered and your route uses eleven miles of it” is not the same rule as “there is an incident 60 metres from the line”, and we have not shipped it. Query the layer directly and intersect it yourself, or wait; do not assume the route response has already checked.

The plow layer exists, and its counts are not trustworthy yet. We carry service_vehicles from 13 jurisdictions and today 1,222 of them are active — Pennsylvania 767, Indiana 243, Iowa 115. The lifecycle on this type flaps: a vehicle that stops reporting is deactivated and reactivated repeatedly, so the active count is a reading of who is transmitting this minute and not a measure of a state’s fleet or its effort. It is under repair. Until it is fixed, treat plow positions as a live sighting, never as a denominator.

Everything above is a September snapshot of a winter layer. The counts will be different in January — that is the entire point of it being an endpoint rather than a table in a PDF. Re-run the queries and you will get the day you are standing in.

Why Wire It in September

The work of adopting a conditions layer is not the querying. It is deciding what your operation does when Québec says Dm, what no report means for a load you have already quoted, and which of the 27 strings are allowed to hold a driver at a truck stop. That is a policy conversation with your dispatch team, and it is a much better conversation to have in September, against a live feed that says everything is clear, than during the first real storm of the season.

The feed is running now. Point it at your corridors and read a month of boring answers — that is how you find out what your rules should be before the answers stop being boring. Most of the road-data problems we write about in the five road-data problems every NA fleet team hits are this shape: the data exists, in 21 places, in 21 vocabularies, and the cost is never the fetching.

Try It

API docs — the /features surface, its jurisdiction and bounding-box filters, and the full feature-type list
Weather at the incident — the observation layer that sits next to this one
Free API key — no credit card, 14-day trial

Originally published on road511.com.

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

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

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

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

The Field That Looks Like an Answer and Isn’t

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

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

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

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

Where Live Status Actually Exists, and How Much of It

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

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

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

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

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

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

Per Connector, Because a Station Is Not a Unit

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

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

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

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

Three Things to Know Before You Build on It

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

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

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

The Same Call as Everything Else on the Corridor

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

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

What This Does Not Do

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

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

Try It

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

Originally published on napspan.com.

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

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

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

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

Opt In With `include`

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

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

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

The Response

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

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

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

Priced for the Vehicle, Not a Sedan

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

Routing Around Tolls

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

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

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

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

What to Expect From the Data

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

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

One Call, the Whole Trip

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

Try It

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

Originally published on road511.com.

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

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

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

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

What the Inventory Actually Says

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

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

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

On the Route

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

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

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

Query It Directly

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

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

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

What This Data Is Not

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

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

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

Provenance

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

Try It

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

Originally published on road511.com.

The Dates DOTs Publish Aren't the Dates They Hit

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

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

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

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

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

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

Eleven Weeks of Watching Dates Move

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

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

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

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

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

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

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

Querying It

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

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

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

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

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

Two Things Look Identical and Mean Opposite Things

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

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

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

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

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

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

What This Is Worth Downstream

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

The Honest Limits

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

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

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

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

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

The Same Mechanism, Beyond Construction

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

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

Try It

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

Originally published on road511.com.

What a Large-Vehicle Router Cannot Know

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

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

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

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

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

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

Twenty-seven names for one measurement

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

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

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

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

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

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

It is not just clearances

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

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

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

The point

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

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

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

Originally published on road511.com.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Three details in that payload matter more than they look:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

What This Data Does Not Do

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

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

The Common Thread

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

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

Try It

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

Originally published on napspan.com.

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

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

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

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

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

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

Both Halves, One Field, On the Route

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

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

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

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

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

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

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

The direction caveat, stated up front

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

Two Vocabularies for One Number

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

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

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

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

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

“No Delay” With Two Lanes Open

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

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

Closed Is a State, Not an Absence

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

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

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

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

How Much of It Is Actually Populated

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

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

The Same Query at Ten in the Morning

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

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

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

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

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

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

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

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

What We Don’t Do

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

The Same Field on the Other Side of the Atlantic

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

Try It

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

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

Originally published on road511.com.

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

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

“Crash on I-80, right lane blocked.”

That sentence describes two completely different events. In one, it’s a dry afternoon, the lane clears in twenty minutes, and the right call is to hold the load and wait. In the other, the pavement is iced, visibility is down to a quarter mile, and the wind is gusting across an exposed grade — in which case the crash you can see is the least interesting fact on the screen, because the conditions that produced it are still there, and they are about to produce another one three miles up.

Every incident feed on the market gives you the first sentence. Almost none of them tell you which of the two events it actually is. Dispatch doesn’t respond to incidents. Dispatch responds to incidents in context — and the context has to arrive attached to the incident, at the moment it appears, or it arrives too late to change the decision.

The Context Already Exists, Sitting in a Different Feed

State DOTs have spent decades installing roadside weather stations — RWIS, in the trade — the instrumented poles that report air temperature, wind, visibility, humidity, precipitation type, and, critically, what the road surface itself is doing — dry, wet, icy, snow-covered. Each agency says that in its own words rather than a shared vocabulary, which turns out to matter a great deal and which we come back to in detail below.

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

The data is public, official, and already flowing. The problem is that it lives in a different layer from the incidents, on a different schema, keyed to different geometry. So the dispatcher gets an incident in one panel and a weather map in another, and does the spatial join in their head, under time pressure, at 3am. That join is the product.

Every Event Carries Its Own Weather

When a new incident lands in Road511 — a crash, a closure, a work zone — we immediately look for the nearest active weather station within 50 km and write down what it was reporting at that moment. That reading is stapled to the event, permanently. Here is an actual record, pulled from the production database as this post was last revised — a Pennsylvania crash on I‑70 from the afternoon of 16 August 2026, verbatim:

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

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

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

The distance_km field is doing real work there, and it’s the reason we return it. A station 1.8 km from the incident is describing the incident. A station 46 km away is describing a different valley, and you should discount it accordingly. Across the whole archive the average snapshot sits about 16 km out, so this is a filter you will actually use. We don’t hide that number behind a confidence score we made up — we give you the distance and let you decide what it’s worth.

What those field values actually look like

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

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

From Anecdote to a Number You Can Argue With

“Bad weather causes accidents” is a thing everyone knows and nobody can put a figure on. Once an event carries a snapshot, the figure becomes a query. Group the incident history by what the road was doing and what was falling out of the sky:

GET /api/v1/analytics/weather-correlation?jurisdiction=OH

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

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

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

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

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

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

On the Route

Weather stations also ride the corridor. Send a route to POST /routing/route and the stations near the line come back in warnings[] as type: "weather", each carrying its readings and the time the truck is projected to reach it — the same channel that already carries bridge clearances and corridor hazards.

Be clear about what that is and isn’t. Those weather markers are surfaced at info severity, as observations. Road511 does not currently threshold them — there is no rule that escalates “road_surface: ice” to a warning, no wind-speed limit that trips a flag for a high-profile trailer. The reading is handed to you; the policy is yours, because the policy is genuinely yours: the wind speed that stops a loaded reefer is not the one that stops a flatbed, and we’d rather give you the number than guess your fleet’s tolerance. When you write that policy, apply the two cautions above — the surface strings are the agency’s vocabulary rather than an enum, and wind and visibility carry no unit — because a threshold is exactly where an unnormalized field does its damage.

And the segment-level road_conditions layer — the DOT’s own “this stretch is snow-covered” assessment — is not enriched onto routes today. It’s queryable as a layer over any bounding box or corridor you define, but it does not currently arrive attached to a route response. If route-level surface state is what you need, that’s a gap, and we’d rather tell you now than have you discover it in integration.

What You Can Build With It

Triage that reads the conditions, not just the headline — auto-escalate an incident whose snapshot shows a freezing temperature and an icy surface string, before a human has read the description. (Both halves: the surface string alone will fire on a summer sensor alarm.)
Winter corridor scorecards — rank your lanes by the severity they produce under the same conditions. The endpoint for this exists today; the archive to fill it starts accumulating its first winter in November 2026.
Post-incident review that isn’t guesswork — when a load is late or a claim is filed, the conditions at the event are already recorded, timestamped, and attributable to a named agency’s station.
Driver-facing condition alerts — surface the observations along the route with your own thresholds applied, tuned to the trailer.
Weather beside everything else on the corridor — conditions alongside work zones, planned construction, and closures in one schema.

Provenance, and the Honest Limits

These readings come from state DOT roadside stations — official instruments, not a modelled forecast and not crowd-sourced. That’s the strength, and it dictates the limits, which are worth stating plainly.

The snapshot is taken once, at the moment the event is created, and never refreshed. It answers “what were the conditions when this appeared,” which is the question that matters for triage and for later analysis. It does not track how the weather evolved over the life of a six-hour closure. For current conditions, query the station directly — /analytics/weather returns its reading time-series.

If no active station sits within 50 km, the event gets no snapshot at all. We do not reach further and pretend a reading from the next county describes this stretch of road. On a rural corridor, expect gaps; a missing snapshot is an honest absence, not a zero.

Readings pass through in the units the reporting agency publishes. Most US stations report Fahrenheit, miles, and miles per hour — but not all of them: British Columbia and, of all places, California publish Celsius. So temperature is the agency’s own number, and temperature_c sits beside it, normalized, for when you need to compare or average across jurisdictions. Where we haven’t established a feed’s unit, temperature_c is simply absent rather than guessed — roughly a quarter of snapshots carry it — and the correlation endpoint leaves those readings out of its average instead of blending them in.

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

This is observation, not prediction. There is no weather forecasting here, and we’re not going to bolt a forecast model onto a road-data API and call it dispatch intelligence. What we do is guarantee that when an incident exists, whatever the nearest station measured exists next to it, in one schema, from 4,082 stations we keep parsed and current as their feeds drift — so that job isn’t yours.

Weather snapshots, the correlation endpoint, and the reading time-series are analytics-tier features (Pro and above). The underlying weather_stations and road_conditions layers are available on every plan, free trial included.

Try It

API docs — the analytics surface, plus the weather_stations and road_conditions feature types
Live map — see the station network and current road conditions
Free API key — no credit card, 14-day trial

Originally published on road511.com.

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

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

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

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

Planned Work Is a Different Dataset Than Active Work

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

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

Planned construction comes from somewhere else entirely: the agency’s project pipeline. A DOT’s capital program, its STIP project list, the “upcoming closures” page maintained by the district office. These records exist before a single cone is placed — but how far before depends entirely on the agency, and that variation is the first thing to plan around. Delaware’s pipeline carries start dates booked into 2030; Virginia’s layer is overnight lane work on a roughly three-day horizon, with a median window of eight hours. Same feature type, two very different horizons: bound your query window rather than trusting the field to mean the same thing everywhere. What these records do carry, and live feeds lack, is a projected start and end date. They also carry the property that makes them awkward to consume: those dates are estimates, and they move.

Where the Dates Come From

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

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

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

Asking the Question Directly

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

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

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

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

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

Two caveats on that example. total is a live reading, not a constant — run the query rather than quoting the number. And Virginia is the short-horizon case described above: it publishes overnight lane work about three days out, so the same query aimed at a month further ahead returns almost nothing. That is a property of the agency, not of the API. For a long-horizon pipeline, run it against jurisdiction=DE, whose records carry start dates years out.

Two details worth knowing

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

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

The Dates Move. That’s the Interesting Part.

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

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

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

That turns a static schedule into a signal. A project that has been rescheduled four times is telling you something a single date field never could. At the jurisdiction level, /analytics/scorecard asks the same question of a wider pool — how far does an agency move the end dates it publishes? — so you can calibrate how much slack a given DOT’s published dates historically need. It rolls up event-modelled roadwork rather than the future_construction records above, and it reports only the jobs whose revisions we can still see, so read the two as complementary views of the same habit rather than one number. Both live behind the analytics tier (Pro and up); the future_construction records themselves are available on every plan, free trial included.

What You Can Build With It

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

Provenance, and the Honest Limits

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

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

Try It

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

Originally published on road511.com.

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

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

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

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

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

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

Why "Average Border Wait" Is a Useless Number

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

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

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

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

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

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

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

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

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

The Part That Changes Dispatch: It Rides the Route

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

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

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

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

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

What to Expect From the Data

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

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

The Common Thread

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

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

Try It

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

Originally published on napspan.com.

DEV Community: Roman Kotenko

Your Fuel Plan Uses One Diesel Price. Europe Publishes 42,323.

Three Countries Publish the Pump. Thirty-Five Publish the Building.

Why the Average Hides the Decision

One /features Call, Prices Included

1. There is no diesel key

2. In Italy the same pump has two prices

3. Freshness is not uniform, and we do not paper over it

Querying by place

Where It Belongs: On the Route

What You Cannot Get, and Why It Is Not a Coverage Gap

The Honest Limits

The Common Thread

Try It

When the Season Turns, “Is the Road Passable” Has 21 Different Answers

Conditions Are Not Incidents, and They Are Not in Your Events Feed

Six Field Names, Twenty-Seven Words, One Question

What the Layer Says Today, Off-Season

Chain Control Is the One That Is Actually Actionable — and California Is the Only State Proven in Winter

Querying It

The Honest Limits

Why Wire It in September

Try It

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

The Field That Looks Like an Answer and Isn’t

Where Live Status Actually Exists, and How Much of It

Per Connector, Because a Station Is Not a Unit

Three Things to Know Before You Build on It

The Same Call as Everything Else on the Corridor

What This Does Not Do

Try It

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

Opt In With include

The Response

Priced for the Vehicle, Not a Sedan

Routing Around Tolls

What to Expect From the Data

One Call, the Whole Trip

Try It

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

What the Inventory Actually Says

On the Route

Query It Directly

What This Data Is Not

Provenance

Try It

The Dates DOTs Publish Aren't the Dates They Hit

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

Eleven Weeks of Watching Dates Move

Querying It

Two Things Look Identical and Mean Opposite Things

What This Is Worth Downstream

The Honest Limits

The Same Mechanism, Beyond Construction

Try It

What a Large-Vehicle Router Cannot Know

Twenty-seven names for one measurement

It is not just clearances

The point

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

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

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

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

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

What This Data Does Not Do

The Common Thread

Try It

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

Both Halves, One Field, On the Route

The direction caveat, stated up front

Two Vocabularies for One Number

“No Delay” With Two Lanes Open

Closed Is a State, Not an Absence

How Much of It Is Actually Populated

The Same Query at Ten in the Morning

What We Don’t Do

The Same Field on the Other Side of the Atlantic

Try It

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

The Context Already Exists, Sitting in a Different Feed

One `/features` Call, Prices Included

1. There is no `diesel` key

Opt In With `include`

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