Note the differentiation between traffic_sign details mapped as a property of a highway=stop vs a traffic_sign mapped as a standalone feature.
The approach I use is:
- Map traffic signs where they are in reality, as an unattached node.
Example, a south-facing stop sign on a post:
traffic_sign=US:R1-1+traffic_sign:direction=180+traffic_sign:support=post
preset details
(from my seattle_stops_and_signs.xml JOSM preset)
<item name="01. Traffic Sign" type="node">
<label text="Traffic Sign" />
<combo key="traffic_sign:direction" text="Traffic Sign Direction (0-359)" values="0,90,180,270,N,S,E,W" default="" />
<combo key="traffic_sign" text="Traffic Sign Type" values="US:R1-1,US:R1-2,US:R2-1,US:R5-1,US:R8-3,US:OM1-3,US:W14-1" display_values="Stop,Yield,Speed Limit,Do Not Enter,No Parking,Yellow Diamond,Dead End" default="US:R1-1" />
<combo key="traffic_sign:support" text="Traffic Sign Support" values="post,pole,gantry,wire,tree,wall" display_values="Post,Pole,Gantry,Wire,Tree,Wall" default="post" />
<text key="ref:US-WA:SDOT" text="SDOT Unit ID" default="" />
<combo key="operator" text="Operator" values="Seattle Department of Transportation" default="Seattle Department of Transportation" />
<combo key="operator:wikidata" text="Operator (Wikidata)" values="Q39052410" default="Q39052410" />
<combo key="operator:short" text="Operator (Short)" values="SDOT" default="SDOT" />
</item>
- Map the implication of the traffic sign as a node on the corresponding highway way
Example, implication of that south-facing stop sign:
highway=stop+direction=forward+traffic_sign=separate
preset details
(from my seattle_stops_and_signs.xml JOSM preset)
<item name="03. Implication" type="node">
<label text="Implication" />
<combo key="highway" text="Implication Type" values="stop,give_way" display_values="Stop,Yield" default="stop" />
<combo key="direction" text="Direction" values="forward,backward" display_values="Forward,Backward" default="" />
<combo key="traffic_sign" text="Traffic Sign" values="separate" display_values="Mapped Separately" default="separate" />
</item>
This way, all of the little details about the traffic sign itself are offloaded to the separately mapped node, and the functional routing-relevant implications of that sign (that drivers have to stop there) are what’s tagged on the node that’s part of the highway.
If the sign is already being mapped as a free-floating node, where direction refers to the direction to which the sign itself is pointing, then why prefix with the feature type?
Well, when multiple features are mapped on the same element, namespacing the details in a <feature>:<attribute>=<value> model is the only way to disambiguate which attribute value belongs to which feature.
Say there’s a utility pole with a streetlight, a surveillance camera, and a stop sign: you’d need to specify light:direction=*+camera:direction=*+traffic_sign:direction=*.
That’s not necessarily ideal, but the other options (stacked nodes or relations) seem worse to me, so I just add the redundant feature prefix to bypass the issue.
Maybe I should add highway=stop_sign to my preset as the “feature-identifying tag” for separately mapped traffic signs?