foot: respect foot=use_sidepath and sidewalk:*=separate tags#7426
Merged
DennisOSRM merged 5 commits intomasterfrom Mar 26, 2026
Merged
foot: respect foot=use_sidepath and sidewalk:*=separate tags#7426DennisOSRM merged 5 commits intomasterfrom
DennisOSRM merged 5 commits intomasterfrom
Conversation
Roads tagged foot=use_sidepath have a separately mapped compulsory parallel footway that pedestrians are required to use (by law in some countries such as the Netherlands and Germany). OSRM was ignoring this tag and routing pedestrians on the carriageway instead. Add 'use_sidepath' to the foot profile's access_tag_blacklist, matching the identical treatment already applied to bicycle=use_sidepath in the bicycle profile. Test coverage added in: - features/foot/access.feature: access-table rows asserting foot=use_sidepath (alone and combined with access=yes/permissive) produces no route. - features/foot/use_sidepath.feature: route-preference scenario verifying that when a parallel footway exists the router takes the footway rather than the foot=use_sidepath carriageway. Fixes #6229 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Ways tagged with sidewalk=separate, sidewalk:both=separate, or sidewalk:left/right=separate indicate that the pedestrian path is already captured by a distinct OSM way. Routing pedestrians along the carriageway in those cases duplicates the separately-mapped footway. Add a local handle_sidewalk_separate handler that blocks forward and backward access when any of these tags is present, unless foot access is explicitly whitelisted (e.g. foot=yes/permissive/designated). Also adds a failing test scenario that verifies routes prefer the separately-mapped footway over the carriageway. Fixes part of #6229. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The previous handle_sidewalk_separate only checked access_tag_whitelist (yes/foot/permissive/designated) as the override guard. This meant foot=destination would still be blocked even though the mapper explicitly allowed pedestrian access. Fix: check per-direction whether the access tag is explicitly set and not blacklisted. Any explicit non-blacklisted value (including destination) suppresses the sidewalk inference for that direction. Also restructure the handler to exit early when no sidewalk:*=separate tag is present, and return false when both directions end up blocked. Add test: explicit foot=destination or foot=yes with sidewalk:right=separate still routes; no foot tag with sidewalk:right=separate does not. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
DennisOSRM
added a commit
that referenced
this pull request
Mar 26, 2026
Roads tagged with cycleway=separate, cycleway:both=separate, or cycleway:left/right=separate have a separately mapped parallel cycleway. Cyclists should be routed via that cycleway instead of the carriageway. Add a handle_cycleway_separate handler to the bicycle profile that blocks carriageway access when any cycleway:* tag is set to 'separate'. Explicit bicycle access tags (bicycle=yes/permissive/designated/destination) override the inference, matching the pattern established in the foot profile for sidewalk:*=separate (PR #7426). Fixes #1171. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This was referenced Mar 26, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Fixes #6229.
The foot profile ignored
foot=use_sidepathandsidewalk:left/right/both=separatetags, routing pedestrians along carriageways instead of separately-mapped parallel footways.Solution
1.
foot=use_sidepath→ blacklistedAdded
use_sidepathtoaccess_tag_blacklistin the foot profile, matching the existing behaviour of the bicycle profile. Ways taggedfoot=use_sidepathhave a compulsory parallel footway that pedestrians must use instead.2.
sidewalk:*=separate→ inference blockAdded a
handle_sidewalk_separatehandler that blocks carriageway access when any ofsidewalk,sidewalk:both,sidewalk:left, orsidewalk:rightis set toseparate. This covers the common real-world case where roads are tagged with directional sidewalk tags instead offoot=use_sidepath(e.g. way 672340162).Explicit foot access tags override the inference:
foot=yes,foot=permissive,foot=designated, orfoot=destinationon the same way suppress the block for the respective direction.Tests
features/foot/access.feature: addeduse_sidepathrow to the access tags scenario; added rows to the access combinations scenario; added a new scenario verifying that explicitfoot=destination/foot=yesstill routes whensidewalk:right=separateis present.features/foot/use_sidepath.feature(new): two route-preference scenarios verifying that routing goes via the parallel footway rather than the blocked carriageway, for bothfoot=use_sidepathandsidewalk:right=separate.All 51
@footscenarios pass.Follow-up
A potential Option 2 (treating
use_sidepathas restricted rather than fully blocked, allowing last-resort routing via the carriageway) is left for a future PR.