A rather extreme case of oneway=alternating perhaps. The documentation for lanes=* already advises the use of oneway=alternating or oneway=reversible in conjunction with lanes=1, giving the following example that lacks a sign regarding directionality:
Sometimes directionality is evident based on width and adjacent barriers or hazards, in which case oneway=* describes a practical limit rather than a legal restriction. This will probably be a difficult reality to accept for anyone who clings to the idea that access tags never have anything to do with practical usability:
On the other hand, oneway=alternating can be a legal restriction too. California sometimes posts the following sign on narrow two-way bridges:
The sign doesn’t prohibit cars from the bridge, and it doesn’t mean that a road crew emerges to erase the yellow centerline as soon as a truck approaches, then repaints the centerline as soon as it finishes crossing the bridge. Rather, the bridge becomes oneway=alternating for everyone in the presence of a truck. The truck driver must drive astride the centerline while cars, cyclists, and pedestrians wait for it on the other side. This situation is currently documented as a big question mark.
The cave you visited would have no need for such a conditional restriction, but imagine you come upon the bucolic alley shown in the footway=alley documentation and so does someone pushing a stroller. Suddenly the alley has effectively transformed into an overtaking=no situation, with either oneway=alternating or foot=yesback=against_wall.
Fortunately, we’re mapping for route planning and navigation guidance, not writing the script for a sitcom in OSM English.
I’ve opened Idea: oneway:type to specify oneway restrictions and who they apply to to discuss the idea of using oneway:type to better map the reasons why we consider a certain way “oneway”. From that additional information, I believe, routers can much better determine whom the oneway tag applies to and what restrictions that entails.
It’s only an idea, for now, so feedback is welcome.
It seems the voting has run its course so I’ve gone ahead and closed the polls. There were far more votes that I had expected and the results are rather interesting. Thanks to all who voted.
Here are the results in a condensed summary table.
Wherever double-digit percentages of mappers have differing opinions, there is a great need for action. Tagging must be improved here so that a clear message (to whom applies the oneway=yes) is communicated (The proposal tried to do this - but it was obviously not understood). The Communicating this via the wiki (wiki said: oneway only applies to vehicles) alone has failed.
This was not a poll about how one should tag oneway!
The question was " how you think a data consumer should interpret a plain oneway=yes on each of the following highway classes"
Please keep in mind that map user and mapper are not the same person and communication between mapper and data user can fail (as we see in the survey).
The job of a cartographer is to communicate (tag) as best he can to convey the message (what the world OTG looks like).
The task of the data user is to interpret the current available data with all its imperfections in such a way that they deliver the best results for the task they are solving. (this may differ from what is documented in the wiki!)
That doesn’t matter. We do not know if the programmer was aware of the problem and made a conscious decision against the wiki. And even then, we must not make new tagging recommendations without thinking (without discussion). Or should we reconsider the meaning of access=no just because it is often used incorrectly and is therefore interpreted tolerantly by routers.
I’d agree that “tagging must be improved” but that means actually going out and surveying, not posting on the forum about what oneway=yes might mean.
The poll was titled “Please choose how you think a data consumer should interpret a plain oneway=yes on each of the following highway classes.”. It’s clear that a “plain oneway=yes” is confusing where there are multiple modes of transport - reducing that level of confusion isn’t achieved by redefining what oneway means or (“has always meant”) in the wiki, it means:
ensuring that it is clear what modes of transport can access a particular way. If it is only one, then oneway=yes is clear.
if unclear, adding tags to make it clear what modes oneway applies to.
but in my experience the biggest problem is actually:
ensuring that mode tagging and oneway tagging actually matches what is on the ground.
Doing those will reduce the places in which “a plain oneway=yes” is ambiguous.
He never said that, and neither did the proposal. He said that the tagging must be improved (not the wiki) so that it’s clear whom oneway=yes applies to. I read this as: not using a plain oneway=yes, but rather adding tags, or using different ones.
You see, herein lies a problem of its own. In some jurisdictions, a cycleway can be used by pedestrians, in others not. In some jurisdictions, a footway can be used by inline skaters, in some not. This is probably one of the reasons why we have such a weird outcome. It seems that the interpretation of oneway=yes on anything that doesn’t allow double track vehicles by default varies greatly enough to warrant a change of tagging.
To be specific, Valhalla introduced one-way footpath support by having the pedestrian costing model respect oneway=yes, oneway:foot=yes, and foot:forward/backward=no, following the same pattern as for each of the other supported costing models:
Some oneway=yes ways were used as examples to demonstrate the fix, including an amusement ride exit and a one-way footpath leading to a parking lot (located in the U.S. but surveyed by a visitor from Germany). The case of a shared use footpath in Germany was not considered, and the developer made no public reference to the wiki. (Valhalla’s developers are well aware of the wiki and have been active in maintaining some pages there. I’ve been highly critical of some of these edits in the past.)
When there have been occasional complaints about unexpected detours on pedestrian thoroughfares, the response has consistently been that these thoroughfares are mistagged.
The results of this poll seem to affirm Valhalla’s behavior with respect to some highway=* values but not others. The same can be said of the other routers, though the specifics differ. Of the major routing engines, Valhalla would probably be the most capable of making a per-country exception for Germany’s shared sidepaths if necessary, though the developers would probably consider a special case to be less than ideal.
This is a very carefully worded statement. It focuses on double-track vehicles, but one can reach a different conclusion when focusing on pedestrian use instead. That is, after all, the whole point of this exercise. I gather that most respondents probably had to scratch their heads for a bit when considering academic propositions like vehicles on steps.
Evidently, this cross-section of the community expects a consistent interpretation of oneway=yes on anything that’s normally exclusive to pedestrians except in unusual circumstances. The options to apply oneway=yes to pedestrians on highway=footway, highway=corridor, and highway=steps all met or exceeded a three-fourths supermajority, the very high threshold required by the proposal process. At the same time, the results also point to some other classifications for which the expectations are much murkier.
Fortunately, there was a consistent outcome for highway=corridor versus highway=footway. That skirts a long-simmering debate about how to tag hallways.
does it support turn restrictions on footways as well? I am not 100% sure they exist (in osm), but if oneway for pedestrians exists, then turn restrictions for pedestrians are also to be expected
This is currently a long tail example, but it would remove the ambiguity for the rare cases if we agree that restrictions by default do not apply to pedestrians.
There are also about 161 relations with except tags that have foot values, but I do not think we should interpret the other 2 million restrictions without the except tag to apply to pedestrians.
I agree that a blanket interpretation lacking nuance would get a lot of cases wrong. This probably deserves a separate thread, in part because it’s very closely related to whether sidewalks are mapped as separate ways. The good news is that, just as with oneway=*, any misinterpretation would merely produce a more circuitous route and a more pessimistic travel time estimate, but in general it wouldn’t lead pedestrians into harm’s way.
This is a common misconception. The following animation provided by OSRM’s creator illustrates how routers generally deal with the situation in which you’re surrounded by inaccessible paths. If your starting point lies within the island, you aren’t trapped on the island. This is important for serving origins or destinations within gated compounds, for instance.
Anyways, I was responding to your point about turn restrictions, not access restrictions. The conservative approach is always to err on the side of honoring a restriction. A pathological case involving access restrictions and turn restrictions could conceivably truncate the route and otherwise make the route worse. But that’s less severe than some of the possible worst-case scenarios when ignoring one-way restrictions, especially in less urban environments, where such restrictions would be more notable and the consequences less predictable.
