The Smart Intersection Investment That Mostly Isn't Being Used
Many cities have spent the past decade installing adaptive signal control systems, vehicle detection sensors, pedestrian countdown timers, and camera-based intersection monitoring. The infrastructure investment is real — federally funded CMAQ and HSIP projects have placed smart intersection hardware across hundreds of corridors nationwide. The systems are running. The cameras are counting vehicles and sometimes classifying them by mode. And in a significant proportion of cases, the data those systems produce is going directly into a traffic signal controller log that nobody outside the traffic engineering division reads.
This isn't a critique of traffic engineers — it's a systems observation. Intersection data infrastructure was built to support signal operations: adjusting phase timing, detecting queue spillback, managing emergency preemption. The data wasn't designed with transit planning or multimodal demand analysis in mind. But the data is there, it often has an API or data export pathway, and it contains mobility signal that transit planners and MPO analysts genuinely need.
The question is how to get that data into a form that's useful for transit demand analysis. The answer involves normalizing across highly heterogeneous API formats, reconciling different counting methodologies, and validating against other data sources before using intersection counts as demand signal. None of those steps is trivial, but they're tractable if you understand what the data actually contains.
What Intersection Camera APIs Actually Expose
There's no single standard for intersection camera APIs — this is one of the core challenges. Different vendors (Iteris, Econolite, Wavetronix, Siemens, and others) expose data in different formats, with different count aggregation windows, different mode classification schemes, and different authentication and access control mechanisms. Cities that have deployed multi-vendor signal systems may have three or four different API interfaces to navigate for a single corridor study.
The data elements that are commonly available, across most modern intersection management systems:
- Vehicle counts by approach and turning movement: The core output of most intersection detection systems. Counts are typically available in 15-minute bins for recent history and in hourly bins for longer archives. Some systems provide real-time event-level counts; others only expose aggregated data via export.
- Vehicle classification: Most modern camera-based systems attempt mode classification — distinguishing cars, trucks, buses, motorcycles, and in some systems, bicycles and pedestrians. Classification accuracy varies by camera placement, lighting conditions, and the underlying classification algorithm. In good conditions (well-lit, clear sightlines, modern AI-based classification), vehicle vs. bicycle vs. pedestrian accuracy is often reasonably high. Bus detection (relevant for transit planning) is generally reliable when buses operate on fixed routes with consistent visual signatures.
- Occupancy and speed data: Loop detector-based systems and radar-based systems often provide lane occupancy percentage and average speed in addition to volume. These are useful for congestion analysis but less directly useful for transit planning purposes.
- Phase timing data: Many modern signal systems expose signal phase timing data through the same API or a complementary endpoint. This is essential for transit signal priority analysis (covered in a separate post) and for modeling dwell time interactions at signalized stops.
Normalization: The Core Technical Problem
The practical challenge in using intersection camera data for transit demand analysis is normalization — converting heterogeneous count data from different systems into a consistent format that supports spatial aggregation and time-series comparison.
The specific normalization steps required:
- Count period alignment: If you're combining intersection data from two corridors where one system reports in 15-minute bins and another in 20-minute bins, you need to either re-aggregate to a common period or use temporal interpolation. For demand surface purposes, re-aggregating to 1-hour bins is usually appropriate and preserves the useful time-of-day variation.
- Turning movement to corridor directional flow: Intersection counts are reported by approach and turning movement — northbound through, northbound left turn, etc. For corridor-level transit demand analysis, you typically want directional total flows along the corridor: total vehicles traveling eastbound along the arterial. Reconstructing corridor flows from turning movement counts requires careful handling of approach/departure balance and consistent orientation conventions across intersections.
- Mode classification normalization: If two intersections on the same corridor use different classification schemes — one distinguishes bicycles, one doesn't — you need a strategy for the intersections where bicycle counts are missing. Substituting a regional bicycle mode share assumption is acceptable for exploratory analysis; for a formal planning study, it should be documented as a limitation.
- Location matching to H3 grid: Intersection latitude/longitude coordinates from the city's asset management database need to be geocoded to H3 cells. This is straightforward if coordinates are accurate; it requires manual review when intersection positions are approximate or when a study area spans multiple cities with different coordinate datum conventions.
Validating Intersection Data Before Using It in Demand Analysis
Before using intersection count data as demand signal in a transit planning analysis, run basic validation checks:
- Volume reasonableness: Do daily vehicle counts at the intersection match what you'd expect given the roadway classification and surrounding land use? A signalized arterial in a dense urban area might carry 15,000–30,000 vehicles per day; a suburban intersection might be 8,000–15,000. Values significantly outside those ranges warrant investigation — possible sensor malfunction, misconfigured aggregation, or API unit errors.
- Day-of-week pattern: Commercial corridors should show a consistent weekday-higher pattern; recreational corridors might show weekend peaks. If the day-of-week pattern is flat or inverted, the data may have quality issues.
- Cross-source comparison: Where corridor counts are available from both intersection cameras and a separate tube count or radar study, compare the two for order-of-magnitude consistency. Don't expect exact agreement — the methods count differently — but systematic differences of more than 20–25% warrant investigation.
We're not saying intersection camera data is unreliable for planning purposes. It's often quite useful. But it's never been through a quality assurance process designed for transportation planning applications, and no transit agency or MPO should treat it as ground truth without basic validation. The data lives in traffic engineering infrastructure that has different quality management priorities than planning analysis requires.
Integrating Intersection Data Into a Transit Demand Surface
Once normalized and validated, intersection count data contributes to a transit demand surface in two specific ways:
Congestion context for transit reliability modeling: Intersection-level vehicle volumes and occupancy data provide the congestion context that explains why buses running through specific intersections accumulate delay. A transit route that chronically runs 5–8 minutes late through a particular arterial segment is almost certainly experiencing intersection-induced delay. Intersection count data, combined with signal phase timing data, allows analysts to estimate the contribution of signal delay and vehicle queue delay to bus running times — input that's essential for transit signal priority feasibility analysis.
Pedestrian and cyclist demand as transit propensity indicator: Where intersection camera systems reliably classify pedestrians and cyclists, those counts are a useful proxy for non-motorized trip demand in the corridor. High pedestrian volumes at an intersection where there's no current bus service or poor transit access suggests there's walk-trip demand in the area that transit could serve or supplement. This is particularly useful for corridors where GTFS ridership data is sparse because service is currently limited — the intersection pedestrian counts give you a demand signal that precedes the transit service, rather than depending on observed ridership to infer latent demand.
API Access: Practical Considerations for Agencies
Gaining access to intersection camera API data requires either a city traffic engineering department with an open data portal or a direct relationship with the city's signal management team. A few practical notes:
Many cities have open data portals that include intersection count data, but the data is often batch-exported in annual or quarterly summaries rather than exposed as a real-time or near-real-time API. For planning analysis, batch exports are usually sufficient. For real-time transit operations monitoring, you'll need a direct API connection to the signal management system, which typically requires a data-sharing agreement with the city's transportation department.
For transit agencies that have existing relationships with the city DOT — as most do — a formal data-sharing agreement for intersection sensor data is a reasonable ask, particularly if the agency is already sharing GTFS feeds with the city's 511 or trip planning system. The data exchange has mutual benefit: transit agencies gain mobility demand context; DOTs gain bus ridership data that helps them understand signal timing impacts on transit performance.