A traffic analytics system has to do more than draw boxes on a live camera feed. Operators need to know which cameras are actually processing, what rule produced an incident, whether the evidence belongs to the right vehicle, and how to inspect the event later. Traffic Pilot brings those responsibilities into a single application we developed for a private client deployment.
The public Traffic Pilot case study presents the capability without linking to the operational dashboard. This article focuses on the product and engineering decisions that turn video inference into a reviewable workflow.
A camera needs a definition of the task
Traffic Pilot includes camera management and a visual configuration workflow. Operators define the regions, lines, and directions that give an observation meaning. A vehicle inside a monitored area, a crossing of a counting line, and movement against a configured direction are different conditions; they should not be inferred from an unlabeled rectangle alone.
For direction rules, the authored arrow matters. An undirected line does not state which direction is prohibited. The application preserves the line's purpose, endpoints, direction, and related monitoring zones so the worker can evaluate the same rule the operator drew.
Speed estimation has another prerequisite: a calibrated area with real-world dimensions. Traffic Pilot uses road geometry and surveyed side lengths to map relevant image positions onto the road plane. It can decline a measurement where image resolution or the calibrated region does not support it, instead of presenting every change in a detector box as a meaningful speed.
Keep the preview connected to the event data
The worker produces an analytics message containing observations, tracked objects, and events. The live analytics preview uses that same message rather than inventing a second preview-only interpretation. This helps keep the displayed boxes and the event logic aligned.
A smooth camera view and an analytical evidence view have different purposes. The camera-only path can prioritize convenient viewing. The analytical path needs the correct relationship between a frame, its timestamp, and the objects reported for that frame. Traffic Pilot keeps that distinction so an overlay does not drift onto a newer image that happens to be available.
Bounded frame handling is part of the architecture. For live monitoring, letting an unbounded backlog grow can make the dashboard display old events as if they were current. Workers and publishing stages therefore have explicit bounds and recovery behavior rather than assuming every camera and downstream service remains equally fast.
An incident must survive a temporary track change
Local tracker IDs can change after occlusion or a brief loss of detection. A useful incident lifecycle should not split one continuously observed parked vehicle into several unrelated cases merely because the tracker assigned another local ID.
Traffic Pilot separates local aliases from confirmed vehicle identity and maintains incident continuity through supported identity transitions and short gaps. It also guards against the opposite error: a different vehicle appearing in the same location must not inherit the previous vehicle's incident simply because the boxes are nearby.
These rules make the event record more useful than a collection of per-frame detections. An active incident has a lifecycle, recorded observations, and a reason to end. A later event after an observed absence becomes a new incident rather than silently extending the old one indefinitely.
Show the evidence that supports the reported rule
The incident inbox retains sampled proof images with their matching analytics payloads and timestamps. Captures are checked against the reported identity, class, time window, and relevant geometry. For stationary incidents, position and box-shape consistency provide additional safeguards against following an unrelated object.
The inspector supports zooming, panning, fitting the image, and viewing it at native size. Operators can inspect region overlays and vehicle boxes or return to the original capture. The stored original JPEG remains separate from those presentation overlays.
Sampled evidence can be played as an animation and exported with incident metadata. It is important to call it what it is: a sampled proof sequence, rather than a continuous video recording. That keeps the operator's expectations aligned with the data actually retained.
Connect individual incidents to overview analytics
The dashboard provides totals, incident trends, type and status breakdowns, proof coverage, camera rankings, duration distributions, and local-hour activity. Review-workload views make it possible to see which types still need attention, not only how many events were generated.
Drilldowns preserve the relevant context. Selecting a camera, type, hour, or review state narrows the incident list. Region-of-interest reports group records by camera, rule, and uniquely identified configured region, while retaining access to individual vehicle timelines.
A map connects camera locations with the event workflow. Missing coordinates are reported as missing, rather than replaced with invented positions. This matters because an attractive camera marker is still incorrect if it claims a geographic precision the source configuration does not contain.
Make the evidence budget part of the product
Unbounded evidence capture can eventually damage the system it is meant to support. Traffic Pilot exposes a storage budget, a free-disk reserve, evidence sampling controls, and an incident-retention lifecycle. Ended incidents and their own retained evidence rotate according to policy; unrelated files are outside that cleanup scope.
Capture availability and collection health remain visible when limits are reached. An operator can export evidence that needs to outlive routine retention. The application therefore makes storage a managed constraint instead of allowing a full disk to become a surprising failure mode.
Review status is also separate from automatic detection. A generated rule event is an observation for inspection, not an automatic assertion that a legal violation has been established. Recorded configuration and directional evidence explain the rule evaluated; they do not independently verify the road's legally permitted direction.
Distinguish a reachable camera from a working pipeline
The monitoring workflow separates camera reachability from processing state. A camera can answer a connection probe while its analytics worker is not producing observations. Showing both states helps the operator investigate the correct layer instead of interpreting any reachable endpoint as a healthy inference pipeline.
Worker heartbeats, processing history, camera-level frame-rate summaries, hardware telemetry, and identity-service health contribute to that operational view. Missing samples remain distinguishable from measured zero activity. This makes the dashboard useful for diagnosing a fleet, not only for showing a successful feed.
The codebase supports accelerator-specific worker implementations and device-native model preparation. Hardware-specific inference artifacts are treated as such; a compiled engine is not assumed portable between a desktop GPU and an edge device. The public capability is the supported architecture and workflow, without turning one device's test into a universal throughput promise.
Compare a physical region, not only a tracker label
The continuity implementation normalizes detector boxes using the dimensions of the accompanying frame. Invalid or non-finite boxes are rejected. It then has different reference geometry for stationary and moving incidents: a parked vehicle uses an anchored region, while a supported moving event can use its latest box. A detector's temporary crop change should not automatically move the physical reference for a stationary incident.
Appearance comparison is deliberately lightweight and inspectable. A crop is resized and divided into spatial color cells; channel histograms become a normalized vector. Preserving spatial cells helps distinguish adjacent vehicles that share a broad color distribution. A separate grayscale spatial signature records texture in a fixed anchored region. These are continuity checks, not a claim of person identity or an independently validated vehicle-recognition benchmark.
Known aliases are not accepted unconditionally. Fresh appearance evidence that contradicts the stationary exemplar can reject a match even when a local identifier is familiar. New identities need sufficiently recent observations, compatible overlap and stronger appearance support. A recorded departure prevents continuity from extending indefinitely, and an out-of-order observation does not rewind the incident's state.
Partial occlusion has a stricter path. A shrinking detector box must retain a known global identity and compatible class, overlap the anchor and leave enough common textured region for comparison. The code also checks for another object reusing the same identity away from that box. It compares the shared physical region rather than treating a broadly similar silhouette as sufficient evidence.
Validate the evidence before presenting the story
Evidence validation starts with the observation window: a captured frame must not fall beyond the allowed relationship to the incident's last reported observation. The saved metadata must identify exactly one object for the proof. Multiple objects in the purported identity record are treated as ambiguity, rather than allowing the viewer to guess which detection justified the capture.
The validator checks that the recorded local track belongs to the incident's aliases, or that the saved verification metadata explicitly binds the original track. If both an incident identity and a reported global identity are present, the latter must belong to the allowed continuity set. Class changes are checked against the classes retained by the continuity record.
Stationary incidents add geometry checks. The saved object should remain close enough to the identity anchor, with a compatible box aspect ratio. Excessive displacement or a substantially changed box shape becomes an evidence issue. These checks do not establish legal correctness; they address a narrower and necessary question: does this proof still describe the object and event the incident record says it does?
Recover useful context without keeping everything forever
After a restart, continuity can recover stationary exemplars from saved proof, but it validates that evidence before using it. It considers an initial capture and recent retained captures, checks their metadata and geometry, and rebuilds appearance or spatial context only when a suitable example exists. Recovery therefore uses the same evidence discipline as normal review instead of trusting an arbitrary last image.
Live continuity state is bounded too. Recent preview frames and appearance samples expire, anchored comparison caches have limits, and alias history is capped. These bounds connect algorithm behavior to operational reality: a long-running camera service cannot accumulate every track and crop forever. They also explain why continuity is a conservative short-term association mechanism rather than a promise of unlimited re-identification across arbitrary gaps or cameras.
Make the event explainable from configuration to export
Traffic Pilot connects scene configuration, inference, identity, incident lifecycle, evidence, review, and operations. Its distinctive feature is that an event can be followed through those layers: which region and rule applied, which observations supported it, and what was retained for a reviewer.
Explore the Traffic Pilot capability case study for the visual overview, or talk with AlgoFly about a camera analytics application with the review and operational controls your workflow requires.