Video Analytics for Traffic Counting: An Urban Planning Guide

Why Cities Are Rethinking How They Count Traffic

For most of the last forty years, counting traffic meant installing a device that answers exactly one question. A pneumatic tube across a carriageway counts axles. An inductive loop buried in asphalt detects metal passing above it. A radar unit estimates speed on a single approach. Infrared beams register a break in a line. Each of these tools is cheap, proven and legally uncomplicated, which is why so many of them are still bolted to lamp posts and buried under resurfaced asphalt.

The problem is not that they are inaccurate. The problem is that they cannot see. A loop cannot tell you whether the vehicle above it was a delivery van blocking a loading bay, a bus running four minutes behind schedule, or a cyclist filtering through queued traffic. A tube cannot record that a pedestrian stepped off the kerb, hesitated, and stepped back. Modern street design decisions increasingly depend on precisely those distinctions — mode share, dwell times, hesitation at crossings, near misses — and single-purpose sensors are structurally blind to them.

Video analytics changes the cost structure of measurement. Once a camera is mounted and a detection model is running, each additional metric becomes a configuration change rather than a procurement exercise. Volume, class, speed, headway, queue length, turning movement, footway occupancy and conflict proxies all come from the same stream of frames. A city stops commissioning one-off studies and starts operating a permanent measurement layer that can be queried whenever a question appears: a cycle street trial, a school zone intervention, a bus route change, a review of a junction that residents keep complaining about.

There is an organisational shift buried in that sentence. Traditional counting is a project with a start date, an end date and a report. Video analytics is closer to infrastructure: it needs owners, maintenance budgets, data standards and a published methodology. Teams that treat it as a one-off study tend to be disappointed. Teams that treat it as a small piece of urban data infrastructure tend to get years of value from the same hardware.

How a Video Counting Pipeline Actually Works

Detection and classification

The first stage is object detection. A neural network processes each frame and outputs bounding boxes with class labels — car, van, bus, truck, motorcycle, bicycle, pedestrian, sometimes e-scooter or wheelchair. Modern detectors are typically convolutional or transformer-based, and they are trained on large annotated image sets.

Classification quality depends far more on the training distribution than on the size of the model. A detector trained mostly on daylight motorway footage will struggle on a wet Tuesday evening in a dense urban street full of cargo bikes, delivery vans, pedestrians crossing mid-block and reflections in standing water. This is the single most important procurement question you can ask: not "how accurate is your model?" but "how accurate is it on footage that looks like my street?"

Tracking and counting logic

A detector that fires on every frame counts the same car sixty times per second. The second stage, tracking, assigns a persistent identifier to each object across frames so that a vehicle is counted once. Tracking is where occlusion becomes the dominant source of error: when a bus hides three cars behind it, those cars may be merged, dropped, or re-identified as new objects when they reappear.

Counting itself is usually implemented in one of two ways. Virtual tripwires require a track to cross a defined line in a defined direction, which gives clean directional counts and turning movements. Zone occupancy reports how many tracks sit inside a polygon at a given moment, which suits queue measurement, parking bays and footway density. Most mature systems combine both, because tripwires alone cannot tell you how long a loading bay was blocked.

Derived metrics: speed, queue and conflict

From continuous trajectories you can derive things that spot sensors only approximate: average speed by vehicle class, headway distribution, queue length at a stop line, stopped delay per approach, and time-space diagrams along a corridor. These are the numbers that reveal whether a signal plan is actually working, not merely whether total volume changed.

Conflict analysis goes a step further. Proxies such as post-encroachment time and time-to-collision estimates let you study safety before collisions accumulate in a police record. They are surrogate measures, not replacements for crash data, but they surface risky turning movements and short intergreen times years earlier than a collision record would. Use them to prioritise, then verify with real outcomes.

Where inference runs

Inference can execute on the camera, on a roadside edge computer, or in a central data centre. Edge processing is usually the right default: bandwidth stays low because only metadata leaves the site, latency stays in the milliseconds, and the privacy surface shrinks because video never travels across the network. Central processing still makes sense for retrospective analysis, model retraining and cross-site dashboards.

Frame rate is a design decision, not a specification race. Counting and classification generally stabilise well below full frame rate, while speed estimation and conflict metrics benefit from higher rates. Matching frame rate to the metrics you actually need keeps compute predictable and avoids paying for detail nobody analyses.

Choosing Hardware, Mounting and Site Geometry

Mounting geometry decides whether your data is trustworthy long before any model runs. Steep downward angles simplify tracking because objects overlap less, but they flatten perspective and make speed estimation harder. Shallow angles capture long trajectories and better speed data, but suffer badly when vehicles hide behind one another.

A practical starting point for urban junctions is a mounting height of roughly six to ten metres with a downward tilt of twenty to forty degrees, chosen per approach rather than uniformly. On corridors, a series of mid-block cameras with overlapping fields of view produces cleaner time-space data than one heroic wide shot.

Lens choice matters as much as position. A wide lens covers more lanes but reduces pixels per vehicle, and small objects such as bicycles and pedestrians at distance become genuinely hard to classify. Where cyclists and pedestrians share your counting goals, place at least one camera close enough that a bicycle occupies a meaningful portion of the frame.

Hardware selection criteria worth writing into a specification:

• Low-light performance. Sensor size and aperture matter more than advertised resolution. Ask for sample footage at your site at night, not a datasheet.
• Wide dynamic range. Backlit scenes at sunrise and sunset are where cheap cameras fail silently.
• Weather-rated housing and glare shielding. A hood is cheaper than a replacement unit and much cheaper than bad data.
• Local storage or buffering. Connectivity drops. The system should keep counting and backfill when the link returns.
• Secure remote management. Firmware updates across dozens of sites need a controlled process, not a technician with a laptop.

Design redundancy into the geometry. If one camera goes offline, a neighbouring view should still cover the junction so the dataset does not develop invisible holes that quietly bias the analysis. A gap in coverage that nobody notices is worse than an obvious outage, because it produces confident-looking conclusions from incomplete evidence.

Finally, plan for cleaning. Dirty lenses and cobwebs degrade detection gradually rather than failing outright, which means the first symptom is a slow drift in counts rather than an alarm. Put cleaning on a maintenance calendar and log every visit.

Metrics That Matter for Planning Decisions

Not all measurable things are useful. The metrics worth building a programme around are the ones that map onto decisions someone is actually making.

Directional volume by class underpins nearly everything: network modelling, environmental assessment, mode share targets. Aggregated into fifteen-minute bins, it also reveals peaking patterns that annual averages hide.

Speed distributions — not just averages — tell you whether a speed limit is self-enforcing or merely signed. The 85th percentile speed is the number that survives scrutiny in a public meeting.

Queue length and stopped delay per approach are the practical currency of signal reviews. If you cannot show delay changing, you cannot defend a timing change.

Turning movements expose conflicts that approach-level volumes conceal. A junction can have modest total flow and still be dangerous because of one dominant turn.

Multimodal counts — cyclists, pedestrians, e-scooters, light goods vehicles — are essential for street design. Directional cycle counts, crossing volumes and footway occupancy all come from the same installation, which makes justifying a protected junction or a modal filter far easier.

Dwell and occupancy for loading bays, taxi ranks and parking bays turn curbside policy from anecdote into evidence. Freight behaviour varies strongly by weekday, season and delivery window, so continuous measurement outperforms periodic surveys here more than anywhere else.

Conflict proxies prioritise safety work. They are most useful as a ranking tool: which three junctions deserve attention first, and what specifically should change there.

From Raw Counts to Planning Workflows

Signal timing and corridor optimisation

With arrival profiles by approach and turning movement, timings can be tuned to measured demand instead of historical assumptions. The real value is in evaluation: before-and-after delay and queue measurements from the same system reduce the risk of attributing an improvement to the wrong intervention. If a junction improves in the same week that a nearby road closed, you need to know that before claiming the signal change did the work.

Street redesign and school zones

For redesigns, pair volume data with speed distributions and conflict analysis. At school zones, time-of-day pedestrian counts and vehicle speeds reveal whether a reduced limit is respected at the bell time or only at three in the afternoon on a quiet day. Use the data to choose between a raised crossing, kerb build-outs, narrowing or a modal filter — and set a measurable target you can revisit in twelve months.

Curbside, parking and freight

Loading bay occupancy, double-parking duration and dwell time by vehicle class inform kerbside management, enforcement priorities and freight policy. A common pattern: a bay that appears underused in an annual survey is actually saturated for ninety minutes each morning, which a continuous dataset shows immediately.

Cycling and pedestrian programmes

Cycle counts are politically powerful and technically demanding. Group movement, riders filtering between lanes, and crowded crossings all stress detectors. Validate bicycle and pedestrian classes separately, because aggregate accuracy can look healthy while pedestrian counts are off by a wide margin.

Data Standards, Validation and Quality Assurance

Decide early on a canonical output format: timestamped records with direction, class, speed band and a stable location identifier tied to your road network model. Standard transport exchange formats work, and so do plain CSV or JSON exports, provided time binning is consistent and timezone handling is documented. Nothing erodes confidence in an analytics programme faster than two dashboards that disagree about last Tuesday.

Validation should be routine, not a one-off acceptance test. Sample footage periodically, count it manually, and record the error per class per lighting condition. Keep the samples so that a future reviewer can reproduce your numbers.

Watch for drift. A camera nudged by a storm, vegetation growth, a new advertising panel or a changed lane marking can all degrade accuracy without triggering any alert. Build automated health checks for stream availability, detection rates and implausible values — such as a lane reporting zero vehicles for an hour — and log every model update so you can explain a step change in the data rather than guessing at it.

Version everything. When a model changes, keep the old version available for reprocessing historical footage, label the period when the change happened, and publish a short note. Transparency about method changes protects the credibility of the whole dataset.

Privacy, Governance and Public Trust

Process at the edge, store counts rather than video, and discard frames as soon as they have been analysed. Do not enable face or number plate recognition for counting purposes, even when the capability exists in the same box. Run a data protection impact assessment before installation, define retention periods explicitly, and document who may access raw footage and why.

Public trust is a design constraint, not a communications afterthought. Signage explaining what is measured and what is not measured prevents most of the friction. So does publishing a short methodology note: what the cameras count, how long metadata is kept, who can see it. Residents who discover cameras without explanation tend to distrust the whole programme, not just the hardware.

Questions worth putting to any supplier:

1. How is accuracy measured, on what data, and by whom?
2. Can the model be validated on our own footage before purchase?
3. What happens during a network outage or a power cut?
4. Which export formats and time bins are supported?
5. How are model updates versioned and communicated?
6. What happens to our data when the contract ends?

Vague answers to any of these become expensive later, usually at the moment you most need defensible evidence.

Common Mistakes and How to Avoid Them

The disappointing deployments fail for predictable reasons rather than exotic ones.

• Treating model output as truth. Detections are estimates with error margins. Validate before publishing anything controversial.
• Ignoring occlusion. Overlapping lanes, parked vehicles and bus shelters create systematic undercounts in specific directions — and systematic gaps are worse than random noise because they bias trends.
• Mixing incompatible datasets. Combining manual counts with automated counts without documenting method differences makes long-term trends meaningless.
• Time-of-day bias. A corridor measured only in the morning peak tells you nothing about evening freight or weekend cycling.
• Skipping the public conversation. Explain first, install second.
• Underestimating maintenance. Cleaning, calibration and firmware management are recurring costs, not setup tasks.
• Buying metrics nobody uses. Every metric should have a named consumer who will act on it.

A Pilot-to-Scale Roadmap

1. Define the decisions first. List the specific planning questions the data must answer, from junction redesign to kerbside policy.
2. Pick two or three representative sites. Choose different lighting, traffic mix and geometry so you learn where the model struggles.
3. Run a parallel validation period. Compare automated counts with manual observation for several days, including a weekend.
4. Write an internal accuracy report. Document per-class error, failure modes and the conditions where the system should not be trusted.
5. Finish one workflow end to end. Signal review or crossing assessment is a good first candidate.
6. Expand by pattern, not ambition. Replicate the validated configuration at similar sites before attempting complex junctions.
7. Review annually. Retrain or recalibrate as the street changes, because the environment the model learned is not the environment it will always see.

Track programme health alongside traffic metrics: data completeness, accuracy against ground truth, time from question to answer, number of decisions informed, and cost per measured site per period. Those operational numbers separate a system that produces impressive dashboards from one that genuinely shapes street design.

Frequently Asked Questions

Do we still need manual counts?

Yes, but less often and for different reasons. Manual observation remains the best way to validate automated output and capture context cameras miss, such as illegal manoeuvres or temporary works. Treat it as a calibration and audit tool rather than the primary source.

How accurate is video-based counting?

Under good conditions, modern detectors typically reach the high nineties in percentage terms for common vehicle classes. Accuracy drops in heavy rain, snow, low sun glare and dense occlusion, and it varies by class. Always request error figures broken down by class and condition rather than a single headline number.

Can the same cameras be used for enforcement?

Often technically yes, but enforcement brings legal, evidentiary and governance requirements far beyond planning analysis. Keeping measurement and enforcement as separate programmes avoids mixing standards and simplifies the public explanation.

What about cyclists and pedestrians in mixed traffic?

They are the hardest and most valuable classes to count. Models need training data covering crowded crossings, group movement and riders filtering through traffic. Validate these classes separately and place at least one camera close enough to resolve them clearly.

How much data should we store?

Store aggregates and event-level metadata for as long as policy requires, and store video for as short a period as possible — ideally none at all when processing happens at the edge. Long retention of raw footage adds risk without adding analytical value.

What if a model update changes historical trends?

Version everything, keep the previous model for reprocessing, label the transition period, and publish a short note explaining it.

Where should a city start?

Start with one corridor or one junction where a decision is already pending. Real decisions create accountability, and accountability produces the validation habits that make scaling straightforward. A pilot attached to a live project teaches more than a technical demonstration ever will.