This is NOT SAFELY. This is only a heuristic that routers can use.
1 Like
I was more thinking that a sole highway=path without any foot/bicycle=designated was retagged to highway=footway. A lot of times, if people are unsure if bicycles are allowed or not, they just use highway=path, even in urban settings.
An example where I might have retagged these personally:
If such a path is the extension of a oneway road, then it happens very often, that these are tagged oneway=yes as well â if they were mapped from the perspective f the oneway road. Looking form the other side however, itâs usually very clear whether bicycles are meant to go there or not (lowered kerb vs. raised kerb). Iâm pretty sure Iâve changed quite a lot of these paths to footways without even looking if thereâs a oneway=yes somewhere, because it simply wouldnât be wrong if at any point, someone would use a vehicle there.
I donât see it as a counterproposal, but rather something that can and should be done no matter what, because it simply dosnât hurt.
But at the same time, I see it a necessity to add oneway:foot=yes to all highway-types (no matter if steps, footway, corridor) that are meant to be unidirectional for pedestrians, simply because itâs clearer and doesnât hurt 
2 Likes
I made the statement purely based on the impression left after reading the discussion there on the OSM Carto issue tracker. I made it in the context of âoneway=yesâ being ambiguous or not depending on highway typification, especially if there are only two choices (foot vs. cycle; would be three, when bridleway included.) Personally I use OSM Carto mostly to verify edits I made. I think the issue was raised after the other change got merged. Perhaps to remind of what has been left out? I felt a bit depressed when after contemplating the issue, I came to the conclusion that from point of view of a mapper I could not help or advise the cartographers in any way.
Obviously, Carto uses oneway on footpaths and cycleways to draw direction arrows, the arrows inheriting the colour/type of the way. A nuanced oneway:bicycle on a footway would allow them to draw a blue direction arrow on a red way. I have yet to see a footway, where pedestrians are forced one-way and cyclists can go both ways.
BTW: I voted âpedestrians onlyâ in above poll regarding âstepsâ and âfootwayâ because vehicles not in the game right from the start.
The poll up thread mixes the question of what should oneway=yes apply to with the question of whether oneway=yes should be used at all. This leads to somewhat muddled results so Iâve started a follow up poll focused just on the first question.
2 Likes
@Tordanik asked what algorithm a router could use as a heuristic. Did @drolbr not answer the question? If not, what do you think of the Lua code I posted? For many routing profiles, I suspect either would be an improvement over current behavior.
A routerâs heuristic is nothing more than an editorial decision. Itâs useful to brainstorm heuristics, to demonstrate the feasibility of applying Postelâs law, but itâs up to routers to choose to use them or not. After all, when some routers for a general audience send pedestrians down the wrong way of a one-way street, what they really mean is to keep to the sidewalk, verge, or shoulder. If you have the freedom to roam, then I guess you can roam vaguely in the vicinity of the street. But if the router is all about helping joggers run through all the streets in town, then itâs going to prefer a street over any footway.
Regardless, at least we can see that thereâs very little magic behind the wizardâs curtain and very little need for artificial intelligence.
OK, thanks for walking me through this scenario. Has anyone tried to quantify it? Has it happened few enough times that we might try to identify and retag these cases instead?
Just to get a rough sense of how big of an issue this might be, I tried querying the Overpass Museum for highway=footway oneway=yes ways in Hanover that used to be tagged highway=path oneway=yes without either foot=* or bicycle=* as of January 1 of various years. I see zero results there in all the years Iâve checked, though maybe @drolbr could double-check my query. I donât doubt your anecdote, but it would be great to find out to what extent it still affects the map.
Coincidentally, while querying, I stumbled upon a series of changesets by @Langlaeufer last year that changed oneway:bicycle=yes on hundreds of highway=paths in the area. (âoneway:bicycle to oneway vereinfacht - oneway bezieht sich nur auf Fahrzeuge.â) Changesets like these might inform our⊠path forward regarding highway=path. This sort of query is totally infeasible for any mainstream data consumer to perform in real time or while refreshing OSM data, but we could still use these queries as part of cleanup efforts.
My point is that replacing oneway=yes with oneway:bicycle=yes on the 4,000 that already have bicycle=yes/designated can apparently be an uncontroversial mechanical edit, whereas adding oneway:foot=yes to the 11,000 that lack bicycle=* can only be an uncontroversial mechanical edit if we disavow the claims about ambiguity that the proposal is predicated upon. Adding oneway:foot=yes is still a good idea, just in case, but it needs to be done with more care to avoid greater disruption. This canât be accomplished by worthsmithing the wiki; someone needs to examine each case individually. Otherwise, itâll eventually be even harder to tell if someone really meant pedestrians by highway=footway oneway=yes oneway:foot=yes, and weâll need another proposal for oneway:foot:foot=yes. (Cue stomping of feet.)
2 Likes
Thatâs very likely, because I explicitly went over all highway=footway + oneway=yes (without any bicycle=tags) in my region, and replaced it with oneway:foot=yes if it was actually unidirectional for pedestrians, or removed it if it was wrong. There arenât many cases where this is correct tagging, pretty much only turnstiles and walkways, so not many are left now.
I would not support a mechanical edit like this, but still want people to look at each way individually There might be parts that could be done mechanically (footway=sidewalk parts probably), but Iâd be careful to claim that they are all the same, even in the same jurisdiction. After all, mappers âare all individualsâ, and prone to making mistakes.
3 Likes
I started cycleway-tagging with using oneway:bicycle=yes or oneway=no. I postet a question in the forum about what the meaning of onway on footway/cycleway/path is and got the clear answer that oneway is only referring to vehicle - as it was documented on the oneway wiki page. From then I started using âoneway=yesâ instead of oneway:bicycle=yes on the shared foot/bicycle infrastructure.
Thatâs fair. If we arenât comfortable with automatically retagging the ways that have bicycle=yes/designated, then for the same reason, we shouldnât be comfortable with automatically retagging more than twice as many ways that lack an explicit bicycle=* tag in even more jurisdictions and situations. If we arenât comfortable with automatically retagging them, then we shouldnât be comfortable with telling data consumers to ignore oneway=yes on these ways, which would have the same effect. If we arenât comfortable with them ignoring this tag, then only one interpretation remains. By process of elimination, highway=footway oneway=yes effectively restricts pedestrians.
We have to describe to the mapper how he can describe things unambiguously. Of cause the data user should know about the correct way of tagging but since there will always be errors in the dataset (it is always work in progress), the data user must find out for himself how best to interpret the data in order to obtain the (statistically) best solution for his application. He has to handle contradictory and incorrect tagging.
then we shouldnât be comfortable with telling data consumers to ignore
oneway=yes
I would never tell a data user to ignore anything. He should take into account all tags that help him to interpret the will of the mapper.
3 Likes
That wasnât really my intention. We both know that a proposal canât dictate to data consumers what theyâre supposed to do. I know the proposal said
Anyone who wants to know if a way is one-way for pedestrians can ignore the oneway=* tag
But I wasnât trying to dictate to data consumers how to interpret tags, I was just trying to explain how the proposed tagging scheme would make life easier for data consumers once itâs been adopted.
Most pedestrian routers are currently ignoring oneway on highway=footway, so the proposal would have essentially confirmed that in the eyes of us mappers they can continue to do so.
I wonder if you would have been less opposed to the proposal if I had written the following?
If the tagging scheme described in this proposal is fully adopted, then anyone who wants to know if a way is one-way for pedestrians will only need to look at the
oneway:foot=tag. They could continue to ignore theonewaytag in pedestrian routing, and would no longer need to look at vehicle access tags to figure out if a way withoneway=yesis one-way for pedestrians.
The main practical effect that the proposal would have had (in my mind) is that it would have expressed community approval for the idea of adding oneway:foot= to lots of footways and paths that currently only have a oneway= tag, for added clarity. My proposal suggested nudging mappers to add oneway:foot to reduce ambiguity, by
- changing the Wiki recommendations on how to tag
- adding some validator warnings that warn mappers that in some cases
oneway=is ambiguous and what the mapper is trying to say can be better expressed withoneway:foot=yesoroneway:bicycle=yes - changing footway presets (e.g. the one in iD) which currently offer the
onewaykey, to offeringoneway:foot=andoneway:bicycleinstead
Of course, if I was writing a router myself right now, then given the current tagging situation, if I wanted to get it right most of the time, Iâd probably implement some logic that looks at vehicle access tags (if itâs bicycle=yes then itâs two-way for pedestrians) aka @drolbrâs rule, or at geographic location (if itâs in Germany then itâs two-way for pedestrians).
Maybe we should continue discussing this in the German forum? I have a feeling it may be controversial, because the idea that oneway never applies to pedestrians (because the oneway tag exists to tag one-way traffic rules and that pedestrians are generally exempt from such traffic rules) goes very far back in the German forum.
For example
(I had to double check to make sure I wasnât making this up!)
1 Like
The voting period for the proposal ended on 31 December.
35 people voted in favour, 19 against, and there were 5 abstentions. That is a 65% approval rate, less than the 75% required by the proposal process.
I still consider it a success in the sense that itâs made more people aware of a practical tagging issue: the way many people are currently tagging pedestrian one-ways (by adding oneway=yes to highway=footway or =path) is being ignored by most pedestrian routers. The community is split on whether or not or when exactly the oneway=yes tag should affect pedestrian routing.
I hope the discussion will lead to better tagging (which for me means adding oneway:foot more often, for added clarity) and to more nuanced tag interpretation by data consumers, so that eventually weâll find a way to tag pedestrian one-ways that is accepted by both mappers and data consumersâŠ
12 Likes
From my perspective, this just highlights a shortcoming that needs to be resolved across many projects. If Iâm not mistaken, each of these routing profiles also ignores oneway=yes on highway=steps, despite overwhelming consensus from the community that oneway=yes does apply to pedestrians on steps. Meanwhile, renderers universally depict oneway=yes as applying to the way in general, so an unintentional side effect of the proposal would have been to further entrench a conflict between renderers and routers.
This intention wasnât as clear as it couldâve been. This is why the proposal template sets off a âRationaleâ section, for reciting the status quo and any benefits associated with the proposed change. (Standards bodies likewise distinguish between ânormativeâ and âinformativeâ sections of a proposal, or âwarrantsâ and âsupportâ.) Many older proposals didnât clearly state their assumptions and intentions; weâre still dealing with the fallout today as people naturally take those proposalsâ provisions out of context.
If approved, the proposed change would certainly have made it very easy for router developers to align with the documentation and make some friends on the forum. However, I donât think it wouldâve made it any easier to arrive at the correct answer for a given footpath in the real world â the actual goal of any router. Instead, it wouldâve introduced yet another possible interpretation of any oneway=yes tag, depending on whether the mapper was aware of the proposalâs passage.
To actually reduce ambiguity following your proposal, we would need to embark on a mass retagging that considers the reason why each footpath was tagged as one-way in the first place. But we donât have this information. If oneway:type=* were already widespread by now, then oneway=* versus oneway:foot=* would be a nonissue, just some cosmetic refactoring.
For the most part, I donât think this rewording addresses the concerns I raised. As the more recent poll shows, the most important consideration is the primary feature tag, the highway=* value. The access keys are relevant in a relative handful of cases but mostly a nonissue. Weâre devoting so much attention to these cases only out of respect for the German communityâs longstanding practice. Scoping the proposal to highway=track, highway=path, or highway=pedestrian would be much less problematic, because there is preexisting ambiguity in these cases.
That oneway=yes only affects vehicle was not introduced by the proposal. It was documented years before in the wiki!
The fact that data users do not interoperate oneway for pedestrians is understandable for several reasons.
- There are very few cases (relative) in real world where this applies.
- It was documented that onway=yes only applies to vehicles
- if oneway=yes is evaluated for pedestrians it probably leads to more incorrect oneway=yes for pedestrians than missing true oneway=yes.
6 Likes
Yes, this is true â if it is evaluated the same way for all highway=* ways. No one is suggesting to do that. (Well, one voter did, but that wasnât me.)
Iâm starting to take offence by this, because the Germansâ âlong standing practiceâ is not the reason weâre having this discussion at all, and itâs not helping anyone.
The point is: the poll has shown that we donât fully agree on what routers should make of oneway=yes on several types of highways. And if I was to write a router that gets oneway-ness right in 80% of all the time, Iâm getting it wrong 20% of all the time. And that is a very poor value. And of course you could start making a table what means what, but itâs all worse than aiming for precision and not using oneway=yes on anything where dual-track vehicles are not allowed to go by default, and use oneway:vehicle=yes and oneway:foot=yes, because the only thing that would speak against this is that it means work. The only counter-argument ever brought forwards.
3 Likes
But I actually only meant the supposed footways (footway, steps, pedestrian).
This is only an unproven hypothesis. But it is easy to imagine that someone would interpret it that way without checking whether there might not be some kind of vehicle traffic that was meant instead. And bicycle on footway or destination vehicle in pedestrian zones are much more often than real onway footpaths. (next unproven hypothesis - but I guess you also canât prove me wrong
We both agree that automatically applying highway=pedestrian oneway=yes to pedestrians would create a widespread problem (affecting 13,652 ways). Iâd argue that this has no bearing on highway=footway/corridor/steps/via_ferrata, because the reasons for tagging oneway=yes are probably different.
In many countries, a standard vehicular one-way sign can appear on a highway=pedestrian but not on a highway=footway/corridor/steps, so highway=footway oneway=yes without bicycle=yes is likely motivated by something else. You want to assume this tag is a no-op, a discardable tag, while I want to trust that the mapper meant something by it. Until we can resurvey these ways to add oneway:type=*, we have nothing else to go by.
I wrote (a fragment of) a routing profile 20 posts ago that considers both oneway=* and oneway:foot=* on four highway=* types (but not highway=pedestrian). I contend that it would likely correct existing misbehavior on more ways than it would regress, and that the severity of the current misbehavior is worse than the severity of any regression. However, I agree that any regression in significant number would be unfortunate.
From this discussion, weâve come up with a starting point for two different mitigation strategies: oneway:[mode]=yes and oneway:type=*. All I ask is that we not mislead data consumers to prematurely assume that the mitigation has already taken place comprehensively.
When I belatedly dove into this debate, @osmuser63783 warned me, correctly, that I was underestimating the strong feelings from one corner of the community. Thatâs all I meant by the passage you quoted; Iâm sorry if it sounds like Iâm out to get anyone by pressing these points.
Your suggestion is not going to change existing routers and software, and while it âlooks super easy to implementâ, you have no idea, how complicated and if ever, this is to integrate into other software. And while your example lua code would solve some of the routing issues on highway=footway, it would definitely not fix oneway paths. Thereâs no way around a more precise tagging on these.
Replacing oneway=yes with the aforementioned tags would work without any change of routers, because these already exist, and are generic.
oneway:type=* is meant for mappers, not data consumers. It wonât solve any of the routing issues, it would just hopefully prevent more from happening.
That is something I can relate to. But you currently seem to be arguing about the amount of mitigation required before it can be considered complete, e.g. highway=footway and such can just keep oneway=yes, so itâs less work and (to you) absolutely clear whatâs meant.
My proposal would be to mark oneway=yes on anything thatâs not a dual-track-road as deprecated in editors (not routers) and ask for either oneway:foot=yes and/or oneway:vehicle=yes, no matter how much work that would mean. And as soon as we reach, say, 90 % completion of this task, we can call the mitigation pretty much over, hug each other, high five, and send weird emojis. And at some point, oneway=yes on footways and paths will be a thing of the past, and we will map happily ever after til a random wiki edit destroys the harmony. No?
1 Like
Admittedly, I just winged it and didnât bother to test my Lua code, but I wasnât BSâing.[1] Except for any embarrassing typos, this code should fit in any existing Lua profile for OSRM without any problem. Valhalla uses a Lua profile too, though itâs more convoluted.
No argument from me about highway=path. You wonât find a harsher critic of that tag than me.
Iâm afraid youâre underestimating the degree to which armchair mappers will happily bonk the âfix itâ button provided by an in-editor validator without giving any thought to the wiki, tagging proposals, or signs. Itâs very much a footgun except for the most cosmetic of changes. The moment iD flags oneway=yes as deprecated in one of these scenarios, mappers will spontaneously remove this tag without replacement or add oneway:foot=yes or oneway:vehicle=yes just to get the warning out of the way and increase their HDYC score. Suddenly our favorite new tags will have become skunked, with far less intentionality than when oneway=yes was originally added to these ways. Weâre already digging ourselves this hole regarding crossing tagsâŠ
On a more positive note, I would like StreetComplete to add a oneway:signed=* or oneway:type=* question, like it has for a number of other keys. Sure, itâs for mappers, but a deprecation rule that factors in this tag would probably be much less error-prone.
I used to work on this stuff professionally. â©ïž
1 Like