THE CHALLENGEA Position Is Not an Insight Until It Has Context
A raw latitude and longitude tells you where something is, not whether it should be there. Most tracking products bolt on a crude radius alert and then drown operators in false entries every time GNSS noise nudges a vehicle across a boundary. Real geofencing needs polygon shapes, dwell confirmation, hysteresis, and the judgement to decide what runs on the device versus the server. That spatial layer is built as a first-class engine so a position turns into a meaningful event you can act on.
Part of the Telematics and GPS Tracking stack, and commonly built alongside Fleet Management Solutions.
WHAT'S INCLUDED
A Complete Geofencing Engine
Fence Creation and Management
An editor and data model handle drawing circular and polygon fences on a map, grouping them, versioning them, and attaching metadata. Fences are stored in a spatial database with indexed geometry so a fix can be tested against the relevant set in milliseconds rather than scanning every shape.
Entry, Exit, and Dwell-Time Alerting
A state machine tracks each asset against each fence and fires on entry, exit, and dwell thresholds. Dwell confirmation and a hysteresis band on the boundary stop a single noisy GNSS fix from generating false alerts, which is the usual reason crude geofencing gets switched off.
Route Deviation and Corridor Monitoring
A planned route is buffered into a corridor polygon, with an alert raised when a vehicle leaves it by more than a set distance. This catches unauthorised detours, off-route stops, and theft that a single destination fence would never see, and it works for fixed delivery rounds and cash-van routes alike.
POI and Zone Automation
Rules attach to points of interest and zones so arriving at a customer site logs a visit, entering a restricted area opens a ticket, and crossing a toll zone tags the trip. The automation layer turns geofence events into actions in your dispatch, billing, or ticketing systems.
Speed-by-Zone Enforcement
Different speed limits apply inside different zones, for example a low limit inside a depot or school zone and a higher one on the highway. The device or server compares the GNSS-derived speed against the active zone limit and raises a violation with the location and timestamp attached.
Geofencing API and SDK
The engine is exposed through a REST and webhook API and an optional SDK so third-party products can create fences, attach rules, and subscribe to entry, exit, dwell, and deviation events. Your team consumes clean events instead of rebuilding point-in-polygon and state-tracking logic.
WHERE THE LOGIC RUNS
On-Device or Server-Side
The single biggest design decision in a geofencing product is where the inside test runs. That choice is made per fence based on the latency, the connectivity, and the number of shapes involved, with a hybrid as the typical design so critical fences are evaluated on the tracker and the long tail stays on the server.
On-Device Evaluation
The tracker holds a small fence table in flash and tests its own GNSS fix on every cycle. This gives sub-second alerts and keeps working through cellular dead zones, which matters for theft and safety triggers. It is bounded by the STM32 or modem MCU memory and only suits a few dozen simple fences.
Server-Side Evaluation
Fixes stream to the platform over MQTT and a spatial engine tests them against thousands of fences with indexed geometry. This handles complex polygons, fleet-wide rules, and frequent fence changes at the cost of one network round trip and dependence on connectivity.
Hybrid Pushdown
The most critical fences are compiled and pushed down to the device over the air, while the full set stays server-side. Devices alert instantly on the fences that matter and the server stays the source of truth for everything else.
ACCURACY AND RELIABILITY
Designed Around Real GNSS Limits
Honest Fence Tolerances
A u-blox or NavIC-capable receiver resolves position to roughly 2.5 to 5 metres CEP in open sky and worse under canopy or between tall buildings. Fence edges are never placed tighter than the receiver can see, so detection stays trustworthy instead of reporting boundary crossings that did not happen.
Hysteresis and Dwell Confirmation
A hysteresis band surrounds every boundary, and the asset must stay inside or outside for a confirmation window before the event fires. This is what stops a vehicle parked on a fence line from generating a stream of entry and exit alerts all night.
Fix Quality Gating
Events are gated on fix quality, using HDOP and satellite count to discard a degraded fix before it reaches the fence test. A geofence acting on a low-confidence position is worse than no geofence, so the bad fix is dropped rather than alerted on.
Map-Matching for Corridors
For route deviation, fixes are snapped to the road network before measuring offset, so a parallel service road or a GNSS wobble is not mistaken for a detour. Only a genuine departure from the corridor raises the alert.
FAQ
Common Questions
Should geofences be evaluated on the device or on the server?
It depends on the alert latency and connectivity profile required. On-device evaluation, where the tracker holds a small fence table and fires events from its own GNSS fix, gives sub-second alerts and works through cellular dead zones, but it is limited by tracker flash and CPU. Server-side evaluation handles thousands of fences, complex polygons, and fleet-wide rules, at the cost of one network round trip. A hybrid is the typical design, pushing the most critical fences to the device and keeping the rest server-side.
What is the difference between circular and polygon geofences?
A circular fence is a center point and a radius, so the inside test is a single distance calculation that is cheap enough to run on an STM32 tracker. A polygon fence is a list of vertices and uses a point-in-polygon test, which is heavier but lets you trace a depot boundary, a customer yard, or a city zone exactly. Both are supported, with the choice made per fence based on the shape actually needed.
How accurate is geofence detection in practice?
Detection accuracy is bounded by GNSS accuracy, which is roughly 2.5 to 5 metres CEP in open sky for a u-blox or NavIC-capable receiver, and worse under canopy or in urban canyons. Fence edges are never placed tighter than the receiver can resolve. To avoid flapping at a boundary, a hysteresis band and a dwell confirmation ensure a single noisy fix does not generate a false entry or exit.
Can route deviation be monitored and not just zone entry?
Yes. Corridor monitoring buffers the planned route into a corridor polygon and alerts when the vehicle leaves it by more than a configurable distance. This catches unauthorised detours, theft, and off-route stops that a simple destination geofence would miss.
Can other teams consume your geofencing engine?
Yes. The engine is exposed as a REST and webhook API plus an optional SDK so your own application can create fences, attach rules, and receive entry, exit, dwell, and deviation events without rebuilding the spatial logic.
Add Real Location Intelligence to Your Product
Share your fences, your trackers, and the alerts you need to get a clear split of the work between device and server and a reliable geofencing engine in your product.
Schedule a Free Consultation