Talk:MUTCD/R
Metric
@Revent: For clarity, we should make sure to limit this page to signs that are part of the current standard. Otherwise, there will inevitably be contradictory information in the tables as signs periodically get renumbered. We could set up a page for no-longer-standard signs, limited to the ones without a target compliance date for removal or a date that's in the future. The metric signs have actually been removed from the federal MUTCD as of the 2009 edition. However, it's possible that some states have retained them in state MUTCDs, in which case we should relegate the signs to the respective state-specific page. Moreover, if I'm not mistaken, the km/h speed limit signs are only posted in the U.S. in conjunction with mph signs, even in Puerto Rico, so maxspeed=* would be set to an mph value exclusively. – Minh Nguyễn 💬 05:05, 4 August 2021 (UTC)
Handling paired oneway signs (R6-1R and R6-1L)
A very common situation is a pair of the smaller oneway signs, with one pointing in each direction (since they are facing in opposite directions). It's unclear to me the right way to tag this. User:salisburymistake has done valiant work in this area, as can be seen here, but I'm not sure how to summarize it. The open questions include: What should the traffic_sign=* value be (options include just US:R6-1, or always using US:R6-1R;US:R6-1L, or using both orders in different circumstances, and probably other options as well)? What should the direction=* value be (presumably it should include both directions (180 degrees apart), but which one should be first)? And there may be other questions I haven't thought of. JesseFW (talk) 14:19, 26 April 2024 (UTC)
- @JesseFW: This is a major reason why I favor mapping multiple nodes, one per sign. If we’re already micromapping, why not believe in it? – Minh Nguyễn 💬 14:40, 26 April 2024 (UTC)
- @Minh Nguyen: Oh, I'm already a big fan of your idea of multiple-nodes-one-per-sign. The problem I'm running into is that in this case, the two different sign IDs are on the same layer=* so I'm not sure how to handle that. But putting each one in a separate node certainly addresses the ordering and direction issues. JesseFW (talk) 14:58, 26 April 2024 (UTC)
- Admittedly I don’t have a great answer for signs placed back-to-back. Maybe validators could allow two coincident sign nodes to share the same layer=* if they have opposite direction=* tags. Or you could spread the two nodes ever so slightly apart, taking advantage of the fact that there’s usually a gap of a couple inches between the signs. (Yes, we’re splitting hairs here.) – Minh Nguyễn 💬 15:08, 26 April 2024 (UTC)
- Yeah, that's why I thought the other options (not specifying the L/R; always using the same order, etc.) would be worth considering. Let's see what @Salisburymistake: has to say. JesseFW (talk) 15:47, 26 April 2024 (UTC)
- Admittedly I don’t have a great answer for signs placed back-to-back. Maybe validators could allow two coincident sign nodes to share the same layer=* if they have opposite direction=* tags. Or you could spread the two nodes ever so slightly apart, taking advantage of the fact that there’s usually a gap of a couple inches between the signs. (Yes, we’re splitting hairs here.) – Minh Nguyễn 💬 15:08, 26 April 2024 (UTC)
- The order of operations I use starts with direction sorted smallest to greatest (0-359), then from top to bottom on each direction. So say you have a pole with two signs pointed north and another pointed south. You'd start with the north first (direction=0) and add the values for those two signs, semi-colon delimited (e.g. "US:R1-1;US:R1-3P"). If there were only those two signs, I'd just leave it at direction=0 because it's easy to infer that it applies to both signs. But if there were a "do not enter sign" on the same pole facing the opposite direction, I'd add it into the semi-colon delimited list like "US:R1-1;US:R1-3P;US:R5-1" and then create a one-to-one mapping in the direction tag with "0;0;180". It makes the most sense to me, currently. - salisburymistake (talk) 18:02, 26 April 2024 (UTC)
- Thanks! So, in this case, with a oneway road with traffic running from west to east, a paired one-way sign on the north side of the road would be: traffic_sign=US:R6-1L;US:R6-1R and direction=0;180. Is that right? JesseFW (talk) 18:21, 26 April 2024 (UTC)
- Yep, that's how I'd do it. But I suppose it doesn't really matter what order you do the directions in, as long as the lists in both tags match up. I just start from 0 to both be consistent and make it easier to visualize in my brain when I'm doing it. - salisburymistake (talk) 18:31, 26 April 2024 (UTC)
- Thanks! So, in this case, with a oneway road with traffic running from west to east, a paired one-way sign on the north side of the road would be: traffic_sign=US:R6-1L;US:R6-1R and direction=0;180. Is that right? JesseFW (talk) 18:21, 26 April 2024 (UTC)
- The order of operations I use starts with direction sorted smallest to greatest (0-359), then from top to bottom on each direction. So say you have a pole with two signs pointed north and another pointed south. You'd start with the north first (direction=0) and add the values for those two signs, semi-colon delimited (e.g. "US:R1-1;US:R1-3P"). If there were only those two signs, I'd just leave it at direction=0 because it's easy to infer that it applies to both signs. But if there were a "do not enter sign" on the same pole facing the opposite direction, I'd add it into the semi-colon delimited list like "US:R1-1;US:R1-3P;US:R5-1" and then create a one-to-one mapping in the direction tag with "0;0;180". It makes the most sense to me, currently. - salisburymistake (talk) 18:02, 26 April 2024 (UTC)
Further examples/analysis: If the direction of traffic is 90 (i.e. East), then it's L;R (0;180). If traffic is 180 (South), then the signs are 90;270 and they are still L;R. But if traffic is the other two ways (West or North), it switches. It switches when the traffic direction is past South (which implies the signs are 1;181 or higher. Not sure if that made sense. :-) JesseFW (talk) 18:40, 26 April 2024 (UTC)
Parallel semicolon-delimited lists are better than nothing, but this approach only works for something like direction=* that inherently applies to every sign. On the other hand, it would get a lot messier for something like destination=* or colour=*: some signs can have multiple values and others can have none. Guide signs and street name signs commonly have this need, and they're often posted back to back. – Minh Nguyễn 💬 18:20, 27 April 2024 (UTC)
- Totally agree. Currently, when it comes to traffic signs, literally the only things I tag are traffic_sign=* and direction=*, so my methodology works for now. And at the very least - as long as I'm consistent with it - it shouldn't be too much of a hassle to update them when/if something better comes along. I'd imagine we could script something that would break them all out into separate nodes if we wanted, even.
- At the same time, I don't see why we can't maintain parallel semicolon-delimited lists with those other tags. Look at turn:lanes=* for example. That one uses vertical bars (|) to separate values (for some inexplicable reason), BUT it's also common form to denote "none" or to leave a value blank when it doesn't apply to an item in the list. I don't see why we couldn't do similar for traffic signs. If the destination or colour isn't applicable to a given sign, just put "none" or leave that value blank in the list for those tags. And if we wanted to provide multiple values within an item in that list... well, now we're getting into a whole other mess: how to do lists within lists in tags. Semicolons seem (aside from the aforementioned turn:lanes thing) to be top level for this. Commas next, probably.
- I don't know that I want to get into this. Point is, I don't think it's impossible. We can figure this out. If you guys are in the US Slack or the forums, I'd rather hash this out there. This is my first time having to deal with a wiki discussion, and honestly... it's not ideal. Not a fan. Plus, I think it would be cool to have more input from others on all of this. The discussion page of a specific OSM wiki page is like, maybe one of the most esoteric things that exists in the world. We are a subset of a subset of a subset of OSM folks. If the goal of this discussion is to come to some consensus on how to tag something, then it shouldn't be decided by the 3 of us. - salisburymistake (talk) 19:12, 27 April 2024 (UTC)
I also created a topic on the forum for this; glad to have the discussion there, instead: https://community.openstreetmap.org/t/handling-paired-oneway-signs/112368 . In any case, I appreciate the comments! JesseFW (talk) 21:07, 27 April 2024 (UTC)