Traffic mirror relation - how to go from wiki docs to mapped features?

The OSM feature wiki page on traffic mirrors documents both node-based as well relation-based tagging schemes.

While nodes tagged ‘highway=traffic_mirror’ sum up to nearly 25k, taginfo stats reported zero(!) existing relation ‘type=traffic_mirror’, when I stumbled over this topic. On feature’s discussion wiki page I read from other mappers similar issues like mine to understand the relation-related documentation part. After putting my own feelings and proposal in there I realized, a better place to ask for comments and more ideas might be in the forum, so here I am with an abstract from the OSM discussion wiki page content.

A recommended alternativ to a node is a relation ‘type=traffic_mirror’. Especially the current explanation for ‘role=to’ in English as well as German translation is vague. Not being a native English speaker I still attempt to suggest a solution with ease of tagging in mind as well as getting more relevant information:

  1. role=device - mirror position, in contrast to documented ‘role=mirror’, reasons: ‘device’ already used for other relations plus option for being more specific on mirror built variant, if some sees need for that
  2. role=from - give-way or stop position (ok, nothing seems vague here)
  3. role=section - the way given insight to by that particular mirror - look-ahead part of the otherwise barely visible or invisible way (OSM wiki: “… other direction you can watch in the mirror”)
  4. role=to - (optionally) one or more relevant destination ways that require looking ahead at traffic to be reached safely

on 1: Is it reasonable (enough) to be more generic than ‘mirror’, if documented after the discussion here?

on 3: Seems tagging the revealed (section of) way a lot easier than estimating or measuring mirror angle or similar properties to others too? IMHO tagging shouldn’t require an physics course on optic or the like. :wink:

on 4: Seems most vague from wiki, even a node on a way on-wards might be sufficient.

2 is certainly most valuable to find objects relevant for the current navigation path, 3 and 4 for rendering or highlighting a mirror an it’s direction in a fictional augmented reality driver display.

See relation 17552472 for an example as I see best fit/use for the power of relation-based tagging.