barrier=gate and barrier=lift_gate should not be whitelisted in car profile #6757
Labels
Comments
|
This bug was motivated by the Community Forum posting https://community.openstreetmap.org/t/osrm-routing-durch-tore-hindurch/107573 Valhalle and Graphhopper both honor the barrier=gate + access=private Flo |
|
Thats the commit i am running with now: |
flohoff
added a commit
to flohoff/osrm-backend
that referenced
this issue
Jan 9, 2024
Currently we only have one step for penaltys of width which is <3m or lanes=1 on a bidirectional way. It makes a difference if a higher class road is 4m or 6m as with 4m you wont be able to pass other cars so you will have some reduction in average speed. So introduce more steps in the penalty for width e.g. <6m which is a small penalty as there be issues with trucks passing, below 5m which is you wont be able to pass trucks without going out to the shoulder 4m which is you wont be able to pass a truck with a car, and 3m where basically one has to go back to let the other pass, or find some passing spot. I ran this change with >1 Mio routes on top of changes in issue Project-OSRM#6772 Project-OSRM#6757 and checked for issues. Overall observation is that now routes tend to slightly stay longer on the higher class road network. Route quality in areas where width has been tagged more increases.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi,
currently in car profile barrier=gate and barrier=lift_gate are per-se whitelisted which means one can not use access tag on that note.
These 2 types of barriers should be processed with access tags in mind as they may be typically open so usable by the public, or they may be typically closed meaning its not usable by the public.
With the whitelisting in place there is no way to prohibit the OSRM car routing from using that path other then tagging the way, which may be completely okay to use for the public.
So please remove the whitelisting for these 2 types of barriers.
This is the commit i am running now with:
flohoff@0eabdc9
Flo
The text was updated successfully, but these errors were encountered: