Pretty sure this only applies to dual carriageways, though, whose directions are mapped as separate ways since it doesn’t make sense for single carriageways to allow pedestrians to go in one direction only. It’s more accurate to say that out of town, the implied values for pedestrian direction is sidewalk:left:oneway=yes and sidewalk:right:oneway=-1 if on a single carriageway.
To, er, close the loop on this, I’ve tagged the one-way trails I described:
- Aquila Loop Trail – explicitly tagged as
oneway=yesoneway:foot/bicycle/horse=yesbecause the signs and posted rules are explicit about affecting the whole trio - Arrowhead Loop Trail – tagged as
oneway:bicycle=reversibleoneway:bicycle:conditional=-1 @ …; yes @ …based on the posted schedule, which may need to be reviewed from time to time, since the schedule is already the opposite of what they posted in March
One of the pictured trails is no longer one-way for anyone, but the photo may help to globalize the documentation somewhat.
The OSM tagging however is unrelated to that.
For example, there are many cyclists over here for example who (mostly or completely) disregard oneway:bicycle=yes (or oneway=yes as the case may be) and even explicit bicycle=no signs as well as many crossing=traffic_signals and highway=traffic_signals when it suits them and they think they can get away with that.
Nor is it limited to cyclists; many car drivers here ignore implicit and explicit parking=no restrictions etc.
Sometimes there are consequences, but many times no, so they continue doing it. Whether one would obey the legal restrictions or no, or do they make logical sense at some location, does not affect what should be tagged – legal restrictions (like oneway, access modes etc) should be mapped as they exist.
One can then choose to obey them, or to write annoyed letter to their mayor, or to silently ignore them, or whatever. But all of that is unrelated to actuall tagging.
And the question here is how to tag oneway in a way that other data consumers can unambiguously determine what was meant by the mapper (and via that, what is actually legally prescribed).
If one wants to use Brouter (or whatever) profile/website which intentionally ignores all oneway (or other) restrictions for bicycles, I won’t be stopping them (not that they’d be likely to ask for my permission anyway 
).
Are we talking about the same proposal? Because in Proposal:One-way for pedestrians - OpenStreetMap Wiki I don’t see anything about “tag redefinition” or “stripping of information”; only about introducing best practice of adding oneway:foot=* in places where just oneway=* is ambiguous. In fact, it explicitly states that “No change to this (i.e. existing oneway=* tag meaning) is proposed.”
I’ll take that this “I’m sure” is American doublespeak / polite euphemism, right? You don’t actually believe that all OSM mappers actually follow all of the laws 100% of the time? I personally would find it highly improbable that even .01% of them actually never broke any human laws (as the saying goes “One only truly obeys laws of physics. All other laws are merely recommendations”)
Agreed. Tags intended to represent legislation (e.g. access and oneway tags) should be tagged as such. If data consumer decides to ignore those tags because they don’t care (or they are intentionally wanting to create chaos), there is little we could do even if we wanted to.
That proposal is not deprecating current meaning of oneway=*, if you meant that?
(The proposal explicitly states so). If it is unambiguous, sole oneway=yes will remain unambiguous, and if it is ambiguous it will remain ambiguous (regardless of whether the proposal passes or fails).
The purpose of the proposal instead (as I read it) is to document best practice how to reduce ambiguity (for new edits only) when oneway=* tag by itself would likely be ambiguous (think e.g. highway=footway + bicycle=yes), by the method of adding extra tag oneway:foot=* in those cases.
Proposal itself is kept relatively simple (just 4 bullet points!) by doing some generalizations, and recommending overtagging in rare cases to play it safe, instead of making a never-ending list of exceptions for rare cases. (e.g. oneway:foot=* might be required to avoid ambiguity only in 98% of the cases, and not 100% of them). That is prudent choice if you ask me (sometimes tagging extra tag which is obvious in rare cases is IMHO significantly better idea then every router having to employ AI / heuristisc to guess attributes of every road and guess wrong ocasionally)
I think the whole affair is because we can’t agree on the actual meaning of oneway=yes.
Some people seem to think that oneway=yes makes the way it belongs to “oneway” (so a oneway trunk behaves different to a oneway footway), while others think it’s a way to represent an access restriction (and is identical to vehicle:backward=no).
As long as we don’t agree on the actual meaning of oneway=yes, there is no reason to vote on this proposal, because we’re voting on 2 completely different things.
Um, no? In Croatia, on highway=motorway dual carriageways it is implied (and practically always the case) foot=no + sidewalk=no. There are some highway=primary dual carriageways, but whether they have sidewalk=yes or not is a question of luck. While technically on highway=primary + sidewalk=no you’re legally foot=yes, in most cases it is actually foot=yes_but_probably_suicidal .
But how is dual carriageway mapped in OSM (as one or two ways) is not at all what I was talking about.
It’s more accurate to say that out of town, the implied values for pedestrian direction is
sidewalk:left:oneway=yesandsidewalk:right:oneway=-1if on a single carriageway.
No. I am talking about walking on the road itself (i.e. on the car traffic lanes), when there is sidewalk=no (obviously, if there is a sidewalk, pedestrians may walk on it).
Imagine, if you will, a highway=primary + sidewalk=no + oneway:motor_vehicle=yes (usually tagged just as oneway=yes, but I’m trying to avoid ambiguity here), mapped as going from North to South (direction of car movement). If it is outside the city limits in Croatia, as a pedestrian you are allowed to walk on that road only from South to North (and staying on the westernmost side of the westernmost car lane on that road), i.e. in such a way that you face the oncoming car traffic.
If you were to explicitly map pedestrian onewayness (which is not best practice), you’d map that specific case additionally as foot=yes + oneway:foot=-1
(the reasoning for legislation is probably that since the cars drive like crazy there and drivers are often drunk and traffic law enforcement is regularly unable to deal with that acceptably, if you as pedestrian are facing oncoming traffic, you’ll at least have a chance to see crazy drivers and avoid death by jumping in the drainage canal / bush on the side of the road, as it is unlikely they would be the ones avoiding you)
What? That is surely exactly the reason to vote for the proposal? Because all the proposal really says is “Please add oneway:foot=yes when it is ambiguous what oneway=yes means for pedestrians (because people don’t agree on actual meaning on oneway=yes)”
What “2 completely different things” do you think we’re voting on?
This isn’t what I was talking about.
This is what I meant.
I’m using sidewalk:* as a shorthand for any pedestrian infrastructure of a road due to the fact that we (usually) don’t use footway=* to denote pedestrian infrastructure (unlike cycleway=* which has been established with the corresponding highway value from the start).[1]
In all fairness, this is more of an edge case since country roads in practice are never one-way outside of temporary construction (and for dual carriageways, both ways count).
However, this isn’t what you previously brought up:
It didn’t read to me that you specifically talked about one-way out-of-town roads (in part because of the rarity of the situation), hence why I brought up dual carriageways which are such examples from OSM’s perspective.
Compare
sidewalk=laneas one way to denote pedestrian lanes. ↩︎
That’s the point: if you don’t consider oneway=yes an access restriction, but rather a property of the way, then there is no ambiguity.
- Whether
oneway=yesis an access restriction (and thus always has the same meaning, regardless of the highway you slap it on) - Whether
oneway:footis better thanfoot:backward=no
That’s what it appears to be.
The actual rule is probably the same as over here: outside of towns, pedestrian traffic has to be left-sided if it’s on the carriageway (driving-side:foot=left, ouch), so if it’s a dual carriageway, it’s getting problematic, and we have to resort to oneway-tagging. C’est la via 
In all fairness, it would have been a lot cleaner not to tag single carriageways of a dual carriageway with oneway=yes, but something more descriptive that says “this is the left/right side of a dual carriageway”. But as always: this train has long departed…
I’m not sure we agree on the definition of the word ambiguity?
To me, it looks very simple (even as a non-native speaker), as those dictionaries say, it means:
“Of doubtful purport; open to various interpretations; having a double meaning; equivocal, capable of being understood in either of two or more possible senses, having more than one possible meaning” etc.
In other words, if you gather 100 people and show them some dress, would all 100 of them agree that it is made of “blue and black” colored cloth? If they all agree to such claim, then the color of the dress is unambiguous. If however significant portion of them claims it is instead of some other color (say, “white and gold” colors), then the color of that dress is clearly ambiguous – no matter how much the other half is sure of the opposite and does not see any way how it could be any different.
In other words, to determine whether meaning of some is ambiguous, it is unimportant what anyone in particular thinks or how good arguments they have for that meaning (that would be determining “correctness” of the term, not its “ambiguity”).
Only things that is important to determine (un)ambiguity is “does EVERYONE agree on the same meaning”? If they don’t, the meaning is ambiguous. So, it is a measure of agreement between multiple people on a single meaning.
I’d say anyone looking at the opinions in this thread and accepting such definition, must deduce that the meaning on oneway=yes is ambiguous (as different people obviously don’t ALL agree on the meaning), the fact that you yourself also stated above:
Thus, by the very definition of the word, oneway=yes has ambiguous meaning. Do you agree?
Yes, but I wasn’t the one voting against the proposal.
Truly, this needs to be clarified first: Does oneway affect pedestrians? I say, that depends: On a footway, certainly so. My reading of the proposal contents, it says, pedestrian routers need not look at key oneway, never, whatever highway kind.
That might resonate well with what a single person without asking the community and without substantiating their claim the least wrote into the Wiki. I observe, it does not resonate with how the mapping community does understand the meaning of the tag oneway=yes.
4 Likes
I would be far from certain that a oneway=yes isn’t intended to refer to bicycles on a highway=footway + bicycle=yes.
In any case, routers should be able to unambiguously answer the question whether a given way is oneway for pedestrians, in such a way that different routing engines will arrive at the same answer. So “it depends” is not a satisfying answer unless it is accompanied by an definitive and complete list of factors it depends on. One that could be turned into an algorithm.
3 Likes
OSM Carto obviously not able to tell what is a cycleway from openstreetmap data.
In this case, I’d say,tagging oneway:bicycle=yes instead of oneway=yes, should do the job quite fine. Would you agree? Oneway:bicycle likely a widely known key with a lot current consumers …
That has been clarified several dozen times by now. Some people think it does, some people think it doesn’t. And wiki has been saying different things at different times too. There is nothing to “clarify” about that really, except to state a fact that people disagree about its meaning, and thus its meaning is ambiguous.
And since it is ambiguous, we need some other way (like extra tag) to make it non-ambiguous.
Bicycles are however only one of transport modes (see e.g. here), and we do not seem to to have unambiguous tag to mark everything else (some claim oneway=* is that tag to applies to everything, but others claim actual meaning of oneway is oneway:vehicle).
Both intentions are often being tagged by the same tag oneway=*, which makes it impossible to deterministically find out what it means in some corner cases (of which there are many)).
If one wants to tag oneway status specifically relating to pedestrians, there is oneway:foot=* tag with thousands of usages already in existence that makes it perfectly clear in 100% of the cases. So the proposal is not about how to tag that – we know that and already use that.
The proposal (as I see it) is more about a suggestion when it should be recommended for that oneway:foot=* tag to be added (i.e. when there is high chance that lone oneway=* is ambiguous), and when it is not really needed (i.e. when existing oneway=* is unambiguous in vast majority of the cases, so tagging oneway:foot=* would be redundant).
1 Like
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.
2 Likes
Just to be clear - are you making that statement based on what you yourself have tested using the latest iteration of the code? Or the last release of the code? Or what has been deployed most recently on osm.org? Or what it is docmented as doing?
I’m particularly asking because this change in this release does significantly change access mode handling on many of these ways.
And yet, we don’t like this behavior for a very good reason: changing a highway=path into a highway=footway should not have any unforeseeable consequences. This has nothing to do with closing one eye, it’s just something called principle of least surprise (shortened):
Mappers are part of the system. The design should match the mapper’s experience and expectations.
And my personal expectation is that changing the type of highway from path to footway should have no other consequences than exactly that. And your expectation is different, so we have to accept that and act accordingly. This doesn’t mean convincing each other of our own point of view, but finding a solution that we can all agree on – no matter the consequences.
These 11,000 highway=footway + oneway=yes might well have been re-tagged from highway=path to highway=footway without the intent to all of a sudden block pedestrian movement. So no matter the outcome of the proposal or this discussion here, we will have to do a lot of re-tagging.
I’m not here to lobby for my opinion, but to find the best solution for mappers and data consumers alike, even if that means retagging thousands of ways. The fact that routers are interpreting oneway=yes so different to a lot of people’s expectation should rather be a wakeup call than a confirmation.
6 Likes
Checking with
area[name="Nordrhein-Westfalen"];
way(area)[highway=footway][!bicycle][oneway][oneway!=no];
out geom;
turned out that all were either mapping errors or intended to be meant for pedestrians. North Rhine-Westphalia has 22% of the German population and is thus already a quite comprehensive sample, and I happen to have seen many places there.
To make this a good rule, it should be also tested against bicycle=no in addition to the absence of bicycle. Afterwards, a pedestrian router can safely follow the rule:
- if
highway=footwayis set andbicycleis absent then process it as a oneway for pedestrians - ignore the
onewayfor pedestrians in all other cases ofhighway=footway
or a variant that includes bicycle=no along the no bicycle tag exemption. Bonus points for looking into highway=steps. Not claimed to be solved here is highway=path or highway=pedestrian (or any other highway value), denying scope creep.
Each of the 11,000 one-way footways lacks bicycle=*. If someone has retagged highway=pathfootway foot=designatedoneway=yes, then my point stands: the way never allowed cyclists in the first place, so oneway=yes apparently refers to pedestrians. On the other hand, if someone has retagged highway=pathfootway foot=designated bicycle=designatedoneway=yes, then they’ve already changed the meaning, regardless of oneway=yes. Are we not equally concerned that they’ve blocked cyclists’ movement? How common is this particular change anyways?
My counterproposal would focus on the 4,000 one-way footways in Germany that have bicycle=yes/designated, retagging them as oneway:bicycle=yes.[1] Everyone who has voted for the proposal has implicitly asserted that this change would be accurate, even if it isn’t their favorite solution. If you’re concerned that some of these ways were originally highway=path foot=designated bicycle=designated oneway=yes, with the intention of applying to both pedestrians and cyclists, and that oneway:bicycle=yes would inaccurately make the ways accessible to pedestrians in both directions, then it sounds like you aren’t in favor of the proposal either. Still, these 4,000 footways are by and large more readily resurveyable than the other 11,000.
If retagging these 4,000 footways is untenable for some reason, then @drolbr’s algorithm works around these footways, albeit slightly less elegantly than what I posted earlier.
I agree, it’s a sorry state of affairs. I hope increased community attention toward these profiles will help pedestrians and cyclists receive some of the benefits that motorists have enjoyed after more than a decade of sustained commercial investment and noncommercial efforts in navigation mapping and router development.
Another 2,000 more are outside of Germany.
oneway:vehicle=yesmight be better for the ones inside Germany, based on the comment you attached to your vote. ↩︎
1 Like
There are 2 ways how to deal with the “oneway=yes ambiguity”. Both require retagging thousands of objects. It could be decided per highway=* element which way to go:
- Define what the ambiguous tag means (pedestrians and/or vehicles)
- Do no use the ambiguous tag (use oneway:foot and oneway:vehicle instead of oneway=yes)
I created some polls for different highway types. Please tick the answers you think would be the best. Don’t tick what is written in the wiki or what you think represents current use.
On
highway=steps, oneway=yes should apply to …- pedestrians only
- vehicles only
- pedestrians and vehicles
- don’t use oneway=yes, use oneway:foot and oneway:vehicle instead
- I don’t know
0
voters
On
highway=footway, oneway=yes should apply to …- pedestrians only
- vehicles only
- pedestrians and vehicles
- don’t use oneway=yes, use oneway:foot and oneway:vehicle instead
- I don’t know
0
voters
On
highway=path, oneway=yes should apply to …- pedestrians only
- vehicles only
- pedestrians and vehicles
- don’t use oneway=yes, use oneway:foot and oneway:vehicle instead
- I don’t know
0
voters
On
highway=pedestrian, oneway=yes should apply to …- pedestrians only
- vehicles only
- pedestrians and vehicles
- don’t use oneway=yes, use oneway:foot and oneway:vehicle instead
- I don’t know
0
voters
On
highway=residential, oneway=yes should apply to …- pedestrians only
- vehicles only
- pedestrians and vehicles
- don’t use oneway=yes, use oneway:foot and oneway:vehicle instead
- I don’t know
0
voters