Geofence Radius Calculator

Because degrees of longitude shrink with latitude: one degree spans 111.32 km at the equator but only 111.32 × cos(φ) at latitude φ — 78.8 km at 45°, 55.7 km at 60°. A 5-km fence at San Francisco (37.77°) needs ±0.0568° of longitude but only ±0.0449° of latitude. Skip the cosine and your 'circle' becomes an ellipse squashed east-west — queries miss points near the east and west edges, a bug that hides until a user near the fence boundary complains.

Box first, circle second: filter WHERE lat BETWEEN φ−Δlat AND φ+Δlat AND lon BETWEEN λ−Δlon AND λ+Δlon — which a B-tree index executes instantly — then compute exact haversine distance on the few survivors and discard the box's corners (the box is 4r² to the circle's πr², so ~21% of candidates are corner waste). Real spatial engines (PostGIS, geohash/S2/H3 systems) industrialize the same two-phase idea: coarse cells, then exact math.

Match the radius to both the use case AND the positioning noise: under ~100 m, phone geofencing gets unreliable (GPS drifts 5–30 m urban, and OS-level fencing uses cell/Wi-Fi positioning that's coarser); 100–300 m suits 'arrived at the store' triggers; 1–5 km suits delivery zones and alerts; above that you're doing coverage areas, not fences. Add hysteresis — trigger entry at r but exit at 1.2r — or boundary jitter will fire your fence repeatedly as a stationary phone's fix wanders.

Two famous places: near the poles the cosine blows up (at 89° latitude a 5-km fence spans ±2.6° of longitude; past the pole itself the box concept collapses — use polar-cap logic), and at the antimeridian (±180°) a box can wrap so its 'min' exceeds its 'max' longitude, silently returning nothing — split the query into two boxes there. For the 99.9% of fences between Alaska and Fiji at sane latitudes, this page's deltas are exactly what production systems run.