Not in Germany. It’s something a router should discourage on its own for regular bicycles. Always based on the stair’s attributes. We have a lot of very shallows stairs over here at the canal, and it’s very common to ride down the stairs. Upwards … not so much, but it’s possible.
what about motorcycles?
Maybe so, but one could argue that an access tag is too blunt an instrument to use for this purpose. I’d prefer to know why some way is inaccessible to a bicycle, for instance.
In the legal case (as the access tags should be used per the wiki), this is extremely straightforward. Otherwise, the criteria are not only muddled, but also multi-modal. Is the way inaccessible because it’s too narrow? Steep? Someone thinks the surface is too spongy or mucky? I’d like to decide for myself how narrow/steep/mucky a path I’m willing to cycle (or walk, or hike, or drive) on. The modalities one would have to encode just keep multiplying.
This, I also think, is spot on. And very difficult to solve!
To the many contributors who put tremendous effort into using, documenting, and creating additional verifiable tags, as well as those who advocate for their support in routers and renderers.
First, sorry, but adding boat=no without any additional details provides little verifiable information. Second, the goal isn’t to remove them but based on the general consensus would be to move them to a separate tag and educate mappers and data consumers about the additional tags available.
Whoever tags bicycle=no based on practicality evidently sees it as self-explanatory, just as whoever tags bicycle=no based on a sign or marking sees it as self-explanatory. But as we saw with highway=footway oneway=yes, signs are also very good at producing disagreement. As a starting point, there should still be a way to say, simply, yes or no. Clarification is good, but we won’t get there by assuming that an unqualified access tag always refers to legal permission or prohibition. If nothing else, there’s a large body of existing homogeneous tagging that we’d need to reevaluate – not that it’s actually causing routers to do the wrong thing in general.
(This last point is going to raise heckling from some in this thread, but I stand by it. If the situation were as dire some assume, OSM would never have been taken seriously as a navigable map anywhere. Now the challenge is to get OSM to this level of usability in the rest of the world, which may indeed require evolving the tagging scheme.)
What I’m getting at is that you need to put the cart before the horse (and maybe pick your battles too). We’re talking about some of the oldest and most common keys in OSM. This practice has been around longer than you or me. Craft a compelling alternative before critiquing the boat=no on an obviously unnavigable urban stream as a violation of a grand unified theory.
Well, firstly I think we ought to at least insist that people use bicycle=discouraged/impractical/nonadvisable/whatever (instead of =no) whenever the criteria for it are based on practicality instead of explicit signage or law.
Furthermore, my point on multimodality stands. A way that is ‘impractical’ for a normal bicycle is often fine for an MTB. A way ‘impractical’ for the Stereotypical Sunday Stroll is often fine for hiking. So presumably we’d need to have ‘impracticality’ tags for all the different vehicles and modes. At that point, we’d just be duplicating descriptive tags.
Notice again that a legal restriction on bicycles almost always covers all bicycles (ditto for Sunday strollers and hikers). So the self-explanatoriness of these cases differ massively.
Exactly. Now, if this were tagged as mtb:scale=3, would that mean it should be tagged as bicycle=no + mtb=discouraged?
How can this approach be even maintainable and sustainable?
I honestly don’t think it is that straightforward. Maybe for roads and streets that are part of the main highway network, but not for all sorts of minor service roads, tracks, and paths. Often the legal situation has to be deduced from physical evidence such as gates, chains, fences, guard dogs, patrolling security guards, or other obstacles. The distinction between mapping legal access and mapping suitability can become blurred. I think any proposal to separate the two needs to allow for that, rather than starting with the idea that legal access will always be clearly signed.
As an example, last weekend I was walking in an area where there is a complicated boundary between public Natural Park land and a mixture of private residences, restaurants, and events venues. If you approach by car and park along the road, locked gates and fences prevent you straying onto private land. But approaching on foot from the forest, I accidentally arrived at the private side of a locked gate and had to retrace my steps. To be honest, my main concern is that maps should not route walkers along that path, and ideally should render it in a distinctive way. Whether that is a legal or practical judgement is a secondary consideration.
I see your point, but obstacles and barriers are already considered by routers, so we don’t always need to add extra tags to the ways if we’re unsure about the official legal access.
But doesn’t relying on barriers simply shift the same issue from the access tags on the way to the access tags on the barrier? The fact that a gate exists doesn’t indicate on its own that a way is not routable for any form of transport.
Looking back at the original post, I see that it’s very carefully scoped to only affect ways. An odd choice, considering that access=* and other access keys are routinely tagged on all sorts of features, not only roads and paths. Gates, parking lots, ferries, building entrances, toilets, restaurants inside a secure area of an airport, playgrounds, swimming pools, to name just a handful of examples. The considerations around legality and practicality differ depending on the feature, and routers aren’t even the most obvious data consumer for access tags on some of these features. Mappers repurposed the access keys for non-traversible features, and now I suppose some of the same thought processes have invaded navigation mapping.
Ah. Well.
bicycle=no has been problematic since the very earliest days of OSM. Does it mean “no bicycles” or “no cycling”? Because there is a difference: “no bicycles” means you can’t push one, “no cycling” means you can’t ride one. The former is arguably the case on most UK footpaths. There’s a load of legal stuff around “usual accompaniment” you can read if you’re having difficulty sleeping. Or big long mailing list threads.
bicycle=dismount was latterly (~2009) popularised to fix this ambiguity, but bicycle=no is still used in an ambiguous fashion.
boat=no has issues too. The Thames above Lechlade should legally be boat=yes. There is a public right of navigation. There are also frequent trees across the river. But you can get a canoe through if you’re adventurous, and people do, and a canoe is a boat. Someone has tagged it as boat=no with the changeset comment “Marked Thames as unnavigable upstream of this point”, which is just wrong, and means there’s nowhere in OSM that the public right of navigation is correctly recorded.
I don’t quite know where I’m going with this other than to observe that using =no to indicate anything other than legal access rights gets very messy, very quickly. I’m 100% up for an easy-to-use tagging practice for practicality, but access tags ain’t it.
So I can go around adding boat=yes to all the streets around town, assuming the authorities around here haven’t ever heard of a portage? 
I think that would be boat=dismount 
Well, the wiki has a lot of catching up to do And yes, we obviously need to start somewhere. Access tags on ways are the most common (and often controversial) starting point.
Are there really any physical restrictions on gates or obstacles (like locked, width, height, or smoothness) that a router cannot interpret or that could influence a particular type of navigation? There was a separate discussion earlier, but I wanted to address the highways first.
If your goal is to improve routing, you need to consider barriers along with traversible ways. Otherwise, all bets are off. Some of us hail from regions where private property is routinely fenced or walled off, so the barriers matter a lot.
I think there needs to be some outlet for generalizations. The list of barrier types is varied and growing longer by the year. Every type has a different form factor, so if we expect a descriptive key along the lines of locked=* for each of them, it’s going to be an unbounded set of keys, which won’t be a very attractive proposal. Remember also that users usually don’t fill out a ten-page questionnaire when requesting a route; the router either needs to trust our generalizations or guess the vehicle’s dimensions, capabilities, etc. A generalization is still a decent first step; not everyone has the patience for a scientific scale.
The vast majority of barriers in some regions are gates or chains along the driveways of Amazon Prime customers. These service roads were mapped by Amazon Logistics staff who haven’t shared their source material and probably won’t come back to migrate the barriers to a new tagging scheme until we’ve convinced them to update their internal routing engine that we’ve never seen. Or maybe we can leave them all alone because trespassing is against the law anyways?
I don’t think that Amazon’s minions restricted themselves to Prime customers (if they did, my local sewage works, which had the concrete round the back mapped by them, was an unusual one). It looked more like “they were paid to add things that look like roads so they did”.
My observations and interaction would suggest (in the UK)
I suspect that we have to treat all of these remotely-added barriers as “needs survey” anyway.
I’m not familiar with their mapping in the UK, but my understanding is that a large share of their mapping in the U.S. has been based on fleet telemetry (so presumably Amazon Prime customers are well-represented). This is based on observations, discussions with drivers, and what they’ve told us. Based on my limited experience field-verifying their mapping, the barriers are much more reliable than the access=private that they littered the map with in the early days, but YMMV.
the number of vehicles one owns is mostly manageable, so if you are using an app (or otherwise have persistent settings) you could well add some more information to your query, without compiling a 10 page questionnaire for every request, only once for every vehicle (provided the app supports it)
This is a very specific notion of an end user. There are many reasons why a user might need to get routes for different vehicle types from request to request, such as riding with someone else, renting a bike, or driving a truck or bus that’s part of a fleet. While there’s certainly benefit in being able to tailor a route to a specific vehicle, it can’t be the baseline requirement for getting a valid OSM-based route. Even today, there are plenty of motorhome drivers who get plain-old Car directions. They just have to be extra mindful of the vehicle’s size and weight and be vigilant against any departure from the main roads.
A fine example of why physical properties should be tagged, rather than mappers attempting to assess suitability for different vehicles. If someone sees a low bridge and tags hgv=no, that doesn’t help motorhome drivers at all.
Edit: and similarly, tagging bicycle=no because of some stairs or narrow sections doesn’t help wheelchair or pram users