Project facts & technologies
Citation-friendly summary of the AI-Powered Traffic Monitoring System — each row is a clean entity-attribute pair for analysts, journalists, and AI search systems.
- Client context
- Urban traffic authority with manual monitoring and limited real-time visibility
- Industry segment
- Urban Traffic Management, Smart City, ITS
- Engagement type
- Real-time CV traffic monitoring platform — design, build, and deployment
- Detection accuracy
- 92–96% vehicle detection and classification accuracy
- Camera uptime coverage
- 90–95% live camera coverage across the deployed network
- Monitoring cadence
- Real-time — continuous processing of live camera feeds
- Vehicle classes detected
- Car, bus, truck, two-wheeler, and other classes as configured
- Detection model
- YOLO object detection (per-frame detection and classification)
- Tracking layer
- Object tracking — cross-frame vehicle identity, trajectory, direction, unique-vehicle counting
- Image pipeline
- Python + OpenCV — RTSP ingestion, frame sampling, lens correction, quality check, ROI extraction
- Traffic analytics
- Vehicle counts by class, flow rate and speed, congestion index per zone, peak-hour patterns, anomaly detection
- AI optimization engine
- Signal-timing recommendations, peak-hour traffic control, diversion strategies
- API and hosting
- Flask / FastAPI on AWS — S3 for media and history, EC2 for inference and APIs
- Downstream consumption
- Live traffic dashboard, signal control recommendations, enforcement alerts, historical analytics, citizen APIs
- Operational benefits
- Reduced congestion, faster incident response, fewer enforcement gaps, lower pollution, better road utilisation
- Built by
- AiSPRY — applied AI and computer vision for industrial, healthcare, smart-city, and enterprise operations
The visibility gap in urban traffic management
Cities have spent decades building out camera networks at their most important intersections, corridors, and peak-hour control points. The infrastructure to see urban traffic in real time already exists — what has historically been missing is the layer that turns those camera feeds into actionable, real-time understanding. Manual monitoring covers only a fraction of the network at any given moment, and the decisions that move traffic — signal-timing adjustments, peak-hour controls, diversion responses to incidents — get made on stale data or on operator judgement alone.
The visible cost of this gap is unpredictable congestion. The invisible cost is larger: delayed incident response (because no one sees the incident until the queue is already minutes long), inconsistent enforcement of peak-hour policies (because monitoring depends on staffing levels at each checkpoint), and the absence of any real feedback loop from "what signal timings did we choose" to "what congestion patterns resulted." Without the loop, signal plans tend to ossify around the pattern they were designed for, even as the underlying traffic pattern changes.
What city traffic authorities actually need is not another camera. They need a real-time intelligence layer on top of the cameras they already have — one that detects every vehicle, tracks each one across frames to enable accurate counting and flow estimation, computes congestion at the zone level, recognises peak-hour patterns as they emerge, flags incidents the moment they appear, and produces recommendations that operations teams can act on directly.
What business problem does the platform solve?
Urban traffic management suffered from unpredictable congestion and manual monitoring, making it difficult to detect congestion early, optimise signal timings, and enforce peak-hour policies. The result was longer travel times, higher pollution, and inefficient road usage. The platform needed to address four specific failure modes that no manual monitoring regime could close on its own:
Four failure modes the platform had to close
- Manual monitoring covered only a fraction of the network — control-room operator capacity is limited, so most cameras were reactive; issues were noticed only after they had escalated.
- Congestion was recognised late — without continuous, automated congestion estimation, build-ups were typically identified only after the window to intervene with signal-timing changes had already closed.
- Signal timings did not adapt to actual traffic patterns — fixed plans drifted out of alignment with reality as developments, work schedules, seasonal effects, and construction changed the pattern.
- Peak-hour policy enforcement was inconsistent — enforcement that depends on staffed checkpoints is inherently uneven, and the gaps between checkpoints became known to drivers, undermining the policy.
How does the AiSPRY platform work?
AiSPRY built the AI-Powered Traffic Monitoring System as a six-layer real-time computer vision platform. Live feeds from the city camera network are ingested through an OpenCV streaming pipeline; the computer vision core runs YOLO object detection for per-frame vehicle identification and an object tracking layer for cross-frame identity (the prerequisite for accurate counting and flow analysis); a traffic analytics layer produces vehicle counts, flow rates, congestion indices, peak-hour patterns, and anomaly detection; an AI optimization engine converts the analytics into signal-timing, peak-hour-control, and diversion recommendations; and a Flask / FastAPI service on AWS surfaces the outputs to dashboards, signal controllers, enforcement teams, and citizen APIs.
01 · City camera network
- Intersection cameras cover signal junctions; corridor cameras provide flow and density visibility along stretches.
- Peak-hour checkpoint cameras anchor policy enforcement zones.
- Pedestrian and mixed-use cameras cover crossings and school zones.
- A camera health monitor tracks uptime and feed quality so the operations team always knows what is and is not being observed.
02 · Video streaming and pre-processing — Python + OpenCV
- Live RTSP streams flow into a Python and OpenCV pipeline.
- Frame sampling at traffic-monitoring cadence (not every single frame).
- Lens correction and quality filtering applied aggressively; failed frames are rejected rather than fed forward.
- Zone-of-interest extraction per camera before frames are queued for inference.
03 · YOLO object detection — per-frame vehicle identification
- Identifies and classifies every vehicle in each processed frame — car, bus, truck, two-wheeler, and other configured classes.
- Produces bounding boxes, class labels, and confidence scores.
- Single-shot detection delivers the latency real-time traffic monitoring demands without sacrificing accuracy.
04 · Object tracking — the prerequisite for accurate counting
- Assigns persistent track IDs across frames so the same vehicle is not counted repeatedly.
- Reconstructs trajectories and direction of travel.
- Supports unique-vehicle counting, line-crossing detection, and lane-level flow estimation.
05 · Traffic analytics and congestion estimation
- Vehicle counts by class, flow rates, and estimated speeds from tracked trajectories.
- Per-zone congestion indices and peak-hour pattern detection that recognises build-ups as they start.
- Anomaly / incident detection — abrupt flow changes consistent with crashes, breakdowns, or other events.
06 · AI optimization engine — recommendations, not just observations
- Signal-timing change recommendations tuned to current and forecast congestion across a corridor.
- Peak-hour control actions when monitored patterns drift outside policy thresholds.
- Diversion strategies when incident detection or sustained congestion warrants routing traffic away from a problem zone.
- Recommendations rather than autonomous changes — operations teams remain in the loop with the supporting analytics in hand.
07 · Flask / FastAPI consumption layer on AWS
- Live traffic dashboard for the operations control room.
- Signal control recommendations for the traffic engineering team.
- Enforcement alerts for peak-hour policy compliance teams.
- Historical analytics and trend dashboards for planning; public / citizen APIs for downstream consumer applications.
- AWS S3 stores media and historical data; EC2 hosts the inference workload and the APIs.
See AI traffic monitoring in action
A walkthrough of the traffic monitoring stack — multi-class vehicle detection, lane-wise counting, density and congestion estimation, and the signal-optimization signal flow on live road footage.
AI traffic monitoring — vehicle detection, counting and congestion in action
What is the architecture of the platform?
The architecture is organised as six layers: the city camera network, video streaming and pre-processing on Python and OpenCV, the computer vision core with YOLO object detection and object tracking, traffic analytics and congestion estimation, the AI optimization engine, and the Flask / FastAPI consumption layer on AWS. Each layer has a clearly defined contract with the next — cameras produce streams, the streaming pipeline produces inference-ready frames, the CV core produces structured detection and tracking outputs, analytics produce zone-level operational signals, the optimization engine produces recommendations, and the API layer makes everything available to the dashboards, signal controllers, and downstream consumers that act on it.
Why these specific design choices?
Detection AND tracking, not detection alone
- Detection-only systems can tell you a vehicle is in a frame; they cannot tell you it is the same vehicle as the one in the previous frame.
- Without that identity, counts become unreliable, flow estimation breaks down, and incident detection misses the trajectory cues it depends on.
- Treating tracking as a first-class layer is what lets the platform deliver accurate counting and flow analytics — not just per-frame counts.
Recommendations, not autonomous actions
- The AI optimization engine produces recommendations — not autonomous changes pushed directly to traffic infrastructure.
- Traffic operations is a domain where context, edge cases, and operator judgement still matter; the platform's role is to amplify the operations team's reach, not act unsupervised.
- Every recommendation ships with the supporting analytics so operators can interrogate it before acting.
Engineered for the realities of city camera networks
- Weather, lighting, glare, partial occlusion, intermittent connectivity, and varying viewing angles are all routine — not edge cases.
- The streaming and pre-processing layer rejects frames that cannot produce reliable detections rather than feeding noise forward.
- 90–95% live camera uptime coverage reflects what is actually achievable across the deployed network, not a lab-best number.
Analytics and optimization as separate cooperating layers
- Splitting "what is happening" (analytics) from "what to do about it" (optimization) mirrors the cleanest design pattern for AI systems whose outputs drive decisions.
- The two layers can be evaluated, governed, and upgraded independently.
- The explicit separation makes it possible to defend any recommendation by tracing it back to the analytics that produced it.
Flask / FastAPI on AWS — a real consumption layer, not a research notebook
- Traffic operations teams, signal engineers, enforcement units, and citizen applications all need different views of the same data.
- Clean, role-scoped APIs surface the platform's outputs to each consumer.
- AWS S3 and EC2 provide the storage and compute substrate that makes the platform reliable at scale.
What measurable results did the platform achieve?
The platform was evaluated against the operational pain points it was built to address — detection and classification accuracy across the deployed camera network, coverage and uptime versus the manual monitoring baseline, and the downstream effects on congestion, signal-timing decisions, enforcement consistency, and incident response.
92–96% detection and classification accuracy
- Consistent accuracy across the vehicle classes the platform monitors — cars, buses, trucks, two-wheelers, and additional configured classes.
- Holds across lighting conditions, viewing angles, and the natural variability of an urban camera network rather than a lab-optimised baseline.
90–95% live camera uptime coverage
- Replaces the staffing-limited manual monitoring that previously covered only a fraction of the cameras at any given moment.
- Every active camera contributes to the analytics layer rather than only the ones an operator happens to be watching.
Earlier congestion detection and faster response
- Continuous, automated congestion estimation surfaces build-ups as they begin rather than after they have escalated.
- The window to act with signal-timing adjustments or diversion responses opens earlier.
- Operations teams report faster, more confident response than the manual monitoring baseline allowed.
Signal timings that reflect actual traffic patterns
- Recommendations grounded in measured flow, congestion, and peak-hour patterns replace static plans that had drifted out of alignment.
- Plans now evolve with the pattern rather than ossifying around the assumption.
Consistent peak-hour policy enforcement
- Automated enforcement alerts at peak-hour checkpoints remove the staffing dependency that had made enforcement uneven.
- The gaps that drivers had learned to exploit closed; policy became as effective in practice as it was on paper.
AI-Powered Traffic Monitoring System — frequently asked questions
The questions most often asked about the platform. Each answer is self-contained, so it can be quoted, cited, or surfaced as a standalone response.