This changeset focused on a business route of Missouri Route 5 in Camdenton, Missouri.

This is a strange business route, as it's not acknowledged by MoDOT as one. It would appear local government designated it as such, and it functions just like one, so...

Docs for the historic site call it RA 13 which is nomenclature I've not seen before...

I don't know the history of route alignments in this area, but MoDOT data does, indeed, support John Shea Drive being MO 13 Spur despite the fact that it does not currently connect to MO 13. (Its travelways are designated SP 13 N and SP 13 S.)

^ Looks like a relation already exists for it: #7785857

modifier does not go on road ways. That tag is meant for use in route relations.

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