Real-Time Traffic Data for Custom Apps: A Developer's Guide

A developer asked me recently which open data sources he could use for real-time traffic in his application. The list is shorter than he expected, and the main reason is licensing.

The value of apps and APIs that do dynamic routing is including how fast vehicles are moving on a given road segment right now, compared to how fast they normally move. This is what lets an app route around congestion instead of just routing by distance. The raw material comes from infrastructure sensors embedded in road surfaces, road cameras, GPS pings from phones and in-vehicle devices, and GPS units in commercial fleet vehicles. Turning those inputs into a speed estimate for a road segment is where business models diverge. The red line on your map is that estimate.

The navigation apps many people have on their phones know exactly what’s happening on every road in real time. Getting that data into your own application, on your own terms, is a different problem entirely.

The Apps Already Have the Data

Waze, Google Maps, and Apple Maps maintain real-time traffic pictures built from the combined location signals of hundreds of millions of users. All three rely primarily on phone-based GPS. Your device records its position at regular intervals while the app is active, and those readings flow back to the company’s servers. Waze, which Google acquired in 2013, collects explicit incident reports alongside passive GPS tracking from every active session. Google Maps layers in anonymized position data from Android devices and users signed into Google accounts. Apple Maps processes location data on-device before it leaves the phone, and then aggregates the data.

Navigation apps work because more users mean better data, and better data attracts more users. You might remember people doing things like driving into a lake before the data improved from more widespread adoption!

Commercial Traffic APIs

The paid traffic API market draws on GPS readings from fleet vehicles, connected car partnerships, and the API vendors’ own user bases.

HERE Technologies offers a Traffic API covering incident data, flow data (how fast traffic is moving right now compared to that road’s normal uncongested speed), and a congestion severity score. HERE aggregates GPS readings from delivery and trucking fleets that continuously report location and speed, telematics data resold by fleet management software providers like Geotab and Samsara, and connected car manufacturers. TomTom, which has been in the navigation business since the early 2000s, sells a comparable product with coverage across more than 60 countries.

Google’s Routes API includes traffic-aware routing and is priced per request. Mapbox offers traffic-aware directions that draw on anonymized location and movement data from applications built with the Mapbox SDK, phone-based signals contributed by users of those third-party apps. Strava and BMW are some of the known Mapbox SDK integrations.

Coverage quality reflects the data source. Fleet-based signals (HERE, TomTom) are strongest on freight corridors and interstates, where commercial vehicles run constantly. SDK-based signals (Mapbox, Google) have broader urban coverage where app users are concentrated, but thin out on rural routes where they rarely drive.

Read the licensing terms as carefully as you evaluate the coverage. These APIs prohibit storing traffic data locally, displaying it outside their approved rendering environments, or using it to train models. You’re paying for access, not acquiring data. Build your application around those terms and you’re locked into them for the life of the product. That’s the default outcome if you don’t plan for it from the start.

Open and Government Sources

What governments publish is a different story. Publicly funded traffic data in the United States is unrestricted and free to use, although it can be limited.

In the US, many state departments of transportation expose real-time traffic displays. Most metropolitan areas participate in 511, a federal standard for traveler information that often includes incident data, construction notices, and speed readings from sensors embedded in the road surface that count vehicles and measure how fast they’re moving. North Carolina, for example, runs drivenc.gov through NCDOT, which publishes real-time incidents, construction notices, and road conditions across interstates and major state highways. NCDOT also exposes this data directly via a public REST API, with endpoints for incidents, road conditions, and county-level alerts returning JSON. California does something similar with the PEMS system. California also publishes downloadable data for a few districts via their DOT site. The GTFS Realtime specification covers public transit positions, trip updates, and service alerts.

By the way, the sensors behind this data are more visible than most people realize, though they serve two different purposes depending on where they’re installed. The traditional type is an inductive loop detector: a coil of wire buried just below the pavement surface, visible as rectangular or diamond-shaped saw cuts sealed with dark filler. At intersections, their primary job is signal control, detecting that a vehicle is waiting so the light can respond. On highways like I-40 or NC-147, the same technology shifts to flow monitoring. Sensors on on-ramps and at regular intervals along the highway count vehicles passing and measure their speed, feeding that data into DOT traffic systems. Newer deployments on both highways and arterials increasingly use camera or microwave sensor housings mounted on signal mast arms, pointed down at the lanes below, serving the same dual purpose. If you want to go down a real rabbit-hole, the FHWA Traffic Detector Handbook covers these sensors in detail.

The difficult truth is that while the data is collected via these publicly owned sensors, very little of it comes back out in a public API. You need to patch together multiple systems, using data from historical congestion, incidents, bus location, and published speed, to come up with only a good estimate of current traffic speed.

Licensing What You Get

On the plus side, government-published sensor data in the United States that you can get hold of is generally public domain with no restrictions. It works for any application, whether commercial or Free/Libre and Open Source Software (FLOSS).

Commercial API data isn’t yours to keep at all: the terms generally prohibit storage beyond a short caching window, redistribution, and use outside their approved rendering environments. This makes commercial APIs a poor fit for FLOSS development, since you can’t ship the data alongside your code or let users run their own instance against a local copy.

Crowd-Sourcing Your Own Traffic Data

There’s another option that doesn’t involve any third-party data at all: collecting GPS speed readings from your own users.

If your application already has an active user base with GPS access, you can record travel times over road segments and aggregate those observations into speed estimates. Waze and Google Maps use this same mechanism, just with hundreds of millions of users generating the coverage. At smaller scales, it works well for regional or specialized applications where your users are concentrated on the roads you care about. The honest constraint is coverage density: you need enough observations on a given segment to produce a reliable speed estimate. Below that threshold, the routing quality degrades in exactly the places where you most need it, and you won’t have good visibility into which segments those are until the gaps bite you.

The implementation uses an open routing engine like Valhalla or OSRM with a custom traffic layer you provide. Speed observations from opted-in users get pushed into the engine, which incorporates them into its routing calculations.

Which Source Fits Your Situation

Commercial APIs (HERE, TomTom, Google, Mapbox) make the most sense when you need broad coverage immediately and can live with per-request pricing. They’re the wrong choice if you need to store or reprocess the data in your own system. If your licensing requirements conflict with the API’s terms, or you’re building FLOSS, they’re off the table.

Open government feeds are underused where they exist, but there’s a catch. Again, most state DOTs collect real-time speed and congestion data from their sensor networks and use it internally, but don’t expose it as a developer-ready feed. What they do publish is usually incident and construction data. That’s useful for some applications, but it’s not the same as speed data on every road segment.

Finally, crowd-sourcing your own data is not a starting point. It only makes sense once you already have active users generating coverage on the roads you care about.

My Recommendation

If FLOSS licensing is a requirement, I recommend OpenStreetMap for the road network (ODbL, attribution required). Run Valhalla or OSRM on your own infrastructure, enriching it with whatever government sensor feeds cover your target region. You can extend it with opted-in GPS speed readings from your own users once you have the coverage. This stack is entirely open-source and does not depend on any third-party API terms.

If you need coverage quickly and commercial terms are acceptable, HERE and TomTom have the longer track record in traffic data specifically, and their APIs are designed for custom application development rather than consumer map products.

Don’t treat traffic data as an afterthought. Whether you’re storing your road graph in PostgreSQL with pgRouting or running a dedicated routing engine, the quality of your traffic inputs sets the ceiling on the quality of your results.

If you’re building something with open traffic data or working through the crowd-sourcing approach, drop me an email. I’d love to hear what you’re up to.