Below are two common cases of sidewalks that don’t meet legal standards in Brazil, where each property owner is responsible for building and maintaining the sidewalk in front of their property. This often leads to fines, but in lower-income areas residents may simply lack the funds to build or upgrade their sidewalk. The result affects all pedestrians, but especially people with disabilities or reduced mobility.
How would you map these situations?
If using sidewalk=* on the main way
If mapping the sidewalk as a separate way with footway=sidewalk
I’d like to focus on two aspects:
Mapping and maintenance effort: how much work should be asked of mappers for these situations, especially when they’re extremely common and there are few mappers available to conduct detailed surveys.
Data consumer readiness: whether the extra detail is actually usable by routers/apps today. This matters more for some pedestrians than others, particularly blind or low-vision users who depend more on the accuracy of routing instructions.
Example 1: sidewalk with uneven levels
Each adjacent property owner builds their own segment of sidewalk, often at a different height than their neighbor’s, creating small unmarked steps between sections. Should this be mapped as highway=steps, or as highway=footway with a barrier=step node at every level change? The latter is more accurate, but multiplied across a whole neighborhood, it could mean an enormous number of extra nodes for a marginal gain, unless routing/accessibility tools actually consume barrier=step today. Would a coarser tag represent most of the practical value with less effort? Or is fine-grained step mapping already paying off in practice, for routing tools, and ultimately for the pedestrians relying on them?
Example 2: sidewalk narrowed by a utility pole or other obstacle
This can sometimes be more extreme, narrowing the path enough to force pedestrians into the street. Should the sidewalk way be split and merged into the main way at the pinch point? Would doing so cause routing/navigation quality problems, such as incorrect routing or confusing instructions? This matters more for pedestrians who depend heavily on precise turn-by-turn guidance, such as blind or low-vision users.
My responses below pertain to footway=sidewalk ways, since this is a level of micromapping beyond what sidewalk=* on the roadway is really designed to express.
This isn’t highway=steps. That’s for a flight of steps that goes up or down more evenly. barrier=step seems to describe this situation well. That’s the main consideration. If you wait for routers to add robust support for something before you map it, you’re going to be waiting a long time, particularly when it comes to active transportation.
At a glance, I don’t see anything about barrier=step in OSRM, Openroutesevice, or MOTIS Per Pedes Routing, but maybe AccessMap considers it. I think wheelchair, stroller, and some cycling profiles would ideally consider it a blocker. By contrast, a general pedestrian profile would probably at most penalize the edge slightly for each step, similar to how a car profile would penalize a speed bump. One wouldn’t be enough to avoid a route, but the ones in the photo would add up.
Another possibility in some cases might be barrier=kerbkerb=raised, which does affect routing in AccessMap and OSRM.
I wouldn’t merge the sidewalk way back into the roadway just for a momentary pinch point. We’re modeling infrastructure, not precise pedestrian movements.
barrier=pole occurs 177 times, presumably on vertices. Some routing profiles avoid any unrecognized miscellaneous barrier=* tag, so it might keep some people away. I’ve also seen the advice to add wheelchair=nostroller=no to either the vertex or the way. (wheelchair=* primarily indicates suitability, though sometimes it also indicates permission.)
We have a lot of low-quality sidewalks here in Bulgaria too. When deciding to map them or not, I tend to look at actual usage. Do pedestrians actually use the sidewalk, or do they prefer to walk on the road? If the sidewalk is not in use because it forces you to squeeze between a pole (or parked cars) and a garden fence, or because it is much more uneven than the road, then I map it as not present. If the sidewalk is in use even though it’s bad (because the road is too dangerous to walk on, for instance), then for separately mapped sidewalks you could try to imagine driving on it with a car and give it a corresponding smoothness tag (Example1) or invent a new value in the obstacle key (obstacle=poles, maybe?) for Example 2. If data consumers will take that into account is another matter.
I don’t mean that highway=steps has to be perfectly even, but this just looks like run-of-the-mill chaos to me. You wouldn’t want the router to tell a pedestrian to “climb the stairs” here. It’s exactly what barrier=step was intended for, repeated haphazardly at the edge of each abutting property. highway=steps would be a crude first approximation, while a micromapper would replace it with highway=footwayfootway=sidewalk and a series of barrier=step.
why not? These are effectively stairs and I have seen and tagged similar structures tagged as highway=steps (granted, usually not on sidewalks, these are usually more well-formed).
I definitely would not be confused by “climb the stairs” here.
I guess I may be rationalizing mistagging for the renderer or get used too much to tagging things like this as highway=steps when mapping hiking trails in detail, but I genuinely see no problem.
I’d expect “climb the stairs” to refer to something more substantial or more abrupt. In Manila, the sidewalks can also be a mishmash. Sometimes there are actual sets of steps between the abutters:
I see no problem with feature X being placed haphazardly (or stupidly, or illegally, or unethically or against wishes of XYZ) still tagged as feature X.
Maybe “flight of steps” from Tag:highway=steps - OpenStreetMap Wiki requires regularity and even structure and lack of haphazardness and I missed it (not a native speaker)?
Those are sets of steps, so you’d map them as highway=steps, not a series of independent barrier=steps. Look a little more closely at the original example and the explanation. The steps along the sidewalk in Brazil have nothing to do with each other. By contrast, in my example from Manila, there is a set of steps every so often. It would be better to indicate the location of each set of steps rather than generalize the whole sidewalk as a single set of steps. Granted, there is the issue of motivation. If no data consumer understands barrier=step, then it is harder to convince mappers to bother with this level of detail.
Anyways, what would a StreetComplete user say the incline=* or step_count=* is for the example from Brazil?
direction of incline is clear from photo, though tag depends on way direction, I see 7 steps on photo though it would be more clear in reality (and tag depends on whether there were more steps earlier and whether it was long highway=steps or mapped as tiny sections of highway=steps)
I would map the Manila example as a 1-meter-long highway=steps way, but I would not map the original São Paulo example as a series of 1-meter-long highway=steps ways.
Taking a step back… do you have any reservations about using barrier=step in the first place? What about when there’s just one step and nothing else to worry about? Here’s an example from the same São Paulo neighborhood:
that is nastier as it has obstacles but these look less steplike, not sure is it qualifying for barrier=step / highway=steps and they definitely vanish toward road.
But yes, I tagged single step as highway=steps step_count=1 before.
highway=steps means steps, plural. A flight of steps is steps arranged intentionally in a series, like your trail examples (which also qualify for flat_steps=yes). If nevertheless you chose highway=steps because it renders, then yes, that would be tagging for the renderer.
Several years ago, I misunderstood barrier=step as the tag for an individual step within a flight of steps. I thought it was a solution for the problem that splitting a highway=steps way makes step_count=* inaccurate. But another mapper corrected me on the talk page and I’ve come to appreciate the ability to tag an isolated step as a barrier.
I’d say you were mistagging for the renderer. A peccadillo in the grand scheme of things, but if @ftrebien was already reeling from the prospect of adding a node for each step in the neighborhood, imagine making them split the way around each individual step!
step_count=* can be added to indicate the number of steps, useful especially for cases where number of steps is low and sparse. It indicates in such cases that steps are less significant obstacle than indicated just by their length.
And its final example shows a sequence of steps of varying lengths.
barrier= is a more micro detail for each feature. Besides wheelchair=no , the =sidewalk can have obstacle= eg the 2 =utility_pole , 4 =steps (and steps=yes )
=pole might be seen, mistaken, or interpreted as similar to =bollard for taller posts. =street_lamp / =utility_pole itself is enough. I would simply add barrier=yes
Another prospect that concerns me is the idea of splitting sidewalk ways in front of every property and tagging each with different surface=* and the challenge of keeping that data accurate and up-to-date everywhere. Sometimes, a new contributor comes along, carries out this work for a few blocks and quits the task midway.[1] This inevitably creates a backlog of maintenance work for other mappers. For instance, when street:name needs to be kept in sync with the name=* of the main way, there are far more small segments to check and update.
Like what happened here in 2021, never picked up by anyone afterward. The blocks to the southwest are mapped like this, whereas the blocks to the northeast are simple footways lacking detail. Typical issues associated with separately mapped sidewalks are all around: missing connections between sidewalks leading to incorrect routing, and absent barrier=kerb nodes at many crossings that actually do have kerbs. As it stands, the calculated pedestrian routes around that area are often misleading, especially for users who rely on accessibility features. ↩︎
Though those are no actual steps. If you want, those are leftovers from people want an even drive way, which is causing a barrier or an obstacle on the sidewalk. That’s different to all the other examples, where the steps where deliberately created.
