-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update/establish best practices for OCD-ID types across countries #170
Comments
Using the local terms will always make sense for local users. A challenge only arises when a user (1) wants to use OCDIDs from multiple jurisdictions and (2) needs to know whether a division type in one jurisdiction corresponds to a division type in another jurisdiction. (@jdmgoogle Can you provide a specific use case?) Now, the problem of deciding whether two divisions in two jurisdictions are of the same type is not a solved problem – by anyone, anywhere.
GeoNames and others all likely have other issues as well, where, most likely, a maintainer had to decide what hierarchy to follow, which might not match reality. In other words, trying to establish a worldwide crosswalk of division types is likely a fool's errand. That said, I think it's fine for users to create aliases to the canonical IDs, where the aliases would attempt to organize the world into a single hierarchy of division types. This repo, however, for the canonical IDs, should use division types that have a local meaning to better match reality. |
Noting comments in #184 (comment) and below about a desire for a metadata file format for defining OCD types. |
This issue spun out of the discussion on PR #168.
Background links:
Creating new OCD-IDs
Division identifiers
The current OCD-ID documentation establishes one canonical identifier type --
country
-- but otherwise gives latitude to within-country maintainers to define and enforce types appropriate for their jurisdiction. E.g., the first-level administrative type in the U.S. is astate
, in Portugal it is adistrict
, and in Germany it is aland
.The current situation gives a lot of flexibility and discretion to these within-country maintainer, but can place a significant burden on consumers of the identifiers to figure out what common types are across countries; e.g., is a
district
a first-level administrative division, or a sub-city legislative division?Previous ad-hoc attempts to address this problem (e.g., PR #148) created identifiers which used the in-country types as aliases of identifiers that were more American in origin. E.g.,
Canonical:
ocd-division/country:de/state:bb
Alias:
ocd-division/country:de/land:bb
This was an attempt to balance the needs of publishers (using in-country types and terminology) and consumers (using types they had already seen). The discussion in PR #168 came to the conclusion that this was not desirable, or at least should go through a more thorough review before being implemented at scale. The options discussed were:
adm1
,adm2
, etc, and not use the US-centric termsstate
andcd
for a global specification.country-de-types.csv
, with the columns local-type and standard-type, with rows likeland,adm1
andwahlkreis,constituency
.Discuss. :)
The text was updated successfully, but these errors were encountered: