# GERS comment

I write on behalf of the [OpenStreetMap Foundation](https://osmfoundation.org/) (OSMF), the global nonprofit organization that supports the [OpenStreetMap](https://www.openstreetmap.org/) (OSM) project. OSM is one of the foremost sources of open geographic basemap data. OSM data powers use cases across a variety of industries, as well as in academia, civil society, and the public sector. OSM is also at the heart of a vibrant ecosystem of open source geospatial software.

From OSMF’s standpoint, the architecture and format of GERS and other Overture Maps products are the prerogative of the Overture Maps Foundation, whether these products are for internal or external consumption. However, we are concerned that this proposal as written could impose an unnecessary burden on the open data community and impede future innovation in this problem space.

In https://github.com/opengeospatial/requests/issues/3#issuecomment-3917834775 and other comments, members of the open source community raise several compelling technical- and governance-related concerns that we urge the technical committee and proposal authors to take into consideration. We certainly take no issue with the stated goal of maximizing interoperability while avoiding centralized control of geospatial data.[^interop] But we do not see how this promised outcome follows from the proposal.

## Authoritativeness

The Overture GERS implementation is the basis for the proposed Community Standard:

> The source of the content for the draft Community Standard is the July 2025 of the Overture GERS release.

To demonstrate vendor neutrality, the justification document implies that multiple implementations of GERS may exist, each with its own GERS Registry:

> * Registry: A GERS Registry serves as the single source of truth for all entities that are part of an implementation of a Global Entity Reference System.

But contrary to the justification document, [Overture’s own documentation](https://docs.overturemaps.org/gers/registry/) unequivocally states that no other GERS Registry may exist:

> There is only ever one GERS Registry. It's not versioned. We update it with each release by comparing the last published GERS Registry with the current Overture data release.

If a third party chooses to implement their own independent GERS and GERS Registry, how would it coexist with Overture’s implementation? How can an independent implementation comply with the Community Standard – as required by the [Community Standard adoption checklist](https://docs.ogc.org/pol/05-020r29/05-020r29.html#annex-c-community-standard-checklist) – if the standard does not allow the implementation to have its own GERS Registry?

This contradiction is more than unfortunate wording or a technical implementation detail. It gets at the heart of what it means to be a global model based on universal identifiers. Entities outside of Overture’s scope cannot receive Overture GERS IDs. When Overture determines its scope [based on its own members’ market needs](https://github.com/orgs/OvertureMaps/discussions/318#discussioncomment-6243608), anyone who wants to enjoy the claimed benefits of GERS with respect to the out-of-scope features has no choice but to stand up their own solution. They should not then have to choose between that solution and participating in an OGC-sanctioned ecosystem.

For example, without public explanation, Overture recently declined to include [historical points of interest](https://github.com/OvertureMaps/data/issues/211) in the Overture GERS Registry.[^ohm] The Overture schemas similarly do not accommodate historical time series data. By contrast, the field of historical GIS abounds with independently published, small- and large-scale datasets. Even if a historical dataset publisher invests resources to create and maintain a bridge to the Overture Places dataset, this would likely represent an minuscule share of the features that must be joined and conflated with similar datasets to create a well-rounded world model. On the other hand, if the historical GIS community were to establish an alternative GERS with different inclusion criteria, there would be a strong potential for confusion about the provenance of a given GERS ID.

One can imagine a similar situation affecting communities beyond academia: a regional transportation agency coordinating local transit operators,[^ab1599] a government regulator tracking privately built utility infrastructure, or a network of advocacy groups collecting data on culturally sensitive sites from indigenous groups.[^care] Can such a third party fork the Overture implementation to create a derivative GERS Registry? If so, how should downstream users reconcile a GERS ID from the Overture GERS Registry with one from the fork, especially after an update to the Overture GERS Registry?

As proposed, the Community Standard would enshrine a model for managing geographic data that depends on a single scope and entrust Overture with defining that worldview. Considerably more thought needs to be put into accommodating or even facilitating alternative models or enhancing governance processes so that the custodian of the GERS Registry can serve more of the community.

## Stability

The proposal emphasizes the stability and continuity of GERS. It is unclear how the feature types would remain stable and backwards compatible when Overture is in the midst of a monthslong overhaul of key portions of the schema. For example, the [places taxonomy](https://docs.overturemaps.org/guides/places/taxonomy/) is being overhauled to remove or reparent a number of categories. Would Overture continue to make significant changes following standardization? How will changes be communicated to users, including users of independent implementations?

## Evidence of implementation

The [Two Track Standards process criteria](https://docs.ogc.org/pol/05-020r29/05-020r29.html#two-track-Standards-process-criteria) require:

> Strong evidence of implementation as required for the Community Standard is generally defined to be implementation in multiple products or environments OR widespread use of the Standard in a community, even if in only one or a limited number of products or environments.

It is unclear which of the two criteria the proposed Community Standard claims to meet. The justification document includes testimonials from multiple Overture member organizations that have reportedly integrated the Overture GERS. Yet no mention is made of a GERS Registry implementation in an independent product or environment.

How does this internal use of GERS, coordinated through Overture without the involvement of a standard, constitute widespread use of the standard in the broader user community? The proposal casts a wide net, defining the intended user community as “commercial, government, research, and open-source communities”, so one would expect evidence of robust adoption well beyond the Overture membership. On the other hand, if a Community Standard is adopted on the basis of prospective use by a community, then there is a real risk that a design flaw will only become apparent after standardization.

[^interop]: > […] 100% consistent with the existing Overture Maps Foundation reference map and IDs but "owned" by the implementing organization.

[^ohm]: The rejected proposal would have sourced the historical POI coverage from [OpenHistoricalMap](https://www.openhistoricalmap.org/), an OSMF-affiliated counterpart to OSM for historical geodata.

[^ab1599]: For example, the California state government is developing [a transit stop registry](https://dot.ca.gov/-/media/dot-media/programs/esta/documents/complete-streets/2024-25_completestreetsactionplan_publicdraft-a11y.pdf#page=13) based on data collected from local transit agencies. The state transportation department is developing a unique identifier scheme to be used in GTFS feeds.

[^care]: The [CARE Principles for Indigenous Data Governance](https://www.gida-global.org/care) call for data self-governance that is inherently incompatible with a system that depends on a central registration authority for geographic entities.