Skip to main content

Places Guide

The Overture places theme contains tens of millions of point representations of real-world entities: schools, businesses, hospitals, religious organizations, landmarks, mountain peaks, and much more. The theme is published under the CDLA Permissive 2.0 and Apache 2.0 licenses. It contains no OpenStreetMap data and carries none of the share-alike obligations of the Open Database License (ODbL).

Overture places theme coverage
Overture places data, July 2026
SourcesLicensefeature count, July 2026
AllThePlaces, OvertureCC0-1.01,418,830
BrightQuery, OvertureCDLA-Permissive-2.0831,651
DAC, OvertureCDLA-Permissive-2.0149,700
Foursquare, OvertureApache-2.04,748,001
Krick, OvertureCDLA-Permissive-2.015,396
Microsoft, OvertureCDLA-Permissive-2.06,305,853
PinMeTo, OvertureCDLA-Permissive-2.0159,426
RenderSEO, OvertureCDLA-Permissive-2.03,655
meta, OvertureCDLA-Permissive-2.060,591,049

Overture defines a place as a concrete, physically identifiable, stationary destination in a publicly observable space. The next section unpacks that definition and how it draws the line between places and Overture's other themes.

In this guide​

What is a place?​

Each part of Overture's definition of a place, a concrete, physically identifiable, stationary destination in a publicly observable space, does deliberate work:

  • Concrete and physically identifiable excludes abstract entities such as administrative areas (countries, states, cities, and neighborhoods, covered by the divisions theme) and standalone address points, covered by the addresses theme.
  • Stationary excludes movable things such as food carts, vehicles, boats, and aircraft that often appear in user-generated content datasets.
  • Destination excludes bus stops, train platforms, and other intermediate waypoints, most of which live in the base theme's infrastructure feature type under the transit subtype.
  • Publicly observable excludes non-public spaces such as private residences, even when they are otherwise identifiable destinations.

Finally, only places that do not include personally identifiable information (PII) are included in the theme.

The public observability requirement reflects a principle that applies across all of Overture's data:

Overture Maps Foundation focuses on map data about physical objects that can be publicly observed and are relevant to map applications. Our goal is to collect high quality data that reflects the physical world as it changes. We do not collect or publish data about non-public spaces or objects. If something is not observable from a publicly accessible area, it does not fit in Overture's datasets.

Places is not the only Overture theme with point data. Addresses are published as point features, divisions include point representations of populated places, and the base theme contains points for natural and infrastructure features. Some real-world entities appear in more than one theme by design: a mountain peak, for example, is in places as a destination and in the base theme's land type as a physical feature. What distinguishes a places record is what it carries (a name, categories, an existence confidence score, and a GERS-matched identity) rather than the kind of point it marks.

Dataset description​

Feature type descriptions​

The places theme defines a single feature type, place, a point representation of a real-world entity carrying attributes such as name, categories, address, and an existence confidence score along with a point geometry.

Core properties​

While the schema defines many properties, a small set is core to how the dataset is built and used:

  • Matching: the matcher relies on names, addresses, websites, phones, the category (taxonomy), and the point geometry itself to decide whether two provider records describe the same real-world place. Completeness of these properties directly affects data quality. Records missing them are harder to deduplicate and more likely to persist as duplicates.
  • Identity: id carries the place's GERS ID, which anchors its identity across releases and is the join key for bridge files and the changelog.
  • Filtering: confidence is the primary tool for separating reliable records from suspect ones (see Confidence score).

The remaining properties are descriptive enrichment. They are useful where present, but not load-bearing for dataset construction.

Column definitions​

Column definitions for the place type are generated from the schema and live in the schema reference.

Category taxonomy​

The Overture Place Categories (OPC) taxonomy is a hierarchical system of roughly 2,300 categories, with broader/narrower relationships, for organizing points of interest: businesses, landmarks, attractions, and so on. It is expressed in the places schema through the taxonomy and basic_category properties, which were introduced to better categorize location entities and to facilitate search, display, and navigation in map applications.

These properties are the product of a taxonomy redesign architected by Ron Rice, the taxonomist at Meta who leads the OPC work. The redesign addresses known issues with the original categories property, including structural inconsistencies, naming ambiguity, and coverage gaps, and applies taxonomy design best practices to improve structure for generalization (rolling up) and specialization (drilling down), compatibility across Overture themes, support for user discovery and visualization, and interoperability with other industry taxonomies.

:::warning Deprecation

The categories property in the places schema has been deprecated and will be removed in the September 2026 release, replaced by the new basic_category and taxonomy properties. All three properties will be available until then to ease the transition. You can explore the old-to-new category mappings here. We'd love your feedback on the new structure and suggestions for further improvement.

:::

Taxonomy change summary​

Users should be aware of the following key updates when evaluating and integrating the new places taxonomy.

Change areaDetailsImpact on Data Use
Top-Level Overhaul (L0)Reduced top-level categories from 22 to 13.Requires updating logic dependent on L0 categories. Consolidation reduces ambiguity.
New Categories209 new categories added (e.g., artist_studio, pickleball_court).New, more granular POI types are available for filtering and display.
Removed Categories80 categories removed (resolved duplicates, merged obscure types).Users must use the provided "redirect" rules to map old category IDs to active categories for backfill/historical data continuity.
Renamed Categories407 categories renamed (primarily plural-to-singular conversion, e.g., banks to bank).Update category-based lookups and display logic to use singular forms for better mapping interface labeling.
Reparented Categories482 categories moved under a different direct parent.The immediate parent-child relationship has changed for nearly 500 categories.
Repathed Categories (Hierarchy)2,108 categories have a different hierarchical structure or "path".Critical: Hierarchy-dependent processing (e.g., aggregation) must be updated to reflect the new paths, especially in areas like food_and_drink and arts_and_entertainment.
Basic Category MappingAll place categories are now mapped to a "Basic Level Category" (approx. 280 labels like restaurant, museum).Facilitates simplified map iconography, high-level filtering, and cross-taxonomy mapping.

Comparing the original and new properties​

Original categories system​

The original categories property remains in the schema until the September 2026 release to allow users to compare the old system to the new taxonomy and facilitate migration.

properties:
    categories:
        primary: greasy_diner

New basic level category​

The new basic_category, introduced in the October release, provides a single, high-level, "cognitively basic" label.

properties:
    basic_category: casual_eatery

New taxonomy structure​

The new taxonomy property, introduced in the December 2025 release, contains a new hierarchy and category labels.

properties:
    basic_category: casual_eatery
    taxonomy:
        hierarchy: [food_and_drink, restaurant, casual_eatery, gas_station_sushi]
        primary: gas_station_sushi
        alternate:
            - gas_station
            - sushi_restaurant

Key taxonomy fields​

  • hierarchy: An ordered list representing the full path from the top-level (L0) category down to the primary category. This array is essential for aggregating POIs based on subtype/supertype relationships (e.g., for aggregating all cantonese_restaurant POIs up to chinese_restaurant).
  • primary: The most specific and appropriate category label for the POI, consistent with the lowest level of the hierarchy.
  • basic_category: Identifies a "cognitively basic" category, as a supplement to the primary place category. This is recommended for use in map applications for high-level filtering and defining map iconography, and for LLMs, as it offers a streamlined set of labels (approx. 280) that are less specific than the full 2.1k taxonomy.
  • alternate: Other relevant category labels for the POI.

What are basic-level categories?​

The basic_category property draws on basic-level categorization, a model from cognitive science which asserts that some categories are more cognitively basic than others, requiring the least mental processing. Asked "what are you sitting on," most people say chair rather than a narrower term like kitchen chair or a broader term like furniture. The same principle applies to places: asked "where are you going," a term like restaurant comes more easily than a narrow term like sushi restaurant or a broad term like food and beverage establishment. Basic place categories are often (but not always) one-word terms like hotel, farm, bar, cafe, park, hospital, and museum.

Every basic category is also a category in the full OPC taxonomy: about 300 of the roughly 2,300 OPC categories (13%) are basic-level, and they sit in the middle of the hierarchy, not too broad and not too narrow, typically one or two levels below the top level. Examples include casual_eatery > cafe, historic_site > castle, market > farmers_market, park > playground, and lodging > hotel. Every OPC category can therefore be described as superordinate (more general than basic), basic, or subordinate (more specific than basic). For example: arts_and_entertainment (superordinate) > museum (basic) > art_museum (subordinate).

Aggregation and generalization​

The structured hierarchy property is designed to support robust aggregation logic. Users can reliably generalize specialized POIs by traversing the path. For example, you can find all Asian restaurants by traversing the hierarchy property of POIs and checking for asian_restaurant.

Hierarchy PathAggregation Level
[food_and_drink, ...]Food and Drink POIs
[..., restaurant, ...]All Restaurants
[..., asian_restaurant, ...]All Asian Restaurants
[..., chinese_restaurant, ...]All Chinese Restaurants
[..., cantonese_restaurant]Specific Cantonese Restaurants

Top-level category counts​

Top Level Taxonomyfeature count, July 2026
Services and Business17,435,507
Shopping13,708,264
Food and Drink10,224,131
Lifestyle Services4,609,813
Travel and Transportation3,941,044
Health Care3,815,554
Education3,537,840
Cultural and Historic3,219,997
Sports and Recreation2,835,951
Community and Government2,728,044
Lodging2,602,877
Arts and Entertainment1,558,117
Geographic Entities995,884

Provider category mappings​

Each data provider describes places using its own category system, so during ingest every provider's raw categories are mapped into the Overture taxonomy. Most of these mappings are exact or previously reviewed matches; the remainder are model-derived semantic matches that are held to a confidence floor and reviewed before becoming permanent lookups.

Beginning with the July 2026 release, Overture also captures these provider category mappings in the pipeline, making it possible to trace how a source provider's original category was translated into the Overture taxonomy. The July 2026 release additionally expanded US coverage from BrightQuery with places in the arts_and_entertainment, lodging, and cultural_and_historic_landmarks categories, mapped to the taxonomy via NAICS-based mappings.

Taxonomy roadmap​

The taxonomy is maintained on a quarterly release cycle, with updates in March, June, September, and December of each year. The emphasis going forward is on expansion for interoperability and on adding definitions that clarify each category's scope and meaning. Planned infrastructure work includes migrating taxonomy management from spreadsheets to GitHub with semi-automated integration into the schema and documentation, a governance framework covering how stakeholders give feedback and how changes are submitted, evaluated, approved, and communicated, and a taxonomy reconciliation hub: a single source of record for industry taxonomies and their mappings, with hybrid curated and AI-assisted alignment.

Sources and licensing​

The places theme is built from a variety of data providers. Its primary source is Meta, which contributes the large majority of place records (roughly 59 million of the ~75 million total), alongside Microsoft, Foursquare, and PinMeTo, together with a number of smaller aggregators and providers such as AllThePlaces, BrightQuery, DAC, Krick, and RenderSEO. The theme does not include OpenStreetMap data.

Places is published under the CDLA Permissive 2.0 and Apache 2.0 licenses, depending on the source. For full per-source licensing information, see the licensing and attribution page.

Note: Joining CDLA Permissive 2.0 data to OpenStreetMap is permitted, but the resulting data may need to carry the Open Database License (ODbL) if it is a derivative database. See the OSM Collective Database Guideline for more information.

How we build the dataset​

Because multiple providers contribute records describing overlapping sets of real-world places, the central problem in building the dataset is conflation: determining which records refer to the same real-world entity. Conflation quality matters beyond deduplication. It is key to GERS stability, because a place whose records are conflated consistently keeps the same GERS ID from release to release, while inconsistent conflation causes identities to split or merge as source data shifts.

Filtering. No theme-wide filtering is applied beyond an existence threshold: places with a confidence score of 0.2 or less are removed.

Matching. Places use ML-based matching with clustering to identify records from different providers that describe the same real-world place. The full conflation pipeline is described in the next section.

Merging. For matched places, a single source is promoted rather than combining attributes. Matched places are clustered, the place from the source with the highest match count is promoted, and no attributes are merged between matches.

The conflation pipeline​

Each provider feed passes through a four-stage pipeline on its way into the corpus:

  1. History matches. Incoming records are first checked for exact matches with places already in the corpus. For a provider that is already in the corpus, roughly 90% of feed records are history matches; only the remaining ~10% of new records continue through the stages below.
  2. Blocking. A pre-filter narrows down the number of possible pairs. Comparing every place to every other place is computationally irresponsible , so the matcher first narrows the search to a set of candidate pairs. Candidates are identified spatially, then filtered by a trained blocking model that uses embedding representations of each place's name, category (taxonomy), and address, together with distance thresholds. The blocking stage is tuned for high recall: it aims to keep every plausible duplicate pair in play for the pairwise stage, including pairs at longer distances that earlier versions of the matcher missed.
  3. Pairwise matching. Each candidate pair is then scored by a gradient-boosted decision tree (XGBoost) classifier that predicts whether the two records represent the same place. The model combines attribute-similarity features, including:
    • name similarity, using both string comparison (with common "core words" like shop or restaurant handled separately) and text-embedding similarity;
    • address similarity;
    • website features, comparing domains and paths;
    • phone number;
    • category similarity, using embeddings of each record's primary taxonomy category;
    • spatial distance and spatial context (how distinctive a name is within its local area).
  4. Clustering and promotion. Pairs the model scores as matches are grouped into clusters, resolving chains of matches into a single entity (if record a matches record b and record c matches record b, all three form one cluster). Each cluster becomes a single place in the released dataset, following the merging rule above: the record from the source with the highest match count in the cluster is promoted, and its GERS ID carries the cluster's identity forward across releases.

How matching quality is measured and improved​

The matching model is trained and evaluated on a large set of human- and LLM-generated match labels sampled across providers, countries, and categories. Human labels come from an in-house Overture labeling team working with purpose-built pairwise labeling and QA tools. Because human labeling is slow and costly, Overture also generates labels at scale with LLMs, using an iteratively optimized prompt built around an evidence hierarchy (functional identity, phone, name uniqueness and distance, and supporting signals such as website, category, and brand). In production, two independent models label each pair; agreements are accepted automatically and disagreements go to human review, which keeps accuracy high while automating the large majority of labeling work.

These labels make conflation quality measurable, turning matching from an ambiguous production problem into a tractable optimization task. Mapping the true distribution of matches by name similarity and pair distance showed that the previous pipeline suffered from undermatching, cases where two records for the same place were not recognized as duplicates, especially when records are more than 100 meters apart or have only moderately similar names, and that the blocking stage was the largest bottleneck.

The matching pipeline was substantially upgraded in the July 2026 release to address these gaps. Better matching also improves GERS ID consistency over time, because a place is less likely to split into (or merge from) multiple identities as source data shifts. Note that the July 2026 release itself re-matches the corpus with the new pipeline, so users should expect a one-time elevated level of GERS ID churn in that release; subsequent releases benefit from the more stable matching.

Confidence score​

The places theme includes an existence confidence score for each feature, a value between 0 and 1 representing the likelihood that the place exists. Confidence measures existence only, whether the record describes a real place rather than junk, and is independent of other attributes such as operating_status. A score of 0 means we are certain the place does not exist; a missing value means no confidence information is available.

Confidence values derive from a mix of provider-supplied signals and internal scoring, and are not calibrated to be strictly comparable across providers. Treat the score as a relative filtering tool rather than a precise probability: raising the threshold trades coverage for precision. You can use confidence to filter out data below whatever threshold suits your use case.

Coverage and data quality​

Coverage. The places theme provides global coverage. Ongoing coverage measurements are in progress, and updated country-level figures will be published here as they are confirmed.

Known quality issues. Places is known to contain duplicates, a high junk rate, and low property completeness. The confidence score (above) is the primary tool for filtering potential junk data; it does not address duplicates or property completeness.

Release artifacts and updates​

The places theme is released on a monthly cadence. Alongside the data, the following release artifacts are provided:

Data access and retrieval​

Overture's places theme data is freely available on both Amazon S3 and Microsoft Azure Blob Storage at these locations:

providerlocation
Amazon S3
s3://overturemaps-us-west-2/release/2026-07-22.0/theme=places/type=place/*
Azure Blob Storage
https://overturemapswestus2.blob.core.windows.net/release/2026-07-22.0/theme=places/type=place/*

Releases are published under dated paths. Rather than hard-coding a specific release date, you can use Overture's STAC catalog to discover the latest release and its assets programmatically.

More information can be found in the Getting Overture Data section of this documentation. You can download the entire dataset directly from the S3 or Azure locations above. Warning: the output will be a very large file.

We recommend downloading only the Overture data you need. If you have a particular geographic area of interest, there are several options for using a simple bounding box to extract places data and output a GeoJSON file.

To quickly view and download modest amounts of data, you can use the Overture Maps Explorer website.

To download data: Pan to the area you are interested in, turn off the other layers, then click Download Visible.

This will download the area visible on your screen.

Querying and analysis​

Querying by properties​

These examples use data properties in the address, category, and confidence scores columns to filter the data in useful ways using DuckDB.

The address column can be used to quickly filter data down to a particular political unit. This example uses the country key to get all the data with addresses in Lithuania. Region can be likewise used to extract data from smaller units such as US states.

LOAD spatial; -- noqa
LOAD httpfs;  -- noqa

-- Access the data on AWS in this example
SET s3_region='us-west-2';

COPY (
    SELECT
-- we can parse addresses into columns to make further filtering of the data simpler
    addresses[1].freeform as street,
    addresses[1].locality as locality,
    addresses[1].postcode as postcode,
    addresses[1].region as region,
    addresses[1].country as country,
    *
FROM read_parquet('s3://overturemaps-us-west-2/release/2026-07-22.0/theme=places/*/*')
WHERE
    addresses[1].country = 'LT'
) TO 'lithuania_places.parquet';

Advanced examples​

These examples present some use cases that combine places data with other datasets.

Overture Places can be a valuable source for conflating with or enhancing your own existing dataset.

In this example, suppose we want to use OpenStreetMap POIs for a project but would like to fill in any missing attributes such as addresses or phone numbers with Overture Place data.

Using some basic matching logic, we can join these two datasets together to create a more robust final product. By also joining the GERS ID to our output dataset we could easily keep our now conflated dataset synced with future Overture releases with a simple join.

To run this example yourself, an Oregon PBF can be obtained from Geofabrik.

Note: Joining data with a CDLA Permissive 2.0 license to OSM is permitted but the resulting data may need to carry the Open Database License (ODbL) if it is a derivative database. Please see the OSM Collective Database Guideline for information on this topic.

LOAD spatial; -- noqa
LOAD httpfs;  -- noqa
-- Access the data on AWS in this example
SET s3_region='us-west-2';

COPY (
-- We'll first select OSM data from Oregon with amenity = restaurant
    WITH osm AS (
        SELECT kind,
            id,
            tags->>'name' AS name,
            tags->>'addr:housenumber' AS housenumber,
            tags->>'addr:street' AS street,
            tags->>'addr:postcode' AS postcode,
            tags->>'addr:city' AS city,
            tags->>'website' AS website,
            tags->>'phone' AS phone,
            lat,
            lon,
            tags
        FROM st_readosm(
                'oregon-latest.osm.pbf'
            )
        WHERE tags->>'amenity' = 'restaurant'
    ),
-- Then select Overture data with any category containing the word restauarant in Oregon.
    overture AS (
        SELECT id,
            names.primary AS "names.primary",
            websites[1] AS website,
            socials[1] AS social,
            emails[1] AS email,
            phones[1] AS phone,
            addresses[1].freeform AS freeform,
            addresses[1].locality AS locality,
            addresses[1].postcode AS postcode,
            addresses[1].region AS region,
            addresses[1].country AS country,
            geometry AS geometry  -- DuckDB v.1.1.0 will autoload this as a `geometry` type
        FROM read_parquet('s3://overturemaps-us-west-2/release/2026-07-22.0/theme=places/*/*')
        WHERE region = 'OR'
            AND country = 'US'
            AND categories.primary ilike '%restaurant%'
    )
-- Now that we have our input data we will join them together.
    SELECT
        -- With the GERS ID joined to the final result this dataset can be quickly synced to future Overture releases
        overture.id AS GERS_ID,
        osm.name,
        -- Using CASE statements, we'll favor OSM data when it is present but use Overture data wherever there are gaps
        CASE
            WHEN osm.housenumber IS NOT NULL
            OR osm.street IS NOT NULL THEN concat(osm.housenumber, ' ', osm.street)
            ELSE overture.freeform
        END AS address,
        CASE
            WHEN osm.city IS NOT NULL THEN osm.city
            ELSE overture.locality
        END AS city,
        CASE
            WHEN osm.postcode IS NOT NULL THEN osm.postcode
            ELSE overture.postcode
        END AS postcode,
        CASE
            WHEN osm.website IS NOT NULL THEN osm.website
            ELSE overture.website
        END AS website,
        CASE
            WHEN osm.phone IS NOT NULL THEN osm.phone
            ELSE overture.phone
        END AS phone,
        overture.social,
        overture.email,
        st_point(osm.lon, osm.lat) AS geometry
    FROM osm
-- To join the data, we'll first match features that have the same OR similar names
        LEFT JOIN overture ON (
            osm.name = overture."names.primary"
            OR osm.name ilike concat('%', overture."names.primary", '%')
            OR overture."names.primary" ilike concat('%', osm.name, '%')
            OR damerau_levenshtein(osm.name, overture."names.primary") < 3
        )
-- Then use a small buffer to match features that are nearby to each other
        AND st_intersects(
            st_buffer(overture.geometry::geometry, 0.003),
            st_point(osm.lon, osm.lat)
        )
) TO 'oregon_restaurants_combined.parquet';

Tools and libraries​

Tools from Overture and the wider ecosystem can help you explore, visualize, and work with places data:

  • Taxonomy Browser: An interactive tool for exploring and comparing releases of the Overture Places category taxonomy hierarchy.
  • Taxonomy visualizations: Interactive visual maps of the OPC and basic-category taxonomies, including views of how many places fall within each category.
  • Overture Maps Explorer: A browser-based tool for viewing and downloading modest amounts of Overture data.
  • POI library: A cross-dataset point-of-interest library, presented at State of the Map, that combines Overture, Foursquare, and OpenStreetMap data for users looking for the most inclusive dataset.
  • Community visualizations: Visualizations of places data built by the wider ecosystem.
Last updated on