syme
October 4, 2025, 2:42pm
1
Hello,
When I use ORS to calculate hiking (or walking) routes, I notice that many local paths are avoided. This includes marked hiking trails that should normally be routable. I’ve checked the OSM data for these paths, and there don’t seem to be any obvious access restrictions (no private=yes, no access=no, etc.).
In addition, I can see sac_scale=strolling on several of these paths, so according to my understanding, that should not exclude them.
For example, most of the ways in these relations are affected:
Here is an example where several of these paths are skipped by the routing engine.
I’d like to understand why the routing engine avoids so many of these paths, even though they seem valid (to me) in OSM.
Thank you for your help!
Hey,
these are marked as sac_scale=strolling, a rather new addition to the OSM, and not a SAC scale that is used outside of OSM.
Compared to sac_scale=hiking, it is also not very commonly used, see this comparison on taginfo.
Therefore, no one has thought about adding it to openrouteservice, and consequently, the ors considers these ways as non-applicable for foot-* profiles.
The fix is comparatively easy though:
main ← feat/add-sac-scale-strolling
opened 01:20PM - 06 Oct 25 UTC
### Pull Request Checklist
- [ ] 1. I have [**rebased**][rebase] the latest v… ersion of the main branch into my feature branch and all conflicts
have been resolved.
- [ ] 2. I have added information about the change/addition to functionality to the CHANGELOG.md file under the
[Unreleased] heading.
- [ ] 3. I have documented my code using JDocs tags.
- [ ] 4. I have removed unnecessary commented out code, imports and System.out.println statements.
- [ ] 5. I have written JUnit tests for any new methods/classes and ensured that they pass.
- [ ] 6. I have created API tests for any new functionality exposed to the API.
- [ ] 7. If changes/additions are made to the ors-config.json file, I have added these to the [ors config documentation][config]
along with a short description of what it is for, and documented this in the Pull Request (below).
- [ ] 8. I have built graphs with my code of the Heidelberg.osm.gz file and run the api-tests with all test passing
- [ ] 9. I have referenced the Issue Number in the Pull Request (if the changes were from an issue).
- [ ] 10. For new features or changes involving building of graphs, I have tested on a larger dataset
(at least Germany), and the graphs build without problems (i.e. no out-of-memory errors).
- [ ] 11. For new features or changes involving the graphbuilding process (i.e. changing encoders, updating the
importer etc.), I have generated longer distance routes for the affected profiles with different options
(avoid features, max weight etc.) and compared these with the routes of the same parameters and start/end
points generated from the current live ORS.
If there are differences then the reasoning for these **MUST** be documented in the pull request.
- [ ] 12. I have written in the Pull Request information about the changes made including their intended usage
and why the change was needed.
- [ ] 13. For changes touching the API documentation, I have tested that the API playground [renders correctly][api].
Fixes # .
### Information about the changes
- Key functionality added:
- Reason for change:
### Examples and reasons for differences between live ORS routes, and those generated from this pull request
-
### Required changes to ors config (if applicable)
-
[config]: https://GIScience.github.io/openrouteservice/run-instance/configuration/
[api]: https://gitlab.gistools.geog.uni-heidelberg.de/giscience/openrouteservice-infrastructure/ors-docs-api#test-new-ors-documentation
[rebase]: https://github.com/GIScience/openrouteservice/blob/main/CONTRIBUTE.md#pull-request-guidelines
It should be part of the next release
Best regards
2 Likes
syme
October 6, 2025, 2:44pm
3
Thank you very much! I can’t wait for the fix to take effect. It’ll save me from having to use so many direct points as a workaround .
1 Like