8 posts tagged with "tools"

If you publish geospatial data, you've probably done this. You put a dataset on a data portal or shared it with colleagues, maybe as a Shapefile, a GeoPackage, or a GeoParquet file. You describe its columns somewhere else: a PDF data dictionary, an FGDC metadata record, a spreadsheet of codes. Someone asks what a code means, so you add a note to the description, and later you fix a column in the data without going back to the description. Now there are three versions of the truth: the data, the portal entry, and the document. They disagree.

You do have a model. You just wrote it in a place nothing else can read. The data dictionary describes the columns, but no validator checks the data against it, and no tool can look up which values are legal. Every copy of that knowledge gets maintained by hand, and hand-maintained copies drift.

We had the same problem at Overture, at a larger scale. The Overture Schema started as JSON Schema, hand-written as YAML, with reference docs written separately and validation that only ran on JSON. When the schema changed, the docs had to catch up by hand, and they didn't always. So we asked how we could write the model so that the data, the validation, and the reference material all derive from it and can't diverge. Our answer was code. Last month we published v2.0.0 of the schema as a Python library built on Pydantic. The model is the source, and the JSON Schema, the reference docs, and the validation checks are all generated from it.

Each Overture Release includes the core dataset of GeoParquet features, the GERS registry, GERS bridge files, and data changelogs.

In addition, the Overture Maps project distributes tilesets in the PMTiles format. This doesn't contain any additional data beyond the GeoParquet datasets. The tileset is useful for interactive visualization of Overture features, since geographic objects are clipped to tiles and simplified to many levels of detail. It's used by the Overture Explorer, as well as internal tools.

Overture Maps produces data products and not platforms or APIs, so the PMTiles tileset format lets Overture distribute tilesets using only an S3 bucket. You can find the tilesets powering the Explorer in the overturemaps-extras-us-west-2 bucket.

When we launched Explorer back in the summer of 2024, we described it as an "x-ray data inspector" and made a deliberate choice to show everything at once — all themes, all feature types, all properties — with minimal cartographic polish. The goal was transparency, not beauty. We wanted you to see the data as it really is.

That was the right call for a launch. But as Explorer has matured and more people have come to rely on it, we've learned that "useful data tool" and "thing you actually enjoy looking at" don't have to be mutually exclusive. The person most responsible for closing that gap is Jonah Adkins, Cartography Lead at Meta. "I didn't have the intention of just redoing the whole thing," Jonah says, "but I was curious what I could get Claude to do." He came up with a plan, and it was, in his words, probably 5 to 6 hours of work total over a few days. By end of day one, Explorer looked like a different site. Dana let him keep going.

("I would have felt better with a heads up," Dana says. "But it's so pretty now.")

Over the past few releases, the Overture engineering team has gone from generating a STAC catalog as an ad hoc release artifact to making STAC the backbone of our tooling. Now our Python client, Explorer, internal QA tools, and data pipelines all use Overture STAC to stay in sync with the latest release. We did this to improve our own workflows, but we think it'll make things easier for everyone.

Here's our STAC, from the top. https://stac.overturemaps.org/.

{
  "type": "Catalog",
  "id": "Overture Releases",
  "stac_version": "1.1.0",
  "description": "All Overture Releases",
  "links": [
    {
      "rel": "root",
      "href": "./catalog.json",
      "type": "application/json"
    },
    {
      "rel": "child",
      "href": "./2026-01-21.0/catalog.json",
      "type": "application/json",
      "title": "Latest Overture Release",
      "latest": true
    },
    {
      "rel": "child",
      "href": "./2025-12-17.0/catalog.json",
      "type": "application/json",
      "title": "2025-12-17.0 Overture Release"
    }
  ],
  "latest": "2026-01-21.0",

In the June release, we introduced new components of GERS, including a new format for GERS IDs and a GERS Registry. In this blog post, we'll walk you through the GERS "system" and show you how to ask probing questions of the Overture datasets.

Understanding GERS IDs​

First, let's look at the new ID format for GERS. As of the June 2025 release, all GERS IDs are UUIDs: 128-bit, randomly-generated identifiers (UUID v4) that Overture keeps stable across data releases and updates. These IDs are stored as strings with dashes: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.

For this release only, we're providing Parquet files that map GERS IDs from the May release to the new GERS UUIDs in June release. These files are partitioned by theme and 'type' and can be accessed here: s3://overturemaps-extras-us-west-2/june_to_may_id_mapping/.

Over the past several releases, Overture has been laying the groundwork to transition our transportation theme from beta to general availability (GA). This post provides a brief roadmap of the work we’ve done to reach that goal, along with a request for our community to continue testing the data and providing valuable feedback.

Overture has launched a new browser-based tool to give users a no-code option to interact with our data. The Explore website is now the quickest way to get started with Overture, no SQL required: https://explore.overturemaps.org

Last week Overture Maps announced the beta release of our schema and data. After months of hard work and steady improvements, we are nearing production-level stability. In a series of posts over the next few weeks -- starting with this one -- we’ll unpack the highlights and improvements you'll see in this release and beyond.