osrm-backend
osrm-backend copied to clipboard
in foot profile, change barrier_whitelist to barrier_blacklist
current whitelisting of barrier serves well for car routing, but due to man barrier types focused on pedestrians (and connected spelling errors), it is very inconvenient to keep a whitelist.
the proposal is to change it to blacklist, and allow foot
routing over all mapping and spelling errors.
@emiltin what about bicycle profile? should it be blacklist or whitelist?
what are examples of barriers that are currently incorrectly blocking pedestrian routing?
looking at data of Slovakia, it is rather a long list: bump_gate,debris,derbis,door,fallen_tree, fallen_trees,fullheight_turnstile,full-height_turnstile,guard_rail,h,hampshire_gate,height_restrictor,chain, jersey_barrier,kissing_gate,lift_gate,log,organic_waste,rope,scrub,stile,sump_buster,swing_gata,swing:gate, swing_gate,turnstile,windthrow
some of them are spelling errors and wrong mapping, but still it is a long list. while the blacklist is rather small (yes, fence, wall).
database query was select string_agg(distinct barrier, ',') from planet_osm_point where barrier is not null and barrier not in ('cycle_barrier', 'bollard', 'entrance', 'cattle_grid', 'border_control', 'toll_booth', 'sally_port', 'gate', 'no', 'kerb', 'block');
for pedestrians i agree most of these should be allowed, although we should go through the list and consider if some should be blacklisted.
for bikes i think it also makes sense to move to a blacklist, although it's harder to decide what needs to be blacklisted. i think stiles and certainly full-height turnstiles http://wiki.openstreetmap.org/wiki/Tag:barrier%3Dfull-height_turnstile should be blacklisted for bikes. but stuff like http://wiki.openstreetmap.org/wiki/Tag:barrier%3Dswing_gate is more of a grey area. if they are closed and you can't go around them, it's certainly not very practical to pass on a bike.
I did some data checking for SK:
barrier | access | foot | bicycle | count
----------------+-------------+------+---------+-------
block | | yes | yes | 161
block | | | | 136
block | | yes | | 21
bollard | | yes | yes | 576
bollard | | | | 373
bollard | | yes | | 32
border_control | | | | 50
cycle_barrier | | | | 119
cycle_barrier | | yes | yes | 25
debris | | | | 12
entrance | | | | 207
entrance | | yes | yes | 66
entrance | | yes | | 33
entrance | | yes | no | 22
fence | | | | 23
gate | | | | 3724
gate | private | | | 708
gate | | yes | yes | 416
gate | | no | no | 231
gate | customers | | | 131
gate | | yes | | 121
gate | no | | | 109
gate | permissive | | | 74
gate | no | no | no | 70
gate | private | no | no | 49
gate | | yes | no | 47
gate | yes | | | 27
gate | destination | | | 26
gate | yes | yes | yes | 22
gate | permissive | no | no | 18
gate | private | yes | yes | 12
gate | delivery | | | 11
chain | | | | 13
lift_gate | | yes | yes | 986
lift_gate | | | | 859
lift_gate | private | | | 104
lift_gate | | yes | | 81
lift_gate | | no | no | 34
lift_gate | customers | | | 26
lift_gate | | yes | no | 16
lift_gate | private | yes | yes | 16
lift_gate | yes | yes | yes | 14
lift_gate | no | yes | yes | 13
lift_gate | yes | | | 12
lift_gate | permissive | yes | yes | 11
sally_port | | | | 14
stile | | | | 25
swing_gate | | | | 79
swing_gate | | yes | yes | 54
windthrow | | | | 13
for foot, I would blacklist those that should be on ways only {'fence', 'wall', 'hedge', 'retaining_wall', 'city_wall'}
for bicycle, I am not sure. they should be connected to width
parameter and access tags. maybe {'cycle_barrier', 'full-height_turnstile', 'kissing_gate', 'turnstile'}
should be bicycle=no
by default.
fyi, the query was select barrier, tags->'access' as access, tags->'foot' as foot, tags->'bicycle' as bicycle, count(*) as count from fresh_osm_point where barrier is not null group by barrier, access, foot, bicycle having count(*) > 10 order by barrier, count(*) desc limit 200;
cycle_barrier is usuallly quite easy to pass on bike, even though it might slow you down, see e.g. the photo here: http://wiki.openstreetmap.org/wiki/Tag:barrier%3Dcycle_barrier. so i wouldn't blacklist that (unless you're on a cargo bike, which is different story anyways.)
after running very short list of blacklist, the only problem is with access=customers
on nodes like door. then it tries to take shortcuts through ZOOs or shops.
Check out https://github.com/Project-OSRM/osrm-backend/issues/3913 - there is a set of restricted tags we set high turn penalties on - but it's based on restricted way tags, think: access=destination
).
You could also handle access=customers
nodes as barriers in the profile's node function.
@daniel-j-h afaik turn penalty only works if the tags are on way. this bug is about tags on nodes (and sane defaults for foot/bike profile). #3862 would solve adding turn penalty based on node.
Just a quick datapoint: I've been debugging a car routing issue which was caused by someone inventing a new tag (barrier=security_control
) which then broke routing along that road. (I've now added an explicit access=yes
to counter it.)
Arguably this is a mapping error but it might be worth considering whether this makes car routing too fragile. OSRM could potentially move to a blacklist for car routing too, at least on highway=tertiary
and better, which are unlikely to have barriers obstructing traffic.
I am also seeing an issue where barrier=height_restrictor is blocking foot routing.
Here for example https://map.project-osrm.org/?z=17¢er=52.617612%2C-2.447741&loc=52.615895%2C-2.441679&loc=52.615315%2C-2.442280&hl=en&alt=0&srv=2
Does barrier=height_restrictor into a whitelist in foot.lua?
This issue seems to be stale. It will be closed in 30 days if no further activity occurs.
Looks like this simply never was closed, despite being done in https://github.com/Project-OSRM/osrm-backend/commit/918e794d6a5a6211851ab134fdaba7d0cf9e7d5e.