Why Waiting Vehicles Need Geofence Truth (Why Waiting Vehicles Need Geofence Truth)

Waiting is a region, not a point

An operator sees a pin and says 'waiting'. The real questions: is the vehicle inside a defined zone, what is ignition doing, and is the wait reason classified?

Telematics point  →  inside circle?  →  wait reason?
       lat/lng              km_metric             ops taxonomy
                              ↓
                     Waiting truth on map

This series builds waiting truth from telemetry, geofence, and operational taxonomy.

Concepts, defined where they first appear

📦 Waiting Truth
A map-shown wait that is operationally defensible.

📦 Circle Geofence
Boundary defined by center and radius.

📦 Ignition Signal
Telemetry evidence such as engine on/off.

📦 False Wait
Incorrect wait record from noise or missing classification.

A point is evidence; without circle and taxonomy it is not an operational decision.

Why a pin is not enough

One coordinate does not say the vehicle is still in a yard. Example rule: remain inside a km radius (e.g. 5 km).

Two truths

Telemetry says where; ops says why waiting.

Telemetry evidence ≠ Wait decision

Job of the map

The map draws evidence; taxonomy records the decision.

The mappings that get confused most often

❌ Last GPS point = waiting
✓ Waiting = boundary + duration + reason class

❌ Radius always hardcoded 5 km
✓ Radius must come from API/config (km_metric)

❌ Vendor UI is the ops system
✓ Vendor feed is an integration edge

A checklist for auditing your own system

1. Which fields make a wait record 'true'?
2. Where does radius come from: code or API?
3. Can a wait open without ignition evidence?
4. Who closes false waits?
5. What metrics appear in the map popup?

What to take away from this part

1. Waiting is a regional decision, not a pin.
2. Telemetry is evidence; ops state is a decision.
3. Radius must be an explicit contract.

Seeing a pin is not managing a wait.