LoRouter MTB profile: inconsistent barrier handling

Viajero Perdido shared this problem ago

Not processed

Hi. It seems the LoRouter MTB profile (online, offline, web), handles barriers differently than the other cycling or walking profiles. I've found this with two different types of barrier: barrier=gate (alone, no other tags), also barrier=gate, bicycle=yes, foot=yes.

All the profiles except MTB seem to let you right through the gate, even without the extra two tags. But MTB never lets you through, even with the explicit access tags.

I'm not sure what a router should do with a simple barrier=*. (In my region, we have lots of simple barrier=gate, with true access really being determined by the adjacent ways. In other words, it might make most sense to consider all barriers transparent for bikes and walkers.

The same problem 0

Replies (2)

Viajero Perdido ●

(Cancel this comment, my mistake.)

Reply URL

Viajero Perdido ●

(Thanks for reactivating this topic.)

The second example (explicit bicycle=yes, foot=yes tags) now seems to work properly, at least in web planner. However, with the first example (simple barrier=gate), MTB still avoids the barrier while the other cycle profiles allow passage.

Reply URL

zossebart ●

yes, your second example is routed fine now. Maybe you didn't wait long enough for the routing data to be updated after your edit in osm?

For the first example, the behaviour is as intended. Because barriers without access tags are not guaranteed to be passable (in all countrys/regions), they are avoided so that you don't end at a closed gate, which could be bad especially if you are far out in the wild.

There could be added a parameter to switch the behaviour (allow barriers without access tags), but I'd rather set it to false by default.

Another problem would be that Locus does not offer all parameters to be switched through the gui except some general ones. So the profile might be adapted, but you wouldn't be able to switch the parameter from locus unless Menion decides to finally allow arbitrary profile parameters :-( See https://help.locusmap.eu/topic/dynamic-brouter-profile-configuration

URL

Viajero Perdido ●

So it's intentional that MTB cannot go through barrier=gate, but Bike Touring, Road Bike, Walking, Hiking can? That seems odd.

https://web.locusmap.app/en/?planner=N4EwvgXg+gQgNsYBDCBREAjGArMAlAboBkB7AWQBUYBuAoA

IMHO, without access tags, barrier should only stop what it can physically stop, no? Gates generally can't stop walkers or cyclists; we go around. Just my opinion. By this logic, every profile today (per this link) except MTB works as expected.

(In the second example far above, which I now consider fixed, I did wait for the update to reach the web planner before reporting.)

URL

zossebart ●

I don't think it is necessarily intended by the Locus developers, but as they include routing profiles from different sources, they behave differently.

IMHO, we can't assume that you can go around a gate by foot or bike, what if the gate is in a fence? Would you like to climb over a fence with your bike at a locked gate because the router sent you there because an osm mapper forgot to add access tags to the gate (it seems to happen a lot in some regions)?

However, it might be a regional thing. In some regions, such gates might be generally passable, in other regions not. Therefore, I added a parameter to the profile which makes it possible to pass those gates, but let it disabled by default. However, as Locus does not display arbitrary profile parameters in it's gui, it would not be switcheable by the user. Locus developers will have to decide which default setting they want to use in their fork (LoMTB) of the profile.

Lift gates are another story, I have to check how they are handled. Here we might assume that you can pass them by foot or bike.

URL

Radim ●

Thanks Zossebart for looking into this issue. A more thorough review of gates related behavior is needed here. (Once more serious reviews are done).

URL