A point-radius geometry is a center coordinate plus a distance: not a polygon at rest, but a rule for constructing a disk on demand. It is the native execution unit of most demand-side platforms and proximity-targeting products precisely because it is cheap to specify and cheap to execute — "3 km around this point" is one comparison per candidate location, not a point-in-polygon test against an arbitrary boundary. That efficiency is also the family's limitation: a circle is rarely the true shape of the catchment it's standing in for, and the radius itself hides two decisions (geodesic vs. planar, and which unit) that change the executed area even when the stated number never changes.
- Cardinality
- One disk per center-plus-radius pair, constructed on demand, not stored
- Governed by
- The platform or caller that defines the radius — no external authority
- Not a geometry
- The radius number alone, before a buffer method (geodesic or planar) is chosen
- Converts via
- Geodesic buffer to a disk polygon, then polyfill
Members
| Member | What it represents | Typical source |
|---|---|---|
| Proximity targeting | "Within N km/mi of this point" ad or promo target | Platform targeting UI |
| Store radius | A simplified stand-in for a store's real trade area | Manually chosen or platform default |
| Device-accuracy disk | A device ping's positional uncertainty, expressed as a radius | GPS/network accuracy metadata |
| Service radius | The area a business claims to serve | Manually declared |
| Platform radius target | A DSP/ad-server's own point+radius execution primitive | Platform API parameter |
Required metadata
| Field | Why it's required |
|---|---|
| Radius units | Meters, feet, and miles are all in circulation; an unconverted unit produces an order-of-magnitude error |
| Geodesic vs. planar | Determines whether the radius is measured as a great-circle distance or in a locally flat projection |
| Center coordinate CRS | Almost always EPSG:4326, but must be confirmed for ingested platform exports |
| Platform-declared minimum radius | Needed to know, before execution, whether the requested radius will be silently clamped up |
Common risks
Geodesic vs. planar divergence: a geodesic buffer measures the radius as a true great-circle distance from the center; a planar buffer applies it in a locally flat projection that is only accurate near that projection's reference latitude. At mid-latitudes and radii under 10 km the gap is usually under 1%, but it grows with both latitude and radius — a planar buffer at high latitude or over several kilometers can misstate coverage area by several percent, and the two methods should never be mixed within one campaign's targets. Platform minimum-radius floors: many platforms refuse radii below a threshold (500 m to 1 km is common) and silently clamp a smaller request up to the floor rather than rejecting it — a 200-meter catchment intended for conservative targeting can execute as a 1 km disk instead, and the requested-vs-executed radius should always be diffed rather than assumed equal. Radius increments: some platforms round the requested radius to a fixed step, changing the executed area in either direction depending on rounding rules. Travel-time confusion: a "10-minute drive" catchment is not a disk, and picking a radius that looks visually similar on a map discards the road-network shape that made the catchment meaningful in the first place — that case belongs to arbitrary polygons, not this family.
Until it is buffered, a point-radius target has no geometry at all — just a number. Two systems agreeing on the same center and the same stated radius can still execute two different disks if one buffers geodesically and the other planar, or if one platform's minimum-radius floor silently overrides the smaller of the two requests.
How it converts to H3
Point-radius targets are buffered into a geodesic (or, when matching
platform behavior, planar) disk and then polyfilled under the same
containment modes used for arbitrary polygons — see
point-radius to H3 for the buffer-then-fill
algorithm in both TypeScript and h3-py. The reverse direction — expressing
an H3 cell back out as a platform-native point-radius target — is covered
on H3 to inscribed circle (the largest
disk guaranteed to stay inside the cell) and
H3 to circumscribed circle (the
smallest disk guaranteed to cover it), which is where platform minimum-radius
floors most often bite.