Brian is correct with “we don’t always assign 6 and 8 to the CCCs” (Denver given as an example, San Francisco near me as another): the latter city-county has a border_type=city;county tag, but it is only tagged admin_level=6, not admin_level=6 + admin_level=8.
A little bit of “runniness” with our exact paint, but we can tell what it is.
Unless someone can come up with a counter-example, I don’t believe we have ever assigned two boundary relations to CCCs. That’s why I find the NYC borough case so curious.
Around 2019-20 (IIRC) I was involved in a bit of tagging vacillation with SF having coterminous 6 and 8 boundaries. Eventually, I left it alone with a single 6 boundary given I had noticed the border_type=city;county tag. (As I nodded my head).
We paint, we touch-up, we wait for things to dry, we discuss, we touch-up, we wiki-document…
Contrary to the Census Bureau, there isn’t actually a general universal class of “consolidated city–county”; it’s just a description of many consolidations, each unique as a snowflake. The City and County of San Francisco is literally one entity, functioning as both a city and a county simultaneously.
The dual nature has caused some back and forth between mappers who want OSM to have a full set of counties and a full set of cities, and those who want to represent the city as it is. Each of these relations has been deleted at some point:
(In the midst of all that, San Francisco briefly became a speed limit.)
East Baton Rouge Parish and Baton Rouge form a consolidated city–parish government, but they remain two distinct entities. You can enter East Baton Rouge Parish without entering Baton Rouge proper:
Conversely, New Orleans is coterminous with Orleans Parish. The parish no longer has a government, but any list of parishes will include it rather than “New Orleans”, and its boundary is prominently marked on the road:
In order to maintain uniform, stable statistics, the Census Bureau conflates all these concepts together, erasing the nuances between them, and even creates geographies out of whole cloth for portions of interest to demographers. But these geographies have less relevance to the typical map user than even a New York community district. This is a risk I had to be mindful of recently when devising a place classification system that relies on census geographies. There too, the task was to determine why the bureau makes a certain call, not to just accept it at face value.
This week, Google Maps made the mistake of putting too much faith in uniformity. Among other things, they went so far as to replace some of the largest U.S. cities with their balances, the Census Bureau’s catch-all for the portion of the consolidated city–county that doesn’t have another city nested within it:
Anyone who demands semantic precision in this line of business is badly overestimating the competition.
While we discuss, please (continue to) use the right mix of modern-OSM key=value tags: not too many, not too few. Getting this mix “right” can take time and/or consensus, like we forge here. Use tags OSM already defines (like suburb, which is an OSM-specific thing that is meant, but if it is how things are done there, use it). If a new tag needs to be coined, it can be (and they have been), but for something this global, a rich, true agreement seems difficult to capture (single tags at a time). Here, we’d be describing a starts-out je ne sais quoi about a place and purport to be inventing a key: for something which isn’t the same thing somewhere else. If this were easy, maybe we’d have done better by now?
We shouldn’t conflate place=* and other tags where assumptions might be made; place=* is a tag that says “something” but likely not “everything” you need to display “someplace” as you like. We must be smarter than this, either in our data, our renderers or both. What this means for any renderer (vital, can’t be subtracted from this equation) is that MANY tags must be interpreted to “display pleasingly” (a very subjective task). Every bit of that and more is going on at all times with this discussion.
Beware exponential growth of need-to-be-solved “local problems” while doing this. It’s not unsolvable, but it is big. Downstream users of our data (renderers) must parse many tags. Perhaps we scale our efforts smartly and accordingly, I don’t yet know. Tags can chase rendered tiles, though these data (like town, suburb, remote rural areas, CDPs related to place…) apparently haven’t (fully) chased each other down (yet). To everyone’s liking. It’s a tall order.
Our data are a good sketch. We’re somewhere between doing our best (?) at describing “what is” (with locally-patchy “these tags make things look better” thrown in) and speculating how we might like to sprinkle some syntactic sugar into our tagging that might goose along prettier rendering that a wider, even global audience can nod our heads about. And/or renderers include smarter rules that examine many tags like “display hamlet at village fontsize if there is a business or commercial zone.” Tall.
