This proposal suggests to extend the use of the relation already specified in highway=traffic_mirror. While the existing specification requires the “from” and “to” members of the relation to be nodes, this proposal specifies how to use ways as “from” and “to” members of the relation. This is quite similar to how a relation is used for mapping of a turn restriction.
The two examples have to/from ways extending across the next intersection. It is more problematic with turn restrictions than with mirrors, but to ensure similarity, I recommend splitting the to/from way at the next intersection. This makes sure it is unambiguous if it only applies if someone drives the whole way or leaves at the first intersection, and it does not brake easily if someone else splits the way without seeing the relation.
Do you have a good example where one or multiple “via” ways might make sense? How would you describe such “via” ways? Are these all ways between the “from” and “to” ways? What is the difference between “to” and “via” ways? Are such “via” ways required to not be visible (through the mirror) from the “from” way? My feeling is that such situations might be better covered by allowing several “to” ways to be used in the relation.
It is a right turn on red restriction for bicycles, which is allowed after the bicycle has come to a stop. The bicycles have to stop at the traffic light. The cycleway is the from way. Between the traffic light (=stop position) and the intersecting street, the cycleway has been split, because the cycleway at the crossing has some extra tags. This short bicycle crossing way has the via role.
yes
I would say, either you don’t see the via way in the mirror, or you just don’t need the mirror, because the via is right in front of you, where you have perfect sight. There should be no announcement in any app, telling me “look for the mirror” if I just pass the “via” way and not the “to” way.
Traffic mirrors are not always at intersections, but can be mounted at curves of narrow streets. They help seeing a vehicle approaching in the opposite direction.
Example (the mirror is necessary when the field on the right side has high growing plants. It is a coincidence that there is also a small street branching off to the left):
The main street goes from the spot where the image was taken to the right. The mirror helps me seeing vehicles coming from the right (=the same street), and it helps drivers of vehicles coming from the right to see me.
Should there be two traffic mirror relations (with flipped to/from roles), or could we introduce some “both ways” tag to stay with one relation?
Perhaps the easiest solution is just leave the roles empty (via ways should still have via roles).
Adding some extra tag on the highway=traffic_mirror that describes the mirror and whether it works both ways or not (most don’t due to their shape focusing on one direction) could also help clarify the situation.
I think of this relation as an extension/clarification of the mirror, so I’d definitely stick to one relation if there is only one mirror.
Yes, it is also quite common on T-crossings to oneway street with low visibility with mirror at 45-degrees, where it provides help for both streets, e.g. here
Hm, I’m not sure it is the best, as it seems confusing and only partially mapped (did someone forgot to add role, or did they intended to mean both roles?)… Probably some new role should be invented instead.
I would prefer either:
separate newly-invented role for street (indicting that it could be eitherfromorto) - easiest for mappers
having two separate relations, one for each direction in which mirror helps - easiest for data consumers
having same street twice in the same relation, once with a from and one with a to role (probably not ideal for anyone, but at least not as ambiguous as not having role atribute at all)
In any case, whatever solution is chosen, it should be properly documented in the proposal and (later, if accepted) relation tag wiki.
Thanks for your input. The discussion made me think about a situation where the destination street includes a traffic island. Example: If turning left (in Continental Europe) from a side street into a main street, we could have a “from” street, a one-way “to” street (right of the traffic island) and a one-way “seen” street (left of the traffic island). Should we add a “seen” role? Is there a better name for this role?
Replying to myself: The existing proposal uses the “to” role for what I just called “seen”. If this inconsistency of the roles with those of the turn relation even confuses me, we should probably not re-use the “to” role, unless we talk about the path of the vehicle. It probably makes sense to change the proposed “to” role to a “seen” role or similar.
You want to go from A to B, not fromAto B.
If you change to to seen, you have also to change from to viewer. viewer/viewed maybe?
I’m not a British English native speaker.
Actually do we even care where we want to go? If I as driver am at an intersection and I have to give way, I will use the mirror regardless of my destination. I could turn right, go straight on or turn left. In (almost) all cases I have to check the mirror to check if passage is clear.
Thanks. The “from” street would still be the street that the vehicle comes from, which is basically the same as the way with the “from” role in a turn relation. Typically, I would consider it to be identical with your “viewer” street. In a turn relation, the street with the “to” role is the street that the vehicle is going to. However, this “to” street is not always identical with the street that can be seen through the mirror. I’m also not a BE native speaker, but my feeling is that a better expression for “seen” or “viewed” might be “visible”.
This would lead to (possibly) multiple relations, like in your example with the high-growing field, one for each viewpoint. Given that this is mostly for routing, that’s probably the most intuitive representation anyway and allows for incremental mapping without having to change tags.
I dont oppose two relations on one mirror, but I would prefer one. Maybe there could be special roles "bidirectional_viewpoint"or “viewpoint_and_target” (also no english native speaker here, feel free to improve the wording) to cover these.
Or, different approach, the mirror could get a reason= (or traffic_mirror:reason=) with possible values =narrow_road (vehicles from both directions need it) and =priority (only vehicles from one direction need it).
I think that I my initial understanding of the original node-based relation was wrong. This was due to the following: 1. The wiki page does not describe it well and does not point to an example. 2. The instances of traffic_mirror relation that I initially found on the map were wrongly implemented.
I think that I have now found a good example of the node-based relation Relation: 8529582 | OpenStreetMap . It is quite similar to the enforcement relation. The “from” node is placed near the point where the mirror can first be seen. The “to” node is placed near the point where it stops making sense to look at the mirror. Both are on the path of the vehicle. And of course the “mirror” node is the node tagged with “highway=traffic_mirror”. Using nodes has the advantage that the relation is less likely to be broken by map edits. However, this information is insufficient to know what can be seen through the mirror. (The “direction” tag of the mirror might be used, but that is quite complicated.)
The way-based relation as proposed has the following problem: The “to” role is misleading, because this way is not always the way that the vehicle is going to drive to. Instead, it might be better to change the role of this way to “visible”. (However, a member with a “to” role will be needed to determine the driving direction that the relation is relevant for.)
This would result in the following changes to the proposal:
Describe proper usage of “from” and “to” nodes. Explain how this is similar to an enforcement relation. Add good examples.
Drop ways with the roles “from”, “to”, “via” from the proposal.
Describe how nodes or ways with the role “visible” can be optional members of the relation.
@Nielkrokodil It probably makes sense to try out the different concepts with a bidirectional mirror and check how they work. Can you point out an example on the map?
@Nielkrokodil The “reasons” that you listed might depend on the personal judgement of the mapper. Maybe the “description” tag is more flexible and more useful for the few situations where additional information about the mirror is needed?
Example 2: Create one “bidirectional” relation: The relations has 7 ordered members:
mirror
from
to
visible
from
to
visible
The idea is that for each “from”/“to” pair all “visible” elements follow directly. If there is a second “from”/“to” pair, it is placed behind the first “visible group”. All “visible” elements after that belong to the second direction. Relation: 21219550 | OpenStreetMap