Skip to content
DataForge

POI Database Download: Points of Interest Data Without the License Headaches

Published 2026-08-04 · DataForge team

Every store locator, delivery zone, site-selection model and geomarketing analysis starts with the same ingredient: a database of business locations — points of interest (POI). The search for “poi database download” leads to a maze of options that differ less in coverage than in something teams discover too late: licensing. Getting POI data is easy. Getting POI data you can legally blend into a commercial product is the actual problem. This guide maps the options honestly.

The main sources

OpenStreetMap. The biggest free POI corpus on earth. Extraction is straightforward:

import requests

# All cafés in Manchester via the Overpass API
query = """
[out:json][timeout:60];
area["name"="Manchester"]["boundary"="administrative"]->.a;
node["amenity"="cafe"](area.a);
out body;
"""
r = requests.post("https://overpass-api.de/api/interpreter", data={"data": query})
for el in r.json()["elements"][:10]:
    t = el.get("tags", {})
    print(t.get("name", "?"), "|", el["lat"], el["lon"])

The catch is the ODbL license: it’s share-alike. If you mix OSM data into your database and your product exposes that database, you can be obliged to publish your entire derived database under ODbL. For internal analysis this rarely bites; for data products, SaaS features and resale, ODbL contamination is a genuine legal risk that commercial legal teams increasingly screen for.

Overture Maps. The Meta/Microsoft/Amazon/TomTom foundation publishes a global places layer (~50M+ POIs) under more permissive terms (CDLA-Permissive for the places theme) as Parquet on S3/Azure — a serious modern option, though place categories are coarse and small-business coverage varies by region.

Government open registries. The under-used gem. Governments license businesses, and many publish those registries as open data with permissive terms: NYC/Chicago/SF business licenses, and the UK’s Food Hygiene Rating Scheme (FHRS) — every food business in the UK with address, coordinates and inspection rating. These are authoritative (a license/inspection means the business really exists — no scraped-ghost problem) and license-clean.

Commercial vendors. Foursquare, SafeGraph/Placekey, Google Places API. High quality, real budgets, and per-seat/usage restrictions that often prohibit warehousing or redistribution (Google Places notably cannot be stored long-term).

Why we built on government registries

Our POI dataset takes the registry route deliberately: 808,397 business locations from US city license registries (NYC, Chicago, SF — 361,421 locations) and the UK FHRS (446,976 food establishments), normalized into one schema with addresses, geocodes and category labels. No ODbL anywhere in the chain — the datasheet documents each registry’s open terms — so blending into commercial products is clean.

What registry data gives you that scraped data can’t: existence verified by a government process, license/inspection dates as freshness signals, and (FHRS) hygiene ratings as a unique feature. What it doesn’t give you: global uniform coverage — it covers what the registries cover.

-- Category mix of licensed businesses within ~1km of a point (NYC)
SELECT category_norm,
       COUNT(*) AS locations
FROM poi
WHERE source = 'nyc_licenses'
  AND ST_DWithin(geom::geography,
                 ST_MakePoint(-73.9857, 40.7484)::geography,
                 1000)
GROUP BY category_norm
ORDER BY locations DESC
LIMIT 15;

POI quality: how to evaluate any source in an afternoon

Whatever source you choose, run the same four checks before committing — they expose the real differences faster than any vendor comparison sheet. Existence check: sample 50 POIs in a neighborhood you know and verify them on the ground (or via Street View). Scraped corpora typically carry 5–15% dead locations (closed businesses linger); registry data carries near-zero, because a license lapse removes the record. Freshness check: what fraction of records have a source date within 12 months? An unmaintained corpus decays at roughly the small-business closure rate — around 10% a year — so a three-year-old snapshot has silently lost a quarter of its truth. Category sanity: pick a category you understand (say, pharmacies) and compare the count against a known ground truth (state pharmacy-board licenses). Category taxonomies are where free sources diverge the most — OSM’s crowd-tagged amenity=* values are wonderfully inconsistent, while a licensing registry’s category is whatever the license class says, which is precise but coarse. Geocode precision: plot 100 random points; rooftop-level geocodes cluster on buildings, ZIP-centroid fallbacks form suspicious grids. Our datasheet reports geocode precision per source so you don’t have to discover the grids yourself.

The meta-lesson: “coverage” numbers in POI marketing (50M! 100M! 200M places!) are nearly meaningless without a decay and verification story. A smaller corpus that a government process keeps honest routinely outperforms a bigger one that nobody prunes.

What people build with POI data

  • Site selection. Retail and QSR chains model trade areas from competitor and complement density.
  • Delivery and logistics. Serviceable-address universes, zone design, demand estimation.
  • Geomarketing. Enriching customer addresses with nearby-business context.
  • Risk and underwriting. Insurers validate business existence and class from registry-backed data.
  • Urban analytics. Food-desert studies, retail-vacancy tracking, hygiene-rating research (FHRS is beloved by UK researchers).

A note on the FHRS data specifically, because it’s the corpus people underestimate: every one of the ~450k UK food businesses — every restaurant, café, pub kitchen, school canteen, supermarket and takeaway — with address, local authority, business type, inspection date and the 0–5 hygiene rating. For anyone modeling UK food retail, delivery catchments, or hospitality market structure, it is simply the best single free-to-inspect source in existence, and its inspection-driven maintenance means the decay problem barely applies. Our packaged version adds geocoding normalization and a cleaned category layer on top, but we’d rather you know the source exists than pretend we invented it.

Options compared

OSM Overture Gov registries (ours) Commercial vendors
Cost Free Free From $299 $$$–$$$$$
License ODbL (share-alike!) Permissive (places) Open government terms Restrictive contracts
Verification Crowdsourced Mixed Government license/inspection Vendor QA
Coverage Global, uneven Global, coarse categories Covered jurisdictions, deep Global, deep
Freshness signal Edit history Release cadence License/inspection dates Vendor SLA

Honest guidance: internal one-off analysis? OSM or Overture, free, today. Global product feature with budget? Talk to Foursquare/Overture. Need license-clean, authoritative locations for the US cities and UK — especially anything food-related — that’s exactly what our registry-based corpus is for. Check the free 500-row sample.

FAQ

What does “license-isolated” mean in your tiers? Each package contains only sources whose terms are compatible with commercial reuse, kept separate so your legal review is per-source, not per-row. No ODbL data enters the corpus.

How fresh is registry data? Registries update on license/inspection cycles (FHRS continuously, city registries typically monthly). Editions are dated snapshots; each row carries its source record date.

Do you dedupe across sources? US and UK sources don’t overlap geographically. Within a registry, locations are keyed on the registry’s own identifiers plus normalized address.

What exactly does ODbL share-alike require — is it really that scary? The obligation triggers when you publicly use a database derived from OSM: you must offer the derived database under ODbL too. The nuances live in “derived database” vs “produced work” (a rendered map image is a produced work needing only attribution; the enriched POI table behind your API is likely a derived database) and in “collective” vs “derivative” databases (keeping OSM data in a cleanly separated column-set may keep your proprietary data out of scope — the OSMF publishes community guidelines on exactly these lines). Plenty of sophisticated companies use OSM happily within these rules. The problem is that “likely” and “may” in the previous sentences are doing legal work, and data-product buyers increasingly refuse to carry that ambiguity — which is why “no ODbL in the chain” has become a procurement checkbox, and why we build from government registries instead.

How do I match POIs across two sources? The same entity-resolution discipline as company data, with geography as your ally: block candidate pairs by distance (say, 150m), score on name similarity plus category compatibility plus address-token overlap, and validate thresholds on a labeled sample. Beware chains (fifty “Starbucks” within blocking distance downtown — address tokens are what separates them) and shopping malls (hundreds of businesses at one geocode). If you need a persistent cross-source key at scale, that’s the problem Placekey-style services sell answers to; for one-off joins the recipe above gets you 90% of the way in a day.

What format does the data ship in? CSV and Parquet, with WGS84 latitude/longitude columns that load directly into PostGIS, DuckDB spatial, GeoPandas or Kepler.gl. Each package includes the data dictionary, per-source datasheet (terms, collection dates, known limitations) and QA report, so your legal and data teams review the same documents.

Can I get chains’ store lists specifically? Yes — registry data includes chain locations (filter by normalized name), verified by licensing rather than website scraping.