I was referring to the one-way signs E,3a and E,3b:
Two different “ONE-WAY” signs may be set up where it is necessary to indicate a carriageway which is one-way:
(The signs look slightly different from country to country. The European Agreement limits when the latter sign can bear the text “One Way”, for example.)
We expect data consumers to make many inferences. They have to infer that highway=motorway and junction=roundabout are one-way roads/carriageways (not without some initial controversy), yet these are cases that may or may not have one-way signs or markings per se. I see no problem with continuing to use oneway=yes on dual-carriageway roads that aren’t motorways, because oneway=yes has never been strictly tied to the one-way special regulation sign.
We also implicitly expect data consumers to infer that conveying=yes implies one-way traffic, which has some consequences on highway=footway and highway=steps regardless of how voters feel about the logic or elegance of combining these primary tags with oneway=yes. There are so many edge cases like this.
With the cases from Germany that @ManuelB701 mentions, we’ve indicated one-way traffic explicitly despite the absence of a one-way sign, because it’s easier than elaborating on exactly why we know traffic proceeds in one direction. Sometimes we can’t easily describe the situation in a few words. It’s apparently the same with one-way footpaths: in the absence of a standard sign, there are a lot of reasons for mappers to infer one-way traffic. I don’t think that makes these one-ways “fake”, warranting a wholesale move away from oneway=yes without collecting more evidence. But if we can reliably identify the sidewalks you mentioned, that would be a solid start.
As long as it’s pretty clear that no traffic besides pedestrians may use a given path in the first place, the oneway=yes tag means something to pedestrians. If the exclusivity for pedestrians is in dispute, then we probably need to clarify the situation further. I think annotating these situations with something like source:oneway=* will be more effective in the long run than only moving to oneway:*=* subkeys based on our implicit assumptions about why it’s a one-way for these transport modes.
I am not as well versed in all these traffic codes. I might have better written “well-known one-way signs” instead. They exist outside of Vienna Convention territory too, don’t they?
In my area, as for pedestrians, I can only think of “source:oneway=full-height_turnstile”. (A bit of funny the recommendation in the article how to convey onewayness.)
But how to tell something from “source:oneway=sign”? Could be a text-only one in a U.S. nature reserve, or a white on blue arrow in a European old town.
PS: @ezekielf I volunteer to post the poll results when complete to the Wiki documentation, this should fit into a fairly compact table.
Right, there can be multiple interpretations of sign, so maybe more specific values would be better in cases where the oneway=yes comes from a non-obvious sign. Whatever goes in source:oneway=*, it’s another signal that the mapper added the one-way tags with intention, so a data consumer probably should impart some meaning from them and can possibly get away with interpreting them more literally.
It doesn’t have to be a single key. Today, a routing profile can already infer directionality from dual_carriageway=yes on some dual carriageways and conveying=yes on moving walkways and escalators. Many sidepaths in Germany have footway=sidewalk, which might be the basis for a heuristic too. Going forward, we could tag footway=queue for single-file lines at amusement parks and airports, narrow=yes on footpaths that you can’t step to the side of, and something for those automated exit lanes at airports. There’s a long tail of possibilities if a router wants to be 100% correct…
But 100% correct isn’t the goal, not when we have a large existing body of footways, steps, etc. that don’t have this kind of detail. For these, a router needs to make an educated guess, like the educated guess they make about whether to ignore access tags altogether. The most obvious factor is the primary feature tag – the very first thing a data consumer reads to determine whether a way is relevant to the use case. That’s a simple check. It isn’t as foolproof as footway=queue, but it addresses enough cases to reduce the urgency of looking at the long tail of other keys. Some routers are considering the primary tag, to their advantage; others have yet to implement this heuristic, for whatever reason.
I’m just saying that “fake” one-ways that are actually sidepaths or one half of a dual cariageway, hold more information than just the oneway=yes. They are probably already largely tagged with footway=sidewalk and dual_carriageway=yes, but in case they are not, I’d encourage people to do so. But that’s clearly a bit off-topic in this thread.
I don’t think it is possible, the national law will be prevailing
these are different, in amusement parks nobody will complain, and it is not forbidden, if after some time in the queue you decide to go back, in airports it may be different.
Article 94 of the Dutch Constitution can be translated (DeepL) as:
- Statutory regulations applicable within the Kingdom shall not be applied if such application is not compatible with universally binding provisions of treaties and of resolutions of organisations under international law.’
https://wetten.overheid.nl/BWBR0001840/2023-02-22#Hoofdstuk5_Paragraaf2_Artikel94
The Netherlands did not ratify the so-called Vienna Convention (yet.) Others did, long since, they may have similar provisions 
There is also the question, how much lee-way the Convention grants.
I wonder what that means: Not read from a traffic-sign, is it that?
This wiki-information seems outdated (at least for the European part of the Netherlands), see formal Dutch government treaty-site below.
I have seen Dutch courts directly referring to contents of the Vienna conventions.
But I agree, the important part for the discussion here is that also in other countries provisions may exist where international treaties have priority above national law when the two are not in agreement
https://verdragenbank.overheid.nl/nl/Verdrag/Details/003177.html
(“In werking” means “In force”)
Yes and no. At least not from a one-way-sign. But the actual main case I’m referring to is the separately mapped sidewalk/sidepath. They don’t have one-way-signs over here, because they actually belong to the street as a whole, and as such, vehicle traffic, by definition, has to keep to the right side of the street. And the same goes for streets where the carriageway divides physically between forward and backward traffic by the use of
and 
These dual carriageways are not signed as two one-way streets, but the fact that they are a dual carriageway makes them, by definition, one way to use.
I’m not saying we should not map them as one-way (we still should), but rather to add the information that they are one of two carriageways, or, a sidepath that belongs to a street. Because other local laws can be derived from this, like whether pedestrians have to walk contra-flow and in one direction only, or not. It would act as a source of the one-way-ness, if that makes sense.
If bicycles are actually directed to the sidewalk, the sidewalk is designated for bicycles, while remaining a footway. The bicycles are not just allowed there, they are supposed to use the sidewalk.
The Netherlands (only the European part) acceded to the treaty in 2007.
For the signatories that haven’t ratified the treaty, it can still be influential but not as predictably. Studies have found that Mexican signs don’t vary from American ones by enough to make a practical difference. Costa Rica adopted the Central American MUTCD, which is largely based on U.S. standards despite EU funding. One sign is based on the Dutch sign for a highway=living_street, but I’m unsure if it actually refers to the same concept. Like the U.S. MUTCD and unlike the Vienna Convention, the Central American standard explicitly applies one- and two-way signs to vehicles only.
This just in defence of Wikipedia map, it shows the current state. The Netherlands rendered light green not dark green.
On the POLL above, I got a first impression from the results: More road-like features attract the One-way for vehicles. Two-way for pedestrians option, while more path-like features attract the One-way for vehicles and pedestrians option. My take home from this observation: cycleway is considered a road-like feature by voters, Path itself ambiguous, no wonder.
Please keep the path discussion out here The take is, data consumers would understand oneway in a way, that it affect the “main” user of the highway=* and every “higher level” user. That makes sense for data consumers to interpret our data.
For me, the results in, we should not use oneway=yes for peds and offer an alternative to us mappers to avoid the problem of making oneway depended on the value of highway=*.
Why is this a problem, other than for values of highway=* that are problematic for other reasons anyways?
Because due to different templates in the editors, common or segregated (segregated=no/yes) cycle-pedestrian paths are repeatedly re-tagged between path, cycleway and also footway (its looks like a normal sidewalk) without all attributes being taken into account.
Such re-tagging happens not only with signposted cycle paths but also with open paths in the countryside, where the mappers do not agree on the main use of the path or assign the highway tags according to different criteria.
Presets are fundamentally based on the notion of a hierarchy of primary versus secondary tags. Secondary tags must be considered in context. Otherwise, iterative refinement wouldn’t be possible. This is largely how we wound up with oneway=yes on features that have nothing to do with vehicular traffic. No one saw a need to write highway:steps:oneway=yes.
Is it the case that some editors don’t have the capability to remove or change tags when switching from one preset to another? To my knowledge, iD has always had this capability, though its presets leave the oneway=* tag untouched because they share the same One Way field with the same assumed meaning. If JOSM’s presets are more conservative, I agree that this behavior could compound with how its preset icons are literally the European mandatory signs to cause some potential confusion.
Even so, I don’t think a renderer or router can reasonably assume that every oneway=yes on highway=footway without bicycle=* is meaningless cruft from an old version of the way prior to retagging. When a data consumer encounters crossing=uncontrolled on a highway=crossing, it doesn’t assume this tag refers to gates and bells and is therefore meaningless, just because it might’ve previously been railway=crossing at a railway-turned-street. Of course a data consumer can introduce such a heuristic if it really wants to, but if we don’t think oneway=yes should depend on a primary tag, then it definitely shouldn’t depend on a primary tag on a hypothetical previous version.
It should be possible to gather statistics on the prevalence of this retagging. I’m quite certain it happens – I’ve seen it myself. But so far scant evidence has emerged to demonstrate that it happens in the presence of a oneway=yes tag in appreciable numbers that require a tagging policy as opposed to a one-time cleanup. So consider this a challenge.
Imagine there is a highway=cycleway+foot=designated+oneway=yes out there and a mapper changes this for whatever reason to highway=path/footway and adds bicycle=designated. But the mapper doesn’t care about the oneway=yes. Maybe he did not surveyed it or he simply don’t care because for his use case it doesn’t make a difference.
Even if the editor would ask, still the mapper simply don’t have the knowledge to answer the question, what to do with the oneway. Or just ignores the warning. So after that edit the data is screwed.
On the other side, on a highway=footway+bicycle=yes I can’t use oneway=yes anymore to indicate bikes, mofas,… can only use it in one direction. Instead I need to add oneway:bicycle=yes+oneway:mofa=yes`,…
For me it’s by far more easy to simply use oneway:foot=yes for the limited occurances.
One of the routers on the openstreetmap main page interprets oneway as including pedestrians on shared use ways. It would have been easy to discard that. I chose to bite the bullet and changed oneway=yes on the few ways into oneway:bicycle=yes. Voilà I get consistent routing whomever I ask
I guess I even did the right thing under the long-germ-goal: That is to make oneway mode specific in all cases. (By long term I think of a decade maybe?)
