Part of the problem is that the poll didn’t mention any other tags. So that question became something like “if you’re designing a router, you have no local knowledge, there are no other tags, which modes would you interpret oneway applying to?”. It’s on that basis that I answered “apply to pedestrians too” as a fail-safe. In the real world there will be other tags such as “vehicle=yes; vehicle:conditional=...”, and as numerous people have pointed out above, when other traffic modes are involved, you have to be more specific to say what oneway actually applies to.
Yes. My intent here is to get people to think like a data consumer. When writing software consuming OSM data, we have to make some decision even if we think the tagging is lacking or ambiguous.
I do not think that we should advise data consumers how to interprete tags.
A better question would be: “How would you interprete … if you were a data consumer.”
We should document how one (mapper) can tag things unambiguous. The results of the poll show how necessary such recommendations are.
Since the data is never free from errors the data consumer has to find his own way to interprete the data he needs for his application. He should use all data that helps him to interprete what the mapper wanted to say.
I like your wording better and would use that if redoing the poll. Please note though that thinking a data consumer should interpret tags in a certain way is not the same as telling or advising a data consumer to do the same. It is definitely not my intent for the results of this poll to be anything more than information about what a (small) sample of the OSM community thinks.
This makes sense and I’m sure it is the case in many jurisdictions. However, in OSM access tagging terminology it seems horse is not considered a subset of vehicle. At least it is currently documented as “without a vehicle”. See: Key:access - Land based transportation - OpenStreetMap Wiki. carriage on the other hand is documented as a subset of vehicle. Perhaps this should be reconsidered, but in a different topic.
As anyone who’s ever stopped and asked someone for directions will know, there’s an art to describing a good route well. If you think like a router, then you mostly don’t make a yes or no decision; you weigh bad options against even worse options. Did you know that major routers ignore access restrictions in some cases, even in their driving profiles? The router needs to be able to help a resident of a gated community take deliveries or commute to work, despite access=private.
Some OSM-based navigation systems are even willing to generate “driving” directions that barrel past road closures (either from OSM access tags or dynamic incident management systems), while explicitly warning the user of the caveat that, past a certain point, the passenger may have to exit the car and walk, but at least it got the driver as close as it could. When the ends justify the means, it may not be so hard to believe that the same router might sometimes advise the user to walk or walk their bike against the flow of traffic on a one-way street. If it can already do that, why not also relax a little on a highway=pedestrian?
highway=pedestrian is a far cry from highway=footway where, in the absence of width tags to the contrary, the router can only assume that you travel linearly in single file. On a pedestrian street or esplanade, the pedestrian probably has even more room to run around in circles chasing a dog than on a highway=residential. It’s about as likely to have a sidewalk too. On the other hand, maybe a serious router should try to avoid the esplanade because there’s likely to be a lot of people milling about, impeding you as you speedwalk with determination toward your destination, just like the cars backing out on a busy service=parking_aisle would impede you as you drive to the store.
Whether the oneway=yes on a highway=pedestrian technically applies to pedestrians or only to vehicles, the router might end up suggesting the route regardless, but with a little icon and an instruction to “walk against traffic” along the street. In practice, what a router does will also be influenced by this community’s best guess as to how and why the tags have been used in the past. If you don’t like that, you can choose the alternative route. The good news is that we aren’t mapping for autonomous feet yet.
from my understanding, and the wiki seems to be consistent with it in this point, for pedestrian streets it is assumed that there is some limited vehicle access (e.g. loading, delivery, maybe taxi and other psv) although it may be limited to certain times or dates.
Looking at the real world I do not see many combinations that suggest vehicle access is typically added to highway=pedestrian
There are 811000 highway=pedestrians, to be save for very few which are indeed oneway for pedestrians, I would not sacrifice suitable pedestrian routing on the hundreds of thousands of others, but maybe that’s just me who has never seen a pedestrian road which was oneway for pedestrians but hundreds which were oneway but only for vehicles. It is the standard here, because streets are often not wide enough for traffic in both directions.
By the way, one oddity about highway=pedestrian is that about a third of the occurrences are areas or multipolygons, on which a oneway=yes tag would be unusable and probably erroneous. Among the one-way pedestrian streets mapped as ways, 13,600 are tagged as lines (more than the number of one-way highway=footways) and fortunately only 27 are tagged as areas.
There are a very large number of OSM tag combinations which are used for real-world objects that are both linear and areas, where an area tag has not been included. These include, but are not limited to:
highway=pedestrian
leisure=track
aeroway=runway
aeroway=taxiway
barrier=hedge
man_made=pier
In some of these case you can figure it out. Closed-way highway=pedestrian are nearly always areas, not linear. There are no linear closed aeroway=runwayyet, so one that is closed must be an area. barrier=hedge is often on an area because someone is trying to use one OSM object for two real-world ones, so you can look at the other tags. Finally (somewhat back on topic) oneway=yes is a good cue that something isn’t an area, but instead a circle.
Unfortunately the only way to be sure with these area examples is the same as with ambiguous oneway examples - have a look, and add enough tags so that it’s not ambiguous.
So the proposal that would have turned the presence of oneway=yes on a footway a meaningless addition that pedestrian routers or other consumers should just ignore failed to reach the required three out of four.
Nevertheless, there is a lot of talk about oneway=yes being ambiguous. Something smells foul.
Personal opinion: Restricting application of oneway to vehicles only does nothing to heal the mess. It might even make it worse. E.g. regarding shared use footcycleways. Adding oneway there should be discouraged if it does not apply to both cyclists and pedestrians. Most often oneway:bicycle=yes is what is meant. (From looking at my local area of knowledge.)
On highway=pedestrian, it is different, there I observe Vienna Convention one-way signs, and these of course only apply to vehicles.
A more comprehensive proposal due. Happy New Year!
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=footways 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.
I’m not guessing how many, but I’m sure a very large part are dual carriageways and separately mapped sidewalks. If we tagged them accordingly (without oneway=yes), we could probably get rid of a lot of these “fake” ones, and allow routers to derive country- or region-specific laws and limitations from these.
At least here in Germany, I can think of the following cases where oneway=yes is used without the sign 220 (one-way street):
The transition from a single to dual carriageway sometimes involves a combination of signs 220 (one-way street) and 267 (no entry) but it also is common to see signs 222 (hold to the right) instead, occasionally combined with 267 for the other side.
Contraflow bus lanes often involve sign 245 (bus lane / busway) or a 267+1026-31 (exclude fixed-route buses) and none on the other side (but may carry typical characteristics like turn restrictions).
Cycleway sidepaths are fairly complex due to the difference between mandatory and optional cycleways:
In general, they never use sign 220 from experience and only rarely a 267 due to ambiguity with car drivers.
Whether mandatory cycleways are one- or two-way primarily depends on whether a sign 237 (exclusive cycleway), 240 (inclusive cycleway / shared foot- and cycleway) or 241 (segregated foot- and cycleway) exists on one or both ends of the way.[1][2] In some cases, a 1022-10 (exclude bicycles) and 1000-31 are used without any other sign (typically if a mandatory cycleway also exists on the other side).
Optional cycleways from my experience are unidirectional by default and are only bidirectional if signed by an additional (weaker) sign such as the aforementioned 1022-10 (sometimes with 1000-31 for clarity) or IIRC a combination of 1010-52 (bicycle) and 1000-31[3] or through paint.
Sometimes strengthened with a sign 1000-31 (bi-directional in parallel direction) but has no legal function. ↩︎
Though if a 237 is used, at least by signage alone, one-way cycleway sidepaths also makes it ambiguous whether they can be used by pedestrians from the other side with a missing 259 (pedestrians forbidden). ↩︎
Historically 1000-33 which is a combination of the above but is now invalid ↩︎
Hi, just checking if we are talking about the same thing here;
to me the Vienna convention seems clear enough that the standard Vienna-style one way-sign applies only to vehicles and not pedestrians (see below). Or did you perhaps mean something else?
This is not a one way sign, but a prohibition of entrance – the sign on the other end of a one way street/road. The actual one way sign isn’t part of the Vienna convention.
We need to be careful here - the Vienna convention applies in some places and not others. Even in countries where it mostly applies, there isn’t always a one to one correlation between Vienna convention signs and “you can’t go there”. As an example, cycle access or oneway restriction based on Vienna convention signage might exist, but coverage might be patchy, and as a cyclist I quite often have to infer “what the planners intended here” (and of course how to map that onto OSM legal access tags is tricky).
Yes, fair point, there are quite a few steps between the convention and on the ground rules and mapping in OSM. And also : even if countries have adopted the convention there may be differences between countries on whether the terms in the convention directly apply and may even overrule national legislation if there are contradictions between those two.
I read the quote from Minh that I reacted to as a statement about the contents of the convention itself, not as a statement about wider consequences of the contents of the convention, I agree that you have to be careful with the latter.
Interesting, I think the blue special regulation sign “One-way” signs are indeed part of the convention (signs E, 3a /b below), but I think I understand Minh’s remark better now. The description below for the blue special regulation sign is not explicit in its limitation to vehicles.
The prohibition and restriction of entry sign that is intended on the other side of the one-way road (C, 1a) is explicit in its limitation in scope to vehicles. For situations where the road is closed for vehicles in both directions there is another sign (C, 2)
icon and an instruction to “walk against traffic” along the street. In practice, what a router does will also be influenced by this community’s best guess as to how and why the tags have been used in the past. If you don’t like that, you can choose the alternative route. 
The good news is that we aren’t mapping for autonomous feet yet.
