Summary
- Traffic analytics deployment options fall into three topologies: in-camera processing on the device itself, an edge device at the roadside, or a server at the Traffic Management Center (TMC).
- In-camera video analytics on supported camera brands cuts bandwidth use and shortens detection-to-alert latency because no video leaves the device before an event is flagged.
- Edge video analytics on a roadside processor works with any camera brand already installed on the corridor, without replacing existing hardware.
- Server-based, on-premise traffic analytics centralizes processing at the TMC for agencies that prefer one location to manage and audit.
- GoodVision reports that configuring a pilot for incident detection, counting, or violation detection on any of the three topologies typically takes 10 to 20 minutes once the device is connected to a live feed.
Choosing where your traffic analytics runs, in the camera, on a roadside edge device, or on a server at the TMC, is one of the first decisions in any ITS deployment, and it drives your latency, bandwidth, maintenance and budget for the life of the corridor. GoodVision's traffic analytics deployment options let operators pick per location rather than commit to one architecture site-wide. Camera-agnostic processing means the choice depends on your existing infrastructure and operational preference, not on which vendor's hardware happens to be bolted to the pole.
What Are the Three Traffic Analytics Deployment Options?
There are three places traffic analytics can run: inside the camera, on a device at the roadside, or on a server at the TMC. Each processes the same underlying video, but where the computation happens changes what travels over the network and how quickly an alert reaches an operator.
In-camera video analytics runs the detection model directly on the camera hardware, on supported brands including Axis and Hanwha. Because the analysis happens at the point of capture, no raw video needs to travel anywhere before an event is flagged, which is what shortens detection-to-alert latency and reduces the bandwidth the corridor consumes.
Edge video analytics moves the same processing to a separate device, either mounted on the camera pole or housed in the roadside controller cabinet. This is the option for any camera brand that does not support in-camera processing, which in practice covers most existing CCTV infrastructure already deployed on a highway or arterial corridor.
Server-based, on-premise traffic analytics centralizes everything at the TMC. Every camera feed is streamed back to a server that runs the detection models, which suits agencies that prefer to manage compute, patching and monitoring in one location rather than distributed across hundreds of roadside points.
Which Topology Fits Your Bandwidth and Latency Requirements?
The topology that fits depends on how much bandwidth you have per site and how fast you need an alert once an incident starts. In-camera and edge processing both keep raw video local, so only structured event data or short clips travel back, which matters most on corridors with limited fiber or cellular backhaul. Server-based processing needs a live video stream to every monitored point, which is the highest-bandwidth option of the three.
Latency follows the same logic. In-camera detection has the shortest path from event to alert because there is no network hop before analysis starts. Edge devices add a small amount of latency for the video to reach the roadside processor, still far shorter than sending it to a TMC. Server-based processing adds the full transmission time from camera to data center, which is rarely the bottleneck for counting and turning movement studies but can matter for automatic incident detection (AID), where every second before an alert affects response time.
Why Does Camera-Agnostic Traffic Analytics Matter for Existing Infrastructure?
Camera-agnostic traffic analytics matters because most highway corridors already have cameras installed, often from several manufacturers accumulated over years of separate procurement cycles. GoodVision integrates directly with that existing infrastructure and does not require proprietary, vendor-locked hardware, so the video analytics deployment can proceed camera by camera without a forklift upgrade.
That flexibility is also what makes a mixed topology realistic. A corridor with newer Axis or Hanwha cameras at some intersections can run in-camera analytics there, while older or different-brand cameras elsewhere on the same corridor run on a roadside edge device or route back to a server at the TMC. The operator chooses per location based on bandwidth, latency, maintenance access and budget, not one architecture for the whole network. For a deeper look at how this plays out on live highway corridors, see how automatic incident detection works beyond a single camera view.
The underlying detection models are trained on one of the industry's larger and more varied traffic datasets, covering vehicle types, road geometries, lighting conditions and driving cultures across the more than 50 countries where GoodVision is deployed. That is why the core detection engine performs out of the box without local retraining or lengthy site-specific tuning, regardless of which of the three topologies it runs on. Capabilities like predictive analytics, ANPR and some custom violation scenarios sit outside this core engine and are built to order, so it is worth confirming with your integrator which tier a given feature falls into before you plan around it.
How Fast Can You Pilot a Deployment Topology Before Committing?
A pilot can be running on live traffic within days of agreeing to proceed, using a compact edge processor shipped with the software pre-installed. The device sits wherever the topology calls for, on the camera pole, in the roadside cabinet, or at the TMC, and connects to live camera feeds either directly or through the existing video management system.
Configuring what the pilot tests, whether that's incident detection, vehicle counting, violation detection or a combination, typically takes 10 to 20 minutes once the device is connected. After that the system is producing real events from real traffic, which lets an operations team compare topologies on the actual corridor rather than a lab bench. All data stays inside the customer's own network during the pilot, with nothing published or transmitted outside it, so there is no data-sharing question to resolve before testing starts. A typical evaluation runs one to three months against an agreed use case, delivered locally by an ITS integrator who understands the regulatory and operational context of the agency running it. Solutions like this are usually part of a broader case for real-time monitoring: see why cities delay adopting real-time traffic monitoring for the objections that typically stall this decision, and GoodVision Live Traffic on Axis cameras for a look at one supported in-camera path.
If your evaluation criteria include how fast an incident gets flagged once it happens, it is worth reading the hidden cost of late incident detection alongside your topology decision, since latency and topology are directly linked. For agencies weighing what data crosses the network under each topology, data security in traffic control software covers the questions procurement teams typically raise.
For an authoritative view on how deployment topology affects ITS network design more broadly, the US DOT's ITS Joint Program Office (https://www.its.dot.gov) publishes guidance on edge and connected-vehicle infrastructure planning, and the Institute of Transportation Engineers (https://www.ite.org) maintains technical resources on ITS device placement and traffic signal system architecture.
FAQ
What is the difference between edge and in-camera video analytics?
In-camera analytics runs the detection model inside the camera itself, on supported brands like Axis and Hanwha, while edge analytics runs on a separate roadside device that works with any camera brand already installed.
Does camera-agnostic traffic analytics work with cameras I already have installed?
Yes. GoodVision integrates with existing camera infrastructure across virtually any manufacturer and does not require proprietary or vendor-locked hardware to run.
Can I use different deployment topologies at different points on the same corridor?
Yes. Operators choose the topology per location based on bandwidth, latency, maintenance access and budget, so a single corridor can mix in-camera, edge and server-based processing.
How long does it take to set up a pilot on a given topology?
Once the device is connected to a live camera feed, configuring the functionality to be tested typically takes 10 to 20 minutes, after which the system is producing real events from real traffic.
Does server-based, on-premise traffic analytics need more bandwidth than the edge options?
Yes. Server-based processing streams live video from every monitored point back to the TMC, making it the highest-bandwidth option of the three, while in-camera and edge processing keep raw video local.
Does the detection engine need retraining for a new region or climate?
No. The core detection engine is trained on data spanning vehicle types, road geometries, lighting conditions and driving cultures across more than 50 countries, so it performs out of the box without local retraining, on any of the three topologies.
Book a demo at goodvisionlive.com/request-demo/ and run your first deployment-topology pilot on your own corridor footage within days.