At the beginning of the book or the end? 
1 Like
This is helpful.
I also remember this rule of thumb about consensus in a class I once took – consensus isn’t necessarily a solution with unanimous agreement, but a solution everyone can live with.
This is not true actually. I think I said this upthread and it’s incorrect. I learned recently while editing CDPs in Virginia that it has:
- Independent cities (
admin_level=6) - Cities/towns within counties (
admin_level=8)
Here’s an example of a town contained within a county:
By our logic, to be consistent, we should probably tag the Virginia ICs at admin_level=8 and simply have them not contained within any county. Then a query of all admin_level=8 would return all the incorporated cities and town in Virginia, regardless of their IC status.
This isn’t exactly right. Virginia only has Towns within counties. Cities are not administratively synonymous with Towns in Virginia, although they are in other states like California. No City in Virginia is within a County, only Towns are. For example, Irvington, which you posted, is a Town (admin_level=8 + border_type=town) within Lancaster County. Meanwhile Fredericksburg is a(n Independent) City (admin_level=6 + border_type=city) not within any County. Which is what I said above:
So I’m fairly sure that this statement is correct:
Now to clarify (or maybe add to the confusion?), these administrative types only have loose correlations to OSM place=* values. Many Cities (border_type=city) are place=city, but some aren’t, and some place=city in Virginia do not correspond to a City but to a Town, or even a census-designated place, within a County.
Ah OK thanks for the clarification.
Still to this point, in pretty much every other state that has both cities and towns, both are at the same admin_level value. Virginia is an outlier in this regard only because the cities are not contained in a county.
So if we are (roughly) agreed there are two types of CCCs, one a single city-county entity and the other a merger of distinct city and county entities, what could be improved on this draft explaining the difference on the Wikipedia CCC page of what we’re discussing here?
I would think of particular importance would be highlighting why a single entity CCC is not an IC.
Inputs welcomed along with any references that could be included.
Consolidated at their creation: Consolidated city-counties consolidated at their creation are single entities encompassing both a city and a nominal county. Although considered a single entity, they are distinct from an independent city, which exists without a nominal county.
- Alaska:
- Municipality of Anchorage: existing verbiage …
- City and Borough of Juneau: …
- City and Borough of Sitka: …
- Municipality and Borough of Skagway: …
- City and Borough of Wrangell: …
- City and Borough of Yakutat: …
- California
- City and County of San Francisco: …
- Colorado
- City and County of Broomfield: …
- City and County of Denver: …
- Massachusetts
- Town and County of Nantucket: …
Merged: Consolidated city-counties that have merged previously existing city and county functions two separate entities, both a city and a county, although the government functions have been consolidated.
- All the rest with the existing verbiage, perhaps better organized by state.
Assuming we leave San Francisco as one boundary, there are a couple changes we could make to the tags, supported by ample documentation.
Hardly any mainstream data consumer actually uses border_type=* with any strictness, since the jurisdictional terms are such a zoo. We can simply tack on ;county. That alone would make it easier to find the conflated features.
Putting a semicolon in admin_level=* is dicier, because both geocoders and renderers rely pretty heavily on that key. As I mentioned, some mappers used to set this key to a semicolon-delimited list on a boundary way that happens to be shared among multiple relations of different administrative levels, such as a admin_level=2;6;8 for a state line that happens to also be a county line and city limits. However, this is considered an error by some validators and was never as common as I thought it was. I don’t know if this approach would be durable or if it would cause problems for any data consumers making the same assumption. It has always been more common to simply set the key to the maximum applicable number.
Whatever the case, I’d imagine we’d need a full complement of tags to elucidate the situation for anyone looking at the individual relation manually: alt_name=* for the county name, note=*, perhaps something like consolidated=city;county or disused:admin_level=8…
The last sentence could be a bit confusing in the context of this discussion. “Nominal” here refers to whether a county can be conceived of, even if it’s nominal in the sense of not being real enough for a separate boundary. 
I’m actually surprised no state legislature has decided to foist upon us a city and a legally distinct county, simultaneously out of whole cloth. That does happen at a more local level in some states between cities and townships. It might be worth scrutinizing the Wikipedia list some more, adding sources, before arriving at a fixed list based on that article.
Any suggestions to clarify it?
The term “nominal” was used because it’s used elsewhere in the CCC article.
Maybe that sentence isn’t even needed . . .
There are several explanations concerning the difference between CCCs and ICs in the article already.
Consolidated at creation : Consolidated city-counties consolidated at creation are single entities encompassing both a city and a county.
1 Like
Sorry, I still don’t really follow this distinction. What distinguishes the cases of San Francisco, New Orleans, and Washington DC in “consolidated” vs “merged”? Is it literally the names? Or the histories?
From my perspective, it’s the names. What we’re mapping is the names of territory. The history is really just exploring the rationale of why separate versus consolidated territory came to be named.
Also, when it comes down to it, boundaries are just about the most “official” thing we can be mapping. If the California Supreme Court, hearing an appeal from the Superior Court of San Francisco County, says San Francisco County is not really a thing, that seems pretty definitive, no? If this ever was a disputed boundary, Kahn v. Sutro (1886) and subsequent cases should’ve settled that dispute officially. Our best reason to second-guess such findings would be evidence on the ground that a boundary still exists de facto. All we have instead is that the boundary still exists de facto on paper.
Meanwhile, proponents of D.C. statehood would be thrilled to hear that the district has been abolished. (I used to work for a company based out of D.C. Consolidation seems to haunt me wherever I go…)
In fairness, if I were coming up with terminology for these phenomena, “consolidated” versus “merged” wouldn’t be my preferred naming scheme. They’re practically synonyms. I’d rather describe it as the difference between consolidation into a single jurisdiction per se versus consolidating only the territory and/or government authority.
1 Like
“Created as a consolidated city-county” and “Merged into a consolidated city-county”?
More specifically:
Created as consolidated city-county: the consolidated city-counties below were created as a single entity encompassing both a city and a county.
Merged into consolidated city-county: the consolidated city-counties below resulted as the merger of an existing city and county.
Something like that?
Fluid.
Fluid.
Below is just the result of a thought exercise for a possible Wikidata tag schema using the concept of “single entity” and “dual entity” CCCs.
As I’m developing this, I don’t become more or less convinced this is the correct path, but here I try …
The goal:
Using the tags below, the naive user should be able to do a simple SPARQL query to return the correct list of counties and cities for each state, accepting that Denver County will show up as a county.
We’ve discussed the naive user at length, but here I introduce the sophisticated user – someone who should be able to easily use the tags to
- remove the redundant county portion of a single entity CCC (i.e., remove Denver County) and
- show that city falling directly under the state
I might need help developing the sophisticated user query. (@Minh_Nguyen?)
Single entity CCCs:
County
Example: Denver County (Q15906757)
Description: county of Colorado “coexistent”? with City and County of Denver, Colorado
Statements:
instance of:
county of Colorado
located in the administrative territorial entity:
Colorado
coextensive with / said to be the same as: both tags required
Denver
City
Example: Denver (Q16554)
instance of:
consolidated city-county consolidated city-county tag goes with city
city in the United States
located in the administrative territorial entity: currently shows state
Denver County
coextensive with / said to be the same as: both tags required
Denver County
Dual entity CCCs:
County
Example: Orleans Parish (Q486231)
Description:
parish of Louisiana that forms a consolidated city–parish with New Orleans
Statements:
instance of:
consolidated city–county
parish of Louisiana
located in the administrative territorial entity:
Louisiana
coextensive with: if required
New Orleans
City
Example: New Orleans (Q34404)
Statements:
instance of:
consolidated city-county consolidated city-county tag goes with city
city in the United States
located in the administrative territorial entity:
Orleans Parish
coextensive with: if required
Orleans Parish
Thoughts – this is almost exactly what is in Wikidata currently with the two exceptions of
- the description for the single entity county CCC as “coexistent” with the city (certainly might be a better word or phrase available)
- the city in the single entity CCC falls back under the partner county rather than directly under the state
The description is not substantive, so the only real change would be to put the city back under the county for Denver and then standardize the CCCs in Wikidata.
It would have the effect of a simple SPARQL query for counties returning Denver County, San Francisco County, etc., but again – I’d argue the naive user accepts that situation without complaint.
Meanwhile the sophisticated user, using the “said to be same as” tag, can modify the SPARQL to remove the county and show the city in a list of counties.
Thoughts?
Does the wiki table (on the Talk page) reflect “the present?”
I believe so, although not all the Wikidata tags from this exercise are present on the table.
1 Like
The phrasing I’ve used in the past is “county of Colorado that forms a consolidated city-county with Denver”. This description probably wouldn’t stand up to legal scrutiny, but the purpose of the description is really to disambiguate the item from similarly named items.
I’d probably quibble with this for the same reason that I did about OSM. In general, it seems awkward to say that A is both in and the same as B; in other words, A is located inside itself. Circular statements like this will result in duplicate results in any SPARQL query that doesn’t add potentially expensive DISTINCT keywords.
Whether the naïve user accepts a result really depends on their preconceptions. The West’s undifferentiated county territory without a name easily breaks the mental model of a New Englander or Midwesterner. Someone who lives on the coasts will never think to insert the Midwest’s townships between its counties and cities. (The same sites that get San Francisco wrong tend to omit this important detail about the Midwest too. Incidentally, this is also how the townships got omitted from the TIGER import.)
Ultimately, there are different ways at looking at it. We could split the difference and put Denver in both Colorado and Denver County at the same time. For better or worse, multiple located in the administrative territorial entity (P131) statements on the same item are a fact of life, since Wikidata’s purpose is to record what other sources claim, even when they differ on the details. To make the multiple statements look more intentional, either statement could be qualified by criterion used (P1013) or nature of statement (P5102). Even so, I would vouch for Colorado as the preferred statement, to avoid the redundant paths that require the addition of DISTINCT. This is the kind of flexibility I love about Wikidata’s data model – there’s no analogue to it in OSM’s data model.