This only affected U.S. Route 61 in Missouri.

Please let me know if this changed something wrongly. I am very confident it was only an improvement, as there were many gaps and a mix of forward/backward and north/south roles (I changed everything over to the latter).

This northbound piece of North Truman Boulevard was only in US 67 relation, but the opposing way was correctly in both US 67 and US 61 relations.

No sources cited because this is just in OSM.

Make that "six", and include O and M.

I also added is_in:county tags to relations for all four mentioned supplemental route relations.

Bounding box is large because I added layer=4 and layer=5 tags on two power lines crossing roads I touched.

Specifically added missing water bodies, smoothed some roads, added a tower crane, and added missing power towers (some of which were incorrectly tagged as poles and the rest untagged altogether).

Source: Bing Aerial Imagery; Esri Clarity; Bing StreetSide; MoDOT travelway definitions (via MSDIS Open Data Portal)

I also added some stop signs, and I smoothed some roads.

Bounding box is large because I unglued some power lines which have been glued since TIGER.

Latest imagery seems to show oxbow lakes formed in an area previously filled along Old River, as well, so I added those.

The shadow is visible in Esri Clarity, and I aligned Clarity to match Bing.

The pavement color changed at the exact same spot as the Arkansas welcome sign, so I used that as the transition between MO NN and AR 181. This does not line up perfectly with the TIGER line, but that's par for the course with TIGER imho.

Bounding box is large due to setting layer=5 on a power line.

^ Reason for this is because USGSHydroCached isn't precise about exactly where a named stretch ends, so I inferred that based on waterway connections. There likely isn't an issue.

Some names need to be verified.

Route E does not continue to MO 164. That is DD, and I'll get to that later tonight.

This changeset also touched up some ways in the relation for A which was added in my previous changeset.

^ However, MO B is signed on either end of the concurrency, and there is a well-established convention that letters aren't reused that closely together (exceptions exist, but this isn't one of them imho).

There is an unsigned concurrency of MO B on MO 162. MoDOT acknowledges this in their TMS open data set, but signs on the ground just recognize MO 162.