A point is a single (lat, lng) coordinate that stands in for a place, an
event, or a moment, but never describes an extent of its own. That
distinction matters more than it looks: a point is frequently treated as if
it has no error — as if a store really does sit at exactly
40.7128, -74.0060 — when every member of this family carries some
positional uncertainty that a downstream conversion needs to be told about
explicitly rather than allowed to assume away.
- Cardinality
- One coordinate per observation — no extent
- Governed by
- Whatever produced the coordinate: a GPS chip, a geocoder, a manual placement
- Not a geometry
- An address string, before a geocoder resolves it to a coordinate
- Converts via
- Direct latLngToCell at the chosen resolution
Members
| Member | What the point represents | Typical uncertainty source |
|---|---|---|
| POI / store point | A place's canonical location | Rooftop vs. building-centroid placement |
| Address | A postal address, pre-geocoding | Geocoder match confidence |
| Venue entrance | A single entry point on a larger footprint | Which entrance was digitized, and when |
| Device ping | A device's reported coordinate | GPS/network accuracy radius |
| Impression | An ad-serving bid or render event's location field | Bidstream truncation, IP fallback |
| Conversion | A purchase or app event's location field | Attribution-window location capture method |
| Transaction | A point-of-sale record's location | Store location, not customer location |
| Sensor reading | A fixed or mobile sensor's coordinate | Installation survey accuracy |
| Event | A single logged occurrence | Whatever produced the coordinate upstream |
Required metadata
| Field | Why it's required |
|---|---|
| CRS | Nearly always EPSG:4326, but never assume — verify, especially for ingested vendor feeds |
| Source | Geocoded, device-reported, or manually placed — each carries a different error profile |
| Timestamp | A point is a snapshot; without a timestamp, staleness can't be assessed |
| Accuracy radius (device pings) | Converts a bare coordinate into an honest uncertainty disk instead of a false-precision point |
| Consent state (device pings) | Determines the resolution the point may legally or contractually be used at |
| Geocoder + match confidence (addresses) | A low-confidence geocode should not be treated with the same trust as a rooftop match |
An address is text. It becomes a member of this family only after a geocoder resolves it to a coordinate — and that resolution is itself an approximation, ranging from a precise rooftop match to a ZIP-centroid fallback with no street-level information at all. Carrying the match confidence forward is what keeps a bad geocode from being consumed as if it were as trustworthy as a surveyed POI.
Common risks
Geocoding uncertainty is the largest source of error for addresses and
low-quality POI feeds: a rooftop match and a street-centroid or ZIP-centroid
fallback can differ by tens to thousands of meters, and the geocoder's
confidence score is the only signal that distinguishes them. Axis-order
reversal — a coordinate supplied as [lat, lng] where [lng, lat] is
expected, or vice versa — silently places a point in the wrong hemisphere
when both values happen to fall in valid range; range-checking and
swap-detection should reject ambiguous cases rather than guess. Rounding
and truncation (bidstream coordinates rounded to 2–3 decimal places) snap
points to a coarse grid that biases which cell they land in, especially at
high H3 resolutions where the rounding grid is coarser than the cell
itself. IP-derived location is coarse and centroid-biased by
construction — it is not physical presence and must be labeled with the
correct matching semantic, not treated as a device fix (see
advertising-geographic matching semantics).
Staleness affects POIs specifically: a store point surveyed years ago
may no longer reflect a relocated or closed location. Duplicates — the
same event logged more than once — inflate counts once points are
aggregated; see multipoints for the aggregate case.
How it converts to H3
A single point converts to H3 with latLngToCell at the chosen resolution
— conceptually the simplest conversion in this knowledge base, and for that
reason the one where skipped metadata (accuracy, consent, geocoder
confidence) does the most silent damage. See
point to H3 for the full treatment, including how
accuracy radius should be handled when a point is really a device fix
rather than a surveyed location, and
point-radius geometries for when a point
is deliberately expanded into a disk before conversion.