Skip to main content
Type I checks evaluate whether a track is present in specific zones and whether its zone interaction metrics (intersection, dwell time, velocity) meet configured thresholds.

When to use

Use Type I for any use case where the core question is “is this object in this zone doing this thing?”:
  • Obstruction / loitering — dwell time above threshold, velocity below threshold
  • Zone intrusion — any presence in a restricted zone with minimum intersection
  • Congestion — multiple tracks in a zone exceeding thresholds
  • Speeding — velocity above threshold in a zone
  • Stopped vehicle — velocity below threshold for extended dwell time

How it works

  1. The node reads the track’s zone data (active zones for live data, historical zones for expired tracks)
  2. For each zone that has a threshold configuration, it evaluates all enabled thresholds
  3. A zone passes if all enabled thresholds pass (AND logic within a zone)
  4. The overall check passes if at least one zone passes (OR logic across zones)

Configuration

Site

Select the Worlds site. This loads the available zones for threshold configuration.

Threshold groups

Threshold groups define which zones to check and what thresholds to apply. Each group contains:
ParameterDescription
Zone IDsWhich zones this group applies to
IntersectionMinimum overlap between the object’s bounding box and the zone polygon
Dwell TimeHow long the object has been in the zone
VelocityHow fast the object is moving within the zone
Each threshold has:
  • Enable toggle — only enabled thresholds are evaluated
  • Operator>=, >, <=, <, ==
  • Value — the threshold value
Threshold units:
ThresholdUnitDescription
Intersection% (0–100)Percentage of bounding box overlapping the zone
Dwell TimesecondsTime spent in the zone
Velocitypx/s or m/sSpeed within the zone (pixel or geo-referenced)
You can create multiple threshold groups to apply different thresholds to different zones. A zone can only belong to one group.

Advanced settings

ParameterDefaultDescription
Check TargetAutoauto detects from trigger mode. Override with active or history.
Debug ModefalseEnable verbose logging

Output

{
  "track_state": { ... },
  "checks": {
    "type1": {
      "passed": true,
      "check_target": "active",
      "check_target_source": "auto",
      "matching_zones": ["79"],
      "matching_zone_count": 1,
      "zone_details": {
        "79": {
          "zone_id": "79",
          "zone_name": "op120-zone",
          "source": "active",
          "passed": true,
          "thresholds": {
            "intersection": {
              "enabled": true,
              "operator": ">=",
              "threshold": 10,
              "actual": 59.25,
              "passed": true,
              "unit": "%"
            },
            "dwellTime": {
              "enabled": true,
              "operator": ">=",
              "threshold": 300,
              "actual": 360,
              "passed": true,
              "unit": "seconds"
            },
            "velocity": {
              "enabled": true,
              "operator": "<",
              "threshold": 5,
              "actual": 1.2,
              "passed": true,
              "unit": "px/s"
            }
          }
        }
      },
      "zones_checked": ["79"],
      "zones_not_configured": ["42"],
      "zones_not_found": []
    }
  }
}

Key output fields

FieldDescription
passedWhether any zone met all thresholds
matching_zonesZone IDs that passed
zone_detailsPer-zone breakdown showing each threshold’s actual vs. configured value
zones_checkedZones that were evaluated (had threshold config and were present in input)
zones_not_configuredZones the track was in but had no threshold config
reasonIf failed: no_zones_configured, no_zones_data_in_input, no_zones_met_all_thresholds, etc.

Business use case examples

Detect vehicles (forklifts, tuggers, AMRs) blocking factory aisles. A vehicle is considered an obstruction when it has been in an aisle zone for an extended period with low velocity.
ThresholdOperatorValuePurpose
Intersection>=10%Vehicle bounding box must overlap the zone
Dwell Time>=300s (5 min)Vehicle must have been stopped for at least 5 minutes
Velocity<5 px/sVehicle must be stationary or near-stationary
Mode: Batch — only need the track summary after the vehicle leaves.All three thresholds are enabled, so a zone only passes if all three conditions are met simultaneously. Different aisle zones can share a single threshold group if they have the same criteria, or use separate groups for zones with different dwell time requirements (e.g., loading docks allow longer stops).See the Obstruction Workflow guide for the full end-to-end walkthrough.
Detect vehicles that fail to come to a complete stop at designated stop sign zones. This is a compliance monitoring pattern — every vehicle passing through creates an event, either compliant or non-compliant.
ThresholdOperatorValuePurpose
Velocity<=25–120 px/s (varies)Vehicle’s average velocity must be at or below the zone’s speed threshold
Mode: Batch — only need the track summary after the vehicle passes through.The key detail: 10 separate threshold groups with different velocity values. Zones near intersections have lower thresholds (stricter stops), while zones in high-traffic corridors have higher thresholds. Each stop zone is assigned to exactly one group.A code node downstream preserves the original pass/fail result as threshold_passed, then overrides type1.passed = true so that both compliant and non-compliant tracks flow through to event creation. The event subtype is set dynamically based on the saved result.
As a pre-filter in the PPE compliance workflow, Type I determines whether a person is in a designated PPE zone before evaluating whether they’re wearing PPE (via a Type III check).
ThresholdOperatorValuePurpose
Intersection>=10%Person must be in a PPE-required zone
Mode: Batch — using person and PPE tags together so interactions are calculated.Only intersection is enabled — no dwell time or velocity requirements. The check simply answers “is this person in a zone that requires PPE?” Tracks that fail are dropped via an early-exit Switch node before running the more expensive Type III interaction check.This demonstrates how Type I can be used as a lightweight filter in a multi-check composition (Type I → Type III → VLM fallback).
Type I is the most flexible check node — different threshold combinations serve very different use cases:
Use CaseIntersectionDwell TimeVelocity
Aisle obstruction>= 10%>= 300s< 5 px/s
Loading dock overstay>= 20%>= 1800s< 2 px/s
No-park zone violation>= 10%>= 60s< 3 px/s
Zone intrusion>= 5%
Speeding in zone>= 10%> 200 px/s
Stop compliance<= 50 px/s
The key principle: enable only the thresholds you need for your specific use case. Fewer enabled thresholds means a broader match.

Active vs. historical zones

Check TargetSourceWhen
Activezones.activeStreaming/live — zones the track is currently in
Historyzones.historyBatch/expired — zones the track was previously in
For historical zones, the node uses “any entry passes” logic — if a track visited the same zone multiple times, only one entry needs to pass all thresholds.

Credentials

Requires GraphQL Subscription API credentials (for loading site/zone options).