Proposal talk:County, city and local highway networks in the United States

From OpenStreetMap Wiki
Jump to navigation Jump to search


For what it's worth, the rationale for ODOT county codes in Ohio is not only that there are lots of township route networks but also that, in transportation, ODOT county codes serve a similar purpose that ISO 3166-2:US/FIPS 5-2 alpha codes serve for identifying states – those are the codes we use for network=* at the state level. Most states maintain county codes for various purposes, but none seem to standardize on a single set of memorable, alphabetic codes as consistently as Ohio has. – Minh Nguyễn 💬 00:46, 8 May 2022 (UTC)

Minh is quite likely 100% correct on that last point, however, it is my observation over many decades that California consistently uses dual-alphabetic county codes (e.g. "SF" for San Francisco, "SC" for Santa Clara or "SZ for Santa Cruz) on its highway mile-marker signage (and at least within CalTrans, our state department of transportation, if not other state agencies). So, it can be said California also uses county codes "consistently within at least one (smallish) context," which ain't nothin'. Stevea (talk) 11:58, 11 May 2022 (UTC)
California uses county codes for one thing, and then another set of county codes for another thing. Minh mentioned on Slack that "even the SAFE system of freeway call boxes uses a different set of county codes on its (larger) signs." California cannot internally agree on how to abbreviate its counties, so it may introduce more confusion if we were to use one of these abbreviation schemes. clay_c (talk) 19:49, 11 May 2022 (UTC)

Ohio's three-letter county codes are used by other relevant programs besides ODOT, such as the Ohio Historic Inventory. The Bureau of Motor Vehicles used to use FIPS 6-4 county codes (numeric codes in alphabetic order by county name), but they abandoned that practice a few years ago. If California's county route network were cleanly divided by county, then the Caltrans county codes would at least be worth consideration, even though most state agencies use FIPS 6-4 county codes. But California divides the county routes by zone instead. – Minh Nguyễn 💬 08:43, 12 May 2022 (UTC)

I appreciate all of the insight here. I didn't realize it was that "bad" in California, so yes, I agree that "it may introduce more confusion if we were to use one of those abbreviation schemes." Besides, OSM doesn't really like abbreviations, such as "don't use St., use Saint," so, yeah. Stevea (talk) 23:39, 12 May 2022 (UTC)
The aggressive expansion of abbreviations on "Saint" seems to be a chiefly US thing. Mappers in other English-speaking countries, even Canada, maintain that various places are properly spelled with "Saint" abbreviated. One time I changed the name of the train station in St. Catharines, Ontario to expand the abbreviation, and it got swiftly reverted by the locals. clay_c (talk) 19:18, 18 May 2022 (UTC)

One thing that kind of bothers me in Ohio is network=US:OH:ASD:TWP for Ashland County's township roads. At Phil Gold's very reasonable insistence, we consolidated all the township roads under a single network, because they're numbered coherently and signposted consistently throughout the county. (It's the only county in the state that manages its township routes so reasonably, to compensate for its worst-in-the-state shields.) The "TWP" was intended to reflect the literal "TWP" on the signs, versus the "CO" on county road signs, but I think that's needlessly literal because a renderer is unlikely to parse the :TWP suffix directly onto the shield. As quite possibly the only person who's ever mapped these routes, I'd be in favor of retagging them as network=US:OH:ASD:township or network=US:OH:ASD:Township, for some semblance of consistency with other networks distinguished by something other than the containing administrative region. – Minh Nguyễn 💬 01:44, 13 May 2022 (UTC)

Might as well. That looks to be in the spirit of these guidelines. I would certainly hope no software that processes network=* is displaying its literal text value, or a substring of it, to end users. These are meant to be unique identifiers for road networks, not word-for-word copies of shield text. The actual appearance of the shields can be documented on the wiki. clay_c (talk) 19:18, 18 May 2022 (UTC)


Virginia has "independent cities" which are not part of any county. I don't know if any of them have their own networks, but it would be worth making sure about so that it isn't another edge case for the tagging. Alaska has a similar thing with their "consolidated city-boroughs". There's also the matter of cities which straddle state lines. I rather doubt that any of them have routes which are shared across the two halves of the city, but it's possible. Eiim (talk) 15:40, 10 May 2022 (UTC)

AFAIK in Virginia, at least in the two cities I'm most familiar with (Roanoke and Lynchburg), there's no on-the-ground signage identifying roads as part of a city network, at least not one that would be consistent state-wide. I could not find any evidence that the largest by area independent city (county-size Suffolk) signposts routes either. I do think Virginia and WV's secondary route systems need a reference on this page, though, as they fulfill the role of county routes. I know WV was recently redone to use US:WV:County with an is_in tag and VA to use US:VA:Secondary with the county disambiguation placed in the name field. OptikalCrow (talk) 16:00, 10 May 2022 (UTC)
Routes signposted by cities are relatively rare. Alaska, Virginia and West Virginia are not known to have any. If a consolidated city-county (or city-borough) decides to signpost a route, it will be treated as a county for the purposes of determining a network=* value (see the example in San Francisco).
Independent cities exist only in Maryland, Missouri, Nevada and Virginia. None of these states are known to have city routes, and two of them have only one signposted county route in the whole state. Though if an independent city ever decides to signpost a route, disambiguation will be needed between counties and independent cities of the same name. I would propose that independent cities be treated as counties for the purpose of network=*, except if a county has the same name, in which case the city will be treated as if it were within that county. So a St. Louis County route would be network=US:MO:Saint_Louis and a St. Louis City route would be network=US:MO:Saint_Louis:Saint_Louis. After all, the strategy is the same when a city isn't contained within one county: just pick a county. clay_c (talk) 19:57, 10 May 2022 (UTC)
Addressing Eiim first: I am certain there are US cities which extend beyond county boundaries (Dallas, Texas is believed to extend into FIVE counties, it may even be SIX), but I do not know of a single city in the US which "straddles state lines." If you know of any, I ask for examples, please.
Next, I thank OptikalCrow for sharing knowledge of Virginia's independent cities. However, while the denotation US:VA:Secondary is good to know there, I'm not sure if the longer-term denotation for West Virginia (or anywhere, really) using "is_in" is a good idea, as it is my understanding that "is_in," while it is a tag designated "in use," is an older tag which is no longer required where all administrative boundaries are fully mapped. Please see Key:is_in for details. It may be best if West Virginia is (or becomes) "fully mapped" (with boundary=administrative, perhaps only necessary out to the county level of admin_level=6, if that is as far as road networks go) and then the "is_in" convention can be dropped.
Clay, I think it doesn't matter in the long run, as Alaska doesn't seem to have any such city-county road networks (though Louisiana MIGHT), but because these two states don't have what are strictly called counties, it is often easier to specify "county or county equivalents" (when talking about all fifty states). It is widely recognized (by both OSM and the US Census Bureau) that "county equivalent" can apply to Alaska's "divisions" and Louisiana's "parishes." Though, beware: "county equivalent" can also apply (according to the Census Bureau but NOT by OSM) to things like Washington, DC and certain "minor civil divisions" of things like territorial municipalities (of which there are at least as many flavors as there are territories). This does not include townships (which ARE "minor civil divisions"). Whew, such nomenclature gets complicated, which is my whole point here, so what I'm saying is to please be careful with how sub-state (or territory) administrative divisions are named: it can be horrifically complex. All in all, I think everything that is being said here is on the right track and I'm glad to see progress on this. But this nomenclature can be fragile and/or brittle, so please see the work we've put into United States admin_level to better grasp some of the immense complexity of sub-state administrative divisions we have in these fifty united states.
Finally, I'm not sure your network=US:MO:Saint_Louis:Saint_Louis notation is correct, as Saint Louis (the independent city) has nothing to do with Saint Louis County, with the sole exception that they are both in the state of Missouri. Importantly, the former is not contained within the latter, making the implied hierarchy of your two examples incorrect. (I think). As I DO think about this, I don't know of a clean and easy way to denote these in such a network hierarchy for this purpose except to "coin" specific values for these two otherwise-ambiguous values, such as network=US:MO:Saint_Louis_City and network=US:MO:Saint_Louis_County.
I know it's "early days" for this, but it's great to see this work underway! Stevea (talk) 11:45, 11 May 2022 (UTC)
I believe the "is_in" convention was to disambiguate between duplicate route numbers across the state. WV's county routes are state-managed and part of a single network with the general rule that the numbering does not repeat within counties but can repeat state-wide. Identical route numbers in different parts of the state are functionally different routes and so it would not make sense to combine them into a single, disjoint relation, and so I believe some form of disambiguation should be necessary- while this can be done through a geographic search I feel it should be indicated directly on the relation. Virginia runs into the same problem and I was the one who suggested adding the county in the name=* tag which was approved locally but concern was brought up about it being a constructed name. Either way, this proposal should be the ground where this is standardized. OptikalCrow (talk) 13:02, 11 May 2022 (UTC)
Texarkana would be the classic example of a city crossing state lines for me. Of course, these types of cities are technically broken into one in either side of the state line for administrative purposes, but it would not surprise me if, in the case that local networks were desired, the two halves collaborated to make it consistent across the city. Eiim (talk) 15:59, 11 May 2022 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Jon Postel specifically addressed this potential for conflicts between county, township, and city names in his original scheme for .us locality domains: for the county and for the city; for the county, for the township, and for the city. [1][2] As network=* is essentially a reverse DNS syntax, any ambiguities could be resolved by adding a suffix such as :county or :city.

In any case, I find it unlikely that any state will outdo Ohio and Texas in terms of local route numbering complexity any time soon. Although Ohio's municipal and township boundaries can get very funky, we've determined that no township or city route in the state need be impacted by this funkiness. Fremont is the one city we know of that maintains its own route network. While it lies in two townships, none of the townships in its county shares the name Fremont, so there's no need to further bury Fremont within the namespace of one of its townships.

 – Minh Nguyễn 💬 08:17, 12 May 2022 (UTC)


I'm not sure if network=US:CA:San_Francisco:49_Mile_Scenic_Drive is more correct, or if network=US:CA:SF:49_Mile_Scenic_Drive is preferred. There is precedent in California (e.g. for bike routes) for SF to prevail over San_Francisco (though I think both can be "stretched to fit" this proposal). There does seem to be room for and good wiki seeds planted for up to 50 different methods (each state is simply unique unto itself) or we may (do already?) get some clustering of "simple, well-stated cases." Also, I'm not sure if 49MSD is really a "network," or merely a single route which should be named this. Must all routes (especially single ones) be "in a network?" At the national level of bicycle routes, there are a half-dozen "national unique routes" that aren't really in any network, each is simply a route unto itself. Surely there either are or aren't single-route networks (I think there are, at least presently, maybe there shouldn't be). I think we likely better decide these things earlier rather than later, though of course, good discussion comes first. Stevea (talk) 02:03, 15 May 2022 (UTC)

Lately there’s been a trend towards assigning single-route networks to one-off routes, especially for toll roads with their own unique shields. This avoids the rendering confusion that occurred in the past when these routes got conflated with ordinary numbered route networks, for example network=US:NY and the New York Thruway. In theory, we wouldn’t need to tag network=* on these routes at all because of wikidata=* already serving as a unique, stable identifier, but network=* is slightly more human-readable and thus more discoverable. Minh Nguyễn 💬 15:51, 15 May 2022 (UTC)
I'm going to stick with the systematic unabbreviated approach to county names in California. The county bicycle route networks in California suffer from some of the same issues described in this proposal, namely that they are de facto tagging schemes that sprung up on an individual basis, and some of the assumptions made about counties with currently mapped bike route relations may not hold true for counties elsewhere with unmapped routes. As mentioned above, California has multiple competing abbreviation schemes for county names, and introducing a new tagging scheme with abbreviations may cause confusion where a county may be abbreviated two different ways.
Perhaps if this proposal is successful, California bike route mappers can have a discussion about whether it makes sense to adopt these guidelines for county bike routes as well. But that's neither here nor there. clay_c (talk) 19:06, 18 May 2022 (UTC)

Large-scale edits without discussion

Hi Stevea,

I appreciate the insights you have added to the proposal page. Some of your clarifications and additions were quite helpful, as with the Mendocino County example. But some changes have introduced wording that semantically changes the effect of this proposal, as with independent cities with names that match neighboring counties. I would rather you have discussed your changes here before adding them to my proposal. Please make sure any further changes are discussed here first. clay_c (talk) 14:52, 18 May 2022 (UTC)

Sure thing. I will say that it can be subtle to know whether my intention of "stating facts personally known (or in the map) to offer breadth of knowledge" treads into the realm of "semantically changing the effect of this proposal." Whereas (of course) I wish for the former and not the latter, it can be difficult to know what the right thing to do is when facts or knowledge, when simply introduced, semantically change effect. By offering further discussion here a priori, I/we will avoid any such inadvertent change and I thank you for calling this to my attention. Stevea (talk) 20:30, 18 May 2022 (UTC)

New York (City)

I believe some finer gradation on whether a certain non-Parkway "highway network" belonging to New York City (the five boroughs / county-equivalents that make up this "glom") is warranted in this proposal. I believe an (exhaustive) examination of those highways which are administered by NYCDOT (distinct from NYSDOT) fall into this category. Example highways in this potential network might be FDR Drive, possibly others like Nassau Expressway and Prospect Expressway. I'm not local and don't fully understand such subtle things, but if we are categorizing networks, doing so here seems like good (early) work to understand and establish here and now. It might make sense to clarify that "sub-state" (where state in the USA is admin_level=4) as a scope here includes admin_level=5 NYC, which is a "unique beast" in OSM. Stevea (talk) 22:09, 20 May 2022 (UTC)

I'm aware that various routes that fall under the "NYC Parkways" umbrella are maintained by NYCDOT, or jointly between them and NYSDOT. However, my understanding is that the signage of these routes is a collaboration between NYSDOT, NYCDOT and NYC Parks (see here). I don't see a compelling reason to assign New York City parkways different network=* values based on their operator=*.
The special case of New York City being made up of five boroughs, each coterminous with a defunct county, would be managed by assigning the city the recognizable abbreviation NYC as a county code, and the borough name where cities and townships are used elsewhere. With that in mind, the proper tagging of these routes would probably be a tossup between network=US:NY:Parkway:NYC (New York City subnetwork of the Parkway subnetwork of New York state routes in the US), and network=US:NY:NYC:Parkway (Parkway subnetwork of New York City routes in New York in the US), as long as they're all consistent. In the interest of keeping it simple on such an ambiguous case, I'm opting for the one that's already accepted by the community.
I don't think the individual boroughs are likely to signpost a network of highways, but in the case they do, they would probably look like network=US:NY:NYC:Staten_Island. clay_c (talk) 00:31, 21 May 2022 (UTC)
To be clear, NYC's borough-based "county equivalents" are not "defunct." There are minor administrative things going on there (I think one or two or more such boroughs have their own library districts, for example). So, let's be careful how we carve things up as authoratative, lest others who are more local and more knowledgable weigh in. That's my whole point here, is that this proposal opens itself up to "the fact THAT" such carvings up (at the sub-state level) are simply happening and going to happen. This is a very organic, unfolding proposal, is what I'm saying. We can't ignore that away as we accept it. I do like the structure as proposed, though there will continue to be edge cases which feather around the edges, there simply will be. As we propose this, we must allow knowledge of its edges into knowledge of our map data, and right now, that is this wiki as a proposal. Let's not hose that down so it can't at least smolder, as such an increase in knowledge is an increase in OSM's data. Stevea (talk) 00:44, 21 May 2022 (UTC)
I asked on the #local-nyc channel in Slack, and I got some responses from those involved in mapping these routes. Consensus seems to be that these routes should all be mapped as one network and operator=* should be used to distinguish who maintains the route if necessary. As for the order of the subnetworks, there weren't any strong opinions between the two competing interpretations, so I think the best thing to do here is work with what's established. clay_c (talk) 17:04, 22 May 2022 (UTC)
I appreciate your efforts and have thanked you for your edits! Stevea (talk) 17:08, 22 May 2022 (UTC)

No longer proposed

I'm not sure of the proper process-and-syntax for these things (I saw the Proposal was archived to avoid confusion, good) but shouldn't the Title of this wiki article delete its initial "Proposed features/"? I'd like to find this Titled "County, city and local highway networks in the United States." (With all of the correct "United States" and "Highways" associations, as those are properly built). This is the "documentation of a proposal gets archived as a proposal (so far, so good) and its "place" in the wiki is established as no longer Proposed, but Approved" process-and-syntax. We're close, but I don't think we're quite there, yet. I guess I'm talking to wiki administratior(s) or Minh, or someone like that. Although I think Clay has largely got most of it right. He might "flip some switches," I don't know. We're almost there. Stevea (talk) 21:45, 4 July 2022 (UTC)