Tagging a sidewalk name or creating relation to street?


Anat here from OpenSidewalks project at the University of Washington. We are a project that promotes mapping of the pedestrian transportation layer with detail. One of our aims is to increase accessibility of pedestrian ways both for travelers with disabilities, but also promoting more active transportation trips.

With every new community we work with, we face similar challenges in that there’s not consistent way to associate the sidewalk ways with the road (when there is a road associated with the sidewalk). In the past, some local OSM communities liked using the “description” (not the “name”) tag to associate something like “NE sidewalk of Eaton Street” with the way. However, globally, OSM community does not love this and it is also difficult to get some of our downstream OSM consuming applications to use this consistently in an automated way.

Before putting up a proposal on the wiki, I wanted to open this discussion in the community. Some of the goals that this tag would achieve are described below, but we want to make sure that everyone’s interests are covered, so please propose others as well. Thanks!


  1. Using sidewalk association with the road/street name, wayfinding applications would be able to offer text or audible turn-by-turn directions for pedestrians (for example, “use the Northeast sidewalk of Eaton Street, walk to the intersection with 4th Avenue”)
  2. Using sidewalk association with road/street name, transportation planning applications can account for presence/absence of pedestrian structure in their street network
  3. Using sidewalk association with road/street name, downstream routing or simulation applications have a consistent manner to connect street environments to pedestrian environments in transit network analyses (for example, tying scheduled bus system stops with the appropriate sidewalk when pedestrians are disembarking the bus).

It is true that each downstream application can apply some set of heuristics to test the proximity of sidewalk infrastructure to streets and impute the association. However, given the variability in building standards in different locations, and the fact that many cities are not built in block-like structure, this endeavor is not as easy as it sounds, nor does it end up in human-validated ways of confirming these associations. It would be great to get a consistent mechanism for explicitly tagging these associations, particularly for the non-obvious cases.

Looking forward to a good discussion!



description= is not reliable, and rel is more complicated. I love name= myself. It is simple, will likely be supported almost everywhere, and is consistent with other parallel road features. (eg divided roads, frontage roadways, and bridges or tunnels) Renderers can choose not to show name= on footway=sidewalk.
I’m unsure of the benefit, reliability, or efficiency of explicit side tagging. This should be determined by applications. A road can change direction anywhere.
The problem with name= in associating is when the road has no name, or ref=. But then any additional functionality won’t work with it anyway. Only in this case does a rel becomes absolutely necessary if needed.
With all the type= from =associatedstreet to =street, the scope and data structure is unclear. To the extreme when a street is very long, or there are many members, it may have to be split perhaps arbitrarily, and require nesting. Another possible question is why not collect all sections of a road in a separate rel a la type=multilinestring first, before relating it to other objects.
Have you commented on is_sidepath= including is_sidepath:of:name=? Which is an awkward syntax to me.
A further issue is associating other features viz roadside facilities and street furniture. Having all the different *:street= for everything is unsatisfactory. The need for associating anything to a road generally (including parking=lane) was recognized in discussion of is_sidepath=. Talk:Tag:parking=street side - OpenStreetMap Wiki


For reference:


Thank you for referencing the is_sidepath proposal. I read through the various arguments and it seems like the identifier is_sidepath only gets through half the battle (that is, of identifying the footpath as a sidepath of another way).

Perhaps I’m not fully understanding the proposed values for that tag, but how would that proposal further identify a sidepath’s (1) orientation viz-a-viz the associated road (northeast sidewalk of… south sidewalk of…) and (2) the actual road/street that this sidepath is associated with?


  1. It can’t.
  2. It relies on name= by is_sidepath:of:name=, and highway= class by is_sideapth:of=.

description= is not reliable, and rel is more complicated. I love name= myself. It is simple, will likely be supported almost everywhere, and is consistent with other parallel road features. (eg divided roads, frontage roadways, and bridges or tunnels) Renderers can choose not to show name= on footway=sidewalk.

yes, in Italy we came to similar conclusions, relations had also been discussed but were seen as not necessary and too complex. The same issue as with sidewalks also applies to cycleways along roads.


but how would that proposal further identify a sidepath’s (1) orientation viz-a-viz the associated road (northeast sidewalk of… south sidewalk of…)

this information is already in the data (geometrically), although using it requires understanding which highway a sidewalk belongs to (e.g. with several parallel carriageways and a sidewalk in between it may not always be clear).

The is_sidepath scheme was designed for exactly the kind of purposes you are facing right now @TaskarCenterAtUW. The proposal has recently been discussed in the community and has been met with controversy. Essentially, it tries to provide a way to express relational information through tags. However, it might be better to use a different syntax for this, e.g. something like related and related:name. Then this kind of “tagging relation” could be applied to other things like linkings between shops and their entrances, linking a roadside parking bay to its street, etc.

The core problem is that relations (as an OSM data element) in their current form are barely/practically not suitable for grouping streets and their adjacent sidepaths, because relations are difficult/practically not usable for non-experts, and there are hardly any possibilities to systematically check and maintain the data. (We are talking about streets that exist practically everywhere - so most OSM contributors would need to be able to create street relations, check them for completeness, integrity, recognise problems with the relation, etc. - this is an utopian vision for the foreseeable future).

In my opinion, a form of “tagging relation” as described above enables exactly the goals you mentioned:

  • offer text or audible turn-by-turn directions for pedestrians (using the related:name, or the proposed is_sidepath:of:name - but this indeed has an awkward syntax :slight_smile:)
  • account for presence/absence of pedestrian structure (you better need to do this by correct tagging on the street centerline, e.g. sidewalk:left=no, sidewalk:right=separate!)
  • applications should actually be able to solve geometrically quite easily the side and direction of the sidewalk related to “it’s” street, if they know for sure that the sidewalk is located next to the street because it’s tagged according to a “relational tagging scheme”.

So we should continue to follow this issue in order to find solutions.


Isn’t this already achieved by sidewalk:right=separate? I.e.: “The next footway right of this way is our sidewalk”.


I was thinking from the perspective of a sidewalk / routing on sidewalk lines: For a direction like “Use the Northeast sidewalk of Eaton Street” [or, in OSM language, e.g. “Use the sidewalk on the right of Eaton Street in OSM line direction”] when routing is happening on a sidewalk grid, the sidewalk segment has to calculate whether it is on the left or right side of the street? Assuming there are sidewalks on both sides of the street.

Not sure if I follow. Your last statement about the usefulness of is_sidepath (and similar) was made under the presumption that the geometry between footways and roads need to be analyzed in order to relate them to each other.

Both is_sidepath and sidewalk:right=separate are indicators for that the footway and road are not incidentally next to each other but are related to each other (i.e. one is a sidewalk of the other).

Now, since resolving such geometric relatonships (for all roads, all sidewalks) is expensive, I expect such things to be done by data users in a preprocessing step so that in the end, the relation to the street is already there when the data is actually used.

So the preprocessing algorithm would be “relate the next footway you find right of this road as sidewalk to this road”.

1 Like

Sometimes OSM way with sidewalk is not related to single street eg. here, I think sometimes it may be impossible to identify related street.

@kubahahaha – If I understand you correctly, I believe that particular sidewalk example you included would just be segmented at the corner in order to make its association identifiable (one segment with Wiersbowa street, the other with Barska street)


Yes it would be required to associate it with named streets.
But I believe it shouldn’t be done on OSM side. With current data model I think we shouldn’t require to create a lot of short ways for some virtual assignments, as we are not doing it for routers right now - in my previous example router has to tell you to turn left even if you are walking along single way.

I prefer to map sidewalk ways in alignment with a single named street because the sidewalk is conceptually part of the street. If I walk down North Union Street and turn left on Grant Street, I’m on a new street now. I don’t think of myself as being on the same sidewalk that has taken a turn around a corner.

Here multiple sidewalks around several blocks have been mapped as a single way. This is fine for a first pass, but it doesn’t seem like an ideal end state. I’ll probably break this up into separate segments along each street at some point.

I’d definitely like to have a good tagging method for associating sidewalks to the streets they are part of.


in the past i went with just name on the sidewalk as it was implied as being possible correct at some point, but people weren’t happy about it. Though now looking I missed undoing it on some roads in my town.

Had it that way for 4 years on a good number of sidewalks around town, I really want to make pedestrian/bike routing work well and really needs to be a way to mark the sidewalk has that name or belongs to that street. Now thinking about it more I am still unsure if undoing it was right, but people told me it was wrong so i changed it.

That is quite good idea actually. As an added benefit: most duplicated properties of roadways (name, ref, surface etc.) can be moved to it and everything else that’s different can be on the way (turn:lanes, lanes etc.).

This does not work in practice and leads to constantly broken and incomplete relations.
It is not without reason that we in Germany (known for precise work :wink: ) have deleted in 2019 all associatedStreet relations.
Discussion in Germany (old Forum)


Sometimes OSM way with sidewalk is not related to single street eg. here, I think sometimes it may be impossible to identify related street.

but in this case it can be related to the nearby streets (and must be split, what could be a preprocessing step). In other cases, going by 2-dimensional proximity, there will be detections of related streets where there isn’t such relation in the real world (e.g. because there is a retaining wall between the sidewalk and the road and both are vertically distant)

Do you have an empiric evaluation on specific wishes posted by those travelers with disabilities to the project of yours? I only can imagine, people with limited eyesight might want something different than people in mobility scooters e.g.

Of course, sensible directions sure is something that also people without any disabilities certainly will appreciate.

1 Like