The geospatial industry has long been on a quest for a universally accepted system to identify real-world entities like buildings, roads, and businesses. Such a system promises seamless interoperability, but its pursuit has been fraught with challenges, often clashing with the commercial realities and vested interests of powerful data owners. Let’s explore this journey through two powerful metaphors: the “One Ring” and the “Holy Grail.”
The Temptation of the “One Ring”: Proprietary Control
Imagine a single, powerful “One Ring” – an entity ID system controlled by one dominant vendor. This system would indeed be powerful, offering a seemingly straightforward way to identify and link data within that vendor’s ecosystem. However, like the One Ring, its singular control could lead to significant issues: vendor lock-in, a “master of all” scenario, and a lack of true openness for the wider geospatial community.
We’ve seen this play out historically. In the UK, the OS Mastermap TOID (Topographic Identifier) was an early attempt at location identifiers. While the concept was valuable, its primary drawback was its proprietary nature and the significant cost associated with licensing the underlying Mastermap database. Users found it difficult to leverage TOIDs effectively without incurring substantial licensing fees, making it a “pointless creation” for those without a Mastermap licence. Such systems, while providing internal consistency, inherently limit widespread adoption and true interoperability outside their controlled environments.
Building on this, the “Holy Grail” metaphor represents the ultimate prize: a single, seamless, universal entity ID system that allows effortless interoperability across all geospatial datasets, regardless of their origin. Yet, its attainment often proves elusive, primarily due to the vested interests of data owners.
The Elusiveness of the “Holy Grail”: Universal Interoperability vs. Vested Interests
Consider WOEID (Where On Earth ID’s), launched by Yahoo! in 2008. This initiative aimed to provide an API for place IDs, promising a “neat way of providing a little more structure around the geotag clouds currently multiplying”. It offered a more open alternative compared to the restrictive OS Mastermap TOID. Despite its initial promise, WOEID did not achieve the widespread, lasting success of a truly global, open standard. While not explicitly stated as “vested interests” in the source, the implicit challenge for any such system is gaining universal buy-in and consistent adoption from all potential data contributors and consumers, many of whom have their own established systems or commercial motivations.
Fast forward to today, and we observe the impressive efficacy of powerful, single-vendor solutions such as Google’s Place IDs. These textual identifiers uniquely identify a place within the Google Places database and on Google Maps. They are widely accepted across a multitude of Google Maps Platform APIs, including the Places API (New and Legacy), Geocoding API, Routes API, Maps Embed API, and Roads API. Developers can readily find a Place ID using the Place ID finder or through various search requests…
However, the very strength of Google Place IDs within their ecosystem highlights the “Holy Grail” dilemma. As a proprietary system, Place IDs inherently tie users to Google’s platform. They are unique identifiers for places in Google’s database. While they can be stored, Google recommends refreshing them if they are more than 12 months old due to potential changes in their database. An obsolete Place ID, perhaps because a business closes or moves, will return a NOT_FOUND status code. This dependency on a single vendor’s database underscores the challenge of proprietary systems achieving universal interoperability across all geospatial datasets, particularly those from other providers. Using Google Place IDs primarily facilitates integration within Google’s sphere, potentially leading to vendor lock-in and continued data integration costs when combining with data from non-Google sources. The “vested interest” here is the company’s control over its own vast and frequently updated dataset, which, while beneficial to its users, does not inherently solve the broader industry’s need for open, cross-platform identification.
The dilemma of the Holy Grail – a singular, universally perfect solution – often runs aground on the reality of diverse data ownership and commercial interests. Each major data provider has invested significantly in its own data collection, curation, and identification systems. To simply adopt one provider’s system as the universal standard would require others to concede their proprietary advantage, a highly unlikely scenario.
The Overture Maps Foundation and GERS: Forging a Shared Path
Recognising these challenges, the Overture Maps Foundation aims to offer a different path – not to possess the Holy Grail, but to make its essence universally accessible and shareable through open collaboration. Their Global Entity Reference System (GERS) is positioned as the first truly open, global, and entity-based ID system. Its open nature means it does not lock users into a single vendor’s ecosystem. Instead, it is supported by a diverse community of nearly 40 organisations, including major players like Amazon, Meta, Microsoft, TomTom, and Esri, who have committed to and are dependent upon Overture data.
GERS seeks to overcome the “data conflation tax” – the significant time and resources organisations spend on data preparation and integration. By providing persistent, unique identifiers for geospatial entities, GERS aims to transform weeks of complex geospatial conflation into simple column joins within minutes. This is achieved through its four key components:
- Overture Reference Map: Monthly validated datasets where each entity carries a unique GERS ID, which is open, free, and accessible
- Data Changelogs: Detailed records of changes between releases, allowing for efficient updates.
- The GERS Registry: A comprehensive database of every GERS ID ever created, offering validation, history, and lookup capabilities.
- Bridge Files: Pre-built mappings between GERS IDs and identifiers from other popular datasets like OpenStreetMap, Meta’s data, and Esri Community Maps, enabling instant integration.
Crucially, GERS IDs themselves utilise the UUID (Universally Unique Identifier) format, ensuring they are globally unique, system-agnostic, and compatible with existing tools and libraries. This means no collisions and universal compatibility across modern databases and programming languages. In essence, while the Holy Grail of a single, centrally controlled, and universally imposed ID system might remain elusive due to the inherent vested interests of numerous powerful data owners, GERS presents a compelling alternative.
It’s not about one entity holding the Grail, but about forging a shared path towards its benefits through open collaboration. By building a system that is openly accessible, jointly maintained, and designed for interoperability rather than exclusive control, GERS offers the closest practical solution to uniting disparate geospatial data without demanding that any single data owner surrender their fundamental interests.
Time will tell as to the success of this Grail Quest. I’m keeping my fingers crossed, but I also know that if this doesn’t work out, future Knights of Geospatial will probably pass this way once again!