You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Whilst debugging a routing issue using the default car.lua profile, I determined the cause was the use of the barrier=kerb tag on a node that is part of a major road. I believe the intention is for the barrier tag to describe the highway crossing, not the highway itself.
barrier=kerb is not included in the whitelist for the default car profile - the OSM guidelines treat the use of this tag for a highway crossing as a mistake.
However, it appears its usage is quite widespread, which leads me to believe a one-off correction would not prevent these from being recreated.
Whilst this is not specifically an OSRM issue and can be fixed with profile changes, it does raise the issue of how the profile can be more resilient to OSM tagging mistakes.
Related
There have been previous discussions around this topic. #5067 - Routing over barrier=kerb may make sense over small private roads, e.g. driveways. #3890 - Discusses changing whitelists to blacklists to deal with unexpected tags. This was applied for foot and bicycle profiles. The suggestion is this could also be applied to major highways for cars, where the list of applicable barriers is stable.
The text was updated successfully, but these errors were encountered:
This is something we've adjusted on our internal deployment and I forgot to push back into the main repo. Our diff looks like this:
diff --git a/profiles/car.lua b/profiles/car.lua--- a/profiles/car.lua+++ b/profiles/car.lua@@ -361,7 +360,11 @@ function process_node(profile, node, result, relations)
local bollard = node:get_value_by_key("bollard")
local rising_bollard = bollard and "rising" == bollard
- if not profile.barrier_whitelist[barrier] and not rising_bollard or restricted_by_height then+ -- make an exception for lowered/flat barrier=kerb+ local kerb = node:get_value_by_key("kerb")+ local flat_kerb = kerb and ("lowered" == kerb or "flush" == kerb)++ if not profile.barrier_whitelist[barrier] and not rising_bollard and not flat_kerb or restricted_by_height then
result.barrier = true
end
end
Made #5999 to add this.
Also included an additional clause for highway=crossing tags as there are still some barriers that the above change doesn't catch, including the example above.
Whilst debugging a routing issue using the default
car.lua
profile, I determined the cause was the use of thebarrier=kerb
tag on a node that is part of a major road. I believe the intention is for the barrier tag to describe the highway crossing, not the highway itself.Here's an example:
node
diverted route
barrier=kerb
is not included in the whitelist for the default car profile - the OSM guidelines treat the use of this tag for a highway crossing as a mistake.However, it appears its usage is quite widespread, which leads me to believe a one-off correction would not prevent these from being recreated.
Whilst this is not specifically an OSRM issue and can be fixed with profile changes, it does raise the issue of how the profile can be more resilient to OSM tagging mistakes.
Related
There have been previous discussions around this topic.
#5067 - Routing over
barrier=kerb
may make sense over small private roads, e.g. driveways.#3890 - Discusses changing whitelists to blacklists to deal with unexpected tags. This was applied for foot and bicycle profiles. The suggestion is this could also be applied to major highways for cars, where the list of applicable barriers is stable.
The text was updated successfully, but these errors were encountered: