We don’t agree about the status quo ante, so we don’t agree about whether this proposal changes the status quo ante. Some have looked at a few innocuous-sounding words on the oneway=yes page that have been there for a while, interpreting it literally, and considered the usage they were already familiar with prior to this discussion. Based on these observations, some have further concluded that pedestrian one-ways are an extreme edge case that isn’t worth occupying oneway=yes even on highway=footway, but that the possibility of this existing tagging creates ambiguity.
On the other hand, I look at the usage I’m familiar with prior to this discussion, in all its diversity. highway=footway oneway=yes by itself doesn’t look very ambiguous or unintentional to me, because I cannot fathom what else was meant. I grow concerned that this is not such an extreme edge case. A grotesque display of legalism over the past few days makes me concerned that this tagging committee doesn’t fully appreciate the consequences of the proposal.
Buried within the proposal is one active ingredient (emphasis mine):
let’s stop using
oneway=yesonhighway=footwayby itself, and use less ambiguous tags instead or in addition
Without this guidance, there is no proposal, only some practical advice and a restatement of some obvious corollaries to existing tagging schemes, like oneway:foot=*. Perhaps unlike in some communities, few over here have any problem with redundantly tagging things like foot=no horse=no on highway=motorway just in case. It’s a little bit of tag entropy, that’s all.
However much the proposal insists that it changes nothing, this guidance tells mappers that they can use highway=footway oneway=yesoneway:foot=yes with the expectation that oneway:foot=yes is tantamount to declaring that the footway is one way overall. We can disagree on whether this is semantically correct. To avoid any doubt, the proposal goes on to tell developers that their pedestrian and wheelchair routing profiles should ignore oneway=yes on highway=footway (emphasis from the original):
Anyone who wants to know if a way is one-way for pedestrians can ignore the
oneway=*tag. Look atoneway:foot=*instead.
Keep in mind that even the most sophisticated renderer or router can’t dissect a way’s history to determine whether oneway=yes was added before or after this proposal’s passage. A router that follows this guidance will simply mishandle 11,000 footways until each one opts back in using oneway:foot=yes. From a pedestrian’s perspective, that might be worse than the time OSRM and BRouter refused to turn right at hundreds of intersections because of some poor advice on the wiki.
For context, I was likening the Open Space Authority’s visitor rules to the terms that we all agreed to when joining OSM, and to the license that data consumers agree to when downloading OSM data. All three are enforceable as contracts. If someone insists that the visitor rules are somehow “soft” and less mappable because one can flout them without getting jailed, that would seem to cast doubt on their intention to follow this project’s ground rules too. After all, when’s the last time the OSMF sued any of us for breaching the terms?
Much of this world still operates on trust. We all have our peccadillos, but I want to believe that our fellow mappers are upstanding citizens and upstanding mappers. Frankly, this line of discussion is an exhausting and unnecessary distraction from the proposal at hand. At least you and I agree that the legal nitpicking has gone too far.
Correct. The view I’m articulating is: a one-way restriction pertains to the manner in which someone may use a road or path, having already secured the right to use it. This restriction is usually signposted or marked in some manner. This view is consistent with international law and, at least in my country, national and state law.
It might come as a surprise that there’s no global legal basis for treating a one-way restriction as half of a vehicular access restriction. The Vienna Convention is silent on the meaning of a one-way road or carriageway and doesn’t proscribe the use of these signs off of the road. The more global Geneva Convention sets one-ways aside as a domestic matter.
Here in the U.S., the national MUTCD restricts the 
and 
signs to situations where the meaning is unambiguous. (These signs are omitted when cyclists behave differently than cars.) There are also provisions for directional and wrong-way arrow markings. The Uniform Vehicle Code only discusses vehicular one-way movement. It only requires pedestrians to keep to the left of a two-way road that lacks sidewalks and shoulders, so the loophole I mentioned doesn’t exist in this code. However, the UVC is only a nonbinding source of state traffic laws. California is one of the states with its own vehicle code. The CVC is silent on the meaning of a one-way street, but it requires walking on one’s left even on one-way streets.
All of this supports the view that a standard one-way sign applies to vehicles rather than pedestrians, but where does the idea come from that pedestrians cannot be regulated too in some cases, or that pedestrians would experience it so differently that we cannot trust the mappers who marked one-way footpaths? In the end, the rules constraining pedestrian movement come from less systematic sources of rules, like the One Way Trail sign that I legally analyzed for this group. Sometimes it even comes from custom: who here thinks it’s proper to cut in line? A map shows one-way arrows as a very strong suggestion of the expected movement, not as a shibboleth for a particular traffic sign.
highway=footway oneway=yes is only “ambiguous” because, as @Nadjita points out, some don’t like the idea of interpreting oneway=yes differently depending on highway=*. If I voluntarily close my left eye while running, I will eventually bump into something because I have abstained from the necessary context. This doesn’t mean there’s anything wrong with my right eye.
It could look something like this in a foot.lua profile for OSRM:
local highway = way:get_value_by_key("highway")
local footway = highway == "footway" or highway == "steps" or highway == "corridor" or highway == "via_ferrata"
local oneway = way:get_value_by_key("oneway:foot")
if oneway == nil and footway then
-- The proposal says not to do this.
oneway = way:get_value_by_key("oneway")
end
if oneway == "yes" then
result.backward_mode = mode.inaccessible
elseif oneway == "-1" then
result.forward_mode = mode.inaccessible
end
A couple of conditional statements in a file that already has dozens, hardly the magic or quandary that some are postulating. According to this logic, certain highway=* tags denote ways that are “for” pedestrians. Apparently this assumption isn’t specific to my country; in fact, it seems to be even stronger abroad.
I don’t want to bill this as a perfect solution. highway=path is a glaring omission from this list of values. It goes without saying that this tag is ambiguous in the first place. highway=pedestrian is also omitted. highway=pedestrian represents a hybrid between a footpath and a street, where cars are sometimes allowed by exception. It isn’t hard to find evidence of cars parked along a pedestrian street and only in one direction:
I’ve argued that, in terms of heuristics, a router would be justified in ignoring or only slightly considering oneway=yes on pedestrian streets. Pedestrians move about nonlinearly on a pedestrian street, reminiscent of how they don’t travel conventionally in the lanes of a traffic street, so one-way restrictions are much less likely. This heuristic could be problematic in cases where highway=pedestrian is misapplied to ordinary footpaths. It does nothing to address the ambiguity of a one-way pedestrian street that lacks any tags regarding vehicles.
If the objective is to promote clearer tagging, this is where I’d start.