US 395 is not a motorway here due to multiple at-grade intersections. I will be reverting this changeset.

One other point - while the fed functional class does classify non-state/US roads as you point out, it is usually way off the mark for local/city roads relative to the OSM scheme. The vast majority of urban arteries the federal class with list as "other principal artery" are 'secondary' or 'tertiary' in OSM, only occasionally 'primary'.

I live in Truckee - the fed functional class here lists everything but the state highways as a local road, which is patently incorrect. The functional class map, and to some degree the NHS system (especially MAP-21 roads), seem to be more based around funding and highway policy than necessarily the way OSM classifies roads.

If you haven't seen these already, here's some good references about US classification:

osm.wiki/United_States_roads_tagging

osm.wiki/United_States_Road_Classification

Some discussion about fed/state functional class systems not corresponding to OSM tags:

https://www.mail-archive.com/talk-us@openstreetmap.org/msg16988.html

https://www.mail-archive.com/talk-us@openstreetmap.org/msg03714.html

Most mappers in the US do not use the federal functional classification since it is both does not correspond well to OSM classification system and is often internally inconsistent. In my opinion, the OHP classes map much better to OSM classes and could safely be used to aid classification decisions.

And believe me, I am on the same page about secondary & state route rendering. I have been on the fence about the main roads in my current Truckee/Tahoe area for years for the same issues.

Anyways, just wanted to explain my reasoning since I am the one who made many of the changes to a region that hasn't seen a lot of love. I will happily defer to active local mappers who know the region better than I do.

For what it's worth, I think the easiest way to fix the rendering/classification problem is the US would be to ditch equating 'trunk' with "expressway", orthogonalize "expressway" with its own tag (since it's a physical attribute of a road and not a measure of importance), and make 'trunk' equal "most important cross-country routes" and then go down from there.

However, last time this was discussed on the us-talk mailing list, discussion devolved into a bloodbath that moderators eventually had to shut down. I doubt a true consensus about this issue will ever be reached in the US, but most often, 'trunk' is used for "expressway" so I am trying to tag that way as well.

Since these changesets undid a lot of the road class changes I made here, I should probably chime in. Lots of words and opinions ahead:

==========================

I agree with mapman44 that the ODOT classifications for both highway class and expressway are generally correct by OSM standards (can't say the same for many other states!).

With the OHP Highway Class layer on:

- Red is interstate which should obviously be 'motorway'.

- Green is a "statewide" route which nearly always correspond to 'primary' roads.

- Blue is a "regional" route - these ones are trickier. If the route is the best way between two decently sized cities where no other interstate or freeway services, then it should be primary. If the route only connects small towns or is mostly paralleled by a freeway, it should be secondary. Example - OR 99W is correctly classified as a primary for being the best way to get from Eugene to Corvallis. OR99E is INcorrectly classified as a 'primary' since it connects small towns and it mostly parallels I-5 through the Willamette - it doesn't really provide routing that the interstate doesn't do better, so it should be 'secondary'. They are both "regional" routes by OHP standards.

- Brown is a "district" route - these are nearly by definition 'secondary' roads ("A highway which is not part of a major route, but nevertheless forming a link in the national route network."). OR 238, a "district" route, is now incorrectly classified as a 'primary' when it should be 'secondary' - its function is mostly to connect Jacksonville, a mid-sized town, to more important roads. It is not an important, cross-country route, nor a major city artery, but instead a link in the network of more major roads. Ashland to Klamath Falls is right on the knife-edge of the primary/secondary divide, but ultimately I decided on secondary because OR 140 is the more important route, and provides a roughly similar network function (Rogue Valley <-> Klamath).

==========================

If 'primary' is going to be used in the US to mean "most important roads in network", then there is overuse of 'primary' in the US. These should be routes that either facilitate major cross-country travel where interstates don't, or are a small handful of the most significant arteries in a major city, whose alignment accomodates significant circulation where no freeway or expressway reaches. Notably, this is why I downgraded OR 99 from Ashland through northern Medford to 'secondary' - the 'primary' route through here is Interstate 5, and theortically OR 99 could be cut off between towns (Phoenix, Talent, etc) without causing TOO much of an issue, since again I-5 is the main artery through here.

I think a major factor in contributors being eager to use 'primary' for any decently major road is one, that it renders like it 'should', and two, to distinguish them from overclassified minor roads:

- (Opinions ahead!) On point one, I don't think the main OSM slippy map properly represents US roads when the mostly-consensual US classification scheme is correctly used. A better US renderer would render state and US routes at lower zooms regardless of OSM class - this is a discussion for a different time, but the point is, don't choose a higher class for a road simply so it shows up 'better' on the slippy map.

- Point two, many areas have waaaay too many minor routes classified too high. I think this stems from TIGER import classifing a ton of driveways and private services roads as residental, and then going from there. In rural areas, driveways (included shared) should be 'service', minor roads that provide local (often dead-end) access to residences are 'residential', minor roads/highways that collect rural traffic (most rural roads) are 'unclassified', and county-level highways that connect small towns or collect traffic towards region-level routes ('secondary's) should be 'tertiary'. Before jumping to 'primary', it's best to make sure adjacent roads aren't overclassified in the first place. Too often every two-lane road in a rural area with a center stripe is tagged 'tertiary', when many/most of them should be 'unclassified'.

==========================

Moving on to 'trunk', the consensus in the US is that 'trunk' should be used for expressways. These are usually high-speed, divided, limited access highways. In the mountainous west, it is not always physically possible to meet these requirements, so usually the way you distinguish an expressway is by access control - limited, if any, access to adjacent properties, intersections with a limited number of roads, occasional grade-seperated interchanges. The OHP Expressway layer in TransGIS nails this pretty well, and nearly every length road it lists as an expressway should be 'trunk' - even the two-lane roads, so long as you have verified that they have high access control.

==========================

Finally, I would caution against relying much on traffic counts to make classification decisions. Most major rural highways have much smaller traffic counts than any arbitrary urban artery, but the former is usually 'primary' while the latter is usually 'secondary'. Traffic counts are a consideration, but shouldn't be TOO much of a deciding factor.

This document doesn't state anything about "(Heavy Traffic Route)" being part of the highway name. Where is this coming from? Descriptions about the road don't belong in the name field.

Hello nemestrinus,

I noticed this changeset as well as a few others (69630583 for example) added 'bridge=yes' and 'layer=1' to large sections of a few trails and roads around the June Lake area. Please review your recent edits here to correct this. Thank you!

Bradley

Hello,
I noticed that this changeset set the far eastern section of CA 4 back to motorway. I believe this to be incorrect. Specifically:

- The RIRO intersection with WB CA 4 and Sycamore Ave is not physically divided (current ways in OSM are incorrect) which is not up to freeway standards in the US.

- The start/end points of the current trunk section on EB CA 4 as currently tagged are arbitrary, and there is no "End Freeway" or "Begin Freeway" signage as is typically in CA for point-failures of unfinished freeways (see: CA 99 & Sankey Rd, CA 149 & Shippee Rd, CA 17 & La Madrona/El Rancho) - evidence that this section is an expressway rather than a freeway.

See also:

- https://en.wikipedia.org/wiki/California_State_Route_4
"The road is an expressway from its starting point until it approaches Martinez, at which point it becomes a full freeway"

- https://www.cahighways.org/001-008.html#004
"However, it is not up to full freeway standards: many intersections are full right turns instead of gentle on- and off-ramps"

- http://www.dot.ca.gov/hq/tsip/hseb/crs_map/05k.pdf
State highways built to full freeway standards are nearly always classified as "Other Fwy or Expwy" on CA functional class maps; this section is not.

Motorway (and trunk, depending on who you're talking to) is the only 'highway' tag that is applied solely based on the physical attributes of the road. All roads that meet the physical standard for a freeway, regardless whether they are interstates, U.S. highways, state, county, municipal, etc... get the 'motorway' tag.

Why was this downgraded to trunk? This is a divided, high-speed (65 mph), grade separated, fully access controlled highway (a.k.a. a freeway) which is exactly the definition for "highway=motorway" (highway=motorway)

Hi Sebastien,

This changeset removed an import of USFS surface ownership that I had added many years ago. I agree that the visualization it produced is useful, which is why I added it in the first place. However, I ultimately decided to remove it for a number of reasons:

- I did not follow import guidelines per: osm.wiki/Import/Guidelines. While I am fairly certain this data is in the public domain, there still needs to be community buy-in and process documentation, neither of which I had done. If you wish to propose to add this data to talk-us, I can certainly help with the technical end. However, I am not convinced a majority will be on board here.

- The data itself hadn't been fully cleaned up. There were lots of excessive nodes, noisy areas, and it added to the massive problem of boundary misalignment already present in this area from previous imported data. Maintainability is always an issue for imports.

- Many of the areas blanket tagged "landuse=forest" didn't actually have managed forest land on them, making the tagging inaccurate in many places.

I plan on eventually working the data back in smaller, more accurate, and more manageable pieces. However, I do this as a hobby and it is quite time-consuming work. I am aware (and appreciative as a mountain biker!) of the work TDLT does in the area and also plan to soon add their holdings as nature reserves. Many of their holdings I have added already. I will try to add the SPI checkerboard conservation easements & corresponding natural work soon which will help bring back some of the missing visual information here. Let me know if you have any other questions; I will stick to changeset comments with this in case there are others curious as well.

For reference - this has been corrected with 61179606 and 61179535

The 'ref=NV 647' is incorrect through most of downtown Reno. Please see https://www.nevadadot.com/home/showdocument?id=4438 (page 197), you may also verify the lack of state route signage on-the-ground east of McCarran.

Why were all these roads upgraded to primary? Most of these roads are minor rural arteries that don't connect any major cities or carry any cross-country level traffic.

The trunk classification here was correct, by both the 'expressway' and 'most important' definition. Seconding that this should _not_ be secondary.

The changes were as listed above, I can't give exact details since I'm on vacation and won't be at my computer for another day or two. If you want the exact changes you might use the Revert plugin for JOSM on this changeset to pull the old data into one layer and the current dataset in another layer to compare between the two.

I'm only asking that you try to stick to established tagging guidelines, when they exist, in the context that this project is first and foremost a global geospatial database, and a slippy map second. Smudging things here and there so it shows up a bit better on the slippy map corrupts the consistency of the data.

More practically, I personally wouldn't have a problem with some of the more important towns that act as service hubs for the area being 'village's but tagging them as 'town's is (in my opinion) obviously incorrect given the definitions in the tagging guidelines. But, you are always free to tag as you wish and I will respect your decisions since you know the area much better than I do.

I would encourage you to search for a pending ticket, or open an issue ticket yourself on https://github.com/gravitystorm/openstreetmap-carto regarding that issue if you feel it is a problem. Hamlets *do* render on osm-carto, but only at high zoom level. Maybe you can make a case for lower level rendering. However, this is also a GIS database not just for northern California, but for the entire world, and I suspect most people will argue that a town of 60 people is not significant enough to be shown at low zoom. If every settlement of population greater than 50 was shown at low zoom, the map would be completely cluttered with name labels.

Alleghany still does not come close to meeting the definition for "place=town" as it is not by any stretch of the imagination "an important urban centre larger than a village and smaller than a city". The 2010 census lists 58 people living in Alleghany. Even if you were to double both the population and the amount of services available in Alleghany, it would still slot squarely into 'place=hamlet', defined as "A smaller rural community, typically with fewer than 100-200 inhabitants, and few infrastructure." Even Truckee just barely makes the cutoff for 'place=town', and it is larger than nearly all the towns (how you and I say, not the tag) within this changeset boundary combined.

My suspicion is that your motivation for this tagging choice is to see the name labels show up on lower zoom levels of the map (osm.wiki/Tagging_for_the_renderer). If this is the case I can certainly sympathize, because the standard renderer is biased towards dense areas and significantly under-represents most of rural USA even when tags are used correctly. However, this is a problem with the renderer, not with the tagging or database itself. If this is the case for you, I would consider proposing some ideas to the osm-carto group: https://github.com/gravitystorm/openstreetmap-carto.

If you don't like the name scheme for the 'place' tags or the way they are applied in the U.S. (also legitimate issues with OSM that I share), try starting a thread for discussion on the Talk-us (https://lists.openstreetmap.org/listinfo/talk-us) or Tagging (https://lists.openstreetmap.org/listinfo/tagging) mailing lists. Many of the most experienced and knowledgeable OSM contributors actively read and post on these lists, and would be more than happy to debate about these issues.

In either case, applying tags vastly out of the consensual norms for their use will simply see these changes reversed, if not be me, then by someone else eventually.