Before the next ITMS camera: a planner's diagnostic

Every Indian city has a version of this meeting. A municipal corporation, a traffic police commissioner, a smart-city consultant, and a vendor sit in a room. On the screen is a proposal for the next phase of ITMS expansion. Thirty new camera junctions. ANPR at twelve arterials. Signal upgrades at forty intersections. A budget that starts at ₹40 crore and negotiates upward.

The decision, on paper, is technical. In practice, it is almost always made on the same instinct: if traffic is getting worse, we need more eyes on the road. So the city adds eyes. Then, two years later, the traffic is still getting worse, and the next proposal lands on the same desk.

This article is not against cameras. Cameras do things no other system can do — enforcement, licence-plate capture, incident verification, evidence for prosecution. Those capabilities matter. The problem is that cities have quietly begun treating camera networks as traffic management systems, and the two are not the same thing. Cameras record the traffic. They do not explain it.

Before the next tender, a planner or commissioner can answer five questions on a single sheet of paper. If the current stack answers them cleanly, the next investment is well-founded. If it cannot, the gap is now visible — and visibility is cheaper than concrete.

1. How much of your road network can you actually see?

Begin with the coverage math, because the rest of the diagnostic depends on it.

A typical Indian city monitors between fifteen and twenty percent of its road network through its ITMS. The specific figure varies — some cities are lower — but the shape is the same. Cameras cover the junctions where cameras were installed. Everything else is a blind spot, because there is nothing watching it.

In Pune, our team monitors 833 road segments every day, using Google Maps probe data aggregated from anonymised smartphone navigation. Over a recent 45-day window, that produced 371,898 hourly observations — enough resolution to describe the actual shape of the network, not a sketch of it.

Here is the shape we see. The median road in Pune operates at 25.6 km/h. One hundred and thirty-five roads — 16.2% of the network — average below 15 km/h on a typical day. Forty-nine roads drop below 10 km/h at evening peak. Five average below 5 km/h during rush hour, which is slower than a person walking.

None of that distribution is visible from a camera network. You can see the worst junctions you installed cameras on, but you cannot see whether your city has twenty critical roads or a hundred and thirty-five, because the evidence only exists on the segments you are measuring. Every planning decision downstream — signal optimisation, enforcement deployment, corridor prioritisation, infrastructure tender — depends on knowing the real denominator.

If the answer to this first question is we don't know what our median road speed is, the next camera tender is being approved without a baseline. That is a hard thing to say in a procurement meeting. It is worth saying anyway.

2. Do you know which roads are structurally broken, and which are only congested?

Once you can see the network, a sharper question becomes answerable. Some roads are slow because something is going wrong. Other roads are slow because the road cannot physically support faster traffic. These two conditions look identical on a camera feed. They require opposite responses.

Take two roads from our Pune data. The first is Engineering College Chowk to RTO Chowk, a 646-metre arterial segment. Its free-flow speed — the speed the road is physically capable of, when nothing is in the way — is 24.3 km/h. Its actual average speed across the monitoring period is 8.1 km/h. That is a 3.0x congestion ratio. The road has proven capacity, and that capacity is being lost to something: signal timing, encroachment, illegal parking, turning-movement patterns, or some combination of all four. This is an addressable road. A targeted intervention — a signal retiming study, an enforcement sweep, a parking audit — can plausibly recover the lost capacity.

Now compare Subanshah Darga to Govind Halwai Chowk. Its free-flow speed is 8.9 km/h. Its actual evening-peak speed is 4.2 km/h. The ceiling is only 8.9 km/h. Even with a perfect intervention — perfect signals, no obstruction, no parking — the road physically cannot deliver a fast trip. The width, the geometry, the land use on either side all constrain it. This is a structural problem. It needs a land-use conversation, a redesign, a pedestrian reroute — not another enforcement effort.

"Spending camera budget on the first road is a credible investment. Spending it on the second is an optical win that delivers nothing measurable."

A planner needs to know which roads fall into which category before approving anything. Without a free-flow reference and a continuous speed signal, the two are indistinguishable.

3. Does your city have a rush hour — or a rush day?

Most ITMS deployments in India are shift-optimised around two peaks: the morning commute and the evening peak. Enforcement staffing, signal plans, and control-room rosters assume the midday window is quieter and the late evening is recovering.

The Pune data does not support that assumption.

From 7 AM to 9 PM — fourteen continuous hours — the city-wide average speed does not return to free-flow conditions. The morning decline begins at 6 AM and accelerates through the 8–10 AM window. Speeds remain suppressed between 22 and 24 km/h from 10 AM through 4 PM. The evening trough at 6–7 PM drops to 19.8 km/h. Recovery begins only after 8 PM.

There is no midday lull. The midpoint is almost as congested as the morning rush.

Friday sharpens this further. Friday 6 PM registers as 19.0 km/h — the single worst hour of the entire week. The day sees a 43% speed collapse between its off-peak and evening windows, the steepest single-day drop measured in the city. Saturday afternoon, contrary to the 'weekend relief' assumption, runs consistently slower than weekday afternoons from noon onward. Sunday is the only day of meaningful relief.

A traffic management roster built on the 8–11 AM and 5–8 PM assumption is over-serving the Monday–Thursday window and under-serving the Friday–Saturday window where the pain is worst. A signal plan that reverts to 'off-peak' settings at 12 PM is running off-peak settings during a 22 km/h period. A control-room shift that winds down at 7 PM is ending one hour into the worst speed hour of most weekdays.

Cameras do not change any of this. They cannot even describe it. This is a roster and a planning question, answerable only when the data is continuous across the whole day.

4. When a road deteriorates, can you tell an anomaly from a trend?

This is the question that separates a traffic monitoring system from a traffic management system. Most camera-led deployments cannot answer it.

A Monday morning report from our Pune deployment flagged CPR Pashan to NCL Guest House as the steepest week-over-week decline on the network. Speed fell from 46.6 km/h to 36.7 km/h — a 9.8 km/h drop, 21.1% worse than the same day the previous week.

On its own, that is ambiguous. It could be a one-day anomaly — a water tanker breakdown, a VIP motorcade, a local event. Control-room officers see numbers like this every day, and the instinct is to note it and move on.

What turns a number into a decision is the second layer: the rolling trend. Over the 7-day window ending February 16, the same road averaged 41.9 km/h, against a prior-7-day average of 46.3 km/h. A 4.4 km/h decline, sustained across a week. The daily drop is not noise. It is the visible tip of a trend that has been running for at least seven days and likely longer. That is almost certainly a physical change on the ground — new construction, a persistent obstruction, a signal timing drift, encroachment that no one has caught.

"A camera at the junction would record the congestion. It would not flag it as unusual, because there is no reference point for 'unusual' — the camera sees only what is in front of it, at this moment, without memory."

A planner needs to answer three separate questions every day. What changed yesterday? What has been trending for a week? What is structurally the same but worsening under load? The answers require baselines, not footage. Without them, the control room is firefighting, and every fire looks the same as the last one.

5. Can you measure the after against the before?

This question is the one commissioners should care about most, because it decides whether the next ten crores were worth spending.

A city widens an arterial. Retimes forty signals. Removes a bus stop. Opens a new overpass. Three months later, the commissioner asks the straightforward question: did it work?

In most cities, the honest answer is a shrug. Officer feedback, fewer complaints, a visual impression. There is rarely a clean measurement of before-and-after travel time on the affected corridor, because the data to construct 'before' was never collected continuously.

This is the most expensive gap in Indian traffic management. It means every infrastructure project is a leap of faith. It means enforcement drives cannot be shown to have reduced congestion. It means the team cannot justify the next budget cycle with evidence, because the last budget cycle was never measured.

A continuous, whole-network speed signal changes this. The intervention is defined. The corridor is tagged. The metric is pre-committed — speed uplift, delay reduction, congestion ratio, peak-hour recovery. The 'before' is already in the data, because it was being collected before anyone knew an intervention was coming. The 'after' is the next thirty days.

This turns traffic management into a measurable discipline. Most of what a traffic department does today can be reframed as experiments with unambiguous outcomes. A signal retime at Engineering College Chowk to RTO Chowk — a 3.0x congestion ratio road — becomes a falsifiable claim. If the ratio improves to 2.0x, the intervention worked. If it does not, the next option is on the table.

You cannot have this conversation without the baseline. More cameras do not supply it. Whole-network probe data does.

Before the tender

A planner reading these five questions should not feel cornered. The point is not that cameras are wrong. The point is that a camera budget and a data budget are different things, and cities have been buying the first while hoping it will answer the second.

If the current stack can tell you your median road speed, distinguish structural from addressable congestion, describe your actual hour-by-hour speed profile, separate anomalies from trends, and measure an intervention from before to after — the next tender is on solid ground.

If it cannot answer two of those, the gap is not a technology gap. It is a data gap. The data already exists. A billion smartphones generate it every day. The cost of turning that signal into a planning-ready dataset is a small fraction of what a single round of hardware costs — and, unlike hardware, it is ready in weeks.

The first question we ask a city considering TraffiCure is not how many cameras do you have? It is do you know what your network looks like? In most cases, the honest answer is that no one has ever seen it. Sixty days later, they have. The decisions that follow tend to be cheaper, more targeted, and measurably better than the ones that came before.

That is the only case that needs to be made.

Umang Saraf is Head of TraffiCure at Lepton Software. TraffiCure is an AI-powered traffic intelligence platform built on Google's Roads Management Insights, currently live in Pune and Kolkata. Pune data cited here is drawn from 45 days of continuous monitoring of 833 road segments, January–February 2026.