Is there consensus on mapping pavements (sidewalks) separately to roads?

[Minh_Nguyen (Minh Nguyễn)]

@Tordanik

A core reason for this situation is that both commonly used approaches lack the ability to capture some important knowledge about the world: Tags on the main highway=* cannot faithfully represent sidewalk geometries (and struggle to represent details such as barriers on sidewalks), while separate ways fail to capture the information which road a sidewalk belongs to. As a result, either choice makes some use cases of OSM data much harder or impossible to implement.

As a developer of both rendering and navigation software, I can attest to this tradeoff. Sidewalks need to be associated with roadways for pedestrian navigation using wearables and especially for assistive technology for visual impairment. The latter use case relies exclusively on voice guidance, so the street name is essential, but so is accurate data about obstacles. I’ve seen at least one wearable application configure Valhalla’s costing model to avoid sidewalk ways just to get road names in voice guidance, but it’s clearly suboptimal.

Despite this tradeoff, I lean in favor of separate ways. Tags on ways are inherently incapable of representing geometries effectively, whereas the problem of associating sidewalks with roadways is hopefully solvable. In regions like mine where sidewalks are generally separated by a curb or verge, if someone is willing and able to draw separate sidewalk ways, I think they should be encouraged to do so. Eventually someone will have to draw the ways anyways, so we should take advantage of that zeal when it arises.

@Tordanik

Some solutions have been suggested (e.g. the is_sidepath:of:name=* tags), but so far, none have gained traction.

Some cities have been adding name or street:name to sidewalks. In principle, data consumers should be able to infer that the sidewalk and roadway are related by comparing their names, in much the same way that Nominatim matches addr:street to road names or Skeletron generalizes dual carriageways based on road names.

I suspect this approach hasn’t caught on more broadly because of the assumption that data consumers can already infer these associations based on geometry alone, or maybe based on sidewalk=separate. Unfortunately, a typical city abounds in cases that violate this assumption, requiring a more explicit approach.

@n76

Or you need to add a connector from the sidewalk to the road to make the foot routing work. But those connectors are not really there, they are simply aids to allow routing and keep the QA tools happy.

As a counterpoint, if the sidewalks are only tagged on the roadways, a non-sidewalk footpath would also need virtual connections with roadways to avoid breaking pedestrian routing. Here are some trivial examples of non-sidewalks that would result in oversimplified routes if connected directly to a roadway without separate sidewalk ways:

• Way: ‪Hiram Street‬ (‪19069650‬) | OpenStreetMap
• Way: 718221566 | OpenStreetMap
• Way: ‪Gage Street‬ (‪744238894‬) | OpenStreetMap
• Way: 1050626542 | OpenStreetMap (edit: the route discussed below)
• Way: 155477812 | OpenStreetMap

Long ago, I started out using the sidewalk key exclusively. Over time, I discovered a steady stream of these edge cases, each one necessitating an oasis of more detailed mapping, until the point where it just made common sense to link the oases together with separately drawn ways.