Proposal:County, city and local highway networks in the United States
County, city and local highway networks in the United States | |
---|---|
Proposal status: | Approved (active) |
Proposed by: | Clorox |
Tagging: | network=* |
Applies to: | route=road relations in the United States |
Definition: | A consistent tagging scheme for highway networks belonging to sub-state administrative divisions of the United States |
Statistics: |
|
Draft started: | 2022-05-06 |
RFC start: | 2022-05-10 |
Vote start: | 2022-05-25 |
Vote end: | 2022-06-08 |
Proposal
A straightforward and consistent scheme for tagging network=* on route=road relations belonging to counties, cities and other small administrative divisions of the United States.
Rationale
The United States has hundreds of highway networks belonging to counties, parishes, townships, and cities. Tagging conventions for these networks have generally sprung up state-by-state without much coordination between them. As a result, there are many inconsistencies that one must account for when making sense of the variety of values of network=* used on route=road relations in the United States.
This presents a challenge when writing software to support network=*. For counties with double-barreled names, some states use a space to separate the two words, and others use underscores. This is a rather insignificant example compared to the inconsistent handling of city route networks and county route subnetworks nationwide: Charlotte Route 4 and the Baldwin Beach Express are currently tagged network=US:NC:Charlotte and network=US:AL:Baldwin, respectively, a scheme easily confused for numbered county route networks.
Most of these tagging schemes remain de facto without having gone through any formal process for defining them. Software support for network=* is in its infancy. OpenStreetMap Americana is one of the first renderers to take advantage of network=* on route=road relations, and as the project grows, we're hesitant to solidify de facto tagging schemes with little to no documentation. Ideally the guidelines presented here will provide a consistent, usable scheme of tagging network=* on routes in the United States, making software support straightforward.
Tagging
In the following guidelines, <state>
represents the two-letter postal abbreviation of US states, <county>
represents the full name of a county-equivalent, and <city>
represents the full name of a city (or township, or other municipality). <subnetwork>
represents a subnetwork of routes within an administrative division, including but not limited to "bannered" routes (modifier=*).
For all values of network=* on route=road relations belonging to sub-state administrative divisions of the United States:
- All spaces will be replaced with underscores
- All abbreviations in place names other than the initial country and state codes will be expanded
- The sole exception being Ohio counties, which will use 3-letter ODOT codes, as explained below
- Abbreviations in names of subnetworks are acceptable as long as they enjoy local consensus, are recognizable, and are sufficient to uniquely identify a network. Wherever abbreviations are used in subnetworks, the full name should be mentioned on the Wiki documentation page for that tag.
- network=US:<state>:CR will be used to represent county roads that belong to a state-coordinated numbering network
- network=US:<state>:CR:<subnetwork> will be used to represent county roads that belong to a subnetwork of a state-coordinated numbering network, such as bannered county roads
- network=US:<state>:<county> will be used to represent roads belonging to the primary numbered network of individual counties
- network=US:<state>:<county>:<subnetwork> will be used to represent roads belonging to subnetworks of individual counties
- network=US:<state>:<county>:<city> will be used to represent roads belonging to the primary numbered network of cities, townships and other municipalities
- network=US:<state>:<county>:<city>:<subnetwork> will be used to represent roads belonging to subnetworks of cities, townships and other municipalities
This proposal acknowledges that municipalities may not always be contained within one county. As city routes are somewhat uncommon, but consistent tagging is prudent and necessary, it is recommended to simply choose the county that the plurality of the municipality's population belongs to for the purposes of determining the value of network=*.
Likewise, it is acknowledged that independent cities, present in four states, are not part of any county. None are currently known to have any signposted route networks, but should one arise, independent cities will be treated as counties for the purposes of determining a network=* value, except where a county in the same state shares its name, in which case the independent city is to be treated as if it were inside that county, such as network=US:MD:Baltimore:Baltimore for the City of Baltimore, Maryland.
New York City is a unique special case, being a city composed of five boroughs, each of which is coterminous with a county. As counties are effectively subordinate to the City in this case, it is proposed to use the recognizable abbreviation "NYC" as a county code and the borough name as the city code wherever necessary.
This proposal does not affect subnetworks of statewide systems. Examples of unaffected subnetworks include bannered state routes, state parkway systems, and secondary state routes (including those in West Virginia, which are confusingly named "County Roads").
Examples
Alabama
County roads belonging to individual counties are to be tagged network=US:AL:<county>. This reflects current practice, but relations may need to be reviewed to ensure there are no spaces or abbreviations.
The Baldwin Beach Express and Foley Beach Express, as subnetworks of Baldwin County routes, are currently tagged network=US:AL:Baldwin, and would need to be retagged. A suggested scheme would be network=US:AL:Baldwin:Baldwin_Beach_Express and network=US:AL:Baldwin:Foley_Beach_Express, respectively.
Arizona
County roads belonging to individual counties are to be tagged network=US:AZ:<county>. Currently, only Yavapai County (network=US:AZ:Yavapai) follows this scheme. County roads in Coconino County are currently tagged network=US:AZ:CR, and in Maricopa County network=US:AZ:MC. Under this proposal, they would be retagged network=US:AZ:Coconino and network=US:AZ:Maricopa, respectively.
Arkansas
County roads belonging to individual counties are to be tagged network=US:AR:<county>. This reflects current practice, but relations may need to be reviewed to ensure there are no spaces or abbreviations.
California
County roads belonging to the state-coordinated alphanumeric system are to be tagged network=US:CA:CR. This reflects California/State_Highway_Relations#County_Highways (current practice), no change in tagging is proposed to this tagging scheme.
California is known to have at least one network of numbered roads assigned by a single county, in Mendocino County. Currently, none are mapped with route=road relations, though some are tagged with ref=* with the value being the number assigned by the county. It is proposed that these, and any other numbered roads belonging to individual counties in California, be tagged network=US:CA:<county>.
49-Mile Scenic Drive, a scenic route of the City and County of San Francisco, is now mapped with network=US:CA:San_Francisco:49_Mile_Scenic_Drive. Separately, the California Department of Transportation (Caltrans) administers signed "Scenic Highways," legislatively defined as part of California's "State Scenic Highway System." These are outside the scope of this proposal, as they are a statewide subnetwork of routes.
Note that (countywide) bicycle routes (assembled as a local cycleway network of routes, in OSM as network=lcn) in the state follow this tagging scheme except for the use of county abbreviations in their cycle_network=* tag. Currently such route networks exist in San Francisco, San Mateo, and Santa Clara Counties, with more proposed. Such bicycle route networks have cycle_network=* values using county abbreviations assigned by Caltrans, e.g. cycle_network=US:CA:SF for San Francisco's numbered local bicycle network. No change is proposed to bicycle routes. However, this proposal specifically avoids using county abbreviations for highway routes in California, because Caltrans has multiple schemes of county abbreviations used in different contexts, which would likely introduce confusion when initially mapping routes in a county with more than one possible abbreviation.
Colorado
County roads belonging to individual counties are to be tagged network=US:CO:<county>. This reflects current practice, but relations may need to be reviewed to ensure there are no spaces or abbreviations.
Florida
Most county roads in Florida have numbers retained from when they were demoted from being secondary state roads in 1977. As county roads in Florida generally follow not only a statewide scheme, but also match the scheme used with state routes, it is proposed to change the tagging of these to network=US:FL:CR. Current tagging follows the format of network=US:FL:CR:<county>.
Georgia
County roads belonging to individual counties are to be tagged network=US:GA:<county>. This reflects current practice, but relations may need to be reviewed to ensure there are no spaces or abbreviations.
Illinois
County roads belonging to individual counties are to be tagged network=US:IL:<county>. This reflects current practice, but relations may need to be reviewed to ensure there are no spaces or abbreviations.
The Chicago Skyway is currently tagged network=US:IL:Cook:Skyway. As it would be considered a special subnetwork of Chicago city routes, it is proposed to retag this to network=US:IL:Cook:Chicago:Skyway.
Indiana
County roads belonging to individual counties are to be tagged network=US:IN:<county>. This reflects current practice, but relations may need to be reviewed to ensure there are no spaces or abbreviations.
Iowa
County roads belonging to individual counties are to be tagged network=US:IA:<county>. This reflects current practice, but relations may need to be reviewed to ensure there are no spaces or abbreviations.
Kansas
County roads belonging to individual counties are to be tagged network=US:KS:<county>. This reflects current practice, but relations may need to be reviewed to ensure there are no spaces or abbreviations.
Louisiana
Parish roads are to be tagged network=US:LA:<parish>. Currently, none are mapped with route=road relations.
Michigan
County roads belonging to the state-coordinated alphanumeric system are to be tagged network=US:MI:CR, and county roads belonging to individual counties are to be tagged network=US:MI:<county>. This reflects current practice, but relations may need to be reviewed to ensure there are no spaces or abbreviations.
Minnesota
Each county in Minnesota has a system of County State Aid Highways (CSAH) and County Roads (CR). Certain counties also have County Park Access Roads. Within a county, route numbers are not shared between these systems, though they are often signed with different shields. Currently, all Minnesota county roads are tagged following the format network=US:MN:<county>, with no differentiation between CSAH and CR. Under this proposal, each relation would be retagged to classify it in one of these subnetworks of county routes. As CSAH and CR are recognizable abbreviations in this context, a recommended tagging scheme would be network=US:MN:<county>:CSAH for County State Aid Highways and network=US:MN:<county>:CR for County Roads. County Park Access Roads seem to be relatively uncommon, and there isn't enough information on what an acceptable abbreviation for this system might be, so network=US:MN:<county>:Park_Access is suggested.
Mississippi
County roads belonging to individual counties are to be tagged network=US:MS:<county>. This reflects current practice, but relations may need to be reviewed to ensure there are no spaces or abbreviations.
Missouri
Missouri has only one known route signposted by a county. No change is proposed to this route, as it is already tagged network=US:MO:Taney in accordance with this proposal.
The city of Branson has three color-coded routes. No change is proposed to these either, as they are already tagged network=US:MO:Taney:Branson in accordance with this proposal.
Missouri supplemental routes (network=US:MO:Supplemental), being a subnetwork of state routes, are outside the scope of this proposal. No change is proposed.
Nebraska
County roads belonging to individual counties are to be tagged network=US:NE:<county>. Currently, none are mapped with route=road relations.
Nevada
Nevada has only one known route signposted by a county. No change is proposed to this route, as it is already tagged network=US:NV:Clark in accordance with this proposal.
New Jersey
County roads belonging to the state-coordinated system, in the range 500-599, are to be tagged network=US:NJ:CR, and county roads belonging to individual counties are to be tagged network=US:NJ:<county>. This reflects current practice, but relations may need to be reviewed to ensure there are no spaces or abbreviations.
New Mexico
Currently, county roads in New Mexico are tagged network=US:NM:CR:<county>. Under this proposal, they would be changed to network=US:NM:<county>.
San Juan County assigns numbers and posts shields for non-county-maintained (NCM) roads, in addition to county roads. Currently, county roads in San Juan County are tagged network=US:NM:CR:San Juan:CM and NCM roads are tagged network=US:NM:CR:San Juan:NCM. These would be changed to network=US:NM:San_Juan and network=US:NM:San_Juan:NCM, respectively.
New York
County roads belonging to individual counties are to be tagged network=US:NY:<county>. This reflects current practice, but relations may need to be reviewed to ensure there are no spaces or abbreviations.
The State of New York has at least one known route signed by a city, Rochester's Inner Loop (NYC might sign more). Currently, it is tagged as network=US:NY. Under this proposal, it would be changed to network=US:NY:Monroe:Rochester.
Parkways within New York City are an ambiguous case. Signage of these routes is a collaboration between agencies of New York City and New York State. There are two interpretations of this situation: the first being that these routes are a geographically restricted subnetwork of parkways belonging to New York State (network=US:NY:Parkway:NYC), the second being that these routes are parkways directly belonging to New York City (network=US:NY:NYC:Parkway). Current local consensus is to model these as a subnetwork of state parkways (network=US:NY:Parkway:NYC), and no change is proposed to this tagging.
North Carolina
North Carolina does not have county routes.
The only city route in North Carolina, Charlotte Route 4, would have its tagging changed from network=US:NC:Charlotte to network=US:NC:Mecklenburg:Charlotte.
North Dakota
County roads belonging to individual counties are to be tagged network=US:ND:<county>. This reflects current practice, but relations may need to be reviewed to ensure there are no spaces or abbreviations.
Ohio
As an exception, counties in Ohio will be referred to by their 3-letter code assigned by the Ohio Department of Transportation (ODOT), rather than their full name. The guidelines proposed here otherwise apply to Ohio. This reflects current tagging—no change is proposed to routes in Ohio.
County, township and city routes in Ohio are already mapped with consistent guidelines of their own. The only difference between the current tagging scheme and the scheme otherwise recommended in this proposal is the usage of 3-letter ODOT abbreviations for counties. This tagging scheme is helpful in Ohio due to its abundance of township-level routes, all of which are otherwise already tagged in accordance with this proposal, with abbreviations expanded and spaces replaced with underscores (e.g. network=US:OH:COL:Saint_Clair for routes belonging to St. Clair Township, Columbiana County, Ohio).
If the Ohio community decides to replace 3-letter ODOT codes with full county names in the future, they are welcome to do so and document their changes, but for the purposes of this proposal the ODOT codes will remain.
Oklahoma
County roads belonging to individual counties are to be tagged network=US:OK:<county>. This reflects current practice, but relations may need to be reviewed to ensure there are no spaces or abbreviations.
The city of Tulsa has two signed expressways with shields. No change is proposed to these relations, as they are already tagged network=US:OK:Tulsa:Tulsa in accordance with this proposal.
Oregon
County roads belonging to individual counties are to be tagged network=US:OR:<county>. At least one county, Grant County, is known to have numbered routes. Currently, none are mapped with route=road relations.
Pennsylvania
Pennsylvania does not have county routes, except for the color belt system of Allegheny County. As this system would be considered a special subnetwork of Allegheny County roads, this proposal recommends to change them from network=US:PA:Belt to network=US:PA:Allegheny:Belt.
South Dakota
County roads belonging to individual counties are to be tagged network=US:SD:<county>. Currently, none are mapped with route=road relations.
Texas
County roads belonging to individual counties are to be tagged network=US:TX:<county>. This reflects current practice, but relations may need to be reviewed to ensure there are no spaces or abbreviations.
There are at least three toll road networks belonging to counties in Texas. Under this proposal, network=US:TX:FBCTRA, network=US:TX:HCTRA and network=US:TX:MCTRA would be changed to network=US:TX:Fort_Bend:FBCTRA, network=US:TX:Harris:HCTRA and network=US:TX:Montgomery:MCTRA, respectively.
Texas currently has one route signposted by a city, Andrews Loop 1910. This is already tagged as a subnetwork of Andrews city routes in accordance with this proposal, network=US:TX:Andrews:Andrews:Loop.
Virginia
Virginia does not have county or city routes. Virginia secondary roads (network=US:VA:Secondary), being a subnetwork of state routes, are outside the scope of this proposal. No change is proposed.
Washington
Washington has only one known route signposted by a county. No change is proposed to this route, as it is already tagged network=US:WA:Benton in accordance with this proposal.
West Virginia
West Virginia does not have routes signposted by counties or municipalities. West Virginia County Roads (network=US:WV:County), being a subnetwork of state routes, are outside the scope of this proposal. No change is proposed.
Wisconsin
County roads belonging to individual counties are to be tagged network=US:WI:<county>. This reflects current practice, but relations may need to be reviewed to ensure there are no spaces or abbreviations.
Wyoming
County roads belonging to individual counties are to be tagged network=US:WY:<county>. This reflects current practice, but relations may need to be reviewed to ensure there are no spaces or abbreviations.
Other states
States not listed above are not known to have any routes signposted below the state level. The District of Columbia and all territories have only one network of numbered roads each, outside the scope of this proposal.
Rendering
This proposal does not recommend a particular rendering, but is intended to facilitate better software support and documentation (in order to produce renderings in the first place).
Features/Pages affected
The network=* tag of route=road relations belonging to many sub-state administrative divisions of the United States would be affected.
The following states have a notable change to their current tagging scheme:
- Alabama
- Arizona
- Florida
- Illinois
- Minnesota
- New Mexico
- New York
- North Carolina
- Pennsylvania
The following states generally follow these guidelines, but may need review to ensure spaces are replaced with underscores and abbreviations in place names are expanded:
- Arkansas
- Colorado
- Georgia
- Indiana
- Iowa
- Kansas
- Louisiana
- Michigan
- Mississippi
- Nebraska
- New Jersey
- North Dakota
- Oklahoma
- South Dakota
- Texas
- Wisconsin
- Wyoming
Other states likely remain unchanged by this proposal.
Guidelines in United States roads tagging/Routes and Category:MUTCD would be updated to reflect these changes, as well as any state guideline pages linked therein where applicable.
External discussions
- OpenStreetMap US Slack:
- collecting information on county road shields
- RFC for this proposal
- question in #local-nyc about parkway shields in New York City
- Announcement of start of voting
- talk-us@ mailing list: aborted mechanical edit proposal where this subject was brought up
- tagging@ mailing list:
Comments
Please comment on the discussion page.
Voting
Voting on this proposal has been closed.
It was approved with 17 votes for, 0 votes against and 2 abstentions.
I approve this proposal. --Txemt (talk) 15:55, 25 May 2022 (UTC)
I approve this proposal. --Nfgusedautoparts (talk) 17:57, 25 May 2022 (UTC)
I approve this proposal. This is a careful and deliberate proposal which I enthusiatically support. However, because of its very wide scope and the (potentially) very large number of smaller jurisdictions involved, if approved, it should continue to closely track progress and exceptions at least as well as it has done up to the point of its presentation as a proposal. So, with my support and Yes vote, I strongly urge that it (or a wiki offshoot of it) be kept updated with knowledge / data of what OSM discovers in the real world and well-translates to these conventions, as well as noting any exceptions (and there are some). Nice work so far! Stevea (talk) 19:33, 25 May 2022 (UTC)
I approve this proposal. --Gerradynn (talk) As Stevea has stated, this proposal is deliberate and well thought out. While it is not complete I believe the proposal is robust enough to work as is, and be used as a template moving forward for missing locales in the United States, such as my own state of Tennessee. 01:18 27 May 2022 (UTC)
I approve this proposal. --Carnildo (talk) 04:27, 27 May 2022 (UTC)
I approve this proposal. --Skunkman56 (talk) 14:01, 28 May 2022 (UTC)
I have comments but abstain from voting on this proposal. Not my place to tell you folks how to map, but this strikes me as busywork (albeit long-established busywork). You don't need to tag something with network=US:NE:<county> - OSM is a geographical database, you can tell that a county road is in Lancaster County by the fact that it's enclosed by the Lancaster County boundaries. A simple ref=CR 232 provides exactly the same information (and if you really wanted you could add `designation=county_road` lest anyone think that CR might stand for Crunchy Robots or something). --Richard
- That's a 90% solution -- but only 90%. The county road system in the US is messy enough that explicit labeling is required. County roads that extend out of their parent county or run along a border can't be correctly labeled through a geometric query. County roads in states like Minnesota and New Jersey, where a county can have more than one network, can't be correctly labeled through a geometric query. There are probably some other one-off situations that also can't be correctly labeled through a geometric query. --Carnildo (talk) 22:02, 29 May 2022 (UTC)
- Spatial queries are, in general, insufficient to determine which administrative unit a route belongs to. There are plenty of examples of extraterritorial routes belonging to US counties and states, as well as Canadian provinces and territories. There is even a Ukrainian national route passing through Moldovan territory. If spatial queries were truly a sufficient solution here, we would have figured out a simpler tagging scheme a decade ago. --clay_c (talk) 23:03, 29 May 2022 (UTC)
- @Richard: A big part of this proposal is actually trying to accomplish what you're proposing: for each state that has one coherent county route system, there only needs to be one network=* value for all county routes in that state. That would be a change from current practice, which maintains a separate network=* value for each county in the state that adds no value beyond a spatial query. Moreover, a route designation is not the same as a road designation: a road may be part of a concurrency, carrying not only a county road but also three other kinds of routes at the same time. For example, this road is part of an Indiana county's county route network as well as part of an Ohio county's county route network, but the two networks are completely unrelated. designation=* would end up as complicated as the network=* values described here, but without the ability to associate each designation with the correct ref=* value. – Minh Nguyễn 💬 23:29, 29 May 2022 (UTC)
- Yes, Richard: even within a single state (like California), it can be subtle and not especially clear as to which network (and hence which sign or shield might render) any given "County Route" (for example) is a member of. See our (linked above, repeated here: California/State_Highway_Relations) wiki's last sub-section and section (2.11 and 3) to better grasp how even for a longtime resident who communicates with our state (and different county) transportation departments (and looks for signs, and categorizes them for OSM...) this can remain snarled. This proposal (with other state wikis like California's) will go a long way towards both unraveling this and providing a solid platform (as in syntax for software) for rendering of shields from signage in the real world. Stevea (talk) 21:22, 30 May 2022 (UTC)
I approve this proposal. Thanks for all the hard work that went into researching and drafting this proposal. Standardizing the tagging for these routes will be extremely helpful to the OpenStreetMap Americana project, by providing reliable network=* values that we can use for generating the appropriate highway shields for these route networks. --ZeLonewolf (talk) 22:29, 29 May 2022 (UTC)
I approve this proposal. Without this reform, this ludicrously long array in OsmAnd's codebase would have to be twice as long for no good reason, and other data consumers would have to do similar gymnastics just to distinguish county routes from bannered state routes. – Minh Nguyễn 💬 23:48, 29 May 2022 (UTC)
I approve this proposal. As others have said this seems well thought out and when looking at Minnesota it addresses the three types of county roads that I know of with a reasonable scheme. It will be a lot of work, but it should be worth it in the end. --Rjgambrel (talk) 00:33, 30 May 2022 (UTC)
I approve this proposal. --User:A Flappy Civic (talk
I approve this proposal. --MoiraPrime (talk) 03:46, 30 May 2022 (UTC)
I approve this proposal. --Jumbanho (talk) 06:34, 30 May 2022 (UTC)
I approve this proposal. --SkateBoard (talk) 17:25, 30 May 2022 (UTC)
I approve this proposal. --RayKiddy (talk) 19:35, 30 May 2022 (UTC)
I approve this proposal. --Longhorn256 (talk) This proposed feature will greatly help mapmakers, especially those who use QGIS. Kudos to everyone who contributed to the guide on this proposal. This is exactly what has been needed in OSM for years.22:52, 30 May 2022 (UTC)
I approve this proposal. --Akadouri (talk) 02:26, 31 May 2022 (UTC)
I approve this proposal. --1T-money (talk) 23:18, 31 May 2022 (UTC)
I have comments but abstain from voting on this proposal. I second Richard's comments. Nebraska does not have a county highway or county route system, so this may be better state-by-state than national. --Stretch Longfellow (talk) 21:21, 4 June 2022 (UTC)
- To this abstention I nod and tip my hat. Any "place" (might be a state, might be a territory) in the USA that "doesn't have such highways nor any such network" simply doesn't have a need to tag any of these. For the other (maybe forty-something of them?) "places," this is a framework that "works where it is needed among a wider world where sharing happens." Don't need to share (or care to share a total of zero?), that's fine, simply "opt out." With respect, Stevea (talk) 21:27, 4 June 2022 (UTC)
- Some counties in Nebraska at least have numbered and/or lettered routes that are only posted on blade signs. Whether such routes are worthy of route=road relations in the first place is up to the Nebraska mapping community. What this proposal is about is standardizing the format of the network=* values in county route relations nationwide, wherever they may exist currently or in the future. --clay_c (talk) 21:40, 4 June 2022 (UTC)