Designing Geofences for Yards, Customers and Ports

The carrier invoices three hours of detention at a distribution centre. The shipper's visibility platform says the truck was on site for 56 minutes beyond free time, because its 150-metre circle around the building centroid missed the queue on the access road and logged a false exit when the trailer was moved to the far side of the yard. Both parties hold timestamps. Neither can prove which one describes what happened, so the invoice sits in dispute for six weeks.

Geofences produce trustworthy events when each one is designed as a definition of a business event: the shape follows the site's real footprint, the boundary is sized from measured position error and the device's reporting interval, entry and exit need confirmation, and every event records which version of the fence produced it. Designed that way, arrival, dwell and departure times stand up in a billing dispute.

• Design choices covered: radius versus polygon, boundary sizing arithmetic, dwell confirmation and exit hysteresis for yards, customer sites and port terminals.
• Failure modes covered: drive-bys, gate queues, signal reflection near container stacks, overlapping fences, tractor-trailer separation and sparse ELD positions.
• Tools included: a GeoJSON fence payload, a detention example in USD and INR, a terminal incident trace and a pre-launch test checklist.

Start from the business event each geofence has to prove

Write down the event before drawing the shape: "truck joined the gate queue", "truck is at a dock door" and "truck left the customer's property" need different fences, even at the same address. One fence asked to answer several questions usually answers none of them precisely enough to bill or alert on.

Most logistics fences serve one of four consumers: the yard management system timing gate-to-dock turns, the TMS starting and stopping detention clocks, the customer notification service sending arrival alerts, and the ePOD application checking that a signature was captured at the right place. Each consumer tolerates a different error, so each gets its own fence or its own ring within a fence.

Our earlier article on ePOD geofence radius locks and dispatch SLA math looks at one consumer, the delivery confirmation screen. This guide steps back to the geometry itself: how to choose, size, version and test fences so that every consumer, including detention billing, receives events it can defend.

Radius or polygon: choosing a shape from the site's footprint

Use a circle only for small sites with one entrance and nothing confusing nearby; use a polygon for yards, multi-gate DCs, port terminals and any site beside a highway or a neighbour's yard. A circle centred on a geocoded address usually lands on the building or a postal centroid, which can sit hundreds of metres from the gate that matters.

The choice also depends on where the fence is evaluated. Android's geofencing API defines a fence as a latitude, longitude and radius, a circle, and limits each app to 100 active fences per device user. Driver apps that use on-device fencing therefore work with circles and must register only the next stops on the route, while polygons are evaluated on the server against the stream of reported positions.

• Circle strengths: one centre and one radius, cheap to store, supported natively on phones, easy to explain to a customer service agent.
• Circle weaknesses: includes roads, car parks and neighbouring yards inside the radius; excludes long queue lanes and remote trailer pools outside it.
• Polygon strengths: follows the fence line, the queue lane and the dock apron; can exclude a public road running past the gate.
• Polygon weaknesses: needs someone to draw and maintain it, and needs server-side evaluation, which in turn depends on a steady position stream from the vehicle.

For polygons, store geometry in GeoJSON as RFC 7946 defines it. Positions list longitude first and latitude second, a linear ring is closed with at least four positions where the first and last are identical, exterior rings run counterclockwise and holes clockwise, and coordinates use WGS 84. Most mapping bugs in fence tools come from swapped axis order, which places a Chicago yard somewhere in the Indian Ocean.

Sizing the boundary from position error and reporting interval

The fence edge needs a margin equal to the position error you actually observe plus the distance a truck travels between two position reports. On most fleets the second term is far larger than the first, so the reporting interval near sites, not satellite accuracy, decides how small a reliable fence can be.

The US government's GPS programme site states that GPS-enabled smartphones are typically accurate to within 4.9 metres under open sky, and that accuracy worsens near buildings, bridges and trees. Android's documentation is more cautious for its fused location: Wi-Fi-based accuracy usually falls between 20 and 50 metres, can degrade to hundreds of metres or kilometres in rural areas without Wi-Fi, and the recommended minimum geofence radius is 100 to 150 metres.

Boundary margin and dwell floor
  d_margin   = e95 + v x dt
  e95        = 95th-percentile horizontal error of your devices at this site, metres
  v          = typical approach speed at the fence edge, metres per second
  dt         = position reporting interval near the site, seconds
  T_dwell   >= n_confirm x dt     (n_confirm = consecutive inside reports required)

Example: e95 = 25 m, v = 11.1 m/s (40 km/h), dt = 60 s
  d_margin  = 25 + 11.1 x 60 = 691 m
  with dt = 10 s near the site: 25 + 111 = 136 m
  with n_confirm = 3 and dt = 60 s, no stop shorter than 3 minutes is reliably seen

GeoJSON fence (illustrative coordinates, longitude first, exterior ring counterclockwise)
{
  "type": "Feature",
  "geometry": {
    "type": "Polygon",
    "coordinates": [[
      [-88.1520, 41.5210], [-88.1460, 41.5210], [-88.1460, 41.5255],
      [-88.1490, 41.5268], [-88.1520, 41.5255], [-88.1520, 41.5210]
    ]]
  },
  "properties": {
    "fence_id": "DC-JOL-YARD",
    "version": 4,
    "valid_from": "2026-11-01T00:00:00Z",
    "event": "INSIDE_YARD",
    "entry_confirm_reports": 3,
    "exit_buffer_m": 60,
    "exit_confirm_reports": 3,
    "max_speed_kmh_for_arrival": 10,
    "owner": "site-ops-joliet"
  }
}

The arithmetic explains a common complaint: "the fence never fired". A truck reporting once a minute at 40 km/h covers about 667 metres between reports, so it can pass straight through a 150-metre circle without a single position landing inside. Ask the telematics provider for a faster reporting rate within a set distance of planned stops, or evaluate the straight line between consecutive positions against the polygon instead of the points alone.

Geofence sizing for yard and customer-site arrival events should add the 95th-percentile position error measured on the fleet's own telematics to the distance a truck covers between reports; at 40 km/h and a 60-second interval that travel term alone is about 667 metres, larger than Android's recommended 100 to 150 metre minimum radius.

Dwell confirmation and exit hysteresis that survive queues and drift

Declare arrival only after several consecutive reports inside the fence at low speed, and declare departure only after several consecutive reports beyond a wider exit boundary. A single position crossing the line in either direction should never start or stop a billing clock.

Android offers the same idea on the phone: its documentation recommends the dwell transition with a loitering delay instead of the enter transition when brief drive-past alerts cause noise, and warns that alerts can lag by up to about two minutes, or longer when the device has been stationary. Server-side rules for vehicle telematics follow the same pattern with explicit counts, speeds and buffers that the fence record stores.

1. Outside: no recent report inside the entry boundary; nothing is emitted.
2. Candidate inside: the first report lands inside; the rule waits for the confirmation count and checks speed is below the arrival threshold.
3. Inside: confirmation met; the arrival event is emitted with the timestamp of the first inside report, not the confirming one.
4. Candidate outside: a report lands beyond the exit buffer; the rule waits for the exit confirmation count before acting.
5. Departed: exit confirmed; the departure event carries the timestamp of the first report beyond the buffer, and dwell equals departure minus arrival.

Where false events come from at yards, customer sites and ports

Most false geofence events come from six repeatable causes, and each has a design fix that is cheaper than arguing about invoices afterwards. Tag every disputed event with one of these causes for three months and the list of fences to redraw writes itself.

• Drive-past traffic: a circle that overlaps a highway or a neighbour's entrance fires as trucks pass; fix with a polygon, a speed threshold and dwell confirmation.
• Queues outside the line: trucks waiting on an access road or outside a terminal gate are invisible to a fence drawn on the property boundary; fix with a separate queue polygon.
• Stationary drift: a parked truck's reported position wanders, especially near tall structures, and crosses the edge; fix with an exit buffer and exit confirmation count.
• Overlapping fences: two customers in one industrial park share an access road; fix by matching events to the planned stop sequence before the nearest fence.
• Tractor and trailer separation: the tracking device sits on the tractor, so a dropped trailer "leaves" with it; fix by recording drop and hook events from the yard system.
• Phone leaves the cab: a driver app reports the driver walking to the shipping office, not the truck; fix by preferring the vehicle's telematics unit for dwell where both exist.

Hours-of-service data is a tempting shortcut and a poor fence feed. Under 49 CFR 395.26(d)(1), an ELD makes an intermediate record while the vehicle is in motion only when there has been no duty status change or other intermediate record in the previous hour. Under 395.26(i), location during authorised personal use is logged with one decimal place, roughly a 10-mile radius.

Hours-of-service ELD records are a weak geofence feed for detention: 49 CFR 395.26(d)(1) requires an intermediate location record only after one hour in motion without another record, and 395.26(i) reduces personal-use location to one decimal place, roughly a 10-mile radius, so dwell timing needs a separate telematics or app position stream.

Keeping fence geometry as versioned master data

A fence is master data with an owner, a version number and an effective date, and every event must store the fence identifier and version that produced it. Editing a polygon in place silently changes how last month's detention would be recalculated, which is exactly the question a disputed invoice asks.

• Never edit in place: a geometry change creates version n+1 with a new effective date; version n stays available for replaying old events.
• Change triggers: a new gate, a relocated queue lane, construction, a new trailer pool or a run of disputed events tagged to that fence.
• Customer confirmation: where detention or service-level credits depend on a customer-site fence, send the customer a map of the polygon and keep their confirmation with the version.
• Review cadence: list every fence with its false-event rate each quarter and assign the worst ten for redraw.

In India, the vehicle often already carries a regulated tracking device. MoRTH's G.S.R. 617(E) of 3 August 2022 requires N2 and N3 vehicles carrying dangerous or hazardous goods, built from 1 September 2022 for new models and 1 January 2023 for existing models, to have an AIS-140 vehicle location tracking device, and states such as Tripura extend AIS-140 fitment to national permit goods carriages. Whether the shipper can use that device's feed depends on the device vendor's contract.

Customer-site geofence polygons stored as GeoJSON under RFC 7946 list longitude before latitude, close each linear ring with at least four positions and wind exterior rings counterclockwise; the TMS should stamp every arrival and departure event with the fence identifier and version so that a detention invoice can be reproduced months later.

A detention dispute worked in USD and INR

A centroid circle with no exit hysteresis undercounted dwell on between a fifth and a third of eligible loads in this illustrative month, costing a US carrier about $11,800 and an Indian fleet about ₹2.7 lakh in detention it could not evidence. The contract terms and volumes below are illustrative, not market rates.

The same design also helps the paying side. A shipper auditing detention claims can only reject an inflated claim if its own events are reliable, so the polygon and hysteresis rules protect both directions. Our guide to truck detention charge evidence covers the documents a claim needs beyond the geofence timestamps.

A container terminal visit that logged ten arrivals

A terminal fence drawn on the property line, with no queue polygon and no exit confirmation, turned one drayage visit into ten arrival events and roughly halved the reported turn time. The trace below shows the visit as the dispatcher's screen saw it and what the redesign changed.

1. 05:42: Dray truck TRK-118, booked to collect import box CNTR-4471, reports a position just inside the terminal polygon at the end of the access road; the board shows "arrived terminal".
2. 05:44 to 07:35: The truck creeps forward in the queue on the public road; its positions leave and re-enter the polygon nine more times, and each exit closes and restarts the turn-time clock.
3. 07:41: The terminal's gate system records gate-in transaction G-0412 for TRK-118, but the dispatch platform does not ingest gate transactions, so the geofence entry at 07:39 stands.
4. 09:58: The truck exits with the box; the platform reports a turn time of 2 h 19 min measured from the last entry, against an actual 4 h 16 min from queue arrival.
5. Next day, 11:00: The drayage firm's waiting-time claim to the importer is rejected because its own log shows ten arrivals for a single visit; the fence is split into queue and terminal polygons and gate transactions become the gate-in source.

Ten arrivals for one visit is the signature of a fence edge running along a queue. The redesign did not need better satellites or a new device, only a second polygon and a rule that a terminal gate transaction outranks a position crossing the property line.

Which geofence decisions a rule settles and where models suggest geometry

Event emission must follow a written state machine that replays identically, while models are useful for proposing polygons from historical stop clusters and for flagging fences whose behaviour has drifted. The person who owns the geometry approves every proposed change before it takes effect.

Gate check-in itself, with plate recognition and a fallback when identity fails, is the subject of our yard check-in pilot guide; the geofence's job ends at telling that process a truck has joined the queue.

Testing a new fence before it drives billing or alerts

Replay at least a month of historical positions through a new fence version and compare its events with gate records before the version goes live. A fence that cannot reproduce known visits from history will not produce trustworthy ones in production.

For related visibility, yard and transport topics, browse the logistics hub. Architects building or replacing a visibility, yard or TMS platform who want fence geometry, versioning and replay in the first release can outline their sites and devices in an RFP submission.