What is Point-in-polygon?

Every geofence check comes down to one question: is this coordinate inside this shape? The point-in-polygon test answers it, and it runs on every position report from every device, forever.

How ray casting works

The standard algorithm is beautifully simple. Draw an imaginary ray from the point out to infinity in any direction, and count how many times it crosses the polygon’s edges.

• Odd number of crossings → the point is inside
• Even number (including zero) → outside

The intuition: every time you cross an edge you move from outside to inside or back again. Starting from infinity, which is definitely outside, an odd number of transitions leaves you inside.

It works for any simple polygon — convex, concave, or awkwardly shaped — and handles holes naturally, because a hole’s ring contributes its own crossings. The cost is proportional to the number of edges.

Circles are much cheaper

For a circular zone there is no polygon to walk. The test is one distance calculation:

inside = distance(point, centre) <= radius

That is why circular geofences are the cheapest kind to evaluate, and why almost every tracking platform supports them even when it supports nothing else. If your zone is genuinely “within X metres of this address”, use a circle — see GeoJSON polygon for when a polygon earns its cost.

Vertex count matters at scale

The per-check cost is small. Multiply it by every position report from every device and it stops being negligible.

A 500-vertex shape costs roughly twenty-five times more to test than a 20-vertex one. With a device reporting every five minutes, that difference is invisible. With thousands of devices reporting continuously across many zones, it is the difference between comfortable and struggling.

The practical guidance: trace the shape you need and stop. Extra vertices add no accuracy that GPS drift has not already erased. Once your vertex spacing drops below the position error of the devices being tested, you are encoding measurement noise into the boundary and paying for it on every check. Twelve well-placed points beat two hundred.

Edge cases

Real implementations have to decide some genuinely ambiguous situations:

• The point sits exactly on an edge. Mathematically it is neither in nor out. Implementations pick a convention and stick to it — inconsistency here causes shapes that share a border to both claim a point, or neither.
• The ray passes exactly through a vertex. Naively this counts as two crossings when it should count as one, flipping the answer. Standard implementations handle it by treating vertex endpoints asymmetrically.
• The polygon crosses the antimeridian. Longitudes wrapping from 180 to -180 break code that compares them directly. Rare, but it breaks badly when it happens.

In practice these matter far less than they sound, because a coordinate landing exactly on an edge is vanishingly unlikely with real GPS data — the position error is many orders of magnitude larger than the floating-point ambiguity.

What Geoblip does

Geoblip evaluates every incoming coordinate against each zone assigned to that device, supporting both circular zones — a centre and a radius — and arbitrary polygons including holes.

The important design point is what happens after the test. A raw inside/outside answer is not enough to alert on, because GPS drift makes that answer flip for a stationary device near a boundary. The geometric result updates the device’s physical position, but notifications are driven by a separate state machine described under alert debouncing.

Getting the geometry right is the easy half. Deciding what to do with the answer is the half that determines whether anyone trusts the alerts.

Last reviewed 7 August 2026.