Quick Insight
Placekey is an open, universal identifier for physical places, written as What@Where (for example, 227-222@62k-phc-qs5). The Where part encodes the H3 hexagon, at resolution 10, that contains the place’s centroid. The What part holds an address encoding and an optional point of interest encoding. Unlike a proprietary place ID, it is not tied to one vendor, so any dataset carrying it can be joined on a single column.
How Placekey Works
- Send what you know: an address, a place name plus address, or a latitude and longitude goes to the Placekey API.
- Get the Where: the location is mapped to a hexagon roughly 15,000 square meters in size, and that hexagon is encoded as three groups of three characters.
- Get the What: the first triplet identifies the address inside that hexagon. The second identifies the specific place at that address, such as one shop in a strip mall.
- Join on it: two tables with a Placekey column can be merged with a plain equality join.
Why Placekey Matters
- Address strings do not match: “123 Main St, Ste 4” and “123 Main Street #4” are the same place but fail an exact match.
- One address, many places: a mall has one street address and dozens of tenants. The POI encoding tells them apart.
- Less cleanup work: matching logic is handled once, upstream, instead of being rebuilt by every team.
- Shared language: it launched in October 2020 with SafeGraph as a founding partner alongside Esri and CARTO.
Common Uses
- Enriching internal data: appending category, brand, or hours from SafeGraph Places, which carries a Placekey on every record.
- Deduplication: finding the same store listed twice under different spellings.
- Merging vendor datasets: combining POI, property, and address data without custom matching rules.
- Tracking places over time: following one location across monthly data releases.
- Linking to shapes: attaching a building footprint to the right business record.
Pros and Cons
Pros | Cons |
Open standard: no vendor lock-in. | One direction: you cannot rebuild an address from a Placekey alone. |
Simple joins: an exact match on one column replaces fuzzy matching. | API dependency: the What part comes from Placekey’s service and cannot be computed offline. |
Handles shared addresses: tenants in one building get separate keys. | Input quality: a vague or incomplete address may return only a Where part, or no match. |
Location built in: the Where part carries the place’s position. | Local uniqueness: a What part is unique only within its Where hexagon, so always use the full key. |
How Placekey Compares to Other Identifiers
- Address strings: human readable, but inconsistent across sources.
- Lat/long coordinates: precise, but two sources rarely place the same store at the same decimal, and a point cannot separate two tenants in one building.
- Proprietary place IDs: reliable inside one platform, but they do not travel between providers.
Frequently Asked Questions
1. Can I get a Placekey from coordinates alone?
Yes, but only partly. Coordinates return just the Where part, written as @where, because a point alone cannot say which address or business is meant.
2. What happens to the Placekey when a business closes and a new one opens in the same unit?
The Where and address parts stay the same. The POI part changes, since it identifies the specific business and not the unit.
3. Is Placekey the same as H3?
No. H3 is the hexagon grid that the Where part is built on. Placekey adds the address and place layer on top, plus its own character encoding.
4. Can I measure distance between two Placekeys?
Approximately, yes. Each Where part decodes to a hexagon so that you can compare hexagon centers. Treat the result as an estimate, not a survey-grade distance.
5. Does Placekey work outside the United States?
Yes, for coordinates, which work anywhere. Address and place matching quality varies by country, so check the current Placekey documentation for the markets you need.
