Talk:Missouri state highways
Article Introduction
I added an introduction to the article since I felt the existing intro was stale and misleading. It made no mention of lettered (supplemental) routes. The even/odd direction rule also has exceptions that I thought needed to be qualified. I'm not an expert, I just think we need better documentation to help tackle our uncountably many state routes that need fixups :) TyFi (talk) 04:42, 19 June 2023 (UTC)
Blue/Orange I-55 Bypass Routes
Does anybody have details about the blue and orange I-55 bypass routes in St. Louis County and Jefferson County? I couldn't find anything about them on Google but it could exist somewhere deep on MoDOT's website. Here are some StreetSide shots of the signage for what I'm talking about:
- U.S. 61/67 N
- https://www.bing.com/maps?cp=38.34343%7E-90.386473&lvl=19.7&pi=-1.4&style=x&dir=112.1 (orange left and forward; just south of M)
- https://www.bing.com/maps?cp=38.368152%7E-90.376178&lvl=19.7&pi=-1.9&style=x&dir=38.7 (orange forward; just north of K)
- https://www.bing.com/maps?cp=38.409483%7E-90.381232&lvl=20.8&pi=-3.4&style=x&dir=21.1 (orange left and forward)
- https://www.bing.com/maps?cp=38.431999%7E-90.378856&lvl=20.2&pi=-3.2&style=x&dir=97.4 (orange forward; by Arnold post office)
- https://www.bing.com/maps?cp=38.437424%7E-90.373952&lvl=22.0&pi=-4.5&style=x&dir=33.3 (orange forward; by donut store)
- https://www.bing.com/maps?cp=38.443794%7E-90.373827&lvl=22.0&pi=-6.6&style=x&dir=43.9 (orange left and forward)
- https://www.bing.com/maps?cp=38.464324%7E-90.357303&lvl=21.3&pi=-1.6&style=x&dir=63.3 (orange left and forward)
- https://www.bing.com/maps?cp=38.485088%7E-90.349024&lvl=20.9&pi=-1&style=x&dir=72.7 (orange left and forward)
- https://www.bing.com/maps?cp=38.500892%7E-90.332719&lvl=18.2&pi=4&style=x&dir=95.2 (orange forward; by Lemay Walgreens)
- https://www.bing.com/maps?cp=38.50349%7E-90.32903&lvl=20.1&pi=17.6&style=x&dir=92.2 (orange right; on ramp to I255)
- https://www.bing.com/maps?cp=38.444112%7E-90.375058&lvl=20.5&pi=-1.6&style=x&dir=130
- https://www.bing.com/maps?cp=38.464923%7E-90.357943&lvl=20.4&pi=3.3&style=x&dir=144.2
TyFi (talk) 04:42, 19 June 2023 (UTC) (Updated 00:41, 21 June 2023 (UTC))
This bypass route follows US-61 the entire way, which makes me think it is just a marker describing how to bypass this section of I-55 and is not actually the road’s designation. Also, interstates (as of my current knowledge) do not have any other bypass routes. --ilikeeditingandcontributing (talk) 17:43, 21 June 2023 (UTC)
Yeah I figured it was a minor thing but the colors really interested me haha, thanks TyFi (talk) 18:00, 21 June 2023 (UTC)
- @TyFi: These are what the national MUTCD calls "color-coded destination guide signs". [1] They can be used for any purpose, not only bypass routes. destination:colour=* might be useful for tagging these situations. Branson has taken this concept to such a degree that their color-coded destinations are indistinguishable from designated routes, so we've taken to mapping them as route relations. I think you could make a case that these are indeed routes that have designated colors, in which case I'd tag them as network=US:I:Bypass colour=orange etc. – Minh Nguyễn 💬 21:40, 22 June 2023 (UTC)
- Ah, it makes sense that they're the same class of sign. I knew about Branson's color-coded routes, but I didn't know the underlying signage was as versatile as it is, so thanks for the MUTCD reference. I was particularly interested because afaict nobody around here knows about the blue and orange coloring which makes me think the whole idea was half-baked. It's not on any state, county, or municipal map I've seen. These sign assemblies don't show up on MoDOT's online sign inventory, so maybe the counties own them. Oh, well TyFi (talk) 17:03, 23 June 2023 (UTC)
- @TyFi: I think this is often true of Interstate detour/bypass/alternate routes. The ones in the Cincinnati area exist solely as decades-old signs and an occasional newspaper article, but there's no trace of them in official records. – Minh Nguyễn 💬 21:58, 23 June 2023 (UTC)
To Name or Not to Name (Ways)
We have many state routes where the ways themselves, not the relations, are named things like "State Highway 100" or "Highway Z" or "Route N" or "Missouri BB" or "State Road A". I have seen all of these forms in the wild. I know these forms of names originated from a TIGER import, but the "State Highway" form specifically has been added back manually on a few occasions by a few mappers. The glaring issue I see with naming ways like this, though, is concurrency. I admit it doesn't affect the semantics of the map too badly to, e.g., tag a way with name=State Highway 21 and alt_name=State Highway B since the route relations support concurrency by their nature, but it's misleading to see "State Highway 21" rendered as the name of the road. If that concern is a bit too adjacent to tagging for the renderer, then the documentation for name=* says to use the "most obvious" name. But is 21 really more obvious than B in that example? The name=* article falls back to the "on the ground" principle when there's disagreement, but the green signs actually say "Route B" and "MO 21" (and those forms are not consistent along the length of the routes). What about when two supplementals are concurrent, e.g., Route N and Route O? The route relations fully qualify the routes, and data consumers are more than capable of parsing this, though the ref=* tag on the ways is easier to parse and enables Carto's pancake shields.
The wiki has recommended removal of these name tags since 2009, and I have actually gone a step further than that and added noname=yes tags on many road ways known only by the routes they carry. This can be done on a way-by-way basis for a long distance road known by different names in different localities, so that's what I recommend. The only reason I can think of for wanting these names is possibly for geocoding, but that would be a pretty fragile geocoder if it relies on that. I am open to discussion on this, though, because my mind could just be stuck after thinking about it for too long and there's a more obvious reason.
TyFi (talk) 01:19, 20 June 2023 (UTC)
Standardized naming for the relations
Is there any known standard for naming the state route relations? e. g. "State Route x", "Missouri Route x", etc. I have been mapping them as "Missouri Route x" with county/city parentheses after if needed and putting modifiers (business, alternate, etc.) after the name; however, I don't know if this style is correct. In some other places, they are mapped as "Business MO 13" or "State Route 13 Business" as well as other variations. --ilikeeditingandcontributing (talk) 19:12, 21 June 2023 (UTC)
- There is no consensus on this afaik. I think at some point I named a bunch of unnamed route relations with the "Missouri Route # (County)" format. I think "State Highway X", "State Route X", "SR X", etc., are too vague when editing near the state border. The "Missouri Route # (County)" format is generally used for Wikipedia article titles, but IMO we don't need to be super picky about what goes in the parentheses as long as it's helpful and unambiguous. Some consistency would be nice TyFi (talk) 22:22, 21 June 2023 (UTC)
I feel like the "Missouri Route # (County)" format is probably the best. If there's no consensus, might as well make one now to increase consistency! I'll add it to the page if you agree. --ilikeeditingandcontributing (talk) 23:25, 21 June 2023 (UTC)
- There is an example somewhere in southwest MO (I can't remember where) where two of the same letter are used in close proximity within the same county (because of course there is), so we might have to break the format sometimes to keep names helpful for editors because that's really the point of the route relation names I think. I can't really think of a reason why a data consumer would need to touch the name tag on a US:MO route relation (or U.S. routes or interstates). TyFi (talk) 00:55, 22 June 2023 (UTC)
It has been added.--ilikeeditingandcontributing (talk) 04:35, 22 June 2023 (UTC)
@TyFi and Asdvfasdfvwerbtewrbtewrbter: Ideally, name=* would be reserved for routes with names that aren't based on other tags like ref=*, or if they are systematic names, then kept as simple as possible. I don't think it should be necessary to replicate Wikipedia's article naming convention within name=*. For one thing, we don't have the constraint that relation names must be unique.
In some other states, mappers have long used keys like is_in:county=*, is_in:city=*, from=*, and to=* to distinguish routes with the same number in the same system but in different places, for example a series of unrelated Interstate business routes branching off the same Interstate. Another example would be the original Route 110 in Jefferson County and the newer Route 110 that's part of the CKC Expressway.
iD currently labels relations based on network=* and ref=*, or name=* if present, with from=* and to=* as disambiguators. It would be pretty straightforward for it to append is_in:county=* as a disambiguator without requiring mappers to manually conform to a naming convention.
– Minh Nguyễn 💬 01:09, 23 June 2023 (UTC)
- @Minh Nguyen: I agree in principle that name=* should not rephrase the other tags.
In practice, however, we already have these other relation names in use: Missouri Highway 114, Missouri Route 76, Missouri State Highway 41, MO J Spur (South West City, MO), State Highway 58 Spur (Centerview, MO), and State Route 179. The only way I can think of a data consumer finding these redundant values useful is using a heuristic to determine if name=* is just a rephrasing and then ignoring those cases, but that seems very fragile to use.
So my logic when calling for naming consistency was that instead of being fragile to use and inconsistent, it might as well only be fragile to use 😅. The Wikipedia title format was just an example of an existing naming scheme. I do like the idea of using other tags for disambiguation, though, and I've been consistently using is_in:state=MO for example.
The from=* and to=* tags feel a bit pseudo-machine-readable in that their purposes are well-defined, but their domains are completely unrestricted (could be city, county, name of an intersecting road, another route carried by said intersecting road, or one of many name strings of said route). But if from=* and to=* have any level of editor UI support for disambiguating routes in a list of relations then that seems like a very strong reason to use them rather than manually conforming to a naming convention, so from now on I will start applying those tags as well. TyFi (talk) 18:50, 23 June 2023 (UTC)
- @Minh Nguyen: I agree in principle that name=* should not rephrase the other tags.