Wouldn’t that cause a router app to punish for both the bad smoothness and the potholes, i.e. it would incorrectly punish twice for the same issue?
if router would do it this way, this does not validate adding fake smoothness
(in practice, is any router taking separately mapped potholes into account at all?)
[Off-topic] I wonder what potholes=craptons means.
Point being, the potholes tag is a rough quality assessment serving as an alternative to pothole micromapping. There is obviously a need for this type of tag.
Looking at the Usable by column, except for the flat sections, I don’t think this surface as a whole could be used even by a car with high clearance (surface=very_bad).
To that, I’ve already added my recommendation of best benefit/effort ratio: just tag the whole way as highway=steps and call it a day, concentrating your saved time on things where your invested effort is likely to produce more significant improvements.
“Do people like eating oysters today?” Such general question is impossible to answer.
But yes, some do support it today[1]. Some even explicitly document that they do. To which extent each of them support barrier=*, and how much attention they pay to the actual value of barrier key, depends heavily on specific data consumer you have in mind[2] – and you would probably get more precise result by asking on their specific communication forum (or looking at the source code yourself).
But, not to leave you completely dry, here is one example: in this default Brouter gravel bike profile, barrier=step would get (maximum/default) penalty of 139 (whereas, if it were barrier=cycle_barrier instead, it would get penalty of mere 87).[3]
(Now, your wheelchair users probably would not be using gravel bike router profile, but some other profile, even better tailored to their specific needs, but it is not a worst profile to start from).
I’m relieved we agree there!
Yes. That is how OSM (and world in general) works. You have incomplete data, and you have to make assumptions, and sometimes assumptions work, and sometimes they don’t, and then you update assumptions so they might hopefully work better next time, and update the knowledge base (i.e. OSM data) with known verified data, so there needs to be less assumptions. Rinse, repeat.
If someone thinks that this process will ever end and all data will be perfectly mapped and we’d all live happily everafter: well, I admire their optimism, but cannot share it.[4]
And also, obviously different data consumers make different assumptions, so you’d pick one which works best for you.
And if you’re picky and willing to define exactly how picky you are, I’d recommend Brouter, with profile tailored exactly to your specification. Also e.g. OsmAnd knows how to use Brouter (if you’re looking for complete navigation solution and not just routing engine itself).
Once made, you can even share that profile to other users with similar needs!
There are whole another threads with hundreds of messages about that (and thus, I’d agree with you that we should prefer sticking to original point about those sidewalks/steps in Brazil here, lest this discussion becomes unreadable); so I’ll just quickly summarize that highway=steps is generally considered bad choice even for more offroad 4WD vehicles then regular sports car or sedan.
On highway=steps, only reasonable interpretation (IMHO) is that smoothness=* tag defines smoothness of each step[5] (alternative interpretation would be nonsensical, as there is no point tagging smoothness=impassable on all highway=steps ways in the world – if one subscribes to that POV, better not to tag smoothness at all in such cases).
and, conversely, some don’t – you’d should be contacting them if you see benefit in them implementing support for that ↩︎
Surely you’re not suggesting people should find all thousands of OSM data consumers in the world, analyze them, and serve you the nicely formatted result; right? ↩︎
Of course, you can easily add extra line
switch barrier=step 931if that strikes your fancy. ↩︎At best – or at worst? – at some point diminishing returns will make mappers bored and they’ll stop mapping. Otherwise, our OCD will continue driving us to ever asymptotically try to approach that ideal of “no assumptions needed, everything is clearly defined” ↩︎
i.e. exactly the thing you excluded in your quote ↩︎
1 Like
Maybe that there are crap tons (i.e. “a lot”) of potholes there?
(But since OSM prefers British English, it should’ve probably been shit tons? 
)
Perhaps look up who added those tags, and ask them on their changeset discussion what they meant?
1 Like
10 posts were split to a new topic: Smoothness on highway=steps
At least in Brazil, applications should not assume that sidewalks or pedestrian crossings (footway=crossing) are wheelchair-accessible, they should assume wheelchair=limited rather than wheelchair=yes). Data from the 2022 census (in Portuguese) reveal this critical situation:
| State capital | Population (million) | Sidewalk coverage % | Sidewalks with obstacles % | Intersections with wheelchair ramps % |
|---|---|---|---|---|
| São Paulo | 21 | 90 | 66 | 17 |
| Rio de Janeiro | 13 | 81 | 53 | 16 |
| Belo Horizonte | 5.2 | 92 | 70 | 28 |
| Brasília | 4.1 | 93 | 72 | 30 |
| Recife | 4.0 | 72 | 57 | 13 |
| Porto Alegre | 3.8 | 82 | 53 | 35 |
| Fortaleza | 3.6 | 89 | 74 | 12 |
| Curitiba | 3.5 | 95 | 62 | 41 |
| Salvador | 3.5 | 56 | 38 | 7 |
| Goiânia | 2.6 | 98 | 65 | 35 |
| Manaus | 2.3 | 82 | 74 | 7 |
| Belém | 2.1 | 77 | 66 | 10 |
| Vitória | 1.9 | 75 | 38 | 35 |
| São Luís | 1.5 | 88 | 82 | 9 |
| Florianópolis | 1.3 | 75 | 49 | 20 |
| Natal | 1.3 | 87 | 72 | 18 |
| João Pessoa | 1.3 | 91 | 75 | 13 |
| Maceió | 1.2 | 85 | 64 | 17 |
| Aracaju | 1.1 | 93 | 74 | 29 |
| Teresina | 1.1 | 93 | 87 | 12 |
| Cuiabá | 1.0 | 86 | 70 | 27 |
| Campo Grande | 0.96 | 85 | 55 | 56 |
| Macapá | 0.65 | 64 | 54 | 15 |
| Rio Branco | 0.63 | 78 | 71 | 15 |
| Palmas | 0.60 | 88 | 75 | 12 |
| Porto Velho | 0.58 | 76 | 63 | 19 |
| Boa Vista | 0.53 | 62 | 43 | 17 |
Now, imagine the work needed to map every obstacle on every sidewalk in the country, or every kerb at every intersection. An app truly designed for people with disabilities cannot assume that all of this will ever be meticulously mapped.
My guess is that it’s analagous to a smoothness tag, but contact the mapper (only 3 examples) to see what value.
It strikes me that a little more nuance is required here for the use of being ‘on’ steps and smoothness.
I am a little familiar with these types of variable spaced stepped footways on the frontages of building on hills from walking on them on holidays where they exist.
I think how a user interacts with the footway matters with respect to impact of the steps on that use.
If a user is driving across them from the main highway to a parking space, the step ‘tread’ is deep enough and smooth enough to do this with ease.
If a user is travelling along the steps, I’m not sure smoothness is of much use. The variable tread spacing and rising is a fair obstacle to many and an absolute obstacle to some. Smooth or not. Smoothness not indicating step rise (height) and tread (length).
So why not record the footway highway as steps, but with a tag step_spacing=variable to indicate the potential change & challenge along the way? Driveways etc across the steps mapped with crossing nodes as would be mapped for unstepped footways. No need to record the height and length of each step. Unless you want to!
I am not sure what you mean here exactly. Do you have picture? (I’m imagining you’re talking about something like a treaded downward ramp like e.g. this but somewhat more rugged, but I definitely wouldn’t have tagged that or similar things as highway=steps)
Interestingly, that is the main use I see. E.g. if you are older, unsure of foot, or there is snow/ice/rain, or carrying things, and/or the surface is not concrete/asphalt/paving_stones, them smoothness is as important (if not more!) for many pedestrians on steps as it is on other flat surfaces (it might not be important to cars, but cars rarely travel on highway=steps over here anyway, so they should not be concerned with any other tags on steps anyways).
Yes, I would agree, smoothness=* is completely different attribute from step:height and step:length in highway=steps context.
1 Like
The first image in the first post of this thread. https://community-cdn.openstreetmap.org/uploads/default/optimized/3X/e/0/e07ba8276276d7c64aa6ae6f19ad81e632b3521e_2_280x500.jpeg
I’m not taking about ramps to carparks. Perhaps this view of one of the other linked images shows it slightly better if imagining a drive or shop front every 5-6 metres.
Hence my focus on whether travelling across the steps or along the steps. I’ve seen drive access or shop fronts make use of the wide/deep (depending on direction of travel) steps, leaving the shorter ones in small groups between the wide steps. The corner slope in the image just makes thing nastier for all. Seen in various places around the Mediterranean, I just can’t be precise where due to memory!
Edit: I think is fair to add the smoothness along the steps for the reasons you indicate.
To conclude and return to the topic, it is perhaps best to map these sidewalks in Brazil as highway=steps because mapping them as highway=footway does not accurately reflect reality, and mappers are not required to micromap, and demanding this would result in consistent failure to provide good information to accessibility tools.
Adding wheelchair=no is also appropriate. However, this might conflict with adding foot=use_sidepath to the main way.
1 Like
Maybe rather say it like this, the “low-level”-way would be to use highway=steps, though highway=footway with barriers or small sections of highway=steps would be the “high-level”-way.
Just keep in mind, not to replace the “high-level”-way with the “low-level” one.
2 Likes
Terminology note: I usually say “high effort” or “high detail”, because “level” can be confused with altitude-as-metaphor-for-zoom level, which goes backwards, where “viewed from a high level” is a lower level of detail.
1 Like
Yeah. I think common term in OSM for that is Micromapping – e.g. in this case micromapping would be mapping a dozen of small highway=footway ways, with connecting nodes between them being tagged as barrier=step each.
As opposed to “regular” mapping (don’t know if we have a term for that, but “low-detail” works for me too), when you would just draw one single way and tag it as highway=steps.
1 Like
The Crux of the terminology is that even though it’s “low detail” it is still correct and acceptable to map. But if someone comes by and switches to the high detail version you’re not reverting or anything, it’s still an upgrade.
2 Likes
I found this article from local media about accessibility on São Paulo’s steepest street quite interesting. This account comes from a consultant who is also a wheelchair user:
Using the sidewalk itself is impossible. It’s not just the slope; the sidewalks are actually formed by a series of steps. So, the sidewalk is essentially one huge staircase. I think I could manage to go down along the street,[1] but going up? No way.[2]
This article also features a photo of a person walking up the street while avoiding the sidewalk, as it is highly discontinuous and full of obstacles: steps, uneven paved surfaces, and tree roots.
The word used, “via”, informally refers to the car traffic area, not including the sidewalks. ↩︎
Original in Portuguese: “Pela calçada em si, é impossível. Não só pela inclinação, porque as calçadas são formadas onde existem degraus. Então, a calçada é uma imensa escadaria. Eu acredito que conseguiria descer pela via, agora subir, de forma alguma.” ↩︎
2 Likes
To me, “low-detail” sounds like it is insufficient, like in the early days, when dual-carriageway highways were mapped as a single line, or when highly imprecise contour lines were drawn in empty areas. There might be a middle ground on this scale, though I wouldn’t know how to describe it with a single word (perhaps “cost-effective”): a point where the level of detail is considered sufficient for most use cases. Of course, “sufficient” always depends on the context: what suffices for the average pedestrian differs from what is required for accessibility purposes, and, in that regard, needs vary depending on the type of disability.
Well, I did not find dual-line motorways being mapped as single line as “insufficient” at the time; if fact we used them just fine.
Agreed. Just like today, such dual-carriageways marked “just” as two oneway=yes ways but without all the appropriate turn:lanes:forward etc. is not “insufficient”, but just not as nice as it could be mapped.
But yeah, you could use comparative “lower-detail” to soften it when discussing both, or just use more neutral “regular mapping” term, or negation (“non-micromapping”).
Or explain with extra sentence or two, if you thing misunderstanding is likely.
Whatever you think might get your point across.
When confusion is likely (yet important it is not misunderstood), I usually just prefer to state explicity what exactly am I actually drawing and tagging, instead of using some generic term trying to describe it.
E.g. as in my post above:
Sure, slightly (but not much) longer than alternatives, but I think extremely precise and with 0% chance of misunderstanding, yes? And it provides extra information that e.g. using “low-detail mapping of steps” does not give.
I don’t particularly like that phrase for that purpose; it can (and does) mean quite different things too (e.g. that you used an import, or automated edit, or AI-assisted editor, etc).