Blog
What is a POI database?
rebecca payton
Contents
A POI database is a structured collection of places — their names, coordinates, categories, addresses and attributes — that applications query to answer, "what is here?".
Modern POI databases are built by matching several independent sources against each other and are queried either by coordinates or by spatial index cell.
Points of interest are the difference between a map that shows streets and a product that can tell a user there are pharmacies, schools and station within a 15-minute walk.
This piece covers what sits inside the TravelTime POI database, where the records come from, how to judge quality, and how teams query one in production.
POIs, demographic and environmental data, green space data, and more are all available via the TravelTime Data API.
What is a POI database?
A POI database stores one row per place, with a stable identifier, a location, a category and a set of attributes. It is the reference layer underneath location search, catchment and spatial analysis, store locators, site selection models and anything that needs to describe the surroundings of a point rather than just plot it.
Three things distinguish a POI database from a list of addresses:
- Entity resolution: One real-world place is one record, even when three source datasets describe it slightly differently.
- Categorisation: Places are classified consistently, so "pharmacy" means the same thing in Manchester and Madrid.
- Spatial addressability: Records can be retrieved by proximity, by bounding box, by polygon or by index cell.
What is POI data?
POI data is the attribute set attached to each place. Taking the TravelTime Data API's POI layer as a worked example, each record carries:
| Field | What it holds | Why it matters |
|---|---|---|
| id | Identifier within a country's dataset | Join, cache and track a place over time |
| name | Consolidated best-available name | Matching, search and display |
| brand | Canonical chain name, or null | Filter to one operator: competitor analysis, own-estate audits |
| category | Primary category | Filtering and aggregation |
| categories, categories_detail, category_groups | Every category, its detail types, and its coarse group | Query at whatever level of granularity you need |
| source_count, independent_source_count | How many of the three datasets contributed and the same count, with echoes discounted | The raw corroboration count and confidence signal |
| confidence_label | register_verified, cross_validated or unverified | One field to read if you only read one |
| sources | Which providers contributed | Provenance and auditability |
| date_refreshed | When a contributing source last touched the row | Your own staleness rules |
| point geometry | A single lat/lng centroid | Positioning and proximity queries |
Contact details, opening hours, reviews and photos also appear in some datasets. These are the fields that go stale fastest and are often excluded in location search and scoring. These fields are not included in the TravelTime Data API and are most often restricted by licence from other vendors.
What is an example of POI data?
A single POI record for a café is a name, a coordinate pair, a category, an address and an ID — plus, in a cross-validated dataset, how many of our independent sources agree the café exists. That last field is an indication of quality and accuracy of the POI, and it’s what lets you decide whether to show it to a user or exclude it from a model.
In practice you rarely fetch one record. You fetch everything within a radius, a polygon or a travel time catchment, and then count or filter it.
What types of POI are there?
A POI database is only as useful as its taxonomy, because the category is what you filter and aggregate on. The TravelTime Data API uses a three-level tree — group → category → detail type — with 16 groups:
- Food and drink
- Shopping
- Health and wellness
- Finance
- Business and services
- Lodging
- Automotive
- Government
- Culture
- Education
- Places of worship
- Entertainment and recreation
- Sports
- Transportation
- Geographical areas
- Uncategorised
Beneath each group is a category and a detail type, so you can query at whatever level suits the job. One specific type of cuisine, every bakery, or all food and drink at once. Places are also tagged with a brand where they belong to a chain, which is what turns a POI layer into competitor-density analysis.
The full tree, with live counts per country, is in the documentation.
Where does POI data come from?
The TravelTime Data API has three independent data sources, collected on a country-by-country basis, combined with authority overlays where available, and supported by our proprietary public transit models.
Place Data
- Foursquare Open Places: a freely redistributable dataset built from Foursquare's global places graph. Strong on commercial venues (restaurants, retail, services).
- OpenStreetMap: the volunteer-edited geographic database. Strong on community-knowledge categories (schools, parks, places of worship, transit) and on countries with active mapping communities. Coverage varies by region.
- Overture Maps: the Linux Foundation's federated map data project. Currently a blend that includes Foursquare and OSM upstream, with additional cleanup.
Authority Data
Where available, the TravelTime API uses data from trusted official registers. This then becomes the primary source for that category — for example, the Care Quality Commission for UK regulated healthcare and comparable registers in other countries.
A place carried by an authoritative register is included even when it appears in only one source and the open feeds disagree and competing low-confidence rows are suppressed. This avoids over-tagging in categories where the open data is noisy.
Public Transit
Public transport is not merged from POI sources at all — stations come from TravelTime's routing-grade transport graph, and transport places report a source_count of 0 to say so explicitly. The network is the authority rather than one counted dataset among three.
How accurate is POI data?
Accuracy is how ‘real’ or ‘true’ a point of interest is — is the name correct, is it categorised correctly, is it listed in the right location, when two datasets both see a place, do they agree it is the same entity, and what share of the places one dataset holds does the other also hold?
It comes down broadly to two things: agreement and coverage.
A dataset can have high agreement and thin coverage, or the reverse. Both need publishing per country and per category, because a averages can hide the categories you actually care about.
In the Data API you can see confidence_label to helps you understand the accuracy of POIs and set a min_source filter.
Confidence labels:
| Label | Meaning |
|---|---|
| register_verified | Backed by an authoritative source — a government register, or TravelTime's transport network |
| cross_validated | At least two genuinely independent datasets agree the place exists |
| unverified | A single dataset, or corroborated only by echoes |
What isn't in a POI database?
In the TravelTime Data API, there are some explicit exclusions:
- No business information: No phone numbers, opening hours or reviews. It is a places layer, not a business-information service. If you need rich venue attributes, pair it with a commercial places API rather than asking one dataset to do both.
- No real-time signals.: A place is either there or it isn't. Nothing models "open now" or "busy right now", so a search at different times of day delivers consistent, reliable results.
- No private or paywalled listings: No licence-only feeds and no private submissions; everything traces to our core sources.
- No drift detection: If a coffee shop closes and a barber opens at the same address, the dataset sees what its sources say. A place marked closed in OpenStreetMap but still live in Foursquare will have a two-source signal until both agree.
How do you query a POI database?
Two access patterns cover almost everything:
- By coordinates: when you have a place and want what is near it. A point and a radius, a bounding box, or free text search, returning GeoJSON ordered by distance or relevance. This powers store locators, "near me" search and address enrichment.
- By index cell: when you have an area and want one row per unit of it. Pass H3 cells or geohashes and get counts and aggregates back. This is the pattern for catchment analysis, heat maps, coverage scoring and feature generation for models, because it makes POI counts joinable to population, land cover and travel time in the same grid.
The second pattern is the one that pairs with TravelTime’s core functionality of calculating multi-modal routes and time-based-catchments. Generate a travel time catchment, take its cells, and ask each layer what it contains — the amenities inside a 30-minute drive, the share of that area that is green space, the population it covers.
What do teams build with a POI database?
Location search
Improve the end-user search experience by contextualising locations with real-world points of interest and location-feature data.
Support the search for POIs around a specific location or listing, such as the local amenities and neighbourhood around a property listing. Filter listings by what is nearby, for example only show hotels that are within a 15-minute walk of a beach. Show what is reachable from a starting location, for example, all of the sushi restaurants near a city centre theatre.
Site selection and expansion
Score candidate sites on the things that make a location work.
Count competitors within a walkable radius, for example how many rival coffee shops sit within 10 minutes on foot of a proposed unit. Measure the footfall drivers around it — stations, supermarkets, schools, gyms — and compare shortlisted sites on the same basis. Ask the question of how many people can get there, for example the population within a 20-minute drive at 8am on a weekday. Filtering by brand turns the same query inwards: check whether a new site would cannibalise one of your own.
Network adequacy and service coverage
Measure how much of a population can reach a provider within a time standard — and prove it.
For a health plan, that could mean testing whether members can reach an in-network pharmacy or specialist inside the drive time a regulator specifies and report the share who can't. As well as the pass rate, you can see which areas fail, how many people that affects, and whether a new provider would close the most of it.
The same pattern applies to any obligation to be reachable — bank branches, EV chargers, locker networks and public services.
Logistics and field operations
Enrich stops with what surrounds them, for example flagging deliveries that sit within a minute's walk of a parcel locker or a fuel station. Cluster territories so each engineer or driver gets a workload defined by travel time rather than by a line on a map. And sanity-check addresses before they reach a driver: if a delivery is booked to a named pharmacy that no dataset places within 200 metres of the given coordinates, that is worth catching in the warehouse rather than on the road.
AI and analytics features
Give a model the actual data instead of letting it guess.
Asked what is near a postcode, a language model will produce a plausible list of places, however it can return results that do not exist or do not match your requirements. Handed real counts by category, accessible via an API, and it describes a location it can be held to.
The same applies to statistical models, where POI counts per cell become features alongside population, land cover and travel time — retail demand, insurance risk, property valuation and demographic scoring all improve when "what is here" is a measured input rather than a proxy.
How is a POI database different from a places API or scoring tool?
Three different kinds of product answer questions about location, and they are built for different jobs.
A places API is generally built for interactive lookup: a user types, you display. The commercial terms usually follow that design — with restrictions on caching and storage, on using the data away from a map, and on feeding it into models or reports.
An out-of-the-box scoring tool is built to give you an answer without modelling work. Walkability scores, amenity scores, area insight indices and location grades all take the same shape: someone else's weighting, pre-computed, returned as a number. You get a plausible result on day one with no data engineering, but it is not tailored to your business, your users and your market.
A POI data layer is built to be queried in bulk, aggregated and joined. It hands you the inputs rather than a verdict. With the data, you can then build a scoring algorithm and integrate into a lookup.
Get this data from the TravelTime Data API
The TravelTime Data API serves five layers for 127 countries through one API, queryable by coordinates, H3 cell or geohash:
- Points of interest: Foursquare, OpenStreetMap and Overture matched into one layer, with authoritative government registers added per country, and a source-count signal on every record
- Public transport: stations, lines, agencies and service frequency from TravelTime's own transport graph, with stops clustered into stations rather than raw GTFS
- Land cover: named parks, green space and beaches, stored as H3 aggregates so you can ask what share of an area is open space
- Population and census: population per cell, plus small-area demographics and income where a country publishes them, and never a fabricated zero
- Areas: the administrative boundary hierarchy, with cells for any division to feed into the other layers
Each country is a separate, versioned dataset, rebuilt from source on a fixed cadence. It sits alongside the TravelTime Isochrone, Matrix and Routes APIs, the same catchment can be drawn and then described in one workflow.
Get started with TravelTime. Request an API key, open the playground to test the Data API, or dive into the documentation.
rebecca payton