This discussion has a different scope and purpose than the proposal. The proposal called for us to tell data consumers to ignore oneway=yes
on highway=footway
, which is a different tag than highway=pedestrian
. Relatively few highway=footway
s are areas; area:highway=footway
is used instead.
This discussion is framed as a thought experiment around “What would a router do?”, which is the aspect that in my opinion undermined the proposal. A slightly ambiguous tag isn’t necessarily meaningless; it can still be a useful signal. In some other cases, a router will ignore or downplay a one-way tag – not because it’s ambiguous, but because it’s irrelevant according to the router.
Yes, if the source of the oneway=yes
tag is a sign, then the definition of the sign becomes relevant. And if it’s the standard one-way traffic sign, then in some jurisdictions, it would be limited to vehicles – but not because of the Vienna Convention:
On the other hand, there are cases where the source of the oneway=yes
tag is clearly not the standard sign, so the definition of that sign is irrelevant. And then there are some other cases where the source isn’t so clear. Imagine if we had a StreetComplete quest for adding source:oneway=*
, like there is for distinguishing explicit and implicit speed limits via source:maxspeed=*
. Then there wouldn’t be as much ambiguity, at least for the ways that use it.