I’ve opened a discussion on how best to tag paired oneway traffic signs, here:
https://wiki.openstreetmap.org/wiki/Talk:MUTCD/R#Handling_paired_oneway_signs_(R6-1R_and_R6-1L)
@Minh_Nguyen @salisburymistake I’d particularly be interested in your thoughts.
At @salisburymistake’s request, let’s move the discussion back here for a wider audience than that obscure wiki talk page.
The question is about signs posted back to back that contain arrows pointing in the same absolute direction and thus the opposite direction relative to the motorist. Typically, the MUTCD assigns a separate code for each variant of the sign, suffixed with an L or R indicating the direction.
Specifically, this changeset dealt with a post with two one-way signs back to back:
The changeset puts a single node at the location of the post, combining the two physical signs into a single node:
traffic_sign=US:R6-1R;US:R6-1Ldirection=0;180The idea is that a query or data consumer would pair US:R6-1R with 0 and US:R6-1L with 180. I think this approach is fine in this situation. Interpreting it any other way would lead to nonsensical results. However, it might not fare so well in other situations.
The following photo shows three examples of back-to-back signs on the same post: R6-2L and R6-2R one-way signs, a double-sided D3-1 street name sign above it, and another double-sided D3-1 above that, crossing at a right angle. This assembly or one like it happens anywhere a one-way street intersects with a two-way street:
Many destination and other guide signs are also posted back-to-back. This sign assembly has one set of destinations on the front and another set on the back (replacing Chestertown with Lake George). direction=125;305 is ambiguous because there are multiple destinations per side.
Many jurisdictional boundary signs are also posted back-to-back. The wiki recommends setting city_limit=both but setting direction=* to a single value as if there’s only one sign facing traffic entering the city. (There’s no word on how to handle boundaries between two adjacent cities, so that both sides say “entering”.) Unfortunately, this pattern doesn’t naturally extend to other kinds of signs, such as one-way signs.
There is an older practice of gluing the node to the roadway, which allows for differing traffic_sign:forward=* and traffic_sign:backward=* tags, but this is rarely practical for one-way signs, which appear at street corners in order to be read from multiple directions. For other kinds of features, such as advertising billboards, some mappers have mapped a way instead of a simple node, which allows for *:left=* and *:right=* tagging. However, a way would be utterly pedantic for a sign that’s barely wide enough to appear in high-resolution aerial imagery.
Typically, I map multiple signs whenever the contents of one side differs from the other side, such as at this county line. Validators already allow coincident traffic sign nodes that have differing layer=* tags, so I figure it’s not much trouble to also allow coincident nodes with opposite direction=* tags too.
That makes sense to me. The one case where I would continue to use multiple direction values is if all the other tags are the same (as is often the case with double-sided street signs).
We should identify the validators and make PRs for them to handle differing direction tags.
