Data Changelog

With each release, Overture publishes a changelog reporting what changed between the previous release and this one, feature by feature. If you hold GERS IDs, the changelog is how you find out which of them need attention without downloading and diffing two releases.

Provider	Location
Amazon S3	s3://overturemaps-us-west-2/changelog/<RELEASE>
Microsoft Azure	wasbs://changelog@overturemapswestus2.blob.core.windows.net/<RELEASE>

The latest <RELEASE> is:

2026-09-23.1/

The files are Parquet, partitioned by theme, type, and change_type, and written in spatial order so that a bounding-box filter reads few row groups.

changelog/<RELEASE>/theme=<theme>/type=<type>/change_type=<change_type>/*.parquet

Coverage

The changelog covers all six themes and every type within them, including the base theme and addresses. This is broader than the GERS registry, which excludes those, and much broader than bridge files, which cover five theme and type combinations. A feature can appear in the changelog without carrying a GERS ID.

Schema

Column	Type	Description
id	string	The feature's identifier. For the feature types in the GERS registry this is a GERS ID. For everything else, including the whole base theme, it is an identifier with no stability commitment behind it.
bbox	struct of float	Bounding box, for spatial filtering.
columns_changed	array of string	The top-level column names that differ from the previous release, such as geometry, names or categories. Populated only on data_changed rows, and never lists a column that was not compared.
theme, type, change_type	string	Partition keys, present in the path rather than in the file.

columns_changed is the column to reach for first. It tells you whether a change touched something you depend on, which usually means you can skip most data_changed rows rather than comparing features yourself.

Types of change

• added: the ID is in this release and was not in the previous one.
• removed: the ID was in the previous release and is not in this one.
• data_changed: the ID is in both releases, and its geometry or one of its compared properties differs.
• unchanged: the ID is in both releases with identical geometry and compared properties.

unchanged is published as a partition like the others, so the changelog is a complete account of the release rather than a diff.

What "added" means

A feature reported as added is new in Overture, not necessarily new in the world. Much of the volume in added is coverage expansion or a new source being ingested. Likewise, removed can mean a source was dropped or a feature was merged into another, not that the thing stopped existing.

What counts as a change

Overture compares geometry and properties, with two exclusions you can see and one you cannot. sources and confidence are never compared, because both change on nearly every feature in most releases and would bury the real edits. The comparison also skips Overture's own record of whether a feature is still active in the corpus, which is internal bookkeeping rather than part of the published data.

The practical consequence is that a feature whose only change is its provenance reports as unchanged. If you track which source a feature came from, the changelog will not tell you when that changed.

Geometry is compared on its normalized text form rather than its raw bytes, so a re-encoding that produces the same shape does not register as a change.

Splits, merges, and restores

There is no change type for a split or a merge. When a segment splits, at most one of the pieces keeps the original identifier; the others appear as added. Nothing connects them. See GERS ID stability for what that means for a maintained join.

There is also no change type for an ID that was removed in an earlier release and has come back. A restored ID appears as added, indistinguishable from an ID that is genuinely new. A restored state has been discussed since 2024 and is not implemented. If you process releases consecutively and keep your links after a removal, a restore is something you can act on and we would like to hear about it.

Querying the changelog

Get the id, type, and change_type for places in Hanoi:

LOAD spatial; -- noqa
LOAD httpfs;  -- noqa
SET s3_region='us-west-2';

-- Places that changed in Hanoi, Vietnam.
SELECT id, type, change_type
FROM read_parquet('s3://overturemaps-us-west-2/changelog/2026-09-23.1/theme=places/type=place/change_type=*/*', filename=true, hive_partitioning=1)
WHERE
        bbox.xmin > 105.70
        AND bbox.xmax < 106.00
        AND bbox.ymin > 20.90
        AND bbox.ymax < 21.15;

Count features by change_type for the same area:

LOAD spatial; -- noqa
LOAD httpfs;  -- noqa
SET s3_region='us-west-2';

-- The same area of interest, counted by change type.
SELECT count(*) AS features, change_type
FROM read_parquet('s3://overturemaps-us-west-2/changelog/2026-09-23.1/theme=places/type=place/change_type=*/*', filename=true, hive_partitioning=1)
WHERE
        bbox.xmin > 105.70
        AND bbox.xmax < 106.00
        AND bbox.ymin > 20.90
        AND bbox.ymax < 21.15
GROUP BY change_type
ORDER BY features DESC;

Join the changelog to the release data on id to see the properties alongside the change type, this time in Athena:

-- Join the changelog to the release on id, so each feature carries its
-- change type alongside its properties.
SELECT
    release.id,
    release.names."primary" AS primary_name,
    release.taxonomy."primary" AS category,
    change_type,
    ST_GEOMFROMBINARY(geometry) AS geometry
FROM overture.release.v2026_09_23_1 AS release
    INNER JOIN changelog_v2026_09_23_1 AS changelog
        ON release.id = changelog.id
WHERE release.theme = 'places'
    AND release.bbox.xmin > 105.70
    AND release.bbox.xmax < 106.00
    AND release.bbox.ymin > 20.90
    AND release.bbox.ymax < 21.15;

Using the changelog to maintain a match

The maintenance pattern is the same whichever theme you work in:

1. Join your matched GERS IDs to this release's changelog.
2. For removed IDs, re-match those records against the current release. These are the ones that will otherwise silently break.
3. For data_changed IDs, check columns_changed and act only where a column you depend on has moved.
4. For added IDs in your area of interest, decide whether any of them match records you previously could not place.

The GERS tutorial works through this end to end.