MAARG Traffic Intelligence
An interactive simulation of the pipeline from camera video to edge AI, streaming, cloud analytics, and dynamic signal control.
01 · Physical road
Camera capture: what the CCTV camera actually sees
Everything starts with pixels. The camera records continuous video. Information such as vehicle type, plate and speed is not 'sent by the camera' — it is extracted from those pixels by the edge AI server next to the camera.
Waiting for a vehicle to cross the count line…
- Video frames25 fps · 1920×1080sensor
- Vehicle position—edge AI
- Vehicle type—edge AI
- License plate—edge AI
- Lane—edge AI
- DirectionNorthboundedge AI
- Timestamp08:42:16config
- Approx. speed—edge AI
- Camera IDCAM_07config
- GPS / location30.7046, 76.7179config
- Confidence—edge AI
The camera does not stream every frame to the cloud for analysis. Its video goes to a small AI computer at the junction (the edge server), which watches the video and writes down short facts about each vehicle. Only those facts travel to the city system.
07 · Multi-camera association
Is this the same vehicle? Connecting observations into one journey
Track IDs from the edge are only valid inside one camera. The cloud compares observations from different cameras using identity, time, place, direction and speed — and the road graph.
- CAM_0108:41:18DL01AB1234car · north · 38 km/h
- CAM_0708:42:16DL01AB1234car · north · 42 km/h
- CAM_0908:42:40DL01AB1234car · north · 40 km/h
- CAM_1408:43:05DL01AB1234car · east · 33 km/h
- CAM_2208:44:02DL01AB1234car · east · 36 km/h
Press "Run association" to compare: vehicle identity, license plate, timestamp, location, direction, speed, spatial relationship and temporal relationship.
MAARG checks whether the same car could really have driven from one camera to the next in that time, on those roads, in that direction. If yes, the sightings are joined into one trip. A same-plate sighting that is physically impossible is rejected and flagged.
02 · Edge AI perception
Edge AI server: video becomes structured observations
A GPU server installed close to the cameras (in or near the junction cabinet) runs the perception pipeline. This is where the heavy video processing happens, with low latency and without sending raw video across the city.
- Inputs4 camera streams
- ComputeGPU inference
- RuntimePython
- Outputobservations
Processing pipeline · click a stage for details
Think of the edge server as a traffic officer standing at the junction who watches the video and writes a short note for every vehicle: "white car, DL01AB1234, lane 2, going north, 42 km/h, 08:42:16". Only the note is sent onward.
04 · Real-time streaming
Apache Kafka: the real-time event bus
Kafka allows observations from many intersections to continuously reach the central intelligence layer — durably, in order, and without overloading any single service.
Partition key = camera / junction · order preserved within a partition · newest on the right
Kafka is like a high-speed conveyor belt. Every junction drops its notes on the belt, and every department in the city system picks up the notes it needs, at its own pace — nothing gets lost if one department is busy.
05 · Central intelligence
MAARG City Intelligence Cloud
The edge understands one junction. The cloud sees every junction at once — it connects observations into journeys, measures the network and decides what the signals should do next.
One junction · video in · milliseconds · "what is in front of this camera?"
All junctions · observations in · history + road graph · "what will happen next, and what should we do?"
The cloud is the city's control room brain. It receives notes from every junction, recognises the same vehicle at different places, measures how traffic is moving, predicts what comes next and tells signals how to adjust.
09 · Traffic intelligence
Zoom out: the whole network, measured live
Observations from every camera become network-wide metrics. Click any intersection to see what MAARG knows about it right now.
Click an intersection on the map.
Every road is coloured by how full it is. MAARG also counts what is waiting at each junction and what is about to arrive — the numbers it uses to time the lights.
10 · The core USP
Dynamic signal timing from upstream traffic
MAARG does not only react to the queue already at a signal. It looks at cameras before the junction, estimates how many vehicles are coming and when they arrive, checks the cross street and the road ahead, and then times the upcoming signal.
- NCAM_01: 42 vehicles approachingNS phase180 m · 36 km/h · ETA 18.0 s · platoon passes in ~18 s
- SCAM_02: 31 vehicles approachingNS phase420 m · 30 km/h · ETA 50.4 s · platoon passes in ~14 s
- ECAM_03: 18 vehicles approachingEW phase300 m · 27 km/h · ETA 40.0 s · platoon passes in ~8 s
- Upstream camera dataCAM_01 42 · CAM_02 31 · CAM_03 18
- + Current signal stateNS green, 12 s elapsed of 30 s (18 s left)
- + Vehicle speed36 km/h (CAM_01 platoon)
- + Distance180 m CAM_01 → stop line (PostGIS)
- + Queue lengthEW 12 vehicles waiting
- + Downstream capacityJ-05 54% occupied
- + Historical patternTue 08:40 profile × 1.00
Predicted arrival: 42 vehicles from CAM_01 expected in 18 s
"Estimated vehicles reaching J-04 in next 30 s: 28"
"Extend North–South GREEN by 18 s"
42 vehicles from CAM_01 arrive in ~18 s and need ~18 s to pass. Current green ends in 18 s.
Yellow 5 s and all-red clearance unchanged; local interlock enforces safety.
MAARG sees a big group of cars just one block away. If the light turned red now, almost all of them would have to stop. So it keeps the light green a little longer — but only as long as the cross street can afford to wait and the road ahead has room.