Every map you use is really two things stacked on top of each other. Underneath is the geometry: roads, coastlines, building footprints, the shapes that make a map look like a map. On top is the layer that makes it useful, the answer to "what is actually here?" That second layer is POI data.
POI stands for point of interest, and POI data is the structured record of the places people care about: the pharmacy that is open until ten, the charging station with the right connector, the clinic that takes your insurance, the café with step-free access. Without it, a map is a picture of streets. With it, a map becomes searchable, filterable, and something software can reason about.
This guide covers what a POI record actually contains, where the data comes from, why quality varies so much between providers, and how POI data is used in applications and by AI agents.
What Counts as a Point of Interest
A point of interest is a named place modelled as a single point rather than an area or a line. The test is whether a person might plausibly want to go there or know it is there.
Restaurants, hotels, hospitals, ATMs, playgrounds, viewpoints, post boxes, EV chargers, bus stops, and recycling centres are all POIs. Streets are not, because they are lines. Neighbourhoods and municipalities are not, because they are polygons and nobody navigates to the centre of a district. Buildings sit in an interesting middle ground: a shopping centre is a POI in its own right, and it also contains dozens of individual POIs inside it.
That last case is worth dwelling on, because it is where naive datasets fall apart. A single coordinate at the centre of an airport is not enough to route a traveller to a specific gate, lounge, or car rental desk. Good POI data models the parent and the children separately and links them.
What a POI Record Contains
The minimum viable POI is a coordinate with a name and a category. That is enough to draw a pin. It is not enough to build a product.
A production-grade record carries considerably more:
- A stable identifier. If the ID changes when the record is updated, you cannot track a place over time or reconcile it against your own database.
- Name, including local variants. A place in Brussels may need both a French and a Dutch name. A place in Athens needs both Greek script and a romanised form.
- Coordinates, ideally with an indication of what the point represents: a rooftop centroid, an entrance, or an approximate address interpolation.
- A structured address, broken into components rather than a single string, so it can be matched, validated, and reformatted per country.
- Category, drawn from a defined taxonomy rather than free text. "Restaurant" is useful. "restaurant / eatery / Restaurant / food" across four records for the same concept is not.
- Opening hours, in a machine-readable format that handles the awkward reality of split shifts, seasonal changes, and public holidays.
- Contact and web details: phone, website, booking link.
- Amenity and accessibility attributes: wheelchair access, outdoor seating, parking, accepted payment methods, whether it is dog friendly.
- Provenance and freshness: where the record came from and when it was last verified.
That last field is the one people skip and later regret. A POI dataset without a freshness signal gives you no way to know whether a restaurant closed two years ago.
Where POI Data Comes From
There are three broad sources, and almost every real dataset is a blend of them.
Open data. OpenStreetMap is the largest openly licensed POI collection in the world, built and maintained by a global community that tags places directly. Coverage is excellent in dense European cities and more variable in rural areas and some regions outside Europe and North America. The attribute richness can be remarkable, since contributors tag things a commercial surveyor would never bother with.
Official registers. Business registries, transport authority stop lists, health service directories, school registers, and cadastral records. This data is authoritative and well maintained, but it arrives in dozens of incompatible national formats and rarely includes the attributes consumers care about.
Commercial collection. Vendors aggregate the above, add their own scraping, buy feeds, and sell access. What you are paying for is usually not the raw places but the work of merging them.
That merging work is called conflation, and it is where most of the difficulty lives. The same café may appear in three sources with three spellings, two slightly different coordinates, and one outdated phone number. Deciding that they are one place, and deciding which version of each attribute wins, is the hard part of building a POI database.
Why Quality Varies So Much
Two datasets can both claim "40 million POIs" and be wildly different in practice. The numbers that actually matter:
- Positional accuracy. Is the pin on the building, or on the street, or at the centre of the postcode? For a store locator this is cosmetic. For last-mile delivery it decides whether the driver finds the door.
- Attribute completeness. Ten million records with names and nothing else are less useful than two million with hours, categories, and accessibility flags.
- Category consistency. If the taxonomy is inconsistent, every filter you build leaks.
- Freshness. Retail and hospitality churn fast. A dataset refreshed annually is describing a world that no longer exists.
- Duplicate rate. Poor conflation inflates counts and produces three pins for one shop.
When evaluating a provider, ignore the headline count and ask what fraction of records carry opening hours, and how recently they were verified.
How POI Data Gets Used
Store locators and finders. The most common use: show me your branches near me, filtered by what I need. See How to Build a Store Locator for the mechanics.
Site selection and catchment analysis. Counting competitors, complements, and footfall generators within a travel-time boundary around a candidate location. POI data plus an isochrone is the core of most retail location decisions.
Logistics and delivery. Resolving a destination to a precise entrance rather than a rooftop centroid, and knowing whether the receiving business is even open.
Real estate and listings. Describing what surrounds a property: schools, transport, shops, green space. This is what turns a listing from a set of photos into something a buyer or an AI can evaluate.
Travel and local discovery. Everything from "what is near my hotel" to full itinerary generation.
POI Data for AI Agents
This is where demand has shifted fastest. When someone asks an assistant "find a pharmacy near the station that is open now and has step-free access," the assistant cannot squint at a map. It needs records it can filter programmatically: category equals pharmacy, opening hours include the current timestamp, wheelchair attribute is true, coordinate falls inside a walking-time boundary from the station.
Every one of those conditions is a POI attribute. An agent with a rich POI source answers the question; an agent with names and coordinates only has to guess, and guessing about real-world places is how you get confidently wrong recommendations.
That is why POI data is increasingly delivered to agents as a tool rather than a tile. Through an API or an MCP server, an agent can query places, filter on attributes, and get back structured results it can reason over and cite.
Getting POI Data Into Your Product
Three practical decisions.
Licensing. Understand what you are allowed to do with the data, particularly around caching, redistribution, and displaying it outside a map. Open data has obligations too, chiefly attribution and, for some licences, share-alike terms.
Where it is processed. If you are operating in Europe and your queries carry user location, where those queries are processed is a compliance question, not just a latency one. See The EU Developer's Guide to GDPR-Compliant Map APIs.
How you keep it current. Decide up front whether you are querying a live API or syncing a snapshot. Snapshots are fast and predictable and start rotting immediately. Live queries stay current and add a dependency.
MapAtlas provides GDPR-compliant POI search, place details, and nearby lookup across Europe and beyond, built on open map data and exposed through both a search API and an MCP server, so the same structured records serve a store locator and an AI agent.
The Short Version
POI data is the layer that makes a map answer questions. A record is a coordinate plus the attributes that let software filter it: name, category, address, hours, accessibility, freshness. It comes from open data, official registers, and commercial collection, and the value a provider adds is mostly in merging those cleanly.
Judge a dataset by its attribute depth and its freshness, not by how many pins it claims. And if AI agents are anywhere in your roadmap, judge it by whether an agent could filter on it without guessing.
Related Reading
- What Is Open Map Data?
- What Is OpenStreetMap?
- How to Build a Store Locator
- What Is a Map MCP Server?
Frequently Asked Questions
What is POI data?
POI data is structured information about points of interest: specific places a person might want to find or visit, such as a pharmacy, a charging station, a school, a hotel, or a bus stop. A POI record pairs a coordinate with descriptive attributes: a name, a category, an address, opening hours, contact details, and often accessibility or amenity flags. It is the layer that turns a map from a picture of streets into something you can search, filter, and reason about.
What is a point of interest?
A point of interest is a single named place represented as a point on a map rather than as an area or a line. The defining trait is that it is somewhere a person might want to go or know about. A restaurant, a cash machine, a viewpoint, and a recycling centre are all points of interest. Roads and administrative boundaries are not, because they are modelled as lines and polygons and nobody navigates to a boundary.
What attributes does a POI record contain?
At minimum a POI has a stable identifier, a name, a latitude and longitude, and a category. Production datasets add much more: a structured address, opening hours, phone number and website, price level, wheelchair access, whether it has outdoor seating or a car park, payment methods, and the date the record was last verified. The attribute depth is usually what separates a usable POI dataset from a bare list of pins.
Where does POI data come from?
Three main sources. Open data, chiefly OpenStreetMap, where a global community tags places and the result is freely licensed. Official and administrative registers, such as business registries, transport authority stop lists, and health service directories. And commercial collection, where a vendor aggregates, scrapes, or buys data and sells access. Most serious datasets blend all three, then run conflation and validation to merge duplicates and resolve conflicts.
How do AI agents use POI data?
An AI agent answering "find me a pharmacy open now near the station" cannot reason from a map image. It needs structured records it can filter: category equals pharmacy, opening hours cover the current time, coordinate falls within a travel-time radius of the station. POI data supplies exactly that, which is why it is increasingly exposed to agents through APIs and MCP servers rather than rendered on a screen for a human to scan.
