Geofencing: where "Control" becomes a shape on a map

A closed area is a legal fact before it's ever a polygon. The pipeline that turns one into the other is where most of e-Boat's real complexity lives.

A closed area — a spawning ground, a marine protected zone, a stretch of contested or restricted water — starts life as a legal instrument: a regulation naming coordinates and an effective date range. A geofence is that same area represented as geometry a system can test a point against. The gap between the two is where a lot can go wrong: a legal description in degrees-minutes-seconds has to become an exact polygon, effective dates have to be enforced, and "inside" has to be computed correctly at the boundary, not approximately.

The evaluation pipeline, not a single check

It's tempting to picture geofencing as "check if point is inside polygon" and stop there. e-Boat's own architecture makes the real shape visible — geofence evaluation is one branch of a fan-out, not a gate telemetry has to pass through:

Gateway (ingest)
   │
   ├──▶ Writer ─────────▶ TimescaleDB (position history)
   │
   ├──▶ GeofenceEvaluator ──▶ domain events ──▶ RuleEngine ──▶ Notifications
   │
   └──▶ SignalR push ──▶ live map

Three consumers read the same position stream independently. Writing the position to the database, evaluating it against geofences, and pushing it to the live map all happen without blocking each other — a slow geofence check does not delay the map, and a database write failure does not silence a violation. That decoupling is itself a domain-informed design choice: in most closed-area regimes, "the map showed the vessel late" and "the violation wasn't logged" are two entirely different severities of failure, and coupling their failure modes together would be a mistake.

The actual geometry work — testing whether a vessel's position intersects a geofence polygon — runs on PostGIS, the geospatial extension to PostgreSQL. This is standard practice, not an e-Boat-specific choice: PostGIS's spatial indexing is what makes "check this point against thousands of polygons in real time" tractable at all rather than a linear scan.

What a real geofence system has to get right

Boundary precision — is a vessel exactly on the line inside or outside? (Most regimes define this explicitly; don't assume.)
Effective dates — a seasonal spawning closure is only a violation zone during its season, not year-round
Offline/degraded operation — some geofencing systems cache boundaries on-device so a breach is still flagged without a live server connection, since marine connectivity is unreliable
Distinguishing "crossed the line" from "GPS jitter near the line" — a stationary vessel right at a boundary can appear to cross it repeatedly from position noise alone

Source: general geofencing-system practice, e.g. Biggworks — geofence alert system for fisheries/marine, which documents the dual-layer (on-device + server-side) pattern used specifically because marine environments can't assume connectivity.

Where this lands in the ToR

C-009..C-039 ("Monitoring objects, map, tracks, geofences") is the largest single requirement group in the ToR — 31 requirements. That size is a signal: geofencing isn't one feature, it's the load-bearing capability the rest of Surveillance depends on. Worth reading that requirement block in full before assuming "geofence" means only "draw a polygon."

Check your recall

Something unclear, or want to go deeper on any term here? Ask the agent that built this lesson — it's your teacher for this workspace, not just a lesson generator.