Overture's Data Retention Policy - Effective September 24, 2025

[danabauer]

Starting with our 2025-09-24.0 release, Overture will implement a data retention policy for publicly available data releases.

What's changing:

• Data releases will be publicly available for a maximum of 60 days (approximately two monthly releases)
• Data files will be automatically removed from public distribution after this period using cloud storage lifecycle policies

What remains available:

• The most recent two monthly data releases (last 60 days)
• Versioned changelogs and bridgefiles for all releases
• GERS registry
• Release notes from all past releases

Why we're implementing this:

This policy ensures compliance with data protection regulations, including GDPR "right to be forgotten" requirements.

You can find complete details about our release schedule and policies on our Releases page. Questions? Feel free to ask in this discussion thread.

[bhousel]

GDPR “right to be forgotten” is about proper storage of individual’s personal data. I’m sure this deletion policy is being implemented for good reasons, but I’m surprised (and a bit disappointed) to hear that it means Overture data files will go away after 60 days.

I don’t think other publicly available map datasets typically work this way. Admittedly I am viewing this from a US-perspective, but data like TIGER, NAD, NLCD are available indefinitely, and people regularly use historical copies of these datasets to better map and understand how the world changes over time.

More directly related to my work, the datasets that we make available in the Rapid editor are stable (generously hosted by Esri, Meta, Microsoft) and I have never even considered the possibility that they might be subject to GDPR’s right to erasure - it’s building footprints and addresses, not checkins or telemetry.

In any case, I hope I am misunderstanding what this announcement means. I’m sure people with more experience with the GDPR than me have put a lot of thought into it and decided this for good reasons.

[danabauer]

Hi Bryan. Thanks for this thoughtful feedback. We've encountered GDPR-relevant cases that prompted us to create this policy and apply it broadly as a precautionary measure. We want to ensure compliance across all themes in our releases.

Our members have also indicated their usage focuses primarily on the latest versions of the data in new releases.

We have been thinking about how the components of GERS (registry, changelog, and bridgefiles) might be able to support change detection use cases like the ones you mention. We're working on creating better examples and workflows in our docs. Would you be willing to share more details about the specific change detection and historical analysis use cases you have in mind?

[sfkeller]

Bryan is right. The GDPR deals with personal data and should not be equated with trying to erase data history and lineage. That would be a misinterpretation. Besides, it doesn't help much that Overture Maps no longer offers data history, since the internet never "forgets" anything anyway.

Are there any other reasons for this (non-)retention policy?

And should'nt there be a bold news or blog post about these fundamental changes in this new policy and schema design (i.e. multi-licensing which would help integrating other data, especially OSM data)?

[danabauer]

Thanks for your feedback, @sfkeller. We'll be sharing more about our plans for new data integration and multi-licensing in the coming months.

[martinfleis]

I would like to point out that from a scientific perspective, this decisions renders relying on OvertureMaps as very problematic as the work that pulls the Overture Data is fully reproducible for a maximum period of 60 days after which the data likely changes. I just ran into this when trying to reproduce my own work that was using the release from August '24, which no longer exists on S3. Since then, not only the data but I believe that also the schema have changed rendering the whole pipeline unusably any longer.

I am not sure what is the position of Overture Foundation regarding support of reproducible scientific workflows but this specific change just killed any attempt to do any reproducible science on top of your data product.

[irm-codebase]

I want to echo this.
We were relying on overture for several workflows due to the stable data retention (for example, creating high-quality country polygons). This new approach will render a lot of scientific work harder to reproduce and may result in us dropping overture entirely.

Not all of your data products are affected by GDPR. My guess is that only Addresses and Places are the ones affected by it (please correct me if I'm wrong, though). We'd very much prefer a more balanced approach: isolating cases that do require GDPR compliance, and warning about them, while retaining the reproducibility and high value of your other data products.

I cannot stress enough how scientifically valuable overture data is. I hope there is still time to re-think this approach on your side.

[yu-ta-sato]

Is there any update for the direction of data retention policy?

While Overture Maps heavily relies on OpenStreetMap (even Places), it does not have such retention policy for "right to be fogotten" in the context of GDPR compliance (link). Also GDPR is not eligible to all the countries, but limited regions especially European Union.

As Martin pointed, this change deteriorated the utility of this data product in terms of reproducibility. In my academic project, I collected the data from 2024 before but now not available anymore, so decided to use OSM unfortunately. While Dana said many applications are for the current data, there could be more needs like me or Martin.

If the current stance holds for long term, many of business applications and academic research would have to turn back to OSM once they need to secure the temporal cutoff.