Apply configurable penalty to gates in car profile#7334
Apply configurable penalty to gates in car profile#7334TheMarex merged 4 commits intoProject-OSRM:masterfrom
Conversation
|
Hrm, can you say more why you think this is different in OSRM then in all other routing engines you referenced? I actually tried this on The gate in question doesn't have an access tag and default accessibility is assumed for all engines.
Yeah but the problem is the inverse is also true: There are tons of parking lots that are accessible and protected with barriers. Unfortunately a lot of POIs would need to snap to those parking lots for correct routing (e.g. to the Lidl above). Making these parking lots unaccessible will mean it snaps to the nearest road which can lead to odd results (snap to a backstreet). A better fix would be to add a penalty in if the access is unclear. Looking at the profile I think we are already doing this? (see |
e7cb042 to
2b055e0
Compare
|
@TheMarex updated to use a 60-second penalty instead of blocking. Is this what you had in mind? |
66f818b to
97462be
Compare
e213988 to
d60bf75
Compare
b71450b to
ec15b49
Compare
ec15b49 to
9d2edeb
Compare
* Remove gate and lift_gate from car profile barrier whitelist * Add the CHANGELOG.md entry * Add configurable gate penalty (60s default) with new Gate obstacle type * Fix gate penalty to allow routing instead of blocking
Issue
Fixes #6757
The car profile currently whitelists
barrier=gateandbarrier=lift_gate, making them unconditionally passable when no access tag is present. This is problematic because many real-world gates lack explicit access tags but are not publicly accessible.This PR applies a configurable time penalty (default 60 seconds) to gates:
access=yes/permissive/designatedbypass the penalty (explicitly open)access=noremain blockedprofile.barrier_penaltiestableGateobstacle type for explicit handlingTasklist
Requirements / Relations