Proposed double-entry of Consolidated City-Counties

Yup: Brian, you are largely correct. Starting from a USA perspective, there are 56 second-level things (admin_level=4), and when we get right down to it, each is unique. (Largely because: federal history and the Tenth Amendment). We must deal with that, evidently, not so simply. We seem to have found agreeable tagging (mostly) in New England to reflect local preferences. That does not necessarily influence this dialog about WDC. Then, when you get to the level of 3000+ third-level things (admin_level=6), again, each is unique and we must deal with that. Regularity that people believe exists is mostly an hallucination. Yes, there are similarities, and we use that fact to collapse some complexity.

If I may guess-summarize, I think part of what Minh says is that there may not even be an 8, what we now call Washington. He asserts that is a historical vestige, that may be correct. If so, WDC is (legally speaking) a 2-4-9-10 glom (instead of the 2-4-8-9-10 it is now). I’d still have to think about (and be shown history, legislation…?) how Washington and the District are different things, as I don’t feel like that is fully teased out in my mind.

But yes, can you see how many dozens, hundreds and thousands of conversations (dragons?) there are here?

There may not be CDPs proper “in” the District, but the Census Bureau (CB) calls “this” a “county equivalent.” So, we might disagree there. The CB has all sorts of micro-precision levels of these things and it can be dizzying to clarify the distinctions among these.

If this is the point you’ve been trying to make all along, it could’ve cut out a lot of back and forth, mostly me going back and forth with myself. :sweat_smile:

Eh, we could use border_type=* to distinguish between the various flavors of places designated by the Census Bureau geography program. But I guess we might as well draw a line in the sand and move everything other than CDPs over to boundary=statistical, which is more flexible and less tied to the decennial census.

From my point of view, it’s a minor issue anyways, since we’re talking about different legal contexts with different geographic schemes (D.C. versus Virginia). But boundary=place does avoid these questions more effectively among people who don’t closely read our documentation ahead of time.

1 Like

I sense better tagging with border_type=* and boundary=place are part of some refinements ahead. I like when I hear that (about COGs and counties in Connecticut): “OSM (-US) can tag however OSM (-US) says it is best to tag.”

Fact: in admin_level land (semantics), each “thing” with a hierarchy is unique.

Has OSM seen some vacillation in tagging (with admin_level, heck, even with railway=light_rail) over the last decade? We sure have and it remains fluid. There is sometimes vast understanding and patient back-and-forth required for there to be “many meeting of the minds” as these discussions happen over the years; part of how consensus is forged.

Some sparks and popcorn, OK, but some good dialog, too; thanks. Let’s keep sharpening it up.

If we are being honest with ourselves, @Loren_Maxwell might update both his table in the Talk page of United States / Boundaries as well as in that wiki and the US admin_level wiki that CCCs might be more correctly denoted:

Unique entities often known as Consolidated

And we are keeping track of these in the table. There is the whole topic of wiki-chases-map (data)-chases-wiki-chases-map-chases-wiki-chases-map…but that’s sort of gum that Loren bit off and I hope has some patience to keep chewing. He might begin to blow bubbles himself (hey, here’s a San Francisco solution…Minh helped me out on it and I think it will work…). I’m spitballing again, but we pave road, we make progress. Go and keep going.

And little successes (bubbles blown, one at a time), for example, we come to agreement that name=Washington gets figured out in a 2-4-9-10 stack-of-data, rather than the 2-4-8-9-10 that it is today…well, especially if we agree 'there is no spoon" (um, sorry, “there is no 6”) and have some census data properly tagged because it IS Census data…fantastic!

Super-elastic bubble plastic: our careful tagging / syntax. Consensus: priceless.

1 Like

Because Falls Church is a first-level subdivision within Virginia by the way Virginia has decided to sub-divide itself. It just happens to not be called a “County”, but an “Independent City”, which is a type of first-level sub-division in Virginia. Virginia has a different second-level subdivision, Towns, which are admin_level=8 and distinct from the concept of Independent Cities, although both correlate to scales of government that would probably be conflated, and usually both admin_level=8, in other states, like e.g. California. Each state has peculiarities in how it administers itself and its land, which is OK by me.

Meanwhile, DC doesn’t sub-divide itself at all (or perhaps, the Federal Government doesn’t sub-divide DC, exactly who is in charge is a bit messy), except for electoral districts (called wards) that change after every census to rebalance the populations and are not marked on the ground.

For the record, I also think it’s probably most self-consistent to map Washington as a boundary=place rather than boundary=administrative + admin_level=8, but I’d be easily swayed to the other camp if doing so would break any tools in unexpected ways.

This is precisely my point. After all, the ICs aren’t counties, in fact they’re places not in any county, which is (waves hands frantically) different from the consolidated city-county concept.

So there’s two possible rules:

  1. All first-level subdivisions of a state must be admin_level=6
  2. “scales of government that would probably be conflated” should have the same admin_level.

I don’t think either of these is a hard and fast rule (neither written down or de facto)

Since the ICs are not in any county, it seems like it would be perfectly consistent for a query of Virginia counties (via admin_level=6) return a map of counties with holes where the ICs are. After all, no counties cover those areas. Virginia could have chosen to describe the ICs as counties. They did not – they described them as areas not in any county.

So if rule #1 is the most important, then level 6 it is. If rule #2 is more important, level 8.

It sounds like we are coalescing on Washington being a place boundary, but if it were an administrative boundary, having it at level 8 means we’re applying rule #2.

That’s why I think consolidated-city counties should be tagged both admin_level=6 and admin_level=8, and ICs should just be admin_level=6 :wink: More to the point, “not in any county” is not the same thing as “not a primary administrative division”. Why would things called “county” be the only things allowed to be tagged admin_level=6?

I would certainly describe #1 as de facto, and in the case of Virginia, it is of course written down…in United States admin level - OpenStreetMap Wiki, the very wiki page we’re discussing.

I’d put it this way: an independent city doesn’t lie within any county. In fact, there’s nothing between it and the state. Skipping level 6 would imply that there’s technically something between the state and the independent city, but we choose not to map it for some reason. On the other hand, what exists between the District of Columbia and Washington? The long-gone Washington County?

Why bias toward small numbers? Because some parts of the country are nested unavoidably deeper than others, but every part of the country is under a level 2 boundary relation. There’s nothing special about level 8.

That is precisely why I would leave a hole in between them. If there’s a hole in the county coverage, then it ought to be mapped that way. admin_level isn’t a mere sort key, it’s also an expression of class membership of similar objects. It seems silly for us to say that it’s not in any county but also it’s a county. If we are saying that these are really just consolidated city-counties under a different name, then say that and tag them as such. But I don’t think border_type=county;city is actually correct here.

The only rationale for doing this would be to satisfy one class of data consumer at the expense of others. It also violates a number of principles. First, it’s duplicating features, violating one feature, one element. Second, it would require us to have a county contain a county in two ways – you’d have a named “City and County” inside a county, and you’d have a county within a county in the border_type key. It isn’t our job to neuter the data model to oversimplify complexity because we think it’ll help data consumers.

In summary, I’m opposed to papering over the real complexity of the world. Some of these concepts are fuzzy and that’s why these discussions are hard.

  • If we have one thing that’s both a city and county, tag that one thing as such.
  • If we have one thing that’s a city not in a county, tag that one as such.
  • If we have one thing that’s the only city in its county, then tag those as such.

You’re confusing admin_level=* with border_type=*. The former is about topology; the latter is about class equivalence. Just as Maine’s townships are not cities, the District of Columbia is not a state, and San Francisco is not a county, nothing about admin_level=6 in Virginia has to mean county – that’s what border_type=county is for.

The topology is satisfied as long as the sort order is correct. The Russian nesting dolls still work if you remove one from the middle. They just rattle around a bit more.

And, border_type only conveys similarity of nomenclature in a very narrow scope that breaks once you go beyond a state. Whereas, admin_level conveys a rough level of equivalence at global scope – or at least, this is how many data consumers have chosen to interpret it. I’m not aware of any data consumers that have done much of anything with border_type and I would cite that scope issue as the reason why.

This is only true from a geocoding standpoint. We keep hyperfocusing on the needs of geocoders at the possible expense of renderers. For renderers, skipping a level actually matters.

Yes, border_type=* is harder to consume because its values vary in meaning from region to region. In that regard, the key is very similar to designation=* or the public transit usage of network=*. For road networks, network=* is prefixed with the country and state, which makes the values less ambiguous on their face.

That said, ambiguity isn’t the main reason border_type=* is so unloved. This key was originally popularized by the TIGER boundary import and only gained global legitimacy due to the approved proposal for international maritime borders. The key’s documentation still casts aspersions at the U.S. usage as an illegitimate artifact of the TIGER import, due to its origin, even as the U.S. community has quietly embraced the key over the years.

admin_level=* is not a way to establish equivalences across jurisdictions. To the extent that you can, it is only a coincidence and an approximation. Instead, the more traditional global practice has been to use place=* on the boundary relation as an internationally harmonized signifier of the type of jurisdiction. Nominatim supports this mechanism and its developer has long encouraged mappers to use it. The TIGER import also included this key on boundaries, but with sometimes wildly inaccurate values.

In the U.S., the consensus is not to put place=* on an administrative boundary, or at least not to care about it, because it conflates the concept of a populated place with a legal jurisdiction, and more practically because values such as town and suburb conflict with both legal designations and colloquial terms. We can barely manage the confusion this causes on place=* nodes, where at least a globally harmonized scheme makes logical sense, because these nodes are supposed to be somewhat agnostic to jurisdictional concerns.

Some countries have tried alternative approaches that avoid both the ambiguity of border_type=* and the terminological confusion of place=*. For example, barangays in the Philippines are tagged place:PH=barangay (though some are tagged designation=barangay instead). Unfortunately, the U.S. system of place classifications is such a zoo that we would at least have to namespace values instead of keys:

In other words, admin_level=* is generally optimized for a different use case than what you’re focused on. You want border_type=* or place=* or something along these lines. Nothing about the number 8 inherently means city, any more than the number 24 means an electoral district. Some mappers have latched onto 8 as sort of a “default” local boundary because so many states (correctly) have so many cities and villages at that level, but this thread highlights the folly of that assumption.

2 Likes

For now, let’s stick to smaller sticks and focus on blowing a bubble.

“Washington, District of Columbia” (WDC) in OSM now has a component known as Washington. In reality, this is a vestige of an administrative “level” when it used to be a county (history lesson…). Shortcut to finish line is we tag our national capital a place named Washington.

Long story short, we’ve got it tagged now so there is an 8 with city-ish taggings which shouldn’t have any admin_level value on it as it correctly becomes a place. In a shorthand I’ve been using, WDC 2-4-8-9-10 as we now have has its 8 become nil, as it’s a place; this becomes WDC 2-4-9-10. The boundary=administrative with 8 becomes boundary=place.

Yes? Let’s do that? Minh, I nudge you to the front of the line here, though anybody here is welcome to speak up. It doesn’t matter if you don’t chew this sort of gum, it doesn’t matter if you’ve never blown a bubble.

There might be someone in the Department of State who offers us their answer. I welcome that perspective. Professors of history, political science, Americana, et cetera, welcome. The topic is “Washington: a place?”

I don’t think this “lightning proposal” is off-topic. WDC is already a pickle in our barrel, we might shave an 8 off as a vestige, giving it better semantics in our data. And we go “aww, yeah!” Or, not. Or, that’s a ways away, though we’ll get there. Up to you, too (anybody reading this). And we keep track in the table. That’s how we’ve been doing a lot of this. This Discourse makes such “lightning” interactive (though Wiki Discussion / Talk pages can be fast and frisky, too).

2 Likes

Yes, there appears to be consensus (or at least defeated lack of opposition) to demoting Washington to a place boundary. I concur with the 2-4 portion of Washington, DC replacing the 2-4-8 scheme.

I’d like to leave the 9-10 levels aside from this discussion since it’s not something we discussed in this thread and the question of DC ANCs are probably similar the disagreements over sub-municipal boundaries in Manhattan. I don’t think this thread can be cited as evidence for their inclusion.

2 Likes

There have been a number of us who are nodding our heads…then we got to the end of last week (Friday evening) and this topic went dark. (Intervening OSM crisis notwithstanding). Still, I find @Minh_Nguyen 's input here especially valuable: my call-out to you was indeed a friendly, gentle nudge to offer perspective. We didn’t get any further august, erudite academic or federal executive-branch input, and Minh has scored a number of goals for this team; I value his perspective here.

And “I agree” about the 9-10 levels; we’re not talking about touching them now, just including them in the whole hierarchy-stack as a talking point. No 9-10 changes for now.

Edit: So, yeah, the train is leaving the station. WDC goes from 2-4-8 now to 2-4 where 4 is the District and Washington goes from boundary=administrative + admin_level=8 to boundary=place and place=city. All aboard!

Done in OSM; the Boundaries Discussion/Talk wiki table is updated.

There are still, ahem, “several ahead” in our table of forty-something.

If I had to suggest an order, I’d say on-deck is San Francisco here or in that wiki. Indianapolis is being discussed elsewhere in this Discourse forum and Colorado and Alaska might follow. No need to rush, good to see progress, however glacial it may be!

Steady ahead, ladies and gentlemen.

If I’m not mistaken, @Loren_Maxwell already took care of San Francisco last week. I followed up with corresponding changes to San Francisco and San Francisco County in OpenHistoricalMap, since the Atlas of Historical County Boundaries that we imported there had an even greater bias toward making everything a county.

1 Like

I (and I believe we!) thank you, Minh. I thought Loren was updating the table, and/or I wasn’t tracking it correctly.

I’ve updated rows for WDC and SF using wiki {{yes|*}} syntax to “make 'em green” in the table.

Please, any or all of us (Loren?!) are welcome (encouraged!) to update the table. It’s good when consensus tracks both the wiki and the map. This has been a little messy, but sometimes this project’s consensus methodologies can be. Thanks, everyone…40-something to go! (Again, no rush. A clap on the back to everyone here).

Yup – I’m still here but just put this discussion on pause for myself while I massage a few other areas of my own website to adjust for how I was approaching this before.


Currently San Francisco, Denver, Broomfield, and Nantucket (the four single-entity CCCs in the contiguous US) show border_type=county;city (and border_type=county;town) in OSM.

Using San Francisco as a template, I’ve also ensured Wikidata reflected the following for Broomfield, Denver, and Nantucket*:

  • Relation with state:
    California contains San Francisco
    – California contains San Francisco County with a deprecated rank
    – San Francisco is located in California
    – San Francisco County is located in California
  • Relation with single-entity county and city:
    – San Francisco is located in San Francisco County with a deprecated rank
    – San Francisco County contains San Francisco
    – San Francisco coextensive with San Francisco County
    – San Francisco County coextensive with San Francisco
    – San Francisco said to be the same as San Francisco County
    – San Francisco County said to be the same as San Francisco

The naive user might still be confused, but hopefully that leaves enough breadcrumbs for them to follow to make sense of the situation before changing any of the values. The Wikipedia article could also be polished a little to better reflect these “single-entity” CCCs as well.

I think the above needs to be outlined in the OSM wiki, although I recognize it’s a little bit out of scope. However, it would greatly reduce the confusion for my humble constituents – the naive users.

What I thought was still being discussed for these four single-entity CCCs is whether they are admin_level=6 or admin_level=8, but perhaps I misunderstood.

My vote, given how it’s currently presented in Wikidata and our discussion here, is that admin_level=6 be used, the same of the ICs, which I think should stay admin_level=6 as well.

A naive user coming from Wikidata would have just seen San Francisco listed directly under California and then in OSM see either admin_level=6 and have that impression confirmed or admin_level=8 and be confused.

*= In Wikidata, there’s a lot of conflation between Nantucket the island and Nantucket the CCC, which is made more confusing by the single-entity CCC status of Nantucket. I’ll eventually try to straighten that out.

If I can get clarification on the admin_level for these four then I’ll confirm or update those in OSM and update those in wiki table as being done and start on some verbiage in the wiki to explain those.


Next
I think following that we should shoot for some easy wins :smile: :

  • The “double-entity” CCCs: probably straightforward and I assume we’ll confirm what’s existent in OSM right now, which are separate county and city entities in OSM and tagged as such
  • The independent cities: again, probably straightforward with the admin_level following whatever we decide on the single-entity CCCs
  • The Alaska “City and Borough of XXX” single-entity CCCs: again, probably easy since I expect they’ll mirror the above single-entity decision, but I’d just need to take time to confirm/update everything

Washington DC
Although Washington DC was slightly out of scope for the CCC thread, I would personally vote for it to be admin_level=6 so that the entire US (at least the 50 states and DC) would be covered in a blanket of admin_level=4 and admin_level=6, but I don’t see anyone else advocating for that or saying anything along the lines as an “admin_level blanket”.

Alaska
On a slight tangent, I think we should have a separate discussion about the Unorganized Borough and the census areas it contains. Currently they’re all admin_level=6, which gives a bunch of admin_level=6 areas within an admin_level=6. I was thinking that was a foul, but perhaps not.

It seemed like there was a growing consensus to kick Washington out of the hierarchy entirely by retagging it as boundary=place. There is still an administrative City of Washington, but it isn’t mapped and wouldn’t be coextensive with the District of Columbia anyways. This would leave a gap in admin_level=6 coverage, but if you’re making a map of just the counties of the U.S. using admin_level=6 instead of border_type=county, then a hole in D.C. wouldn’t be terribly surprising, given other holes in Maine and Alaska.