FYI this is not a state business route. It's a local route named North/South Business Route 5. It probably still deserves a route relation for semantics, but it's not in the US:MO:Business network.

And #155354621

This is a large bounding box, but the edits are very sparse. Everything was done manually.

I copied and pasted the text in my previous comment from my comments on changeset #155351001, so that's why it reads awkwardly.

We try to avoid abbreviation in OSM unless the "true" name contains the abbreviation...that's always a case-by-case debate, but in this case it should have been "Highway" if anything.

And to be clear, this road is named, but it's not a simple string name that can be canonicalized in the name tag. This is a state road designated as part of State Route 7...or Route 7, State Highway 7, Highway 7, Missouri 7, etc. That's the issue: there is not a canonical text rendering of this designation. So we use route relations to convey this and also ref tags for data consumers that don't process the route relations.

I did not add noname=yes back to the ways

Also Hwy is an abbreviation, and we try to avoid those on OSM unless the "true" name contains the abbreviation...that's always a case-by-case debate, but in this case it should have been "Highway" if anything

To be clear, this road is named, but it's not a simple string name that can be canonicalized in the name tag. This is a state road designated as part of State Route 248...or Route 248, State Highway 248, Highway 248, Missouri 248, etc. That's the issue: there is not a canonical text rendering of this designation. So we use route relations to convey this and also ref tags for data consumers that don't process the route relations.

Although, in hindsight, it looks like only SSRs were impacted. So the typo is correct!

Also, I made a typo in the comment: SSRs should just be SRs. This covers more than just supplemental routes.

There was also an instance where the name tag on an SSR used a semicolon delimiter...so I removed that.

Continued in changeset #155350752

Also, I saw one instance of justification for some of these redundant way-names as making the road match with addr:street on nearby buildings. This is tricky, as it runs into the same issue I outlined two comments up: our road network is highly decentralized in the US, and many entities cooperate with loose terminology. When a county applies physical addresses to land parcels, it may do so with the form "Hwy 67" instead of "Lindbergh Boulevard", but that IMHO does not justify renaming the road to a variant of the former.

^ Even that has exceptions, though, such as "Business 13" in Branson West.

This is done in an effort to help normalize nomenclature across the Missouri state highway system. As it currently stands, ways can use any number of name strings from "Route X" to "State Road X" to "Highway X" to the most common, and most TIGERish, "State Highway X".

It's important to recognize that, when a MoDOT sign indicates a road is named "Route X" or "Hwy X", that's not the canonical name string. That's a systematic designation of the road segment as belonging to the X route in the broader state route system.

Additionally, I removed a few "is_in" tags containing strings of the format "{countyname}, MO" and some ZIP codes (?) in both postal_code and addr:postcode tags

Each route connects to both directions of US 65, so there is a slight overlap in the middle.

I also added lane counts, turn restrictions, and service roads; and I smoothed some ways out.

I also smoothed out ways, adjusted lane counts, and added some smaller roads like driveways and service roads.

I also added stop signs, a yield sign, and smoothed out the ways.

There was a road segment previously mapped as a secondary_link road which is actually a proper designated route segment (MO 49). If you're just looking at designations, then the intersection looks like a Y. The road segment that closes the triangle is actually an undesignated connector segment inline with MO 49 to the south and MO 21/72 to the north.