Open map data has never lacked sources. It has lacked a source that is simultaneously broad, conventionally structured, licence-clear, and shipped in a format that a production pipeline can consume without a preprocessing project attached.
Overture Maps is an attempt at that. It is a collaborative effort that assembles open and contributed map data into a set of themed datasets with a defined schema, published on a regular cadence in a format designed for large-scale analytical access.
The distinguishing feature is not that the data is open, since much of the input already was. It is that the output is normalised into a documented schema, carries identifiers intended to remain stable, and is packaged so that a query can read a small part of a very large dataset without downloading the whole thing.
Why an effort like this exists
The problem it addresses is one that anyone who has assembled a map dataset from open sources will recognise.
Open geospatial data is fragmented. Buildings come from one place, roads from another, points of interest from a third, addresses from a fourth. Each has its own schema, its own coordinate handling, its own update cycle, its own quirks, and its own licence. Making them work together is a conflation project, and conflation is difficult, expensive, and easy to do wrongly in ways that create a third dataset worse than either input.
Each organisation solving this solves it privately. The normalisation work, the schema decisions, the geometry repair, the entity matching: all of it gets redone independently and none of it is shared, because the result usually contains something proprietary or the effort of publishing it is not justified.
A shared, normalised, openly licensed baseline changes the economics of that. The undifferentiated work happens once, and organisations differentiate on what they add rather than on their ability to clean up the same inputs.
The second problem is identity. Two datasets both containing the same building have no way to say so. Matching them is a geometric and textual inference that has to be redone by every consumer and re-done again after every update. A shared identifier scheme addresses this directly, and it is arguably the more consequential contribution.
The themes, conceptually
The data is organised into themes, each covering a class of real-world entity with its own schema. Understanding what each theme is for matters more than memorising field names, since the schema evolves and the documentation is authoritative.
Places covers points of interest: businesses, amenities, institutions, and other named entities that occupy a location. The typical representation is a point with a name, a category, and whatever contact and address attributes are available. This is the theme most sensitive to freshness, because businesses open and close continuously, and the theme where confidence and provenance matter most.
Buildings covers structures as footprint polygons, with attributes such as height or level count where a source provides them. Coverage and attribute richness vary substantially by region, since the underlying sources include contributed mapping and machine-derived extraction from imagery, and those have different characteristics.
Transportation covers the network: segments and connectors forming a routable graph, with the attributes that routing needs such as classification, access restrictions, and direction. The distinction between a segment as a geometric piece of road and a connector as a junction point is what makes the theme a graph rather than a pile of lines.
Base covers the physical and environmental backdrop: land cover, land use, water bodies, and the general-purpose features that make a map readable and that analysis needs as context.
Addresses covers address points, the mapping between an address string and a position. It is the theme where regional variation is most extreme, because national address data availability varies from complete open publication to nothing at all.
Divisions covers administrative boundaries and place hierarchies, which is what allows anything else to be aggregated into countries, regions, and localities consistently.
The value of the theme structure is that it separates concerns with different update rhythms and different quality profiles. Boundaries change slowly. Places change constantly. Treating them as one dataset with one refresh cycle would serve neither.
Licences differ by theme, and this is the thing people miss
The single most consequential practical fact about Overture is that there is not one licence for the release. Licensing follows the sources, and the sources differ by theme and sometimes within a theme.
Some themes incorporate data under share-alike terms, most notably where contributed open map data forms part of the input. Those carry the corresponding obligations, including attribution and the requirement that a distributed derivative database be offered under the same terms. Other themes are drawn from sources under permissive terms, where attribution may be required but share-alike is not.
The failure mode is direct. A team evaluates the release, reads that it is open data, builds a product that mixes several themes into one internal database, and discovers at launch that one theme's obligations now attach to a combined database they intended to distribute under different terms. Nothing was hidden. The licence was published per theme and the team read it once for the release.
The discipline that avoids this is unglamorous.
- Check the licence for every theme you consume, at the version you consume, and record it.
- Keep theme provenance at the column or table level inside your own storage, so that a later question about obligations can be answered without re-deriving where each field came from.
- Decide, before combining themes, whether the combined artefact will be distributed. Internal use and distribution have materially different consequences.
- Re-check on each release rather than assuming licensing is stable, since sources can be added or changed between versions.
The same rule applies to any multi-source open dataset, but it bites harder here because the release presents as one coherent product, which invites a single licence assumption that the data does not support.
GERS, and the problem of stable identity
The identifier scheme, referred to as GERS, is a system for assigning persistent identifiers to real-world entities so that different datasets can refer to the same thing unambiguously.
The problem it solves is worth stating carefully, because it sounds trivial and is not. Two datasets contain a building. They have different geometry, digitised from different imagery at different times, with different vertex counts and a metre or two of offset. They may have different names, different addresses, and different categories. Deciding whether they are the same building is an inference, and every consumer performs it independently, differently, and repeatedly.
A shared identifier turns that inference into a lookup. If both datasets carry the same identifier for the entity, joining them is a key join rather than a spatial and textual matching exercise. Enrichment becomes composable: an organisation can publish attributes keyed to identifiers without publishing geometry, and consumers can attach those attributes to their own copy of the base data.
The hard part is persistence across change, and it is worth understanding why this is difficult rather than treating identifier stability as a solved property.
Real entities change in ways that break simple identity rules. A building is extended, so its footprint changes but it is the same building. Two adjacent units are merged into one shop, or one is split into two. A business closes and a different business opens at the same address, which is a new entity at the same place. A geometry is corrected, so the shape moves without the thing moving. A duplicate is discovered and two records must become one.
Each of these requires a decision about whether the identifier survives, splits, merges, or retires. Any such scheme therefore needs not just identifiers but a defined lifecycle for them, and consumers need to handle identifiers that disappear or change relationship between releases. Building a system that assumes identifiers are permanent and immutable will eventually be surprised.
The pragmatic reading is that a shared identifier scheme is a large improvement over matching everything yourself, and not a guarantee. Systems that depend on it should keep the matching evidence, geometry and name, so that a broken identifier link can be repaired rather than losing the association entirely.
The distribution format, and why columnar matters
Overture is distributed in a cloud-native columnar format rather than as conventional GIS files, and this is a substantive engineering decision rather than a preference.
The traditional options do not survive at this scale. A single monolithic file of a global dataset in a row-oriented or text-based format has to be downloaded in full and parsed in full to answer any question. Formats that store every attribute of every feature adjacently mean that reading one column costs the same as reading all of them. Text-based formats spend a large fraction of their bytes on structural characters and lose numeric precision guarantees.
A columnar format changes the economics in three specific ways.
Column pruning. Values for each column are stored together, so a query touching three of forty columns reads roughly three fortieths of the data. For wide schemas, which map data always has, this is the dominant saving.
Predicate pushdown. Column chunks carry statistics such as minimum and maximum values. A reader can skip an entire chunk without decompressing it if the statistics show no row in it can match. Applied to coordinates or to a spatial key, this turns a full scan into a targeted read.
Range requests over object storage. Because the format has a footer describing the layout, a client can read the metadata, work out which byte ranges it needs, and fetch only those ranges over HTTP. Data that is hundreds of gigabytes can be queried from a laptop, because the laptop never touches most of it.
Partitioning multiplies these effects. Organising the files by theme and by geography means a query for one theme in one country reads a small set of files, and the rest of the release is never opened.
The consequence for consumers is that the correct mental model is not download then process. It is query in place, materialise only what is needed, and keep the extraction step as a filter rather than a copy. Teams that start by pulling the whole release onto local disk usually do so because that is the habit from shapefile-era workflows, and they pay for it in storage, in transfer, and in a stale local copy that has to be refreshed.
There is an adjacent development worth knowing about: tiled archive formats that package pre-rendered vector tiles into a single file addressable by range request. Those solve the display problem the way columnar formats solve the analysis problem, and the two are complementary rather than competing.
What it does not solve
Being clear about the limits prevents the disappointment that follows an over-promising evaluation.
Coverage still varies by region, because the inputs still vary by region. A normalised schema makes the variation easier to measure, it does not remove it. A theme can be structurally complete, in that every record has the expected fields, and substantively thin, in that a district has almost no records. Those are different properties and only the first is guaranteed by the schema.
Freshness is bounded by the release cadence and by the currency of the sources. For entities that change quickly, particularly places, a periodic release is a snapshot, and any product presenting it as current is making a claim the data does not support.
Conflation is improved, not finished. Where sources disagree about whether two records are the same entity, a decision has been made, and decisions have error rates in both directions. Duplicates survive and distinct entities get merged.
Attribute completeness is uneven within a theme. A building record may have a footprint and nothing else, or a footprint with height, level count, and class. Analysis that requires an attribute has to reckon with the subset that carries it, and that subset is not a random sample of the whole.
None of these are criticisms of the effort. They are the residual difficulty of describing the physical world, and no distribution format or schema removes them.
The check that should be routine
Before depending on any theme from any release, do three things.
Read the licence for that specific theme at that specific version, and store the answer next to the data rather than in someone's memory. This is the check that gets skipped, and it is the one with consequences that cannot be fixed by reprocessing.
Measure coverage in the regions that matter to the product, per theme and per attribute. Structural completeness is not substantive completeness, and the difference between them is where a demonstration succeeds and a deployment fails.
Test the identifier assumption across two releases. Take a sample of entities, carry the identifiers forward, and see how many survive, how many changed, and how many disappeared. A system built on stable identity should know its own churn rate before it depends on it, not after a release breaks a join that had worked for months.