This article focuses specifically on the Traffic Lane feature and related functionalities. It introduces the concept of lanes in FLOW, the configuration of Traffic Lane (TL) elements, the use of the aggregate Multi-traffic lane (MTL) operator, and the resulting data outputs in the form of TrafficData and TrafficEvents. In addition, it describes global Traffic Lane settings, such as Level of Service (LOS) thresholds and more, and describes MTL events and Generic events, as part of the supported communication framework.

The TrafficLane feature is also exposed through the FLOW API and can be integrated via OPC UA or webhooks. For additional details and related resources, refer to the separate document “Multi-traffic lane API” or visit www.datafromsky.com.

The term lane is used consistently throughout this documentation. The alternative expression generalized lane is used interchangeably in other readings to cover different types of lanes regardless of their traffic purpose.

Three main types of lanes can be distinguished:

Regular lanes represent the standard traffic lanes on a roadway used by vehicles travelling in a defined direction. They form the primary pathways for vehicle movement and are typically monitored for parameters such as traffic flow (level of service), speed, congestion, and related indicators.

Regular lanes are commonly numbered Lane 1, Lane 2, … up to Lane 16, following industry practice for lane indexing from left to right or right to left, depending on local conventions.

Shoulders, or shoulder lanes, are typically designated areas adjacent to the outermost regular lanes. Left shoulder and right shoulder are used for emergency stops, breakdowns, or occasionally opened as auxiliary lanes during peak traffic conditions.

Inter-lane islands, or midIsles, represent either physical or painted separations between lanes. They provide buffer zones or control traffic flow in complex layouts.

Monitoring interlane islands allows for detection of lane integrity breaches, e.g. vehicles crossing buffer zones, which is useful for accident prevention.

Reversible lanes are special traffic lanes where the permitted direction of travel can be dynamically changed depending on traffic demand or construction scenarios. This concept applies independently of the lane type (regular lanes, shoulders or inter-lane islands). Monitoring reversible lanes ensures vehicles follow the currently valid direction, contributing to flexible traffic management.

Figure: Example of annotated lanes in a camera view, following their designated purpose and possible numbering convention.

The Traffic Lane (TL) is a fundamental spatial element in FLOW, used to define individual roadway lanes within the camera view, enable their identification, and associate detected traffic insights with them. Each TL consists of multiple sub-elements that together support trajectory filtering, lane assignment, and further traffic calculations.

Figure: Creation of a Traffic Lane using control points.

Each TL element consists of the following configurable elements, which are further described:

Figure 1: Elements of a Traffic Lane – (1) Section Gates, (2) Decision Gate, (3) TL Directional Widget, (4) TL Name, (5) Settings dialog - next screenshot, (6) Coloring settings, (7) Distance input, (8) Delete option, (9) Finish button.

Traffic lane settings contain the following:

Figure: Settings dialog of a Traffic Lane – Lane code assignment and Reversibility configuration.

Tip: Traffic Lanes may also be hidden in the display settings.

Figure: Show/hide traffic lanes.

They have global and local parameters.

Section gates play a central role in generating traffic statistics for a given TL. Marked as orange lines across the view, section gates are automatically generated within the TL polygon based on its shape and bounding box. They extend through the TL and beyond its boundaries to ensure that vehicles changing lanes during their travel are included in the calculations. Their position can be manually adjusted.

Section gates also determine the expected direction of vehicle passage, as their angles define the default angle for Right-way and Wrong-way classification (see the TL Direction Widget section). In addition, section gates provide the basis for speed and level-of-service calculations using the standard section-speed methodology, without requiring geo-referencing. Accuracy depends on the correct input of the distance between gates.

When a TL is active, move around their definition points as needed to adjust them.

The Decision gate is a critical filtering element within a TL. Only vehicles that pass the decision gate are counted in TrafficData statistics. For TrafficEvents, however, all events occurring within the TL are accounted for, regardless of whether they passed the decision gate.

By default, the decision gate is generated automatically during TL creation and visualized as a green line. Its position can be freely adjusted within the TL polygon. When s TL is active, move around its definition points as needed to adjust it.

The entry timestamp at the decision gate is used as the passing timestamp for calculations.

Annotation tip: Distances between adjacent decision gates should be minimized. This helps avoid cases where a vehicle may pass through multiple decision gates in congested traffic conditions, potentially causing duplicate counts.

The TL Directional widget defines the expected travel direction of vehicles for each TL. It is based on two parameters:

The default values for both parameters are calculated at the moment of creating the TL element based on its shape. They are not recalculated when the lane is edited, they need to be manually adjusted.

Expected pass angle of the vehicle. First input value in the widget (green point).

The tolerance of the expected angle both left and right of the Pass angle. Second input value in the widget (green sector).

The widget is based on the Cartesian coordinate system, where 0° is directed rightwards and angles increase clockwise within <0; 360°).

Figure: Cartesian coordinate system used for the TL Directional widget.

Figure: Example A (left) – filter for vehicles passing straight north (90°), tolerance ±90°.

Example B (middle) – filter for vehicles passing at -45°, auto-corrected to 315°, tolerance ±90°.

Example C (right) – filter for vehicles at 234°, tolerance ±70°.

To easily check trajectories’ angle calculated by FLOW in real time, visualize it by toggling the heading flag under flags list. When turned on, all objects are overlaid with a red arrow angled as per their current evaluation.

Figure: Heading flag in FLOW.

For a quick overview of directionality of all lanes, including their current gates’ set up, the following overlay is shown in FLOW. Users can see Traffic lane names, boundaries of all TLs (including their visualized core zone - refer to the Wrong way core zone parameter in the global Traffic Lanes settings), section gates and decision gates and their directionality state.

Figure: FLOW Insights - overlay of TLs setup including visualization of Core Zones.

The user may assign a Lane code to each TL (in some interfaces these are referred to as Zone IDs). This ensures correct mapping of traffic data to ATMS or other connected systems. Available options are:

Figure: Traffic Lane settings - list of available traffic lane codes.

The Reversibility flag allows a TL to be configured as reversible. Based on this user-defined setting, the lane is permitted to change its direction of travel. This inverts the right-way/wrong-way classification logic applied to passing trajectories.

The Reversed indicator reflects the current status of a reversible lane (True/False). When active, the pass angle is internally rotated by 180°, while the stored pass angle value remains unchanged.

Figure: Traffic Lane settings - Reversibility and Reversed statuses.

The Multi-traffic lane (MTL) operator groups several individual Traffic Lanes (TLs) into a single composite element, allowing the user to configure and manage them as one. Within an MTL, the user may select which TLs are included.

When an MTL is created, two widgets are automatically generated and added to the Dashboard, where they can be further edited:

Figure: Multi-traffic lane operator moved to Canvas with automatically added 2 widgets. For now, 6 lanes are configured as part of the MTL operator.

In the operator’s configuration panel, the user can define the following:

Figure: Multi traffic lane widget - settings: choosing which TLs are selected to generate TrafficData and TrafficEvents, Filtered events settings, and setting priorities between TL decision gates. Option to Apply settings or Delete the MTL widget.

Figure: Multi traffic lane widget - settings: For each Lane, additional settings are available to configure enabled vehicle categories (which vehicle types will be included) for every event type.

Important:

This local setting is a priority over the global settings set in the Block -> Traffic Lane Settings. If Global settings does not allow a specific event setting, this setting is not locally available.

Figure: Events which are greyed out (here: car, van, heavy for Presence) are disabled from by global settings (greyed out).

TrafficData and TrafficEvents for the selected TLs are accessible both through these widgets and via the FLOW API (e.g., OPC UA or webhooks). Detailed descriptions of TrafficData and all supported TrafficEvent types are provided in the following sections.

Only a single MTL per analytic (cube) is allowed to avoid conflicts with TL priorities. However, TLs may be registered in other MTLs in different analytics.

For each TL included in the MTL, the user can define whether to collect:

This configuration ensures flexibility in how data is aggregated for specific lanes. Lanes not configured for calculation are ignored.

TL priorities within the MTL decide which TL a vehicle is accounted for when it passes multiple decision gates. If a trajectory crosses several gates, it is deterministically assigned to the TL with the higher user-defined priority.

TrafficData are aggregated statistics calculated for each TL of the MTL entity. They provide a snapshot of lane conditions within a defined time block, with results published once the block closes.

The reporting block length is configurable in Traffic Lanes Settings. TrafficData outputs include:

Figure: MTL Data widget output on the Dashboard.

For each TL, the Level of Service (LOS category) is calculated based on the average speed of vehicles in each time block. Six levels are implemented, ranging from the lowest average speed to free flow:

LOS levels are unrelated to actual speed limits for various lanes. The user may define custom speed thresholds for each category. Default values are pre-configured and adjustable in the Traffic Lane settings (see next chapter).

The Average speed in km/h or m/h is calculated using the position of the section gates which the objects are crossing and the distance between them. Position of the section gates is configurable on the camera view, the distance between the gates is an input as part of the TL element.

The Average length in m is calculated as a weighted mean of detected vehicles, based on their categories and the estimated average length for each category.

Estimated lengths per category are default values, configurable in the Traffic Lane settings.

Occupancy represents the share of time a traffic lane is “occupied” by vehicles. The occupancy parameter is calculated based on vehicle speed, virtual detector length, and estimated vehicle lengths. Pedestrians, bicycles, and motorcycles are excluded by default.

Formula:

where

With a physical detector on the roadway (e.g. an induction loop), d would correspond to the detector’s physical length. Since FLOW operates purely on video and no real detector is present on the road, the Virtual Detector Length is introduced to model this effect.The loop is occupied from the moment the front of the vehicle enters it until the rear of the vehicle leaves it – meaning the effective occupied length is the sum of the vehicle’s length and the detector’s length.

FLOW vehicle classes and their estimated lengths are configurable in the global Traffic lane settings.

TrafficEvents focus on discrete occurrences within TLs that may require attention, such as wrong-way driving, congestion, or abnormal vehicle behavior. Unlike TrafficData, which aggregates statistics over the whole time blocks, TrafficEvents report individual events that occurred at any time within a reporting interval.

An important property of TrafficEvents is that any event lasting for any part of the interval will be reported, regardless of the set time block length for TrafficData statistics.

The widget displays the following event types per lane and time block:

Figure: MTL Events widget output on the Dashboard.

Below follow descriptions of the available TrafficEvents with examples of JSON data received through the REST API. More information and REST API descriptions can be found in the Multi-traffic Lane API documentation.

The Presence event is generated if a simple detection condition is fulfilled within the given lane.

The Wrong way event is generated if a trajectory does not comply with the expected direction configured in the TL Directional widget. Specifically, if the average trajectory angle does not respect the configured Pass Angle and also falls outside of the allowed Angle Tolerance.

The Slow trajectory event is generated if the average section speed of a trajectory (measured between the Section gates) is lower than the threshold configured in the Traffic Lane settings under the Speed free flow parameter.

The default value for slow trajectory threshold (free flow limit) is configurable in the Traffic Lane settings.

The Stopped trajectory event is generated when a trajectory is classified as stationary within the TL. A trajectory is considered stationary if the bounding boxes of its first and last update positions overlap by at least 70% within the evaluation window (approximately 3 seconds). This overlap threshold is fixed and currently not configurable in the user interface. As soon as the vehicle is detected as stationary, the settings for generating a stopped vehicle are evaluated. This includes the minimum stationary time defined in the global settings, or optionally the settings specific to the given class.

For lanes where LOS event reporting is enabled, an LOS event is generated each time the Multi-traffic lane data time block closes. This means LOS events are produced periodically with the same interval as the MTL data block, with the LOS level reported in the range 1–6.

Note: If no trajectory contributing to LOS statistics is present in the block, the event is not generated.

This option, when turned on, ensures that one trajectory can generate at most one event of a given type within a multi-traffic lane (across all lanes included), regardless of how many times the trajectory meets the event condition or how much time passes between their individual detections. When aggregated, the original event data is updated - its start time stamp stays unchanged, while the end time stamp aligns with the end time stamp of the last event detection. Also, Lane Code will get updated and will be aligned with the last Lane Code associated with the event.

Aggregation applies strictly to trajectory events. Events that are not tied to a specific trajectory (in particular, LOS), are not aggregated.

Trajectory aggregation settings can be turned on for each MTL widget or globally on selected analytics (see Chapter Bulk Actions).

Figure: MTL settings - Aggregation of trajectory events.

Users may configure detailed Traffic lanes settings for the entire Block under Block ->Traffic lanes settings. These are often referred to as global TL settings. Some apply generally for the Block, others are defined separately per object category.

Figure: Block -> Traffic lanes settings - settings for the traffic lanes for the Block.

Sets the length in m or ft of the virtual detector. This value does not refer to any actual VA object, but is a configured value used formally in the calculation of occupancy metrics together with estimated category type lengths.

A larger Virtual Detector Length results in higher occupancy, as each vehicle is considered effectively longer during passage. A smaller Virtual Detector Length results in lower occupancy.

Figure: Traffic lane global settings - Virtual detector length.

Defines the free flow speed limit in kmph or mph. Vehicles travelling slower than this value are considered slow, which directly determines whether a Slow Trajectory event is triggered for a given lane.

Figure: Traffic lane global settings - Speed freeflow (Slow Trajectory threshold).

Defines the threshold for congesting vehicles in kmph or mph. Vehicles traveling slower than this value are considered congesting, which directly determines whether a Congesting Trajectory event is triggered for a given lane.

Figure: Traffic lane global settings - Speed congestion (Congesting Trajectory threshold).

Defines the Stopped vehicle duration threshold. Vehicles which have stationary duration over this limit are considered to have stopped, which directly triggers a Stopped Trajectory event for a given lane.

Figure: Traffic lane global settings - Minimum Stationary Duration.

Defines minimum time window which needs to be met before a Presence Event is triggered for an object in a given lane, where Enabled. Object types, which have Presence event detection enabled must meet at least this threshold. This helps minimize false or ghost (very short) detections.

Figure: Traffic lane global settings - Minimum Presence Duration for filtering Presence events.

Parameters to help filter wrong way events:

Figure: Traffic lane global settings - Parameters for filtering Wrong Way Trajectory events.

The core zone is visualized in the Analytics as an inner orange rectangle offsetting from the control points of the defined TL.

Figure: Wrong way core zone - visualized offset from the TL control points.

Noise track filter, if enabled, drops all MTL events from trajectories that look like detection noise (DNN flicker on static features such as shadows, road markings, signs). Each parameter is independently configurable and all must be satisfied to emit events.

Set their value to 0 to disable just that parameter.

Note: vehicles that arrive and then park are not filtered out, while vehicles that were already parked when the analytics started (with no observable arrival) will be filtered out as they cannot be distinguished from static false positives.

Minimum lifetime at trajectory must reach before it is allowed to emit events short tracks are typically DNN flicker.

Track displacement, expressed as a multiple of the tracks own average detection bounding box diagonal, that the trajectory must reach. Scale-invariant: the same value works at every camera distance - a real vehicle always traverses several of its own body lengths. Typical values 1.0 to 2.0.

Track displacement, expressed as a percent of the input image diagonal that the trajectory must reach. Acts as a safety net for tiny distant tracks, where DNN bbox jitter alone could inflate the self-ratio. Typical values 2% to 10%.

Figure: Traffic lane global settings - Noise track filter advanced settings.

Defines the length of the time blocks used for aggregating TrafficData statistics. Once a block closes and is published, its values cannot be corrected.

Supported intervals are:

Figure: Traffic lane global settings - configurable TrafficData time block length.

To improve accuracy, FLOW applies a short publishing delay (3.5 seconds) to allow backward corrections after the time block has been closed. However, trajectories that overlap two blocks may still appear in both, potentially causing double counting.

Tip: Place decision gates of neighboring lanes close together to reduce duplicate detection, or increase the time block length to minimize the total number of blocks.

Users may define custom LOS speed thresholds in kmph or mph. These are respected in the calculation of the LOS statistics within the TrafficData.

Figure: Traffic lane global settings - configurable thresholds for Levels of Service 1–6.

Each object category (car, bus, bicycle, etc.) may be configured with a specific average physical length in m or ft. Object category lengths are used in the calculation of occupancy within lanes and may be adjusted by the user.

Figure: Traffic lane global settings - object category lengths.

Users may specify whether a given object category (by default, all object categories are included) should be included or excluded from certain statistics in the TrafficData, specifically:

Figure: Traffic lane global settings - Inclusion of objects in non-count statistics inclusion.

For each event type, users may specify which lane types should be included in the calculation. Lane types that can be selected are:

This can also be configured for each category type separately.

IMPORTANT: If certain events are disabled per category or lane type in this global settings, it cannot be enabled locally in specific analytics, MTL operator. The check boxes will be greyed out.

Figure: Traffic lane global settings - selection of lane types for each event type and object category.

For Presence event detections, users may define speed thresholds which must be met in order to emit an event. These settings may help filter false or ghost events, such as too fast objects (mis-)categorized as a pedestrian, tractor etc., or too slow vehicles which are expected to go fast.

Figure: Traffic lane global settings - filtering presence events by speed of their trajectories.

For Slow trajectory event detection, a slow speed override may be set for a specific object category, in kmph or mph. This value overrides the globally set Speed Freeflow parameter, just for this specific object type. This may be useful when different speed is considered slow for different categories.

Figure: Traffic lane global settings - filtering slow trajectory events by adjusting their slow speed threshold per category.

Verify configuration button goes through all FLOW analytics, all MTL operators, all TLs, and their settings. It lists any invalid lanes, which should be inspected for their settings. Specifically, it checks for the following:

Figure: Traffic lane global settings - Verify configuration.

This summary can be copied and investigated.

Figure: Traffic lane global settings - Verify configuration output summary.

With Alt+E shortcut on the List of Analytics screen, a bulk action dialog is activated with a number of options to manage the set of analytics. The following are related to the Multi-traffic lane feature.

Figure: Bulk settings dialog activated with Alt+E on the List of Analytics screen.

Iterates through all Traffic Lanes present. Options are:

Figure: Analytics bulk settings - TLs’ Reversed statuses bulk settings.

For all MTL operators Enable or Disable event aggregation.

Figure: Analytics bulk settings - Bulk-enable event aggregation.

In addition to TrafficData and TrafficEvents, FLOW supports sending Generic Events. These events do not describe traffic conditions but reflect the system state or the status of analytics.

Generic events are divided into two categories:

The behavior of generic event delivery can be configured in the Webhook interface.

Figure: Configuration of the policy for sending system and analytic events (generic events).

Internally, all enabled events are stored in a buffer. For each unique combination of type + cube id + analytics id, exactly one event is kept, controlled by its own timer. Events that are not enabled for sending are not buffered and therefore will not be available retroactively if settings change later.

List of Generic Events:

Details for each of the event type, including JSON data examples and threshold limits are described in the Multi-traffic Lane API documentation.

FLOW enables the option to navigate through all emitted MTL events through the MTL Events section. This section lists all historical events, paginated by 100 objects, presents their details and offers export functions. It contains 3 different views:

Figure: MTL Events section with 3 views and a list of results.

List of events can be searched and filtered as follows. Applying filters, the list is automatically updated to meet the search and filter criteria:

Figure: List View search bar.

This filter allows complex filtering by cubes using inclusion or exclusion lists.

Figure: List View advanced cube filter.

As some events may not have video available, use this filter to filter out such events, where:

Figure: List View filter for videos with their video evidence available.

Figure: List View time and range filtering options.

Figure: List View Event type and Category filtering options.

Currently filtered events may be exported in a CSV file format as an overview.

Figure: List View - exporting to CSV.

Events in the List view can be sorted by ID, Cube, Lane #, Event Type, Category, Traj. ID, Start Time and End Time.

Figure: List View sorting options.

The Statistics view calculates the statistics of event types per cube. This view offers similar filtering and searching options, and export options, as the List view.

Figure: Statistics view with an overview of event types statistics.

The Cluster View introduces additional gap parameter, which groups filtered events by their time proximity and presents their count.

Figure: Cluster View with a gap parameter, grouping the events by time proximity.

Right clicking a cluster either, the user may Export videos from this group, or show the clustered events in a list.

Figure: Cluster view right-click dialog.

Figure: Cluster View - expansion of the event cluster to a detailed event list.

Further to that, specific events from the cluster may also be (right-click) exported as video, or shown in JSON format.

Figure: Exporting options inside the Cluster view detailed list.

Events in the Cluster view may be sorted by Count, Cube, Lane, Event Type and

Figure: List View advanced cube filter.

Currently filtered events in the List View and Cluster View may be exported as videos using a batch command. Export Videos dialog offers further limit and render settings of the exported videos:

Figure: Export Videos dialog managing an export of the current filtered event list, triggered by the Videos button.

Right clicking a specific event in a list, the event may be

Figure: Export video configuration options.

Figure: JSON payload format of an event shown using the right-click dialog.

Similar to the MTL Events section, Generic Events section presents all emitted events, which are non-MTL. Generic events, as described in the respective chapter are separately configured in the Webhook settings and are used to oversee the system state or the status of analytics. Details are available but there are no export options per their nature.

This section contains 2 different views:

Figure: Generic Events Section with 2 views and paginated outputs.

The List View contains a list of emitted events with their details.

Figure: Generic Events List view.

Filtering is possible using the following criteria. The list is automatically regenerated.

Figure: Generic Events list filter by Event type.

Similar to MTL events, Generic Events Statistics view provides a summary for a defined filter per cube.

Figure: Generic Events Statistics view.

Learn more about widgets and sinks in FLOW, explore time processing, or check out other widget types such as Value and Movement Set Statistics. Use the FLOW Public API to access data from widgets and sinks and integrate it with your external systems.

Make your traffic analytics smarter and more connected with FLOW.