Point-in-Polygon Tester — check if coordinates fall inside a geofence

Why point-in-polygon results surprise people

The maths of “is this coordinate inside that shape?” is settled, yet real-world geofence checks disagree with expectations all the time. Almost always it is the data, not the algorithm. Four causes account for the vast majority of surprises:

• Latitude / longitude swaps. GeoJSON, WKT, and most engines expect longitude, latitude order, but spreadsheets, GPS exports, and “copy coordinates” buttons often produce latitude, longitude. A swapped pair can land your geofence in the wrong hemisphere, so every point tests as outside. When a value looks swapped, the tester flags it.
• Winding order. RFC 7946 GeoJSON asks exterior rings to be counter-clockwise and holes clockwise. Many point-in-polygon implementations do not care about winding, but plenty of downstream systems do — a reversed ring can flip which side is “inside” or silently drop a hole. The tester surfaces winding-order issues on the geofence before you rely on it.
• Holes (interior rings). A geofence with an exclusion zone is one polygon with a hole, not two polygons. A point inside the hole is outside the geofence. If your check treats the outer ring only, points in the exclusion zone will wrongly test as inside.
• Boundary points. A coordinate sitting exactly on an edge or vertex is a genuine edge case: depending on the convention, it can be inside or outside. That is fine until a point that “should” be inside sits a rounding error away from the edge. The tester reports boundary hits explicitly so you can pick a rule and apply it consistently.

A common fifth trap is the antimeridian (the ±180° line). Planar point-in-polygon tests — including this one — treat coordinates as flat degrees, so a geofence whose ring crosses ±180° will not test correctly. Geofences that merely sit near the line without crossing it are fine. If you operate across the Pacific, split such a geofence into two polygons on either side of the line.

Vendor limits worth knowing

Testing containment in a browser is unconstrained, but the platform that ultimately enforces your geofence usually is. Two categories of limit tend to bite teams late in a project. Treat the specifics below as general guidance and confirm the current numbers in each vendor’s own documentation before you design around them.

Circle-only geofencing APIs

Some mobile geofencing APIs — Android’s built-in Geofencing API is the classic example — model a geofence as a circle: a centre point plus a radius, not an arbitrary polygon. That is efficient for battery and background monitoring, but it cannot represent an L-shaped delivery zone, a coastline, or an exclusion hole. Teams typically work around this by approximating a polygon with several overlapping circles, by doing a coarse circular pre-filter on the device and a precise polygon test server-side (or client-side, as here), or by tiling the area with a spatial index. Each approach trades accuracy, battery, and complexity differently, so validate the polygon test itself — this tool — independently of whatever the enforcement layer supports.

Vertex caps on polygon geofences

Platforms that do accept polygons frequently cap the number of vertices per geofence, and some cap the number of geofences per account or per driver. Delivery, ride-hail, and marketing-geofence products commonly sit somewhere in the low hundreds of points per polygon; the exact figure varies by vendor and changes over time. A geofence traced by hand from a detailed boundary can blow past those caps without anyone noticing until upload fails. That is why the tester shows the geofence’s vertex count next to it: if you are near a known cap, simplify the polygon (reduce vertices while preserving shape) before you hand it off.

Turning a circle into a polygon

Because so many systems speak in circles while others speak in polygons, converting between the two is a routine geofence-QA chore. A circular geofence — a centre and a radius in metres — becomes a polygon by sampling points around the circumference at a fixed angular step and closing the ring. More samples mean a smoother circle but more vertices, which runs straight into the vertex caps above, so there is a real trade-off between fidelity and portability. A 64-sided polygon is visually indistinguishable from a circle at city scale while staying well under typical caps.

A dedicated circle-to-polygon converter is on the roadmap for this site. In the meantime, if you already have the polygon approximation, paste it here to confirm your test points land where you expect.