I wouldn’t claim that the wiki page (the tables) represents the complete and definitive truth about default values; at most, it serves as a guideline. After all, at the top of the same wiki page (emphasis mine), it says:
The (sometimes changing) values in the tables below are not a reason to omit explicit tagging on ways in OSM and are also not a reason to remove existing tagging from ways.
This page documents what some mappers consider to be correct fallback behavior in a routing engine and could be considered a proposed specification. However, no mainstream routing engine uses this page directly to influence routing behavior.
By the way, now that I’ve read the introductory paragraphs of the wiki, I also understand this discussion here much better. It’s clearly not as simple as I initially thought. Still, I would personally stick to the principle of only recording what you actually observe (OTG) and leaving any questions about default values to the consumers. Whether those consumers choose to use the tables from the wiki is up to them.
While I don’t disagree with that, we’re still dealing with an unusual case of tagging for the router here, because the intent is to “fix” cycle routing problems which do not exist.
For the benefit of everyone else here, from previous edits we’ve discussed, I believe one of the tools you’re using is the CyclOSM renderer (right?). It renders pavements with/without bicycle=no differently — they’re greyed out with bicycle=no and are rendered in colour without it (i.e. the default).
I’ve just been up in Manchester and was using SCEE while walking around.
Unsurprisingly, none of the separately mapped highway=footway + footway=sidewalk or footway=crossing ways I saw had a diagram 951 “cycling prohibited” or 966 “cyclists dismount” sign. For the crossings, I simply removed the bicycle=no tag. For the sidewalks, I replaced it with bicycle:signed=no, a value determined by an in-person survey, not added through a mechanical edit. I also frivolously added completely useless tags describing surfaces, lighting and accessibility at crossings while I was there.
As there still isn’t an issue or PR on CyclOSM’s Github, I think we can treat that attempt to map for the renderer as an entirely spurious justification. So far, I don’t think anyone has been able to find a cycle routing service which does not honour highway=footway without additional and redundant access tags.
When I have time, I’ll write a proper mechanical edit proposal to reverse the rest of these and open it up to community discussion and a vote.
I confirm CycleStreets already, and has since we launched almost 20 years ago, treated a general highway=footway as no cycling (but pushing permitted). There is no need to add any other information.
If another router or cartographic renderer is implying that cycling is permitted, you must raise it with them, as their code is simply wrong. The solution is not to add extra data to OSM.
So please do not clutter the database with bicycle=no/dismount on general pavements (sidewalks).
As you know, we come from a cycle campaigning background, promoting responsible cycling, and we have absolutely no intention whatsoever to suggest that cyclists should be cycling on pavements. Thank you similarly for all your work for cycling over so many years.
A highway=footway without any bicycle tagging does already mean cycling is not permitted (but cycles can be pushed). It is a tagging implication (by common knowledge) that bicycle=dismount is intended.
It is not really correct to say that it is undefined because it may or may not allow cycling. If cycling is permitted, a highway=footway can be changed to the entirely different legal scenario of a shared-use pavement (technically an unsegregated cycle track) by adding bicycle=yes. Without the bicycle tag it is unambiguously not intended for cycling even though this is not explicitly stated.
OSM is chock-full of these kinds of implications. Examples:
We don’t normally put bicycle=no on every highway=motorway - as that is already the legal situation
We don’t put oneway=yes on every junction=roundabout - we only add that when it’s an exception
We don’t put oneway=no on every road - we only add that when it’s an exception
We don’t put surface=asphalt on every road - we only add surface=… when it’s an exception
and hundreds more similar cases.
So you can be reassured that the absence of any bicycle tagging on a highway=footway will not result in people being routed over it by cycle.
Has anyone reported this to them? Couldn’t immediately see it.
Providing a very clear explanation to them (with particular reference to the UK situation) would be useful, and hopefully would enable someone to do a simple PR without having to wade through complex knowledge. If it is currently wrong, we and everyone else would surely welcome getting this corrected ASAP.
Can someone provide a screenshot of where that renderer is apparently getting it wrong?
That’s the only point I’d take issue with. With StreetComplete, that gets added all over the place. The most concise way for SC to tag a highway segment that it’s been surveyed and found not to be a surface other than asphalt is probably to add surface=asphalt. Also, for people with enough time to enable the smoothness=* quest, that requires a value of surface=*.
No. The only person who claims there’s a problem needs it to remain unsolved as it’s the nearest they have to justification for spamming every separate sidewalk with bicycle=no.
If they really, desperately, needed to add a redundant access tag to reflect the prohibition of driving a carriage on a footway in s. 72 Highway Act 1835, it probably ought to be vehicle=no + bicycle=dismount.
The other obvious problem with adding bicycle=no with a mechanical edit rather than a survey is that short sections of footway where cycling is allowed will be missed. Unless you have very good aerial and street side imagery, you can’t see all of the diagram 956 and 957 signs, or the buff corduroy tactile paving at the boundary of a shared section.
Sorry to resurrect this one again, but just as a “heads up” - the situation where “you’re not allowed to cycle on a pavement in the UK but are allowed to push a bike there” is now getting tagged asbicycle:pushing=yes; bicycle=no. That isn’t in line with previous UK usage of bicycle described above but it does contain the information that “pushing a bike here is allowed”.
This is somewhat documented in the wiki - I suspect that page was created as a result of the numerous forum threads there were as of January this year. That page says “Requires bicycle=no”; that statement doesn’t quite fit with the forum threads from 9 months ago; it’s usual in the UK** for bicycle=dismount to be used to indicate that pushing is allowed and for bicycle=no to mean that neither pushing nor cycling is allowed.
** driven by the large numbers of England and Wales “public footpaths” where “the right to even push a bicycle” cannot be assumed (and no, please let’s not have the discussions about the lack of case law around that again; it’s all in previous forum threads).
Difficult to say - overpass finds two areas only currently.
Edited to add: Re “mechanical” as described by the policy: That covers (selective quote) “substantial changes made using ‘find and replace’ or similar functions”. As an example, I’d no idea what the source of the bicycle=no edit to https://www.openstreetmap.org/way/1147203736/history was - whether it was
“I’ve been there, seen that it is just a pavement beside a road, know that there is no cycling on the pavement by law and therefore added a bicycle=no tag” or
“I’ve searching for a footway=sidewalk without bicycle=no, assumed that it is mapped correctly as a pavement beside a road, not done any investigation beyond that, know that there is no cycling on the pavement by law and therefore added a bicycle=no tag”
The former is clearly not mechanical; the latter is, and of course there is is a large grey area between them.
I don’t think Pete Owens does mechanical edits, and I believe he does (occasionally) read these forums, so my best suggestion would be to engage with him (probably via changeset comments or a private message on OSM) and discuss this latest tagging move. He does (mostly) respond to factual messages and does sometimes change his editing practices as a result (although he won’t ever admit it).