An unorganized territory is analogous to a census county division but not quite the same thing. The Census Bureau designates them in different states at the same summary level:
Unlike CDPs, which are named after populated places and somehow spatially relate to them, UTs and CCDs are purely statistical boundaries whose names are descriptive but don’t play a role in wayfinding, even by officials. If we do map these statistical boundaries, we’re really setting aside the on-the-ground rule, so there should be a strong reason for them. Unlike with Alaska’s census areas as county equvialents, I haven’t seen a very strong need for comprehensive national coverage of township equivalents, at least in California where I live, but maybe it’s different in other states?
Since CDPs have been tagged as boundary=census for a long time in OSM, geocoders such as Nominatim have probably grown accustomed to this tagging. A CDP lies inside of a CCD and is subordinate to a CCD in the census hierarchy. We should definitely give CCDs an explicit tag, such as border_type=census_county_division. Existing geocoders may need to adjust their heuristics to distinguish boundary=census relations by border_type=*. Setting admin_level=* may happen to help them make this distinction if they aren’t properly distinguishing between boundary=administrative and boundary=census, but that would be a bit of a hack.
If we are going to deliberately start using border_type to distinguish CDPs from other types of census bureau statistical divisions, we will also need a mechanical edit to add a border_type to all existing CDPs. I’ve added them in a few states in places where I’m confident that the things I’m touching are CDPs, which is why border_type=CDP is growing, but I haven’t systematically added them to the database.
I mean the motivation (at least for me) is a completeness level, and they do show up in certain end data users (my Strava runs used to say “Lawrence County, SD” now they say “North Lawrence, SD”). I was also going to propose a bill to my state rep to request that the Postal Service allow rural residents to use unorganized territories/organized or unorganized townships as their address city so they don’t have to pay the city sales tax on online purchases, but that probably doesn’t mean these need to be in OSM.
If, however, these will cause a massive headache (which it sounds like they might), I can clear them out. Currently, only Lawrence, Custer, Fall River, Yankton, Bon Homme, and half of Pennington counties have these relations (at least in SD) so it’s not that big of a haul.
Another option for avoiding surprises would be to tag them as boundary=statistical, which is ideally how the CDPs should’ve been tagged originally. (Not every country strictly ties their statistical regions to a national census.) But we already have some CDPs in Alaska that are nested inside boundary=censusadmin_level=6 relations representing census areas, so I guess any problems would’ve arisen by now.
Would that work? I’m fine with that proposal, and I can update the boundary wiki page to reflect that. That way the validator would have something to go off of.
I don’t feel very strongly about CCDs. If you tag them as boundary=statistical to get them out of the way of existing data consumers, I don’t have any objection to that. border_type=* would still be a good idea however.
I also don’t feel terribly strongly about it. If anything, we should tag them boundary=statistical + border_type=CCD and in the future look to re-tag all CDPs as boundary=statistical + border_type=CDP…
Rather than abbreviations (which OSM discourages), might we propose
boundary=statistical + border_type=census_county_division
and in the future look to re-tag all CDPs as boundary=statistical + border_type=census_designated_place?
That works for me, and while I don’t feel strongly about it (either), his suggestions seem to be on the right track. Un-abbreviate and I think we have a winning strategy to make present use-cases understandable, workable and extendable for future use-cases.
Sounds good to me, I’ll update at least the SD section on the boundary wiki page and start making the updates to CDPs/CCDs as I work on my multi-year “SD Boundary Cleanup Project”.
I’ve been tap-tapping on “other” wiki that mention border_type tagging, but a comprehensive (wiki-wide) search of where updates to South Dakota make sense is likely required so what we’re doing here is more-fully wiki-documented. (Maybe Municipalities, definitely Boundaries).
As we start and continue to “point things to one another” in our wiki using the usual (exhaustive, or at least as much as we can be that) cross-referencing we do, some redundancies will begin to sanely collapse and more-simply point to one another (a link or in a “See also” section). In the meantime, it’s OK to have some redundancy, since if I were searching the wiki and landed on our Municipalities page, for example, I might not find or see exactly what I’m looking for on, say, the Boundaries page.
Inch by inch, step by step, we build a great map. Part of that includes wiki-ing along the way to getting there. In my opinion, we’re doing fine.
Could you add boundary=statistical to the validator when you get a chance? I’ve changed over the relevant boundaries in Fall River County and now the validator is saying the CDPs don’t exist.
I’ve updated my validator with this change to now treat boundary=census and boundary=statistical + border_type=census_designated_place as synonyms. Additionally, I added a flag that reports an error if it finds boundary=statistical with no border_type flag.
Dang: stir gently until it gels. It is my privilege to contribute together with all of you. Nice work, everyone. My attitude of gratitude inner monologue kicked into gear.