Add support for foot=use_sidepath / sidewalk=separate

[TheMarex]

Several communities in the US have started to map sidewalks as separate ways, even if they are attached to the main roads. This degrades the quality of our routing as we route on the main road and the sidewalk, generating erratic routes, problems with snapping and blowing up the size of the road network artificially.

There are two tagging schemes that mark roads that have a detached sidewalk: foot=use_sidepath and sidewalk=separate. Roads tagged like that should not be included in the routing graph anymore.

[emiltin]

ew. mapping sidewalks (and bike lanes) as separate ways is an annoying practice that should be reversed when ever possible :-)

[TheMarex]

mapping sidewalks (and bike lanes) as separate ways is an annoying practice

I agree, but the local communities in Denver, San Jose and Washington DC don't feel that way. This is causing real issues for our pedestrian routing in these cities and ignoring the center-line streets is at least a work-a-round that make it less bad.

[emiltin]

oh boy i've seen some spaghetti intersections based on this type of modelling.

[1ec5]

Modeling bike lanes as separate ways is a separate issue from modeling sidewalks as separate ways. The distinction is that sidewalks in these cities generally have “limited access” to the road, whereas bike lanes are part of the road. So in San José, for instance, sidewalks are mapped separately while bike lanes are just cycleway tags on the roadways.

[emiltin]

not sure what you mean by limited access to the road?

[1ec5]

Sorry for hand-waving there. In much of North America, the norm is that a sidewalk is separated from the roadway by a verge, so a router would ideally only have a pedestrian leave the sidewalk and cross the road at crosswalks or perhaps driveways. By contrast, a typical bike lane is only separated from vehicular traffic by a pavement marking. Since the vehicular lanes are modeled together as one way, so would the bike lane be modeled together with them.

As far as I can tell, the presence of a verge is the main reason for modeling sidewalks as separate ways. I’d imagine some protected bike lane designs would be mapped as a separate way by the same reasoning.

Hopefully instances of sidewalk=separate and foot=use_sidepath have been mapped carefully enough that avoiding these highway ways won’t break routing significantly. I think it’s fair to say the intent of these tags is for walking routers to avoid them anyhow.

[3vivekb]

Perhaps alternatively you can penalize unnamed sidewalks that are along roads? Thus keeps on using the roads?

Also sometimes one might want to keep the sidewalk=left and sidewalk=right tags, even though sidewalks are tagged as separate ways. This preserves compatibility with OpenTripPlanner which is moving to support those tags.

[1ec5]

Perhaps alternatively you can penalize unnamed sidewalks that are along roads? Thus keeps on using the roads?

Penalties could only be applied to graph edges, but the problem that motivated this issue is that the sidewalk ways themselves bloat the routing graph.

Also sometimes one might want to keep the sidewalk=left and sidewalk=right tags, even though sidewalks are tagged as separate ways. This preserves compatibility with OpenTripPlanner which is moving to support those tags.

How would routers and renderers distinguish this tagging scheme from the scheme in which sidewalks aren’t modeled as separate ways? (Imagine a renderer that synthesizes sidewalks based on sidewalk=left/right tags.)

[1ec5]

Should we treat this issue as a duplicate of #1171?

[nbolten]

Sidewalks are often mapped as separate footpaths because it's a more appropriate description - they have their own geometries and interface with other features several meters away from the centerline of the road, often with several barriers between the road itself and the sidewalk. Please do not revert them or advocate for reverting them.

I tried to keep my 'reasons to map this way' brief but kept failing, so sorry for the length:

(1) First, geometrical accuracy. Sidewalks are separated ways in some way or another, otherwise they'd just be part of the street - they are separated by markings, bollards, raised curbs, verges, etc. They are several meters removed from the street centerline, and do not need to match the street's geometry with a consistent offset. Whether sidewalk users can also transition to the street varies widely. In addition, as mentioned by @1ec5, they interface with other footways and driveways, and they do so several meters removed from the street centerline.

(2) Second, semantics and connectivity: sidewalks connect to one another via crossings (or other footways), and this is awkward to represent with street centerlines and crossing nodes. Let's take a situation where you want to use crosswalks preferentially. As footways, you can just draw a continuous way and split it into types - sidewalk, crossing, etc, and routing along them is the same approach as for streets, just use the way network + tags. As street metadata, you are in this curious situation: route along the street, keeping in mind what side you are on. When you meet a street, travel 'up' it if it's on the correct 'side' during approach. If you encounter a highway-crossing node, use it. Then travel back down the street to the intersection, and turn left/right depending on the initial approach. Continue. There are some ways to attempt to preprocess this information, but at some point this type of logic has to be handled routing with for sidewalk=* on street centerlines.

(3) Third, it massively clutters and complicates street centerlines once you have to add even just a little more metadata. Adding just sidewalk width and surface changes means splitting the way every time one of those facts changes, which happens to be pretty often. A semi-randomly selected sidewalk near the University of Washington (my area) has ~3 surface changes and 7 width changes, which would mean splitting the street centerline 10 times. And that's just for one sidewalk - the other side also has a sidewalk that can vary in other important, pedestrian-relevant attributes.

Also, due to reason (2), if a router ever wants to properly handle side-of-street and crossing information, it'll need to expand the graph anyways or embed a lot of extra state into the routing algorithm to keep track of the fake 'turns'.

Finally, there's going to be lots of footways near streets anyways, as OSM becomes more complete, so the challenge of selecting footways vs. streets is there no matter what.

So in summary:

• Separate sidewalks are nifty and great.
• Sidewalks as metadata are fine if your only question is 'is there a sidewalk on this side of the street?', but are a big pain for anything else.
• Tackling this issue is probably necessary even if you disagree with the other points.

[HolgerJeromin]

You dont need ugly sidewalk modeling for the need of foot=use_sidewalk
https://www.openstreetmap.org/way/58421500#map=18/51.87161/8.49429
https://www.mapillary.com/app/?focus=photo&pKey=cQvKyObKMGw7MonbaX-X3A

[jtracey]

I'll point out that cycle tracks are unambiguously supposed to be mapped seperately, and also make use of the similar bicycle=use_sidepath and cycleway=separate tags. The former is particularly important, since it means right now OSRM is giving directions that would be illegal to follow.

I'll also add a +1 to mapping sidewalks as separate ways, and note that it's standard practice in Canadian cities. Mapping the interaction between cycleways, sidewalks, and crossings would be a nightmare using tags alone.

[jdhoek]

Unlike bicycle=use_sidepath — which was succesfully proposed here, and is documented here — other tag/value combinations with use_sidepath have not been documented and discussed.

Tag usage for foot=use_sidepath currently exceeds 30.000 ways.

It would probably help if someone with some affinity with the tags (foot=use_sidepath in particular) could document their broader use on any access key (not just bicycle) on the relevant wiki-pages, including access.

To the best of my knowledge foot=use_sidepath should mean that OSRM should ignore roads tagged with it for pedestrians and dismounted cyclists — the latter is something the bicycle profile supports, and the use of foot=use_sidepath now leads to routing instructions that send cyclists over busy roads they shouldn't use because this tag is ignored, and the road considered suitable for dismounting and walking a bit if it's the faster route.

[kaligrafy]

Any news on this?
I also map sidewalk and cycling paths separately from roads because we need to be more precise in the future around intersections and crossings. Crossing locations and distances can also be used as a routability indicator (minimizing crossing distances also reduces probability of collision with cars).

[Henryk14]

Roads tagged foot=use_sidepath (and sidewalk=separate) are still used for pedestrian routing. Is there any chance to change it?

[jdhoek]

@Henryk14: sidewalk=separate on its own says nothing about the allowed use of the road for pedestrian users. This tends to depend on local laws and local road layout, hence the need for foot=* if there is a separately mapped sidewalk and pedestrians can't walk on the street itself. Routers should ignore sidewalk=separate for basic can or cannot access rules, but may (conceivably) use it to slightly penalize ways tagged with it, because usually the sidewalk is preferable to pedestrians.

(With regards to my comment from 2019 above: the use_sidepath tag value is now much better documented on the wiki, and routers shouldn't route over them if applicable to their mode of transportation.)

[Henryk14]

@jdhoek I completely agree with you, @TheMarex and others, that routers shouldn’t generate a pedestrian route over roads tagged with foot=use_sidepath but apparently OSRM (and also GraphHooper) still does it. The question is: can we do sth about that?

If there are no plans to change the routing algorithm, then maybe tagging foot=use_sidepath should be abandoned, and foot=no should be used instead?

[kaligrafy]

just add 'use_sidepath' to the access_tag_blacklist array in the foot profile and it will work well!

[jdhoek]

If there are no plans to change the routing algorithm, then maybe tagging foot=use_sidepath should be abandoned, and foot=no should be used instead?

It shouldn't be too hard to fix, nor controversial. I contributed 92406da two years ago where bicycle=use_sidepath is handled in the bicycle profile. At that time documentation for the other use_sidepath tags was lacking, but this has been addressed in the mean time, and foot=use_sidepath has become an established tag in its own right.

[Henryk14]

just add 'use_sidepath' to the access_tag_blacklist array in the foot profile and it will work well!

I'm new to OSRM. Can somebody help with that?

[kaligrafy]

In the foot profile
Change these lines (starts at line 40):

access_tag_blacklist = Set {
      'no',
      'agricultural',
      'forestry',
      'private',
      'delivery',
    },

to these lines:

access_tag_blacklist = Set {
      'no',
      'agricultural',
      'forestry',
      'private',
      'delivery',
      'use_sidepath',
    },

[kaligrafy]

But be advised that some parts of the world are not completed/validated for the use_sidepath tag. In the Montreal area (Canada), we are building a team right now to sanitize and validate all the routing data (around 10% done so far, WIP). Most of the time, there are missing connections between sidewalk/footpaths and the rest of the road network, so be careful.

[Henryk14]

@jdhoek @kaligrafy
Can you look at my pool request?

[jdhoek]

I'm only an outside contributor, so I'm not qualified to say anything official about the patch. Thanks for taking the time to try to fix it though!

First: have your PR target the master branch of Project-OSRM/osrm-backend instead of the master of your own fork. That should bring it to the attention of this project's maintainers.

Personally, I would recommend adding a comment like I did in 92406da, add a similar line to CHANGELOG.md, and see if there is a unit test you can expand the same way I did for bicycle=use_sidepath.

Running the tests may be tricky, but someone will probably step up to help with that in the PR.

[github-actions]

This issue seems to be stale. It will be closed in 30 days if no further activity occurs.

[kaligrafy]

Not stale, still needs discussion and concensus. mapping sidewalks as separate ways will not disappear and is docuemnted officially, so we need to discuss how to deal with foot=use_sidepath. I propose to add it to both the blacklist and the restrited so the routing can use it at the beginning or at the end of the route to connect to a POI or precise location.

[github-actions]

This issue seems to be stale. It will be closed in 30 days if no further activity occurs.