Traffic event detection software misses incidents because it is built one camera at a time. A per-feed detector reports what falls inside its own field of view, so an incident in the gap between two cameras, or one whose only early signal is a change in how traffic behaves across a corridor, has nothing watching it at all.
If you run a highway TMC, a tunnel, or a bridge network, you have probably reviewed footage after an incident and found your automatic incident detection (AID) system never raised an alert. The mirror image is more common: a system fires on every passing shadow until operators stop reading it, which costs you the one alert you needed. Both complaints come back to the same architecture. A detector looking at one feed in isolation has no way to tell a real obstruction from a brake-check, and no way to see the road it is not pointed at.
Traffic event detection software identifies roadway incidents automatically and in real time, without relying on an operator to spot them or waiting for a phone call, and raises a structured alert carrying a location, an event type, a timestamp and, on better systems, the flow measurements that triggered it. The approaches in use include video analytics on cameras an agency already owns, detection-equipped smart cameras, radar and lidar roadside sensors, fiber-optic sensing, and cloud platforms ingesting third-party and crowdsourced data.
Detection quality on a single feed is no longer where these systems differ much. The models work, they are widely available, and they keep improving across the market. What separates one deployment from another is what happens to a detection afterward, and whether anything is watching the road between the feeds.
A false negative is a real incident that never reaches an operator as an alert. Rather than one accuracy problem, it is a detection lost at a specific point in the chain, and four of the five places it happens are properties of per-camera architecture rather than of the model:
Only the last one is a tuning question, and it is the one vendors argue about. The rest are architectural, which is why a better model on the same camera does not close them.
A corridor can see an incident nobody filmed. Rather than treating each camera as an isolated detection zone, GoodVision treats the monitored corridor as a single continuously analyzed traffic system, understanding not just what a camera sees but what must be happening in the space between cameras.
It tracks the trend of key measurements at every monitoring point in real time: vehicle counts, flow rate, individual and average speed, gap and headway between vehicles, and road saturation. Flow gets analyzed by direction, by individual lane, and down to each individual vehicle. When an anomaly or an over-threshold change shows up at one point, the system cross-checks the neighboring upstream and downstream points.
Consider the pattern that gives an obstruction away. Saturation at the upstream point climbs while the downstream point thins out. No camera recorded a vehicle stopping, and no per-feed detector has anything to report. Read across three monitoring points, those conditions are consistent with something blocking the road between two of them, so GoodVision reports that an incident has occurred on that segment together with the quantified flow parameters that triggered the detection. The method uses proven algorithms from established traffic flow theory, including the classic California algorithm approach.
The same correlation across cameras surfaces events that never exist on one feed at all. Propagating congestion is the clearest case: a slowdown detected at one location gets tracked as it builds and travels backward through the network, so operators see how congestion is forming, where its head and tail are, and how fast it is spreading, rather than only that it exists.
What this delivers, stated precisely: corridor-wide detection of flow-affecting incidents, including the segments between cameras, with classification and visual evidence within camera views. Where it works and where it does not:
Between cameras, GoodVision infers incidents from how traffic behaves at the neighboring monitoring points. That works where the points are close enough that a change at one shows up at the next. Where they sit further apart, the inference tells you a segment is affected rather than pinpointing a location, and in-view detection is what gives you a classified event with visual evidence. We size this per corridor during the pilot.
Lowering a detection threshold to catch missed incidents creates false alarms because a single-feed threshold cannot tell a stalled vehicle from a car braking hard for two seconds. Both are a deviation from expected flow, and looking at one camera there is nothing else to consult. Sensitivity becomes one dial reading two failure modes, and your vendor set it where their benchmark scored best rather than where your corridor sits.
A system that cries wolf on every gust of wind, passing shadow or momentary brake-check trains its operators to disregard it, at the exact moment a genuine incident occurs. That is the real cost, and it is why a false alarm rate low enough that operators act on every alert is a functional requirement rather than a nice-to-have. Operators panning a PTZ camera add to the same problem, because moving one shifts every calibrated detection zone at once.
Automatic verification cuts false alarms by adding a second stage between detection and the operator screen instead of moving the detection threshold. Every event is automatically cross-checked against surrounding traffic conditions before it reaches an operator, filtering transient anomalies so that only verified, prioritized events surface.
That check runs on the corridor data the system already maintains, which is what makes it the same capability read from the other end. A threshold decides whether one candidate looks unusual. Verification asks whether the neighboring monitoring points agree that something is wrong. A few vehicles slowing at one point with normal flow either side of it is noise, and so is momentary sensor noise or an isolated single-frame artifact. The same slowdown with saturation climbing upstream and thinning downstream is an obstruction. Detection sensitivity can stay high, because the noise it lets through gets caught downstream rather than never being generated. Every surfaced event carries a priority level, so a wrong-way alert does not queue behind a congestion report.
GoodVision handles the PTZ problem at the same layer. When an operator pans, tilts or zooms, the system recognizes the change, pauses analytics while the operator looks at the scene, and recalibrates when the camera returns to its designated park position, with no manual step and no engineering call-out.
What we do not publish is a zero false alarm figure. Our own engineering language for the verified rate is close to zero, and a permanent public absolute is not defensible against one corridor with an unusual failure mode. Ask any vendor quoting you a 0% rate which feeds it was measured on.
You should evaluate incident detection accuracy by comparing your system alerts against a ground truth log, not by relying on a published percentage. A vendor figure describes the conditions it was measured under, not the conditions on your cameras, in your weather, at your volumes.
Before you attribute a miss to the model, rule out the feed. A fouled or fogged lens, camera drift after high wind, aggressive compression, dropped frames and variable frame rate all reduce what the model has to work with, and none of them show up in a vendor accuracy figure.
The Federal Highway Administration's Traffic Incident Management program frames detection performance as a function of the full clearance timeline rather than a standalone accuracy score, which is the right lens for a TMC evaluating a live system rather than a lab benchmark.
GoodVision is the sensing and intelligence layer over cameras you already own. It runs detection against your existing infrastructure, correlates across the corridor, and delivers verified alerts in under one second via HTTPS. It is built to feed the systems where decisions actually get made rather than to replace them, so events and reports route to your ATMS, dispatch platform, variable message signs or performance-reporting tool, with the message format configurable per event type.
On the failure points above, four things carry most of the work:
It is camera-agnostic, running in the camera on selected brands including Axis, Hanwha and Hikvision, on an edge device at the pole or cabinet, or on a server at the TMC, chosen per location to fit bandwidth and latency constraints.
Yes, by inference rather than by sight. Comparing flow measurements at neighboring monitoring points identifies a segment where conditions are consistent with an obstruction, such as saturation building upstream while traffic thins downstream, without any camera having recorded the vehicle that stopped.
A false negative is a real roadway incident the system never flags, so no alert reaches an operator. It is measured as a rate against a manually logged ground truth set, and a per-camera benchmark cannot score the misses that happened between cameras.
The detection is lost at one of a few points: no camera covered that piece of road, the incident fell between cameras, the event type was never configured, the camera had been moved, or a threshold suppressed the detection to keep nuisance alarms down. Only the last is a tuning problem.
Yes, by verifying events against corridor context rather than desensitizing detection. Cross-checking each candidate against traffic conditions at neighboring monitoring points filters transient anomalies while detection sensitivity stays high, which is how GoodVision keeps its verified false alarm rate close to zero.
Configuring a GoodVision pilot typically takes 10 to 20 minutes once the edge processor is connected to live camera feeds. A full proof of concept runs one to three months, and all data stays inside your own network.
For more on the operational cost of catching incidents late, see the hidden cost of late incident detection and how real-time AID supports traffic safety programs. The GoodVision AID solution page and the highways solution overview outline deployment options against existing cameras.
Book a demo at goodvisionlive.com/request-demo/ and ask what your current system reports for an incident that happens between two of your cameras.