Would you consider exposing upcoming highway=stop nodes on the matched way, resolved to the direction of travel?
I want to flag up front that this is a bigger ask than the way-tag ones I have opened, because it is node data rather than a field on the Way struct, and I do not know what that costs in your offline format. If the answer is that nodes are not worth carrying, that is a completely reasonable place to stop reading.
The case for it being worth the cost is that it is not a niche tag. Worldwide, from taginfo:
highway=stop 2,468,125
highway=traffic_signals 2,003,001
highway=give_way 1,651,677
Stop signs are more common than traffic signals globally. For comparison, the two way tags I asked about in issues 129 and 130 are 11k and 19k objects, so this is over a hundred times either of them.
Measured across three US metros, 9,845 stop nodes:
stop nodes direction stop= signals
Salt Lake County 5655 96% 34% 2811
Portland OR 3331 87% 27% 2263
Atlanta GA 859 59% 23% 1589
Two qualifiers matter for anyone consuming this, and both fit patterns you already have:
direction is on 90% of them, and it is nearly always directional rather than symmetric: 4,185 forward, 4,177 backward, 438 both. A stop node sits on a two-way way and usually applies to ONE approach, so a consumer reading stop nodes without resolving direction would slow for signs facing the other way about half the time. That is the same direction-of-travel resolution you described for the lane tags, applied to a node.
stop is on 30%, and reads minor 2,077 times against all 902. On stop=minor the major road does not stop at all, so it is a refusal signal rather than a detail.
What it is for: openpilot's driving model detects stop signs visually and the response is unreliable enough that I have logged its output for a drive to find out whether the failure is detection or reaction. A map answer is independent of the camera, and a stop sign is static and complete in a way a speed limit is not. I would use it to cross-check the model, never to brake on its own.
Happy to be told this is out of scope for the offline format.
Would you consider exposing upcoming
highway=stopnodes on the matched way, resolved to the direction of travel?I want to flag up front that this is a bigger ask than the way-tag ones I have opened, because it is node data rather than a field on the Way struct, and I do not know what that costs in your offline format. If the answer is that nodes are not worth carrying, that is a completely reasonable place to stop reading.
The case for it being worth the cost is that it is not a niche tag. Worldwide, from taginfo:
Stop signs are more common than traffic signals globally. For comparison, the two way tags I asked about in issues 129 and 130 are 11k and 19k objects, so this is over a hundred times either of them.
Measured across three US metros, 9,845 stop nodes:
Two qualifiers matter for anyone consuming this, and both fit patterns you already have:
directionis on 90% of them, and it is nearly always directional rather than symmetric: 4,185 forward, 4,177 backward, 438 both. A stop node sits on a two-way way and usually applies to ONE approach, so a consumer reading stop nodes without resolving direction would slow for signs facing the other way about half the time. That is the same direction-of-travel resolution you described for the lane tags, applied to a node.stopis on 30%, and readsminor2,077 times againstall902. Onstop=minorthe major road does not stop at all, so it is a refusal signal rather than a detail.What it is for: openpilot's driving model detects stop signs visually and the response is unreliable enough that I have logged its output for a drive to find out whether the failure is detection or reaction. A map answer is independent of the camera, and a stop sign is static and complete in a way a speed limit is not. I would use it to cross-check the model, never to brake on its own.
Happy to be told this is out of scope for the offline format.