This proposal specifies use of the key traffic_mirror=* for tagging of the specific kinds of traffic mirrors, such as dead-angle traffic mirrors or bidirectional mirrors in curves. It also specifies how to use this key for tagging of traffic mirrors if they are a secondary feature, for example if the traffic mirror is mounted to a street lamp. The tag is intended to be used for the node.
(The ideas for such tags already came up in recent discussions about the proposal for an enhanced traffic mirror relation, but were outside the scope of that proposal. So, this new proposal is part of the cleanup process after acceptance of the relation proposal.)
Some mappers have tagged attributes like mirror_curvature=convex, shape=semicircular,support=wall_mounted, or added information as a description or a note that is usually covered by a ref tag.
Apparently, some mappers have used traffic_signals:mirror=yes , probably to indicate that a traffic mirror is attached to a traffic light? This might be an example of a tagging a traffic mirror as a secondary feature, but I can’t find any documentation of the tag.
The two main elements of the (current) proposal, “bidi and dead_angle” can be derived off a recently approved traffic mirror relation.
Why would we tag it twice? Is a relation seen as refined tagging of the node? Should the relation replace the tags on the node, or should the tags on the node stay when a relation is created?
This is a traffic light with mirrors. The mirrors help cars from the left (behind the bridge) to see cars from the point of view. The mirrors are useful in case of a service interruption of the traffic lights.
Thanks! I tend to consider this to be a “traffic mirror that is only relevant if the traffic light fails”. It would be distracting for the driver to be always told by a navigation system to look at this traffic mirror when approaching the junction.
How do we more generally deal with such backup features that only become relevant when a traffic light fails? Most junctions have priority, give-way and stop signs for such situations. My impression is that those signs are typically not mapped right now.
A very simple option for new mappers might be to combine highway=traffic_mirror (or possibly traffic_mirror=yes) with a description in their native language.
I dont like the description= idea. Things which could be mapped should not go into description. If you dont want to / be able to map it, but want to leave information for other mappers (or yourself) then leave a note.
We decided to not map them as they are usually irrelevant. But at traffic signals, which operate only at certain hours (= the traffic sign is relevant otherwise), we did not come to a solution.
The problem I see is, that the purpose of the traffic mirror is not easily to identify for everybody. If someone sees a not-yet-mapped mirror, they should be able to map it without thinking if the mirror is only a backup. I would suggest an new traffic_mirror= value for this kind of mirror. Maybe =traffic_signals_backup?
My thinking was: Things which are not yet tagged should be in the description. This allows map users to read this information. Experienced mappers can then apply the correct tags or relations - and then either delete (or shorten) the description or move information to a note if needed to explain to other mappers why the tags were applied.
This depends on who is intended to read the text. In my opinion, a description could say “This is a dead angle mirror” (while no relation has been added) but only a note could say “Two relations, because this is a bidirectional mirror”.
it is a possibility, but generally inventing a semantic tag (after you found nothing in taginfo) is better IMHO, this way sooner or later a tag can emerge because several people had the same idea. In description, things are usually not found.
As similar existing example in OSM is public_transport=stop_position. Many tags (name, ref, …) are “recommended” at the node, but if a stop_area relation exists, they are only “optional” at the node.
This means both ways of tagging can coexist. The information is kind of a duplicate, but the derivation off the relation, to know if its a bidirectional or dead_angle mirror will be pretty hard, maybe it cannot be computed at all in special cases (How would you know a dead angle mirror for a separately mapped cycleway?). So I guess some data users will have an advantage if it is mapped both ways.
So we could propose, the mirror can be
mapped as a relation, and, additionally (optional)
Ok. However, if the information is important enough to be shown to map users, then it should also be put into a description. A note will typically only be shown to other mappers and not to map users.
There’s a difference here. The stop_area relation will contain the name or ref tag, and all members will inherit these tags of the relation. It is currently not defined for traffic_mirror relations to contain the tag traffic_mirror=*, and it would also not make sense to add it there.
Where for public transport the stop_area relation concentrates the information of several stop_position elements, for a bidirectional traffic mirror it is the traffic_mirror node that concentrates the information about two traffic_mirror relations.