TL;DR*: Current systems standardize locations, not places. Standardizing place requires a comprehensive, easily accessible dataset. Overture’s approach, focusing on accessible data rather than maps, could be a solution.
Seen on: Simon Willison’s Weblog: Towards Standardizing Place.
From Towards Standardizing Place | Drew Breunig:
Coordinate reference systems (CRS) do a great job defining how we can describe locations as coordinate sets in our databases. (…) WGS 84 is excellent and (almost always) interoperable. It has standardized location in our databases
But these systems cannot standardize place.
The difference between locations and places is an important nuance. (…) coordinates [ VS ] roads, paths, houses, stores, schools, forests, arenas, cities (…)
So what do we need to standardize place? (…)
- A Source of Truth: (…) For WGS 84, this source of truth is
(0,0)
(…)- Mechanisms for Disseminating the Truth: (…)
- A Format for Expressing Your Position Relative to the Truth: (…)
My favorite example is our current standardization of time, the trio of UTC, NTP, and UNIX Time.
(…)
To standardize place, our source of truth must be much more complex than WGS 84’s or UTC’s. (…) We need a dataset that knows about all the places we want to associate with and ask questions of. This dataset must be open and iterrogable by all. (…)But even “open” isn’t enough. It must be easy to access. If a dataset is open but requires you to download a massive file and stage it in a specialized database – unfamiliar to most – is it really accessible?
This is why Open Street Map isn’t sufficient to standardize place. OSM is an amazing project, focused on making the best maps, freely available. But their dissemination mechanism is the map itself; everything is done in service of building that final map view.
Overture’s main product is its data, not a map. This data is staged accessibly, on AWS and Azure, in cloud-native geoparquet. Accessing the entire corpus, a single layer, or a subset of either can be done with AWS, Azure, or Overture’s Python CLI tools. If you use Google Cloud or Snowflake, CARTO staged the data on both.
Heck, you can use duckdb to query the data remotely.
The fact that OpenStreetMap is not suitable for this purpose made me think of On Exactitude in Science (Borges) and Map–territory relation.
* TL;DR generated with claude.ai