poutnikl / Brouter-profiles

My profiles for Brouter offline routing on Android platform
76 stars 17 forks source link

Barrier restrictions #8

Closed utack closed 7 years ago

utack commented 7 years ago

Hi,

the trekking profile currently seems to have a bug, where it routes through barriers For example it will go though a "barrier=gate", that does not have bicycle=yes or any other access tag specified

I would suggest to do the following on any barrier:

  1. Check if it has a "bicycle" tag, if yes use that
  2. Check if it has a "foot" tag, if yes use that (if it has foot=yes and no bicycle information, we can probably push trough it at least)
  3. Check if it has a "motor_vehicle" or "motorcar" tag, if yes use that (if a car can pass through and no bicycle information is given, we can likely use it with a bike)
  4. If neither is present, check if it has an "access" tag, and if yes use that
  5. If none of these tags is present, assume the gate really blocks the way and avoid it

Unfortunately I could not quite figure out where to fix this, help would be really welcome

Thanks Jakob

poutnikl commented 7 years ago

Hi, hmm, it is not a bug, but a feature. :-) My trekking-poutnik profile and the original Arndt's Trekking profile more or less share the general default evaluation of accesses to OSM ways and nodes. Both takes absence of restrictions as implicit access allowed. Similar approach is applied e.g. to tracks without surface= or tracktype=.

The implicit restrictions would solve one problem and create another - plenty of way features with allowed or possible access would be avoided, not being mapped with explicit access related hints.

IMHO, the better is to expliciltly map the obstacle access tags on the OSM.

Removed comment about barrier in way context, as lookups.dat contain only barrier key for node context.

poutnikl commented 7 years ago

For own puposes, the best would probably be to modify in the node context section defaultaccess = if ( access= ) then true # add default barrier restrictions here! else if ( access=private|no ) then false else true bikeaccess footaccess

utack commented 7 years ago

So under defaultaccess I just check for a barrier, and then implement my logic above? Oddly enough this is happening, despite barrier being represented in lookups.dat

unknown lookup name: barrier

poutnikl commented 7 years ago

Yes, this way.

Why oddly ? It is not related to presence in lookups.dat.
Note that BRouter processes barrier= key in node context only, even if OSM defines it for way context as well. The design is, the false restrictions are considered more serious than false lack of them. My profiles reflect but details the access policy of original profiles, as I consider them reasonable.

poutnikl commented 7 years ago

E.g. there is lots of gates on forest tracks in my country, that are either not mapped at all, or incorrectlly tagged, aimed to exclude the forbidden car traffic physically. Avoiding them would be a challenge for planning/calculation of trekking routes.

poutnikl commented 7 years ago

if you want for nodes tagged barrier=gate the default access as forbidden, replace

assign defaultaccess =
       if ( access= ) then true # add default barrier restrictions here!
       else if ( access=private|no ) then false
       else true 

by

assign defaultaccess =
       if ( access= ) then not  ( barrier=gate )   # or barrier=gate|value2|value3......
       else if ( access=private|no ) then false
       else true 
poutnikl commented 7 years ago

Closed as intended design, with hint for wanted deviations.

utack commented 7 years ago

Thank you for the help