DanRunfola
commented
8 months ago This is a really hard problem, because we want to ensure that unique geometries have unique codes - i.e., if you have the same geoboundaries ID, then you should be able to assume that the underlying geometry has not changed. Today, we actually hash the geometry itself to make the code, which is why you see changes - a change in our ID means that the geometry has changed. The problem here is that, of course, most changes are fairly small, which is really just resulting in an ID system that is highly instability (which is also undesirable).
We've discussed this a bunch with a range of actors, and what we're currently thinking is something like (lots of details that need to be figured out):
1) Create a grid across the globe for each administrative level, at a resolution fine enough that it guarantees no two administrative units would overlap in the grid their centroid falls into (possibly a dynamic resolution implementation, where we start course and split as needed). 2) Identify what grid cell the centroid of a given unit falls into. 3) Create a persistent ID based on the combination of (A) the ISO code, (B) the ADM level, and (C) the grid ID. So an identifier would be something like "USA-ADM2-209948". The only case in which that would change is if the geometry changes enough that the grid cell it's centroid falls into changes, which would hopefully be a valid reason to change things up.
This would also allow us to provide a geometric-based join to other cases (i.e., UN SALB or P-Codes from OCHA) through a similar matching process to their datasets.
Basically: a "coarser resolution" version of what we do now, which would result in more stability at the cost of IDs not changing with every geometric shift.
Edit: Also, keep in mind that for much of the world we do not have place-names (or they are highly uncertain / unstable). So the ID has to be generated without text-based metadata, which is where the challenge comes in.
This sounds like a good dissertation chapter, by the way :)
jacobwhall
TL;DR: I would like to associate geoBoundaries data with other datasets. This is difficult to do because geoBoundaries does not persist boundary identifiers across versions. I suggest that geoBoundaries introduce persistent identifiers for administrative entities.
The 2020 geoBoundaries paper states in its opening paragraph:
The "globally unique ID" for each shape is described in this table:
...which glosses over the volatility of shape identifiers:
USA-ADM2-3_0_0-B672USA-ADM2-92793851B4335834252423323B7850950298334952423323B61032845323419There is no (documented) way to reliably link geoBoundaries entities with data from other sources, or even with those from previous versions of geoBoundaries. Matching boundaries based on shapeName is bound to run into difficulties with regard to formatting, language differences, and formal name changes.
I will continue using Richmond as an example. There are many databases that catalog administrative entities, here are a few:
10045969to Richmond0000000405094755E39PBJtCCxFgd9Kg99KkHbYgKd2592301390101728675Many more are listed on Richmond's Wikidata item page, which itself has the permanent reference
Q43421.If Richmond annexes more of Chesterfield, its identifier in the above databases is unlikely to change. I understand that many boundaries tracked in geoBoundaries are ever-changing, yet there remains a need for persistent identifiers. This would make it much easier to associate shapes in geoBoundaries with their associated entities in the above databases.
I believe there are two options for accomplishing this:
The first option might be the easiest to implement. The persistent identifiers could be added to Wikidata for example, enabling cross-dataset queries. This would allow for complex metadata to be associated with geoBoundaries.
Thank you for your consideration!