What Is POI Data, and What Makes a POI Dataset Usable?
A POI record is a name, a category and a coordinate. Everything that makes POI data hard lives in those three fields.
- Author
- HuiTu Technology
- Published
- Updated
POI stands for point of interest. A POI is a specific place recorded as a coordinate with attributes attached: a restaurant, a pharmacy, a school, an ATM, a bus stop, an EV charger. A POI dataset is a table of those places, and at first glance it is the simplest kind of geospatial data there is.
In practice POI data causes more analytical damage than almost any other dataset, because the errors it contains are invisible on a map. A duplicated venue looks like a venue. A miscategorised cafe looks like a restaurant. A closed business looks open. You only discover the problem when two analyses of the same market disagree and nobody can say which one is right.
What a POI record actually contains
A minimal record needs three things: an identifier, a location and a category. Everything else is enrichment, though some of that enrichment is what makes the data commercially useful.
| Field | Type | Why it matters |
|---|---|---|
| poi_id | string | A stable key. Without one you cannot track a place across refreshes. |
| name | string | Human label, and half of most deduplication keys. |
| category | string | Determines every count you will ever produce from this dataset. |
| source_category | string | The original label, kept so category decisions stay auditable. |
| latitude / longitude | float | WGS 84 decimal degrees. Precision beyond six decimals is noise. |
| address components | string | Parsed, not concatenated, so joins and validation are possible. |
| status | enum | Open, temporarily closed, permanently closed. Counts are wrong without it. |
| collected_at | date | Freshness. A POI dataset without a date is an undated claim. |
The category problem
Ask three sources for coffee shops in a city and you will get three different counts, sometimes differing by more than a third. Not because coverage differs, but because one source calls a place a cafe, another a coffee shop, and a third files it under restaurant with a coffee tag.
This matters enormously for anything involving counts: market sizing, competitive density, penetration per capita. The fix is not to pick the source with the most flattering number. It is to define your own category scheme, map every source label onto it explicitly, and publish the mapping alongside the data.
- Define categories by the decision you are making, not by what sources happen to publish.
- Keep the original source label in its own column, always.
- Deliver the mapping table with the dataset so any decision can be audited or reversed.
- Resolve genuinely ambiguous labels by inspecting a sample by hand, not by rule.
Duplicates, and why they are not obvious
Combine two POI sources and you will duplicate somewhere between 15 and 30 percent of records. The duplicates are rarely exact: the same venue appears as "Joe's Coffee", "Joes Coffee Co" and "Joe's Coffee - Main St", with coordinates 20 metres apart because one source geocoded the entrance and another the building centroid.
A workable deduplication rule combines normalised text matching with a spatial threshold. Normalise the name by lowercasing, stripping punctuation and removing common suffixes, then treat records as candidates for merging only if they fall within a distance threshold appropriate to the density of the area.
-- Candidate duplicate pairs: similar names within 50 m
SELECT a.poi_id, b.poi_id,
similarity(a.name_normalised, b.name_normalised) AS name_score,
ST_Distance(a.geom::geography, b.geom::geography) AS metres
FROM poi a
JOIN poi b
ON a.poi_id < b.poi_id
AND ST_DWithin(a.geom::geography, b.geom::geography, 50)
WHERE similarity(a.name_normalised, b.name_normalised) > 0.6
ORDER BY name_score DESC;Fifty metres is a reasonable default for a dense city centre and far too tight for a retail park, where the same store might be recorded at either end of a building. The threshold is a decision, and like every decision in this work it belongs in the documentation.
Five checks before you trust a POI dataset
- Coordinate sanity: no zeros, no swapped latitude and longitude, nothing outside the study area's bounding box.
- Centroid clustering: count records sharing an identical coordinate. Large clusters mean geocoding fell back to a postcode or district centre.
- Category distribution: compare against a known baseline. If one category holds 60 percent of records, the mapping is probably wrong.
- Duplicate rate: measure it, report it. An unreported deduplication rate makes cross-market comparison meaningless.
- Status coverage: how many records carry a closure status? Counting permanently closed venues as operating inflates every metric downstream.
- Restaurants · 34
- Cafés · 22
- Retail · 26
What POI data is genuinely good for
Once it is clean, POI data answers questions that are difficult to answer any other way: how many operators exist in a category and where, how densely a market is served relative to its population, which neighbourhoods have demand without supply, and how any of that changes over time when you re-collect on a schedule.
It is less good at telling you how well those businesses are doing. Ratings and review counts are useful proxies for popularity, but they are proxies, and they are biased towards venues whose customers happen to leave reviews. Treat them as a signal, not as revenue.