Convention for tagging independent cities, consolidated city-counties, and notable exceptions

Communities United States
1

There are 82 US cities that warrant special consideration for tagging. While most follow some sort of sensible tagging there is a degree of inconsistency that can cause confusion and difficulty querying.

I’m trying to get a consensus as to how they should be tagged and clean those up.

The outcome of this discussion will be captured on the United_States/Boundaries and United States admin level pages so future mappers will know the convention.

Independent cities (ICs)

  • Definition
    An independent city is “a city that is not in the territory of any county or counties and is considered a primary administrative division of its state”.
    In other words, there is no intervening county between the state and the city as with every other city in the US (except for the notable exceptions below).

  • Scope
    There are 41 ICs in the US: 38 in Virginia plus Baltimore, Maryland; Carson City, Nevada; and St. Louis, Missouri.

  • Proposal
    An IC should be tagged admin_level=6, place=city.
    An alternative proposal would be admin_level=6, border_type=city.
    Additionally the following note should be added to each IC:

This is an independent city. Independent cities in the US are considered a primary administrative division of its state and should be tagged admin_level=6 (not 8) and place=city (not county).

  • Overpass query
    The following Overpass should (and currently does) return the exhaustive list of independent cities:
[out:json];
area[wikidata=Q30]->.usa; // Q30 = United States
relation[admin_level=6][place=city](area.usa);
out tags;
  • To do if accepted:
    The admin_level and place tagging is done, although the note for each IC would need to be updated to the verbiage above (I can do).
    The United_States/Boundaries would need to be updated (I can do).
    The United States admin level is done.

Consolidated city-counties (CCCs)

  • Definition
    A consolidated city-county “is formed when one or more cities and their surrounding county (parish in Louisiana, borough in Alaska) merge into one unified jurisdiction . . . A consolidated city-county differs from an independent city in that the city and county both nominally exist, although they have a consolidated government, whereas in an independent city, the county does not even nominally exist.”
    In other words, the county and city are two separate entities even if merged into a single consolidated jurisdiction for governance. Additionally, although the Wikipedia article does not state this, the city and the county boundaries for consolidated city-counties may or may not be coextensive, and there are plenty of examples of each.

  • Scope
    There are 39 consolidated city-counties in the US with a 1:1 city-county pairing. The notable exception (see below) is New York City, which is an agglomeration of five counties. Of the 39 1:1 pairing CCCs, all are tagged as normal counties and cities with the exception of six that are in Alaska (see current status under Talk:United_States/Boundaries).

  • Proposal: Both the county and city for all CCCs should be present in OSM, even if they are coextensive. The county should be tagged admin_level=6, place=county and the city should be tagged admin_level=8, place=city.
    If it is important to regularly get a list of counties or cities in CCC relationships, then an additional proposal would be add a value of “city_county” as the border_type for these entries or enter “city;county” as the border_type.
    I do not personally need this for my application, but it would make it easier to verify the entries for CCCs are correct.
    Additionally the following note should be added to each CCC:

This is a member of a consolidated city-county (CCC). Counties in CCCs should be tagged admin_level=6 and place=county. City in CCCs should be tagged admin_level=8 and place=city.

  • Overpass query: With the basic proposed tagging there would be no special Overpass query to specifically return counties or cities in CCC relationships, although if needed the following query would work using the note tag as long as the note is not further altered:
// Returns the counties
[out:json];
area[wikidata=Q30]->.usa; // Q30 = United States
relation[admin_level=6][note~"^This is a member of a consolidated city-county"](area.usa);
out tags;

// Returns the cities
[out:json];
area[wikidata=Q30]->.usa; // Q30 = United States
relation[admin_level=8][note~"^This is a member of a consolidated city-county"](area.usa);
out tags;

// Returns the counties and cities
[out:json];
area[wikidata=Q30]->.usa; // Q30 = United States
relation[note~"^This is a member of a consolidated city-county"](area.usa);
out tags;

If this list is needed on a regular basis, then the border_type value of “city_county” or “city;county” should be adopted and the Overpass could be adjusted to use the border_type tag instead of the note tag.

  • To do if accepted: If the consensus here is to accept the tagging I’ve proposed then the six areas in Alaska need to be fixed (I think I would need help). Also the CCC members need to have the note added (I can do).

Notable exceptions

The two notable exceptions for US cities are Washington, D.C., and New York City. There is already sufficient guidance for how to tag each at the United_States/Boundaries and United States admin level pages and the proposals here for ICs and CCCs do not affect them.

Thanks for reading this far and looking forward to the discussion!

Loren

2

As a start, it would be helpful for you to describe:

  1. The exact problem you’re hoping to solve; and
  2. What you are proposing to change compared to what has already been tagged prior to recent edits.

I operate a data consumer of city-level boundaries, so this is something of high interest to me. As you might expect, I live in exceptions, and I will say that there is no possible scheme that is optimal in assigning admin_level values. I will note that you already took it upon yourself to add the suggested note to Virginia ICs.

What you are describing below is already the case for Virginia’s ICs:

This thought process leads down a somewhat unproductive path, but here goes:

What is the difference between an Independent City and a Consolidated City-County (CCC)?

It seems to me that the only difference is nomenclature. In both cases, these entities perform the functions of both a city and a county in their respective locales. The only exception is Honolulu, which is named as a CCC, but is in all respects exactly identical to all other counties in Hawaii, since there are no municipal governments or divisions – only county governments.

Setting aside the Hawaii case, you have five basic approaches for the remaining CCCs and ICs:

  1. Give them all county tagging only (admin_level=6).
    a. Good for: data consumers that require space-filling subdivisions of a state without gaps and data consumers that walk the hierarchical tree of subdivisions from state down to city.
    b. Bad for: data consumers that require municipal-level subdivisions of a state
  2. Give them all municipal tagging only (admin_level=8).
    a. Good for: data consumers that require municipal-level subdivisions of a state and data consumers that walk the hierarchical tree of subdivisions from state down to city. It’s conceptually-logical for ICs - they are cities which are not in county, so they shouldn’t come up on the county list in queries.
    b. Bad for: data consumers that require space-filling subdivisions of a state without gaps
  3. Duplicate the boundaries, so you have BOTH admin_level=6 and admin_level=8
    a. Good for: both data consumers that require space-filling subdivisions and municipal-level subdivisions.
    b. Bad for: data consumers that walk the hierarchical tree, who now have to filter out the duplicates. This also violates the OSM principal of one feature, one element.
  4. Set admin_level=6;8
    a. Good for: Tagging absolutists that want the most accurate tagging to define the situation, since these boundaries are both cities and counties simultaneously. Also workable for both space-filling, municipal-only, and tree-walking use cases, with software changes.
    b. Bad for: Every single data consumer, including the standard tile layer on OSM.org, which expects only a single number to be in the admin_level tag. All of these data consumers will break immediately.
  5. Some other tag to hold the second admin_level value, such as alt:admin_level=8. I’ll leave this as an exercise to the reader as to who this is good or bad for.

Anyways, the longer point here is that every scheme produces unexpected results for a naive data consumer. Each scheme is easier for some data consumers and harder for others.

Frankly, everyone that writes software to consume boundary data has to keep all these lists of exceptions in order to make their software work as expected, and few of them are paying attention to this forum. So my preference is inertia. Introducing a change is going to break someone’s software, somewhere, so please come up with an airtight rationale about what problem you’re trying to solve before mucking about with changes.

We’ve all, on the whole, learned to deal with the admin_level schemes in the map as documented. I have much gratitude to @stevea and the other wiki gardeners that have painstakingly documented this over the years and patiently worked through all the debates that ended with the current set of compromises that we’ve landed on.

1 Like
3

Thanks, Brian – I appreciate your concerns and your thoughts.

I’m not sure how to say this initial part, but I’m shocked to be asked to provide “airtight rationale” to justify the standardization of data as superior to no standardization of data. I can understand debating what the standard should be, but it seems obvious that one should exist.

Anyway, I’m going to be a data consumer as well (I’m developing a site that collects high school sports results by state, county, and city), which is why having a known convention seems far more attractive to me than having no convention (the current the inertia approach).

Surely there will be other new data consumers in the future who will be trying to make sense of the data (as I was) and at some point other ICs and CCCs that will pop up that will need to be coded somehow, and it would seem far more preferable (even obvious) to not only have similar entities tagged in a predictable way but to also have a convention as to how new entities should be tagged going forward.

But the guidance for CCCs at the moment (taken directly from the United States admin level page) is “currently there is no convention”.

Because there is no convention, I changed tags as I saw fit, admittedly without any thought or even awareness as to how it might affect you, a fellow data consumer, or any other data consumer.

That’s the last thing I would intend to do and certainly the last thing I want done to me, but having no convention did nothing to help me (or others in the future) be aware of changes could affect anyone else.

In short, my airtight rationale for proposing a convention would be to avoid the very situation we’re all concerned with, which is anyone “mucking about with changes” based on what makes sense to them or their specific needs without knowing how the rest of us are consuming the same data and how they can know what we’ll do.

Fortunately, the inertia approach had already resulted in pretty much the tagging that I’m proposing.

Aside from Alaska, 27 of the 31 CCCs were tagged in the way I’ve proposed and I have adjusted the other four to match. And (going from memory here) all 41 of the ICs were tagged as I proposed, so it seems the disruption would be minimal for current data consumers.

I guess I’m open to others opposing a convention as well and preferring no known standard for how ICs and CCCs should be coded, and if that’s the consensus then so be it, but I think that unfortunately frees us all up to code it however we please without regard to how it will affect others. But hopefully the need for some convention, what it may be, can at least be agreed upon and then we can turn our focus on what that conventions should be.

One other item I’d like to touch on is the one feature, one element potion. I agree with that and do not think coding the county and city separate run afoul of that. Counties and cities as members of CCCs are separate entities, even if their boundaries are coextensive, which not all are (see Cusetta, Georgia, and Chattahoochee County, Georgia).

If I’m looking for all counties in California, I will miss San Francisco County if it is not separated from the city of San Francisco. If I’m looking for cities in California, I will miss San Francisco if it is not separated from San Francisco County. That their governing bodies are or are not consolidated or their boundaries are or are not coextensive are incidental.

4

Beyond the exactitudes of how to tag consolidated city-counties, which I agree would be good to come to consensus on, I disagree with two philosophical aspects of your proposal. The first is that you appear to be suggesting the use of place=* tags on administrative borders to say something about the style of administration. This is a fraught endeavor, as place=* tagging is an importance hierarchy of populated places which does not always correspond well to administrative hierarchies. In fact, my understanding was that in current practice place=* is essentially meaningless on a boundary. Aligning with this, I note that the admin level wiki page contained essentially no mention of place=* tags until your recent edits a couple of days ago. I would strongly favor an approach that uses border_type for this.

The second is that you appear to be mandating a value of note=* for certain feature types. This does not seem like a very stable approach, since note=* is basically a catch-all freeform tag. It would be much better to use an exact tag if you mean something exact, again like border_type.

2 Likes
5

Can you describe in a bit more detail what you changed on the other four, and how they were tagged before? Or at least post the changes here?

1 Like
6

Thanks, willkmiss – I see what you’re saying about the place tag and border_type might be the better tag to use.

And I understand the point about the note.

I’m not married to either of those approaches.

As far as the changes, I’ll have to look up the specific change sets, which I’m not able to do at the moment, but essentially for San Francisco County and Nantucket County I reverted deletes that were done three years ago. For Broomfield County and Denver County I couldn’t revert the deletes so I duplicated Denver and Broomfield and moved some of the tagging between the city and the country entities to match what other CCCs have, which is just what other counties and cities have without regard to their CCC status.

1 Like
7

This is a fraught endeavor, as place=* tagging is an importance hierarchy of populated places which does not always correspond well to administrative hierarchies.

Just to provide some concrete examples of the problems/inconsistencies that can ensue by conflating place and border_type:

  • Some administrative cities don’t correspond to any place=city. An example is the Independent City of Manassas Park, Virginia: the node has place=town, and the relation has place=city + border_type=city + admin_level=6. IMO the place=city tag on the boundary is not necessary and probably should be discouraged, border_type=city is sufficient.
  • Some place=city don’t correspond to any administrative boundary. A classic example is Bethesda, Maryland, where the node is place=city, but the area is unincorporated. The only boundary it corresponds to is a Census Designated Place (CDP), which is not administrative. It appears you recently added border_type=town and place=town to the relation, which both strike me as incorrect: it should just be boundary=census. Although, in your defense, the place=locality tag it had before was probably also wrong. This issue gets a little off-topic from your post, but just goes to show it gets messy out there in the wilderness of US administrative boundaries.
2 Likes
8

Just want to point out that place=* not necessary need to have same geometry of the boundary. So it’s not a good fit to describe an admin_level and border_type seems to me a better fit describing a boundary.

1 Like
9

Thanks @willkmis and @aighes – I see the examples and read up on those tags and it all makes sense about border_type=* vs place=*.

I was thinking place=* since Nominatim uses admin_level=* and place=* but not border_type=*, but your explanations make sense.

I also appreciate your guys’ willingness here and Stevea’s willingness on the wiki talk page to explain the tagging and encourage my efforts to contribute to OSM, even if it appears I’ve made some initial missteps. I’m admittedly new and inexperienced with OSM, but I’m also plenty enthusiastic about learning and contributing.

And I also appreciate @ZeLonewolf for somewhat taking me to task about not coordinating on some of the changes I’ve made :slightly_smiling_face:

I was following the Wikipedia mantra of “Be bold” but I had no idea there was a robust community policing the data in that way. However I’m glad to know I can post here for guidance and be corralled back in bounds when needed!

Ok, back to CCCs – it should be border_type=* instead of place=* and place=* isn’t really appropriate for boundaries anyway.

I’m looking forward to more thoughts and how this resolves :slightly_smiling_face:

10

First off, I appreciate you coming here to join the discussion. This is not the first time someone has come along wanting to build something off OSM data, found it to be more complex than expected, and then tried to do “cleanup” and then encountered friction when it broke things. This actually happens a lot, and I appreciate the enthusiasm.

I’ve just finished reverting the recent changes Canada’s province place nodes, which it turns out was the cause of their labels disappearing from OpenMapTiles last night! (slack discussion link)

image

Anyways, I point this out because there’s a handful of tagging areas (boundaries, place nodes, highway classifications, etc.) that are the way they are because of 15+ years of negotiated settlements on how to tag the complexities of the world. This was one of them. If something seems weird, there’s a really good chance that there’s a reason for it and software will break if you change it.

I would also like you to be aware of the osm-revert tool:

With that, you can drop changeset IDs into it, and it will do a forcible revert. It’s quite good at it.

I see that you’ve already begun to duplicate city boundaries, most notably Denver.

Please revert these changes. There is no consensus for duplicating city boundaries for consolidated boundaries.

Further, from the description you posed:

Added Denver County, which is coextensive with the city of Denver but is a separate entitiy

…I’m not sure this is true. It appears that you got this phrase from this wikidata item which originated as an import from Dutch wikipedia. City and County of Denver is a single entity performs the functions of both a city and a county in Colorado. It’s one feature, and by OSM conventions gets one element. If we are going to form a new consensus on duplicating CCCs, then that needs to be done in the absence of a unilateral edit.

I would rather have a single feature which has some kind of CCC tagging, possibly in border_type. Data consumers should have the option to expand a CCC to represent both levels of the hierarchy OR treat it like a single layer in the cake. Duplicating the boundary takes this away from a data consumer.

Lastly, the problem you are trying to solve (hierarchical display of geographic data) does not require any of these changes. The screenshot below is from my site, where I do more or less the kind of processing you’re describing. Cities, grouped into counties, grouped into states. All of the hierarchy information comes from the wikidata “located in the administrative territorial entity” key.

image

I also agree with the comments above about removing the note tagging.

11

Thanks, Brian – I apologize for the for the disruption on the OpenMapTiles and I (along with many others I’m sure) appreciate you quickly reverting those changes to get that service operating as it should!

I know it’s a separate subject, but it might be of interest to note that I didn’t change Nova Scotia from border_type=state to border_type=province because it already had the value of province: Relation: ‪Nova Scotia‬ (‪390558‬) | OpenStreetMap

Thinking that Nova Scotia was correct (with “province”) and the other Canadian provinces were wrong with “state” led me to “correct” the others, causing the OpenMapTiles issues.

I’m curious as to if Nova Scotia does or doesn’t show up on OpenMapTiles.

At any rate, I’m sure it’s a good example of the frustration that occurs on your end when a (well-meaning :innocent: although not necessarily harmless :upside_down_face:…) new member changes something without the awareness of how it impacts anything beyond what they’re working on!

But I’ll keep this OpenMapTiles example in mind going forward and be more mindful that I’m working in a broader ecosystem.

Ok, I reverted most of the changesets I did from the last 24 hours, which is namely “reverting the revert” of the deletion of San Francisco County and Nantucket County from three-ish years ago and reverting my addition of Denver County and Broomfield County, Colorado.

For reference here are the four relations:
San Francisco County: Relation: 396487 | OpenStreetMap
Nantucket County: Relation: 2387088 | OpenStreetMap
Denver County: Relation: 18351788 | OpenStreetMap
Broomfield County: Relation: 18351840 | OpenStreetMap

Not to get too confusing, but of note is that Denver County and Broomfield County had also existed in the database at one point, but were deleted (or rather their county portion (admin_level=6) renamed to the city and the city portion (admin_level=8) deleted) several years ago and the OSM revert tool could not revert those, so I created them.

See version 65 where the admin_level=6 was turned into Denver from Denver County: Relation: ‪Denver‬ (‪1411339‬) | OpenStreetMap
Previous Denver entry that was deleted: Relation: 253750 | OpenStreetMap

See version 18 where the admin_level=6 was turned into Broomfield from Broomfield County: Relation: ‪Broomfield‬ (‪1411321‬) | OpenStreetMap
Previous Broomfield entry that was deleted: Way: 33153017 | OpenStreetMap

Point being, the county and city portions of those CCCs were on OSM at one point, just the same as the other 27 are currently.

Further, I can’t find any discussion at either community.openstreetmap.org or help.openstreetmap.org about deleting them, so I’m not sure what, if any, community consensus those deletions had.

Concerning the Wikidata solution – I’m aware of and was initially using property P131, “located in the administrative territorial entity”, but found it at times to be almost as inconsistent as well, which led me to the solution I currently have, which is to download the geojson from Nominatim and calculate it myself using the spatial features in MySQL.

This has worked relatively well – as long as I can get the geojson data for those four CCC counties on OSM! :grin:

Ok, just to sum up where I think this discussion stands after a day:

ICs
It seems the only feedback so far is that border_type=city is the proper tag to use over place=city.

CCCs
Aside from the same feedback the border_type=* vs place=*, the main point of contention seems to be whether the county and city should be listed separately.

Aside from Alaska, having them listed separately is the case for 27 of the 31 remaining CCCs. The other 4 have the city only listed at admin_level=6 and border_type=city, the same as an IC.

One question that stands out to me is whether the county and city are coextensive.

Cusseta / Chattahoochee County, Georgia, form a CCC and their borders are not coextensive. Athens / Clarke County, Georgia, form a CCC and Clarke County has other municipalities still within the county.

Just a quick check shows at least Macon / Bibb County, Augusta / Richmond County, New Orleans / Orleans Parish, Philadelphia / Philadelphia County, and all five boroughs of New York City are coextensive with both county and city entries in OSM.

Statenville / Echols County, Anaconda / Deer Lodge County, and Camden / Camden County, all have both city and county in OSM but the county is a relation while the city is a node, as is Honolulu County and Honolulu although i recognize that’s a slightly different situation.

At any rate, I don’t see a difference between the four counties in question and the others that I’ve listed that are coextensive.

There may be options I’m overlooking but I would think we’d choose either to:

  1. include San Francisco County and the other three counties to match the existing 27, or
  2. delete the counties of CCCs that are coextensive with the city (such as Bronx County, Philadelphia County, Orleans Parish, etc.) to match how the city of San Francisco is entered, while keeping the ones that are not coextensive such as Athens / Clarke County in order to map those two features separately

Thanks all and looking forward to more discussion!

12

Take it from someone who has done this (and has been operating on MySQL for years and regrets it), you’ll want to use PostgreSQL if you have control over your tech stack. It has an extension called PostGIS (in addition to other database features not present in MySQL) that will allow you to do much more of this kind of processing at the database level. MySQL’s geometry support is unfortunately primitive.

Also - help appreciated in improving Wikidata. I built a few tools you may want to check out that can assist with working with it:

There is also a tool called QuickStatements that’s capable of bulk changes to Wikidata (for example, bulk setting P131 after running spatial queries…)

Lastly, because Wikidata has a rich relationship model, it can handle a lot more of the real-world complexity, such as cities and town which span more than one county (good luck with that one…)

You’re also going to need to figure out what to do in places that don’t have municipalities. Hawaii, Maryland, and Virginia have been the biggest offenders so far. Those are places where CDPs can be good substitutes.

Between OSM and Wikidata there should be a pretty complete representation of the real-world boundary scheme, or at least, the ability to store it for places that are incomplete.

13

Thanks Brian – I’m aware of PostgreSQL and PostGIS, although I’m not sure how much control I’ll have to implement that or whether my specific needs would push me to adopt something more than MySQL.

I only really get the parents and the neighbors and maybe will end up calculating distances between centroids, but that’s about it. So far MySQL has been sufficient.

However I’ll definitely be willing to help keep Wikidata/Wikipedia/OSM up to date and your QA checker looks like a great tool!

QuickStatements looks promising, so I’m excited to check that out!

As the risk of turning this thread on ICs and CCCs into a recipe book for MySQL, here’s the query I use to identify parents, which also captures cities spilling over into multiple counties:

SELECT odosm.wikidata_id, odosmp.wikidata_id

FROM sa_opendata_openstreetmap odosm

INNER JOIN sa_opendata_openstreetmap odosmp
ON (odosmp.osm_admin_level < odosm.osm_admin_level OR (odosmp.osm_admin_level <= 6 AND odosm.osm_admin_level IS NULL))
	AND (
        ST_INTERSECTS(
            -- Have to convert from geometry to text and back because it will miss some otherwise (MySQL bug?)
            -- Alabama (Q173) and Tennessee (Q1509) is an example
            ST_GEOMFROMTEXT(ST_AsText(odosm.geometry_boundingbox)),
            ST_GEOMFROMTEXT(ST_AsText(odosmp.geometry_boundingbox))
        ) = 1
    )
    AND (
        ST_WITHIN(odosm.geometry_boundary, odosmp.geometry_boundary) = 1
        OR ST_OVERLAPS(odosm.geometry_boundary, odosmp.geometry_boundary) = 1
    )

WHERE odosm.wikidata_id = ". $this->db->quote( $qid ) ."

-- And add self without having to search through all similar admin_levels
UNION

SELECT ". $this->db->quote( $qid ) .", ". $this->db->quote( $qid ) ."

This uses ST_INTERSECTS on the boundingbox to narrow the candidates down and then ST_WITHIN and ST_OVERLAPS on the actual boundaries to find the correct ones. I can’t say it’s perfect but so far I’ve not found any errors.

It provides the country, state, and county(ies) for any city and the UNION also provides an entry of the item as its own parent, although that’s a particular quirk of the way I’m using the data.

Note I suspect a MySQL bug that occurs unless I convert from geometry to text and back, which is annoying.

This is the query I use to find neighbors:

SELECT odosm.wikidata_id, odosmc.wikidata_id,
MOD(
    DEGREES(ATAN2(
        SIN(RADIANS(ST_Y(odosmc.geometry_centroid) - ST_Y(odosm.geometry_centroid))) * COS(RADIANS(ST_X(odosmc.geometry_centroid))),
        COS(RADIANS(ST_X(odosm.geometry_centroid))) * SIN(RADIANS(ST_X(odosmc.geometry_centroid))) - 
        SIN(RADIANS(ST_X(odosm.geometry_centroid))) * COS(RADIANS(ST_X(odosmc.geometry_centroid))) * COS(RADIANS(ST_Y(odosmc.geometry_centroid) - ST_Y(odosm.geometry_centroid)))
    )) + 360, 
    360) bearing

FROM sa_opendata_openstreetmap odosm
INNER JOIN sa_opendata_openstreetmap odosmc
ON odosmc.osm_admin_level = odosm.osm_admin_level
	AND (
        ST_INTERSECTS(
            -- Have to convert from geometry to text and back because it will miss some otherwise (MySQL bug?)
            -- Alabama (Q173) and Tennessee (Q1509) is an example
            ST_GEOMFROMTEXT(ST_AsText(odosm.geometry_boundingbox)),
            ST_GEOMFROMTEXT(ST_AsText(odosmc.geometry_boundingbox))
        ) = 1
    )
    AND (
        ST_INTERSECTS(odosm.geometry_boundary, odosmc.geometry_boundary) = 1
    )
    
WHERE odosm.wikidata_id = ". $this->db->quote( $qid ) ."

Basically the same except using ST_INTERSECTS for the final criteria and that I calculate the bearing to the centroids as well.

14

2 posts were split to a new topic: Proposed double-entry of Consolidated City-Counties

15

A post was merged into an existing topic: Proposed double-entry of Consolidated City-Counties