A truck spends the week between the yard, a customer and an underground lot. The report says that twelve times, with the engine off and nobody touching it, it left the yard and came back in.
For years we used geofences for almost everything: yard entries and exits, no-go zones, customer arrivals, routes. Circles and polygons; polygons were a more interesting challenge than a plain circle. And for years we fought the same failures: alerts that matched nothing, arrivals that never showed up, times that did not add up.
This note is about those failures, about the fixes almost everyone applies, and about a design mistake that stays hidden until someone changes a value: computing the geofence on the fly.
The figures in the examples are illustrative: they come from a simulator with a typical week of a truck, not from measurements of those fleets.
In or out looks like an easy question
For a circle, one distance is enough: if the position is closer to the center than the radius, it is inside. For a polygon, the classic test draws a line from the position off to one side and counts how many times it crosses the edge: odd, inside; even, outside. An L-shaped yard, a zone that follows an avenue, a customer with two gates: all of that is a polygon.
The geometry is the easy part. The hard part is that the question is put to a GPS position, and the position does not always say where the truck is.
What failed
Parked, the position jumps farther than the geofence. With the truck standing still, accuracy sometimes falls apart and a position lands a hundred or two hundred meters away. The simulator's yard is eighty meters across. To the geofence that is an exit, and the next good position is an entry. In the history, the truck seems to cover large distances in a few minutes without having moved.
Positions that arrive late. A 7:10 position that arrives at 7:30, after the 7:20 ones, puts the truck back where it no longer was. If the geofence is evaluated in arrival order, that is one more entry and one more exit that never happened.
The device stops transmitting right before it arrives. In an underground parking lot the signal is lost on the ramp. The last position stays on the street and the next one comes in once the truck has already left. The entry never shows up.
And the interval makes all of it worse. With the ignition on, our devices reported every 3 minutes; off, every 120. At 40 km/h, the truck covers 2 km in 3 minutes. A 400 m no-go zone is crossed in 36 seconds, so only one crossing in five leaves a position inside.
In the simulator, one week of that truck: 205 reports, 70 real entries and exits. Deciding with the raw point, position by position, gives 45 false alerts: 31 with the truck parked in the yard, and 14 from positions that arrived late. It sees 3 of the 14 zone crossings and none of the 7 entries into the underground lot.
A bit of all three
The fixes we applied, and that almost everyone running a fleet applies, were a bit of three things:
- A margin to exit. The geofence is entered at the edge, but to exit the truck has to get a certain distance away. That removes the dithering of a truck parked by the fence. Against a two-hundred-meter jump it does nothing: with a 30 m margin, the 45 false alerts drop to 39.
- Waiting for several reports in a row. A lone jump confirms nothing. With two positions in a row, false alerts drop to 13. But with the ignition off each position comes two hours after the previous one: the seven returns to the yard are reported two to six hours late, and seven of those 13 are real arrivals at the wrong time. And a single late position in between breaks the streak: it sees 3 of the 7 customer arrivals.
- Using the ignition or the speed. With the engine off, the truck does not move. That removes almost all the yard ones; 21 remain, mostly from late positions and from the stretch when the engine warms up with the truck parked.
Each one helps, and each one is paid for somewhere else. I would sum up what we learned like this: any intervention or change of values eventually causes false positives or altered information.
On the fly
And the worst part was none of those. On that platform, a geofence entry or exit was not stored: it was computed in the web client, on the fly, every time someone opened the map or the report.
As long as nobody touches anything, that seems to work. The problem arrives with the first complaint. Someone enlarges the yard so the alerts stop, or raises the margin, or changes the customer's polygon. From that moment on, last week's report is recomputed with the new geofence and says something else.
In the simulator, enlarging the yard by 100 m brings the false alerts from 45 down to 31: it does not silence them, because the late positions and the longest jumps are still there. And in that same week's report, computed on the fly with the new yard, 23 alerts change: 16 disappear, 3 move to a different time and 4 appear that were not there before. If someone asked on Tuesday about a yard alert, the one they were shown may no longer be there, or may be at another time.
A history that changes when the configuration changes is not a history.
What I would do today
Store the event, once. The entry or exit is computed when the position arrives and stored, with the version of the geofence and that day's values. If the yard grows tomorrow, it grows from tomorrow on.
Stamp it with the position's time. Not the time it arrived. A late position is slotted into its place in the trip, and the alert carries the time it happened, even if it is sent later. If that position changes an event already stored, the event is corrected and the record says it was corrected and why: a late data point explains the change; a new configuration does not.
Drop the position, not the report. A position flagged as bad by its own quality data is discarded. But the report still says the device spoke and, if it is the ignition-off report, when the truck stopped.
Confirm with more than one signal. Two positions in a row, or the ignition-off report, or a position whose GPS speed is above 15 km/h. On most devices speed is measured separately, from the Doppler effect, and barely jumps with the position: a truck doing 40 km/h is not jumping. With the ignition off, a jump does not take the truck anywhere; if the GPS says it is moving, that is a different alert, the tow alert.
Check the segment, not just the point. If the straight line between two positions goes through the no-go zone, the truck most likely crossed it, even if no report fell inside. The time is interpolated along the segment, and the crossing is stored as inferred. With real streets, the line is checked against the street layout.
Three states, not two. Inside, outside and unknown. When the device goes quiet near a place known to have no signal, the entry is inferred, and stored marked as inferred. Whoever reads the report knows what was seen and what was deduced.
With as much of that as the simulator can model, in the same week: no false alerts, all 70 entries and exits, 36 of them inferred and marked as such (the zone crossings and the underground lot), and the time 1.1 minutes off on average. Not because it is perfect: the simulator only carries the failures I put in it, and the street has others. But each of those rules answers something that fails.
To try it with another week, with more bad or late positions, another margin or a bigger yard, there is the geofence simulator: it runs in the browser and decides in or out five ways.
Geofences did not fail because of the geometry. They failed because a lone position was asked something only the truck's history can answer, and because that answer was not stored.
Your turn
Where does your platform decide in or out: when the position arrives, or every time someone opens the map? And if someone changed a geofence today, would last month's report change with it? If you want to try your own margin and rules on a full week, the simulator is at crtdrops.mx/geocerca.
Israel Negrete Lepe is an electronics engineer. Twenty-five years making different systems work together under real conditions: from the sensor, the vehicle or the transaction to the backend, the data, security and operations. Today, increasingly, edge AI.
