DEV Community: Roman Kotenko

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?country=DE&type=incident&status=active" \
  -H "X-API-Key: your_key"

{
  "data": [
    {
      "id": "de_mobilithek_4711",
      "country": "DE",
      "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&country=NL" \
  -H "X-API-Key: your_key"

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

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

curl "https://api.napspan.com/api/v1/events/corridor?\
from_lat=52.52&from_lng=13.40&\
to_lat=52.37&to_lng=4.90&buffer_km=5" \
  -H "X-API-Key: your_key"

One call, two NAPs (Mobilithek + NDW), one consistent response shape.

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 (nil-safe, optional)
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 hazmat 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,
      "axles":    5,
      "hazmat":   true
    },
    "alternatives": 1,
    "avoid": ["tolls"],
    "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_truck, or van), weight_t, height_m, and optional width_m, length_m, axles, and hazmat. 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, a projected_arrival_time, 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",
          "distance_along_route": 38200,
          "projected_arrival_time": "2026-05-29T15:12:00Z",
          "geometry": { "type": "Point", "coordinates": [-121.97, 47.51] },
          "properties": {
            "name": "I-90 over Snoqualmie Pass on-ramp",
            "clearance_m": 4.11,
            "truck_height_m": 4.2,
            "clearance_pad_m": 0.15,
            "deficit_m": 0.29
          }
        },
        {
          "type": "rail_crossing",
          "severity": "critical",
          "distance_along_route": 201400,
          "projected_arrival_time": "2026-05-29T17:41:00Z",
          "geometry": { "type": "Point", "coordinates": [-119.85, 47.20] },
          "properties": {
            "crossing_id": "BNSF-094821X",
            "grade": "at_grade",
            "public": true,
            "reason": "placarded_hazmat_mandatory_stop_49cfr39210"
          }
        },
        {
          "type": "traffic_event",
          "severity": "warning",
          "distance_along_route": 372600,
          "projected_arrival_time": "2026-05-29T19:08:00Z",
          "geometry": { "type": "Point", "coordinates": [-118.20, 47.45] },
          "properties": {
            "event_type": "construction",
            "description": "US-2 EB right lane closed for paving",
            "jurisdiction": "WA"
          }
        }
      ],
      "features": [
        { "type": "truck_parking", "distance_along_route": 250100,
          "properties": { "name": "Ritzville Rest Area", "spaces": 28 } }
      ]
    }
  ],
  "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, your truck_height_m, and the deficit_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();

  const conditionColors = {
    dry: '#22c55e', wet: '#3b82f6', icy: '#ef4444',
    'snow-covered': '#8b5cf6', flooded: '#f97316'
  };

  return L.geoJSON(data, {
    style: (f) => ({
      color: conditionColors[f.properties.condition] || '#6b7280',
      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 - Frost Zone 3",
      "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": "Zone 3",
        "from_location": "TH 10",
        "to_location": "CSAH 12"
      }
    }
  ]
}

Each restriction has:

Polyline geometry — the exact road segment, not just a point
Start/end dates — when the restriction is active
Weight limit — in tons (MN), as a percentage reduction (MI), or by road class (WI)
Location description — from/to landmarks

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

Message History

Road511 records every message change in the sign_message_history table. Only actual changes are stored (not every poll), so you get a clean timeline of what each sign displayed and when.

This is data that doesn't exist anywhere else publicly. No state DOT publishes a historical archive of DMS messages.

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

Bridge Clearance Data API for Fleet Routing

Roman Kotenko — Wed, 22 Apr 2026 22:00:00 +0000

If you're routing commercial vehicles, you need to know which bridges your truck can't clear. The FHWA National Bridge Inventory has 621,000 bridges with height and weight data — but it's buried in an ArcGIS FeatureServer with pagination limits and cryptic field codes.

Road511 normalizes all of it into one queryable API. Plus state-level bridge inventories from PA, OH, TX, VA, NY, FL, WA, and IN with enhanced detail.

The Data

Every bridge record includes:

Height clearance — vertical clearance in meters
Weight rating — operating and inventory load ratings in metric tons
Posting status — open, posted, posted_closed, closed
Condition ratings — deck, superstructure, substructure (0-9 scale)
Road carried and feature crossed — "I-80 over Passaic River"
Year built, ADT, inspection date — for infrastructure analysis

Query by Bounding Box

curl "https://api.road511.com/api/v1/features?type=bridge_clearances&bbox=-75.5,39.5,-74.5,40.5&limit=50" \
  -H "X-API-Key: your_key"

Returns every bridge in the Philadelphia metro area with clearance and weight data.

Corridor Search

The killer feature for fleet routing — query all restrictions along a route:

curl "https://api.road511.com/api/v1/truck/corridor?from_lat=41.88&from_lng=-87.63&to_lat=40.71&to_lng=-74.01&buffer_km=5&height=4.2&weight=36" \
  -H "X-API-Key: your_key"

This returns every bridge clearance, weight restriction, and truck restriction within 5km of the Chicago-to-NYC corridor that a 4.2m tall, 36-ton truck can't clear. The height and weight parameters filter results to only show conflicts.

GeoJSON for Route Overlays

curl "https://api.road511.com/api/v1/truck/corridor/geojson?from_lat=41.88&from_lng=-87.63&to_lat=40.71&to_lng=-74.01&buffer_km=5" \
  -H "X-API-Key: your_key"

Drop the response directly onto a map to visualize every restriction along the corridor.

Data Sources

Source	Bridges	Coverage
FHWA NBI	621,000	All US states + DC + PR
Pennsylvania PennDOT	56,000	PA bridges + 3K restricted roads
Texas TxDOT	58,000	TX posted bridges
Ohio ODOT	45,000	OH posted bridges
Virginia VDOT	40,000	VA posted structures
New York NYSDOT	2,300	NY posted load + height bridges
Washington WSDOT	10,800	WA bridge inventory
Indiana INDOT	4,400	IN LiDAR per-lane clearances
Florida FDOT	824	FL weight-posted bridges

Who Uses This

Fleet management software — pre-route clearance checks
Logistics platforms — automated route validation
Oversize/overweight permitting — clearance verification
Engineering firms — infrastructure condition analysis
Insurance — bridge condition risk scoring

Try It

Live map — zoom into any area to see bridge markers
API docs
Free API key

How to Get Real-Time Traffic Camera Feeds via API

Roman Kotenko — Sun, 19 Apr 2026 07:39:52 +0000

No major traffic data provider gives you camera feeds. Not HERE, not TomTom, not Google, not INRIX. They all sell traffic flow from probe data, but live camera images? Nobody aggregates that.

Road511 does. 10,000+ traffic cameras across 40+ US states and Canadian provinces, all accessible through one REST API.

The Problem

Every state DOT publishes camera images, but every one does it differently:

Georgia — JSON array with ImageUrl field, refreshes every 30 seconds
California — Caltrans CWWP2 SOAP-like API with district iteration
Ontario — Transnomis map markers with lazy-loaded detail popups
Kentucky — ArcGIS FeatureServer with paginated queries
Wyoming — XOR-encrypted protobuf binary files

Want cameras for a cross-state route? You're looking at 5+ separate integrations with different auth, formats, and update schedules.

One API Call

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

{
  "data": [
    {
      "id": "ca-cam-d7-101-001",
      "jurisdiction": "CA",
      "feature_type": "cameras",
      "name": "US-101 at Ventura Blvd",
      "latitude": 34.1583,
      "longitude": -118.4686,
      "is_active": true,
      "properties": {
        "image_url": "https://cwwp2.dot.ca.gov/data/d7/cctv/image/us101atventurabl/us101atventurabl.jpg",
        "direction": "Northbound",
        "highway": "US-101"
      }
    }
  ],
  "total": 1847,
  "has_more": true
}

The image_url is a direct link to the camera image. Most refresh every 30-120 seconds. Some cameras also have video_url for live streams.

GeoJSON for Maps

Want to drop every camera in a state directly onto a Leaflet map?

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

Returns a standard GeoJSON FeatureCollection. Add it to your map layer with zero transformation:

const response = await fetch(
  'https://api.road511.com/api/v1/features/geojson?type=cameras&jurisdiction=GA',
  { headers: { 'X-API-Key': 'your_key' } }
);
const geojson = await response.json();

L.geoJSON(geojson, {
  onEachFeature: (feature, layer) => {
    const { name, image_url } = feature.properties;
    layer.bindPopup(`
      <strong>${name}</strong><br>
      <img src="${image_url}" width="320" loading="lazy">
    `);
  }
}).addTo(map);

Bounding Box Queries

Don't know which states your route crosses? Use a bounding box:

curl "https://api.road511.com/api/v1/features?type=cameras&bbox=-118.5,33.7,-117.8,34.3&limit=50" \
  -H "X-API-Key: your_key"

This returns cameras within the LA metro area regardless of jurisdiction.

Lazy-Loaded Details

Some cameras return compact data in list mode but have richer detail available on demand:

curl "https://api.road511.com/api/v1/features/ab-cam-001/details" \
  -H "X-API-Key: your_key"

The detail endpoint fetches the latest image URL and any additional metadata directly from the upstream source, cached in Redis for performance.

What's Available

State/Province	Camera Count	Refresh Rate
California	~1,800	1-5 min
Ontario	~800	2-5 min
Georgia	~700	30 sec
Michigan	~780	2-5 min
Texas	~600+	1-5 min
Pennsylvania	~500+	2-5 min
And 35+ more...

Use Cases

Navigation apps — show live camera views at upcoming interchanges
Fleet dispatch — verify conditions before routing a truck
Traffic dashboards — wall of cameras for control rooms
Weather verification — ground-truth current road conditions
ML training — traffic density estimation from camera images

Try It

How to Get Real-Time Traffic Camera Feeds via API

Roman Kotenko — Sun, 19 Apr 2026 07:32:36 +0000

No major traffic data provider gives you camera feeds. Not HERE, not TomTom, not Google, not INRIX. They all sell traffic flow from probe data, but live camera images? Nobody aggregates that.

Road511 does. 10,000+ traffic cameras across 40+ US states and Canadian provinces, all accessible through one REST API.

The Problem

Every state DOT publishes camera images, but every one does it differently:

Georgia — JSON array with ImageUrl field, refreshes every 30 seconds
California — Caltrans CWWP2 SOAP-like API with district iteration
Ontario — Transnomis map markers with lazy-loaded detail popups
Kentucky — ArcGIS FeatureServer with paginated queries
Wyoming — XOR-encrypted protobuf binary files

Want cameras for a cross-state route? You're looking at 5+ separate integrations with different auth, formats, and update schedules.

One API Call

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

{
  "data": [
    {
      "id": "ca-cam-d7-101-001",
      "jurisdiction": "CA",
      "feature_type": "cameras",
      "name": "US-101 at Ventura Blvd",
      "latitude": 34.1583,
      "longitude": -118.4686,
      "is_active": true,
      "properties": {
        "image_url": "https://cwwp2.dot.ca.gov/data/d7/cctv/image/us101atventurabl/us101atventurabl.jpg",
        "direction": "Northbound",
        "highway": "US-101"
      }
    }
  ],
  "total": 1847,
  "has_more": true
}

The image_url is a direct link to the camera image. Most refresh every 30-120 seconds. Some cameras also have video_url for live streams.

GeoJSON for Maps

Want to drop every camera in a state directly onto a Leaflet map?

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

Returns a standard GeoJSON FeatureCollection. Add it to your map layer with zero transformation:

const response = await fetch(
  'https://api.road511.com/api/v1/features/geojson?type=cameras&jurisdiction=GA',
  { headers: { 'X-API-Key': 'your_key' } }
);
const geojson = await response.json();

L.geoJSON(geojson, {
  onEachFeature: (feature, layer) => {
    const { name, image_url } = feature.properties;
    layer.bindPopup(`
      <strong>${name}</strong><br>
      <img src="${image_url}" width="320" loading="lazy">
    `);
  }
}).addTo(map);

Bounding Box Queries

Don't know which states your route crosses? Use a bounding box:

curl "https://api.road511.com/api/v1/features?type=cameras&bbox=-118.5,33.7,-117.8,34.3&limit=50" \
  -H "X-API-Key: your_key"

This returns cameras within the LA metro area regardless of jurisdiction.

Lazy-Loaded Details

Some cameras return compact data in list mode but have richer detail available on demand:

curl "https://api.road511.com/api/v1/features/ab-cam-001/details" \
  -H "X-API-Key: your_key"

The detail endpoint fetches the latest image URL and any additional metadata directly from the upstream source, cached in Redis for performance.

What's Available

State/Province	Camera Count	Refresh Rate
California	~1,800	1-5 min
Ontario	~800	2-5 min
Georgia	~700	30 sec
Michigan	~780	2-5 min
Texas	~600+	1-5 min
Pennsylvania	~500+	2-5 min
And 35+ more...

Use Cases

Navigation apps — show live camera views at upcoming interchanges
Fleet dispatch — verify conditions before routing a truck
Traffic dashboards — wall of cameras for control rooms
Weather verification — ground-truth current road conditions
ML training — traffic density estimation from camera images

Try It

How to Get Real-Time Traffic Camera Feeds via API

Roman Kotenko — Wed, 15 Apr 2026 14:30:36 +0000

No major traffic data provider gives you camera feeds. Not HERE, not TomTom, not Google, not INRIX. They all sell traffic flow from probe data, but live camera images? Nobody aggregates that.

Road511 does. 10,000+ traffic cameras across 40+ US states and Canadian provinces, all accessible through one REST API.

The Problem

Every state DOT publishes camera images, but every one does it differently:

Georgia — JSON array with ImageUrl field, refreshes every 30 seconds
California — Caltrans CWWP2 SOAP-like API with district iteration
Ontario — Transnomis map markers with lazy-loaded detail popups
Kentucky — ArcGIS FeatureServer with paginated queries
Wyoming — XOR-encrypted protobuf binary files

Want cameras for a cross-state route? You're looking at 5+ separate integrations with different auth, formats, and update schedules.

One API Call

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

{
  "data": [
    {
      "id": "ca-cam-d7-101-001",
      "jurisdiction": "CA",
      "feature_type": "cameras",
      "name": "US-101 at Ventura Blvd",
      "latitude": 34.1583,
      "longitude": -118.4686,
      "is_active": true,
      "properties": {
        "image_url": "https://cwwp2.dot.ca.gov/data/d7/cctv/image/us101atventurabl/us101atventurabl.jpg",
        "direction": "Northbound",
        "highway": "US-101"
      }
    }
  ],
  "total": 1847,
  "has_more": true
}

The image_url is a direct link to the camera image. Most refresh every 30-120 seconds. Some cameras also have video_url for live streams.

GeoJSON for Maps

Want to drop every camera in a state directly onto a Leaflet map?

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

Returns a standard GeoJSON FeatureCollection. Add it to your map layer with zero transformation:

const response = await fetch(
  'https://api.road511.com/api/v1/features/geojson?type=cameras&jurisdiction=GA',
  { headers: { 'X-API-Key': 'your_key' } }
);
const geojson = await response.json();

L.geoJSON(geojson, {
  onEachFeature: (feature, layer) => {
    const { name, image_url } = feature.properties;
    layer.bindPopup(`
      <strong>${name}</strong><br>
      <img src="${image_url}" width="320" loading="lazy">
    `);
  }
}).addTo(map);

Bounding Box Queries

Don't know which states your route crosses? Use a bounding box:

curl "https://api.road511.com/api/v1/features?type=cameras&bbox=-118.5,33.7,-117.8,34.3&limit=50" \
  -H "X-API-Key: your_key"

This returns cameras within the LA metro area regardless of jurisdiction.

Lazy-Loaded Details

Some cameras return compact data in list mode but have richer detail available on demand:

curl "https://api.road511.com/api/v1/features/ab-cam-001/details" \
  -H "X-API-Key: your_key"

The detail endpoint fetches the latest image URL and any additional metadata directly from the upstream source, cached in Redis for performance.

What's Available

State/Province	Camera Count	Refresh Rate
California	~1,800	1-5 min
Ontario	~800	2-5 min
Georgia	~700	30 sec
Michigan	~780	2-5 min
Texas	~600+	1-5 min
Pennsylvania	~500+	2-5 min
And 35+ more...

Use Cases

Navigation apps — show live camera views at upcoming interchanges
Fleet dispatch — verify conditions before routing a truck
Traffic dashboards — wall of cameras for control rooms
Weather verification — ground-truth current road conditions
ML training — traffic density estimation from camera images