DEV Community: Roman Kotenko

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

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

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

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

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

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

The Data Exists — in Two Forms

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

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

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

What a Parking Stop Needs to Tell You

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

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

Putting It on the Corridor

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

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

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

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

Where Parking Meets the HOS Clock

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

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

What You Can Build With It

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

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

Provenance, and the Honest Limits

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

Try It

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

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

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

Originally published on road511.com.

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

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

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

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

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

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

2. The Toll Bill Changes at Every Border

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

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

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

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

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

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

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

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

5. Charging an Electrifying Fleet, Across the Gaps

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

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

The Common Thread

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

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

Try It

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

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

Originally published on napspan.com.

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

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

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

1. Fifty States, Fifty Dialects

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

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

2. The Bridge Your Truck Doesn't Fit Under

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

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

3. The Limits That Appear Every Spring

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

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

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

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

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

5. The Data Is Stale the Moment You Cache It

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

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

The Common Thread

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

That's the entire premise of Road511: do that aggregation once, for everyone, and hand you one normalized API — events, features, bridge clearances, restrictions, routing with corridor hazards — instead of fifty integrations to keep alive. You spend your engineering time on the part that makes your product yours.

Try It

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

Originally published on road511.com.

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

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

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

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

How It Works

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

curl -X POST "https://api.road511.com/api/v1/routing/route" \
  -H "X-API-Key: your_key" \
  -H "Content-Type: application/json" \
  -d '{
    "origin":      { "lat": 41.8781, "lng": -87.6298 },
    "destination": { "lat": 39.7392, "lng": -104.9903 },
    "departure_time": "2026-06-08T06:00:00Z",
    "truck": {
      "profile":  "tractor",
      "weight_t": 36.0,
      "height_m": 4.2,
      "axles":    5,
      "hos": {
        "ruleset":           "us",
        "drive_remaining_s": 39600,
        "duty_remaining_s":  50400,
        "since_break_s":     0
      }
    },
    "enrichment": {
      "include_features": ["truck_parking", "rest_areas"]
    }
  }'

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

The HOS Clock

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

Field

Meaning

ruleset

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

drive_remaining_s

Driving-limit budget left.

duty_remaining_s

On-duty window budget left.

since_break_s

Driving time accrued since the last qualifying break.

elapsed_remaining_s

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

cycle_remaining_s

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

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

The Response

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

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

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

Reason

What tripped

break_required

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

drive_limit

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

duty_window

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

cycle_limit

The weekly/cycle budget ran out.

The Part That Matters: Reachable Parking

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

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

The Regimes

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

Ruleset

Regulation

Key limits

us

49 CFR 395 (FMCSA, property-carrying)

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

canada_south

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

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

canada_north

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

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

eu

Regulation (EC) No 561/2006

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

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

Where It Fits

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

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

Try It

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

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

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

Get Free API Key Read the Docs

Normalizing DATEX II Across 30 European National Access Points

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

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

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

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

The Spec, Then Reality

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

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

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

Where the NAPs Actually Diverge

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

1. Profile

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

2. Version

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

3. Transport

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

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

4. Authentication

The matrix here is wide:

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

5. Cadence and freshness

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

The Format Zoo, in DATEX II Form

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

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

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

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

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

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

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

Same regulation. Same standard. Three different parsers required.

The Architecture

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

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

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

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

Registration happens at init time:

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

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

The Normalized Model

Everything converges into two tables:

traffic_events — time-bounded incidents with lifecycle tracking:

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

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

The Hard Parts

1. Profile Field Mapping

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

2. Lifecycle Tracking

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

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

3. Coordinate Reference Systems

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

4. Rate Limiting at Scale

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

5. Schema-Free Feature Types

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

The API

After all that normalization work, the API is straightforward:

Get active incidents in Germany:

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

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

Get traffic cameras in the Netherlands as GeoJSON:

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

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

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

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

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

What's in the Data

Once normalized, the dataset includes:

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

Tech Stack

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

Try It

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

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

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

Ready to try NAPSPAN?

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

Get Free API Key Explore the Map

Truck Routing That Warns You Before the Bridge Does

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

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

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

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

How It Works

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

curl -X POST "https://api.road511.com/api/v1/routing/route" \
  -H "X-API-Key: your_key" \
  -H "Content-Type: application/json" \
  -d '{
    "origin":      { "lat": 47.6062, "lng": -122.3321 },
    "destination": { "lat": 47.6588, "lng": -117.4260 },
    "truck": {
      "profile":  "tractor",
      "weight_t": 36.0,
      "height_m": 4.2,
      "width_m":  2.6,
      "length_m": 21.0,
      "axle_count": 5,
      "hazardous": ["flammable"]
    },
    "alternatives": 1,
    "avoid": ["toll_road"],
    "enrichment": {
      "buffer_m": 100,
      "clearance_pad_m": 0.15,
      "min_severity": "warning",
      "include_features": ["truck_parking", "rest_areas"]
    }
  }'

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

The Response

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

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

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

The Warning Types

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

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

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

Tuning the Enrichment

The enrichment object controls how aggressively the corridor is scanned:

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

Saved Routes, Re-Evaluation, and Monitoring

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

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

Quota and Access

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

Why This Is Different

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

Try It

Fuel Price API for Fleet Cost Planning

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

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

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

The Sources

US — EIA (Energy Information Administration)

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

Canada — Statistics Canada

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

Both are official government data, free, and unrestricted.

Get Latest Prices

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

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

Historical Trends

Track how prices change over time:

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

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

Cross-Border Queries

Get both US and Canadian prices in one response:

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

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

Combine with Corridor Data

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

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

All from one API, one key, one integration.

Use Cases

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

Try It

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

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

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

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

What Each Provider Actually Offers

Data Type	Road511	HERE	TomTom	INRIX
Traffic flow (speed/congestion)	Limited (select states)	Yes (core product)	Yes (core product)	Yes (core product)
Traffic events/incidents	57 jurisdictions	Yes (own sources)	Yes (own sources)	Yes
Live cameras (10K+)	Yes	No	No	No
DMS sign messages	Yes (30+ states)	No	No	No
Bridge clearances (621K)	Yes	No	No	No
Truck routes (479K STAA segments)	Yes	No	No	No
Weight restrictions	Yes (multi-state)	No	No	No
Spring load limits	Yes	No	No	No
Road conditions (surface state)	Yes (15+ states)	No	No	Limited
RWIS weather stations	Yes (20+ states)	No	No	No
Rest areas & truck parking	Yes (30+ states)	No	No	No
EV charging (100K+ stations)	Yes	No	No	No
Fuel prices (state-level)	Yes (EIA + StatCan)	No	No	No
Event lifecycle history	Yes	No	No	No
GeoJSON native	Yes	No	No	No
Webhook notifications	Yes	Via HERE Platform	No	No

Pricing

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

Road511 at $29-99/mo is 10-100x cheaper than HERE/TomTom for similar request volumes, and has data categories they simply don't offer.

When to Use Which

Use HERE/TomTom if you need:

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

Use Road511 if you need:

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

Use both if:

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

The Real Differentiator

HERE, TomTom, and INRIX compete with each other on the same data: traffic flow. They spend hundreds of millions on probe data collection.

Road511 provides the infrastructure data that nobody else aggregates. 10,000 cameras, 621,000 bridges, 479,000 truck route segments, real-time sign messages, road conditions — all normalized from 57 government sources into one API.

The data is complementary, not competitive.

Try It

How to Build a Traffic Dashboard with Road511 + Leaflet

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

Let's build a real-time traffic dashboard from scratch. By the end, you'll have a map showing live incidents, camera popups with images, and road condition overlays — all powered by Road511's GeoJSON API.

Setup

Create an index.html with Leaflet:

<!DOCTYPE html>
<html>
<head>
  <link rel="stylesheet" href="https://unpkg.com/leaflet@1.9/dist/leaflet.css">
  <style>
    body { margin: 0; }
    #map { height: 100vh; }
  </style>
</head>
<body>
  <div id="map"></div>
  <script src="https://unpkg.com/leaflet@1.9/dist/leaflet.js"></script>
  <script src="app.js"></script>
</body>
</html>

Initialize the Map

// app.js
const API_KEY = 'your_api_key';
const BASE = 'https://api.road511.com/api/v1';

const map = L.map('map').setView([39.8, -98.5], 5); // center of US
L.tileLayer('https://tile.openstreetmap.org/{z}/{x}/{y}.png', {
  attribution: '&copy; OpenStreetMap'
}).addTo(map);

Layer 1: Traffic Events

async function loadEvents() {
  const bounds = map.getBounds();
  const bbox = [
    bounds.getWest(), bounds.getSouth(),
    bounds.getEast(), bounds.getNorth()
  ].join(',');

  const res = await fetch(
    `${BASE}/events/geojson?bbox=${bbox}&status=active&limit=500`,
    { headers: { 'X-API-Key': API_KEY } }
  );
  const data = await res.json();

  const severityColors = {
    critical: '#991b1b', major: '#ef4444',
    moderate: '#f59e0b', minor: '#22c55e'
  };

  return L.geoJSON(data, {
    pointToLayer: (f, latlng) => L.circleMarker(latlng, {
      radius: 6,
      fillColor: severityColors[f.properties.severity] || '#6b7280',
      fillOpacity: 0.8,
      stroke: false
    }),
    onEachFeature: (f, layer) => {
      const p = f.properties;
      layer.bindPopup(`
        <strong>${p.title}</strong><br>
        <span style="color:${severityColors[p.severity]}">${p.severity}</span>
        &middot; ${p.type}<br>
        ${p.affected_roads?.join(', ') || ''} ${p.direction || ''}
      `);
    }
  });
}

Layer 2: Cameras with Image Popups

async function loadCameras(jurisdiction) {
  const res = await fetch(
    `${BASE}/features/geojson?type=cameras&jurisdiction=${jurisdiction}`,
    { headers: { 'X-API-Key': API_KEY } }
  );
  const data = await res.json();

  const camIcon = L.divIcon({
    html: '📷', className: 'camera-icon', iconSize: [20, 20]
  });

  return L.geoJSON(data, {
    pointToLayer: (f, latlng) => L.marker(latlng, { icon: camIcon }),
    onEachFeature: (f, layer) => {
      const p = f.properties;
      layer.bindPopup(`
        <strong>${p.name || f.properties.id}</strong><br>
        <img src="${p.image_url}" width="320" loading="lazy"
             onerror="this.src='data:image/svg+xml,<svg/>'">
      `, { maxWidth: 350 });
    }
  });
}

Layer 3: Road Conditions

async function loadRoadConditions(jurisdiction) {
  const res = await fetch(
    `${BASE}/features/geojson?type=road_conditions&jurisdiction=${jurisdiction}`,
    { headers: { 'X-API-Key': API_KEY } }
  );
  const data = await res.json();

  // properties.condition is raw per-DOT text ("Bare Dry", "Cvd Snw", "3 - dry",
  // "Clear", ...), so key colors off keywords instead of exact enum values.
  const conditionColor = (c) => {
    const s = (c || '').toLowerCase();
    if (s.includes('clos')) return '#ef4444';
    if (/snow|ice|icy/.test(s)) return '#8b5cf6';
    if (/wet|rain|flood/.test(s)) return '#3b82f6';
    if (/dry|bare|clear/.test(s)) return '#22c55e';
    return '#6b7280';
  };

  return L.geoJSON(data, {
    style: (f) => ({
      color: conditionColor(f.properties.condition),
      weight: 4, opacity: 0.7
    }),
    onEachFeature: (f, layer) => {
      layer.bindPopup(`
        <strong>${f.properties.name}</strong><br>
        Condition: ${f.properties.condition}
      `);
    }
  });
}

Put It Together

const layers = L.control.layers(null, {}).addTo(map);

loadEvents().then(layer => {
  layer.addTo(map);
  layers.addOverlay(layer, 'Events');
});

loadCameras('CA').then(layer => {
  layers.addOverlay(layer, 'Cameras (CA)');
});

loadRoadConditions('CA').then(layer => {
  layers.addOverlay(layer, 'Road Conditions (CA)');
});

// Refresh events when the map moves
map.on('moveend', async () => {
  // Remove old events layer, load new one for current viewport
});

Auto-Refresh

Events change frequently. Add a 60-second refresh:

setInterval(async () => {
  eventsLayer.clearLayers();
  const newLayer = await loadEvents();
  newLayer.eachLayer(l => eventsLayer.addLayer(l));
}, 60000);

Next Steps

Add sign messages as a layer
Add weather stations with condition badges
Show truck restrictions along a corridor
Use the analytics endpoints to show a sidebar with incident trends

Try It

See a working example — built with this exact approach
API docs
Free API key
Full code examples

Spring Load Limits API for Trucking Compliance

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

Every spring, northern states and provinces impose weight restrictions on roads as frost leaves the ground. The pavement is weakest during thaw, and unrestricted heavy loads cause millions in damage.

The problem: every state publishes restrictions differently, with different dates, formats, and geographic references. Fleet operators check each state manually.

Road511 normalizes spring load limits from MN, WI, MI, ON, QC, and NS into one API with polyline geometry and active date ranges.

The Data

curl "https://api.road511.com/api/v1/features?type=weight_restrictions&jurisdiction=MN" \
  -H "X-API-Key: your_key"

{
  "data": [
    {
      "id": "mn-wr-zone3-seg12",
      "jurisdiction": "MN",
      "feature_type": "weight_restrictions",
      "name": "CSAH 5 (Southeast frost zone)",
      "start_time": "2026-03-10T00:00:00Z",
      "end_time": "2026-05-15T00:00:00Z",
      "properties": {
        "restriction_type": "seasonal_weight",
        "weight_limit_tons": 5,
        "frost_zone": "Southeast",
        "from_ref": "0+00.000",
        "to_ref": "9+00.995"
      }
    }
  ]
}

Each restriction has:

Polyline geometry — the exact road segment, not just a point
Start/end dates — when the restriction is active
Weight limit — MN posts a per-axle limit in tons (weight_limit_tons: a 5 means 5 t/axle, not gross), MI a percentage reduction, WI by road class
Segment endpoints — from/to mile-point references (from_ref/to_ref, e.g. 0+00.000), source-specific per state

Coverage

State/Province	Type	Details
Minnesota	Spring load limits	~26 segments with ton limits by frost zone
Wisconsin	Class II + Posted	148 restricted highways + 19 posted roads
Michigan	Truck Operator Route Map	~1,757 segments with 25-35% weight reductions
Ontario	Spring load limits	143 polyline segments
Quebec	Trucking network restrictions	Province-wide route restrictions
Nova Scotia	Spring weight restrictions	8,599 restricted segments

Corridor Check

Use the truck corridor endpoint to check if a planned route crosses any active restrictions:

curl "https://api.road511.com/api/v1/truck/corridor?from_lat=44.98&from_lng=-93.27&to_lat=46.87&to_lng=-96.77&buffer_km=10&weight=30" \
  -H "X-API-Key: your_key"

Minneapolis to Fargo — returns every weight restriction along the corridor that your 30-ton load would violate.

Historical Tracking

Road511 tracks when restrictions are posted and lifted via feature_history. Over multiple seasons, this data shows:

When each state typically starts/ends restrictions
Which zones get restricted first (geographic progression of thaw)
Year-over-year pattern changes

Try It

GeoJSON Traffic Events API with BBox and Radius Queries

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

If you're building a traffic map, the last thing you want is to parse a proprietary format and convert coordinates. Road511's GeoJSON endpoints return standard FeatureCollections that drop directly into Leaflet, Mapbox, MapLibre, ArcGIS, QGIS, or any GeoJSON-compatible tool.

GeoJSON Endpoints

Every list endpoint in Road511 has a /geojson variant:

GET /api/v1/events/geojson
GET /api/v1/features/geojson?type=cameras
GET /api/v1/truck/corridor/geojson

All return Content-Type: application/geo+json with a standard FeatureCollection.

Bounding Box Query

Show events in the current map viewport:

const bounds = map.getBounds();
const bbox = [
  bounds.getWest(), bounds.getSouth(),
  bounds.getEast(), bounds.getNorth()
].join(',');

const res = await fetch(
  `https://api.road511.com/api/v1/events/geojson?bbox=${bbox}&status=active`,
  { headers: { 'X-API-Key': key } }
);
const geojson = await res.json();
L.geoJSON(geojson).addTo(map);

Radius Search

Find everything within 50km of a point:

curl "https://api.road511.com/api/v1/events/geojson?lat=34.05&lng=-118.24&radius_km=50&status=active" \
  -H "X-API-Key: your_key"

Multiple Feature Types

Build a layered map with different feature types:

const types = ['cameras', 'signs', 'weather_stations', 'rest_areas'];

for (const type of types) {
  const res = await fetch(
    `https://api.road511.com/api/v1/features/geojson?type=${type}&jurisdiction=CA`,
    { headers: { 'X-API-Key': key } }
  );
  const geojson = await res.json();
  L.geoJSON(geojson, {
    pointToLayer: (f, latlng) => L.marker(latlng, { icon: icons[type] })
  }).addTo(layerGroups[type]);
}

LineString Geometry

Not everything is a point. Construction events, truck routes, and weight restrictions include polyline geometry:

{
  "type": "Feature",
  "geometry": {
    "type": "LineString",
    "coordinates": [[-87.63, 41.88], [-87.62, 41.89], [-87.60, 41.90]]
  },
  "properties": {
    "id": "fhwa-il-staa-001",
    "feature_type": "truck_routes",
    "name": "I-90 STAA National Network"
  }
}

Spatial Queries Under the Hood

Road511 uses PostGIS for all spatial operations. Every feature has a geometry column with a spatial index. Bounding box queries use ST_Intersects, radius queries use ST_DWithin on geography. The truck corridor endpoint builds a buffer geometry with ST_Buffer and intersects it against all truck-related features.

Try It

Live map — built entirely on Road511's GeoJSON endpoints
API docs
Free API key
Code examples

Real-Time DMS Sign Messages API: What's on the Highway Signs Right Now

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

Dynamic Message Signs (DMS) — those big electronic boards over highways — display real-time traveler information: incident warnings, travel times, amber alerts, construction notices.

Road511 captures the current message from every DMS sign across 30+ US states and Canadian provinces. Nobody else aggregates this data.

What You Get

curl "https://api.road511.com/api/v1/features?type=signs&jurisdiction=GA&limit=10" \
  -H "X-API-Key: your_key"

{
  "data": [
    {
      "id": "ga-sign-i85-042",
      "jurisdiction": "GA",
      "name": "I-85 NB at Clairmont Rd",
      "latitude": 33.8103,
      "longitude": -84.3179,
      "properties": {
        "message": "CRASH AHEAD / I-85 NB AT SR 42 / RIGHT LANE BLOCKED"
      }
    }
  ]
}

The message field contains the exact text currently displayed on the sign, including line breaks encoded as /.

Why This Matters

DMS messages are a leading indicator. The sign updates within minutes of an incident, often before the event appears in some 511 feeds. Cross-referencing sign messages with traffic events gives you:

Faster incident detection — sign changes before event feeds update
DOT response time analysis — how long after an incident before a sign is posted
Traveler information coverage — which corridors have DMS signs, which are blind spots
Historical message patterns — Road511 now tracks message changes over time

Use Cases

Navigation apps — show upcoming sign messages on the route
Traffic management — monitor DMS coverage and response times
Research — analyze traveler information effectiveness
Emergency alerting — detect amber/silver alerts from sign text

Try It

Live map — click any sign marker to see current message
API docs
Free API key