Geofence-Based Road Closure Detection for Pre-Departure Route Adjustment

A driver leaves the depot at 6:14 AM with 34 stops. Somewhere around stop 8, they hit a road closure that was not there yesterday. No alternate was pre-computed. The detour costs 22 minutes. Two time-window stops fail. The dispatcher finds out at 9 AM when the customer calls. By then, recovery is not an option. We have seen this exact sequence play out across regional carriers, and almost every instance was preventable with information that was already available before departure.

Why Closures Discovered After Departure Are Expensive

The math is straightforward but brutal. A detour does not just cost the time it adds to one segment. It compresses all downstream stops against their time windows, forces a driver to make on-the-fly sequencing decisions at the wheel, and eliminates the dispatcher's ability to do anything useful. Rerouting options are constrained by where the truck physically is. You cannot re-sequence from the office when the driver is already four stops in.

Post-departure closure impact is not random, either. It concentrates in dense urban corridors where construction and utility work are common, and it hits hardest on routes already running close to time-window boundaries. In our tracking of route failure modes across last-mile parcel networks, undetected road closures account for roughly 18% of time-window misses on next-day runs in metropolitan service areas.

The core problem: most routing systems treat the road network as static at solve time. They compute the optimal sequence given current constraints, then hand it to the driver. What happens between solve time and departure is a visibility gap. Geofence-based closure monitoring is how you close it.

How Pre-Departure Geofence Monitoring Works

The architecture is simpler than it sounds. You are doing three things: representing planned route corridors as geofenced polygons, continuously checking those polygons against incoming closure data, and triggering a targeted re-solve if any closure intersects a corridor before the vehicle departs.

Corridor polygons do not need to be precise. A 150-meter buffer around each planned road segment captures the relevant area without generating excessive false positives. You are not modeling every possible detour; you are flagging corridors where the planned path is blocked. Coverage matters more than precision here.

The monitoring loop runs on a schedule. Fifteen minutes before depot cutoff is a natural trigger point. Carriers running continuous dispatch cycles often run it every 30 minutes from 8 PM onward, catching closures that go into effect overnight. The computational cost is low: polygon intersection checks against a list of closure geometries, not a full re-solve of the route graph.

Fact: the goal of geofence monitoring is not to catch every possible road event. It is to catch planned, announced closures that appear in municipal feeds before they affect a truck already in motion. That constraint is what makes the problem tractable.

Integrating Municipal Feeds and Geotab Traffic Data

Two data sources do most of the work: municipal road closure feeds and fleet telematics.

Most metro areas publish closure data through 511 portals, city open-data APIs, or state DOT feeds. Formats vary considerably. Some publish GeoJSON with structured event types; others push plain-text NTCIP messages that require parsing. The schema inconsistency is real, and it demands a normalization layer before you can do reliable polygon intersection. In our experience, standardizing around a simple closure struct with four fields (geometry, effective_start, expected_duration, closure_type) handles 90% of municipal feed variants without needing custom per-feed parsers.

Data Source	Coverage	Update Frequency	Primary Use
Municipal 511 / DOT feeds	Planned construction, utility work, permitted events	15 min to 1 hour	Corridor intersection checks
Geotab HD Map traffic layer	Real-time incident detection, speed anomalies	Near real-time (<5 min)	Unplanned closure detection, travel time adjustment
Driver-reported closures (mobile)	Hyper-local, on-route observations	Immediate	Feed enrichment, feedback loop to dispatch

Geotab's traffic data layer complements municipal feeds in a specific way: it catches unplanned closures. A water main break at 4 AM will not appear in a construction permit database. But Geotab's speed anomaly detection will flag a segment where traffic has dropped to near zero. That is a usable proxy for blockage. Neither source alone is sufficient. Together they give you planned closure coverage plus an incident detection signal.

One integration detail worth being precise about: municipal feeds often report closures in local coordinate systems or with road name references that do not match your routing graph's segment IDs. Map-matching against your graph is a pre-processing step you cannot skip. Get this wrong and your intersection logic will miss closures or fire false positives on unrelated segments. Both outcomes erode dispatcher trust in the system faster than almost anything else.

Triggering Targeted Re-Solves for Affected Corridors

When a closure intersects a corridor, you do not re-solve the entire route. Full re-solves are expensive, and most of a route is unaffected by any given closure. You isolate the affected corridor. Typically 3 to 7 stops adjacent to the blocked segment. Re-solve just that sub-sequence with the closure marked as a hard constraint in the road network, then splice the revised sub-sequence back into the original route order.

This targeted approach keeps solve times under 4 seconds for most corridor re-computes. Fast enough to run at scale across 80 or more routes during the pre-departure window without introducing queueing delays that would eat into the dispatch timeline.

The re-solve output needs to be immediately actionable. That means updated turn-by-turn for the affected segment, revised ETAs for all downstream stops, and a time-window impact summary. Not just "route updated." Dispatchers need to see which stops are now at risk before they decide whether to accept the revised route or pick up the phone.

Dispatcher Notification and Time-Window Impact Reporting

Here is the thing about closure alerts: volume kills them. If dispatchers receive 40 notifications per morning and 35 are low-severity, they stop reading them. Alert design matters as much as detection accuracy.

We structure closure notifications around three tiers:

1. Critical: Closure intersects corridor and re-solve found no feasible path within current time windows for one or more stops. Requires dispatcher decision before vehicle departs.
2. Warning: Closure intersects corridor and re-solve found a viable path, but it adds 8 or more minutes to the affected sub-sequence. One or more stops are now at risk.
3. Info: Closure detected near corridor but does not intersect the planned path. No action needed, logged for visibility.

Critical and Warning tiers surface in the dispatch dashboard with stop-level detail: which stops are affected, what the revised ETAs are, and how much time-window buffer remains. Dispatchers can accept the re-solve with a single click, or flag it for manual handling.

Info-tier events do not generate push notifications. They appear in the route audit log if a driver later reports an issue in that area. Silence on the alert side is not silence on the logging side. That distinction matters when you are trying to understand why a particular corridor keeps generating noise.

What This Changes Operationally

Dispatchers stop learning about road closures from drivers mid-route. That is the first and most immediate change. The second is that exception handling shifts from reactive to pre-departure, where options actually exist.

In our experience with pre-departure geofence checks across regional parcel carriers, 3 to 7% of routes per day flag at least one corridor closure that requires a re-solve. Most of those re-solves are transparent to dispatchers: the system handles them automatically and posts to the audit log. The fraction requiring active dispatcher attention is typically 0.5 to 1.5% of routes per day. Small number. But those are the exact routes that, without pre-departure detection, would have generated time-window failures and customer complaints.

The data also accumulates in useful ways. Every confirmed closure, every missed geofence hit, every driver-reported correction feeds back into feed quality scoring. Over time, you know which municipal feeds are reliable at a 2-hour lead time and which ones need 6 hours before their geometry can be trusted. That calibration makes the monitoring progressively sharper. Not in dramatic steps. Just steadily more accurate each week.

Honestly, the hardest part of building this is not the polygon math or the feed parsing. It is getting dispatcher buy-in during the first two weeks, before the system has proven itself. The first time it catches a closure that would have cost a time-window failure, that conversation changes. Every time after that, dispatchers check the alert queue before they look at anything else.