Hiking profile ignores acces=no

[Helium314]

Brouter routes along steps with access=no, which it definitely should not:
https://brouter.de/brouter-web/#map=18/48.26936/16.33782/standard&lonlats=16.339615,48.269619;16.336176,48.26888&profile=hiking-mountain

Or is there any reason to ignore this (imo very straightforward) restriction?

[poutnikl]

The issue goes rather to me and my Hiking-Poutnik repository, as the Brouter Hiking-Mountain profile is based on my Hiking-Poutnik template.

For the specific reported route, it is, similarly as for BRouter original trekking profiles for cycleroutes, (or at least until recently, if changed) ,
overruled by the pedestrian route marking route_hiking_iwn=yes.

---

In general: As you can check at Hiking-Poutnik - master - Hiking.brf, there is assigned

assign accesspenalty switch footaccess 0 9998

As you can see at Brouter-profiles - wiki - Glossary, the Costfactor 9998 is the highest costfactor still allowing passage. It means that e.g. 10 m of such a way is equivalent about 100 km of the way considered as optimal.

The rationale behind this is that if there is any other possible way, Brouter avoids an OSM way with such a high costfactor. But, if there is no other way, and if there was not implemented this last option fallback, routing would fail with an error there is no possible way to the destination.

There are many scenarios you have good justification to go via such a way anyway. There are often many cases OSM ways are not properly tagged and restricted access does not in reality apply to pedestrians, or it can be justified, Typical cases are "the first mile" and "the last mile".

So the decision has been made that the risk of allowing it is lesser harm than the risk of not allowing it.

In context of BRouter profiles, there are many such occurrences of decisions that involve weighing of risks and impacts of allowing what should be denied versus denying what should be allowed.

[poutnikl]

As work around, it can be changed on BRouter web as custom profile edit (or as a custom profiles in the app) to

assign accesspenalty switch footaccess 0 9999

The value costfactor=9999 means the respective way segment is not used for routing, but is considered for generation of direction hints.
The value costfactor=10000 means BRouter pretends the way segment does not even exist..

As a variant for aventual profile tweak, there can be defined the variable in the global profile segment like

assign UseHardNOaccess = false # used the current default

and in the way profile segment

assign accesspenalty switch footaccess 0 9998

could be replaced by

assign accesspenalty switch footaccess 0 switch UseHardNOaccess 9999 9998

With assign UseHardNOaccess = false, the current behaviour would be kept,
With assign UseHardNOaccess = true, access would be denied, triggering routing failure if it is the only option.

[vodie]

Delete or comment out the line 132 (assign nodeaccessgranted...). This parameter overrides the access restriction in this case for hiking routes.

[poutnikl]

That is the way to overcome it, but will have regression for the opposite cases, if made as permanent tweak.

[Helium314]

Thanks for the thorough explanation!
I understand and agree with the reasoning regarding high cost vs no routing at all.

For dealing with contradictory tagging ("forbidden" hiking route), I would argue that no should be treated different than private. no often indicates paths that should not be used until some part is repaired (which may take a rather long time). So the route markers are still in place, but you can't or would not want to walk there for safety reasons.

This is different again when tracks and other roads for motor vehicles are involved, as people too often wrongly use access when they should use motor_vehicle or vehicle... but that mostly concerns private.

[Luzandro]

overruled by the pedestrian route marking route_hiking_iwn=yes.

actually currently it's only tagged as a questionable proposed:route=hiking

[poutnikl]

overruled by the pedestrian route marking route_hiking_iwn=yes.

actually currently it's only tagged as a questionable proposed:route=hiking

The above tag route_hiking_iwn is not an OSM tag, but BRouter pseudotag, similarly as cycloroutes in BRouter native trekking profile. It it workaround for lack of ability to process OSM relations like route marking in OSM data. Profiles cannot query OSM relation data. these pseudotags are present only in BRouter rd5 files, assigned to every OSM way that is part of such a route relation. But it is not present within original OSM data.

So, it is an error of interpretation and transcoding of OSM data to BRouter rd5 routing files. Profiles have no idea it is just a proposed route, this info is not available to them.

The posted table shows for all route segments available OSM way and node tags/pseudotags. (more exactly - by default only those considered by the used profile, to speed up route calculation.

---

There may be problem in current Brouter data implementation that while cycleroutes do have considered the
proposed state withing their pseudotags, hiking routes do not.

Quote from the current BRouter lookups.dat

route_bicycle_icn;0000088753 yes
route_bicycle_icn;0000000001 proposed
route_bicycle_ncn;0000268180 yes
route_bicycle_ncn;00000000001 proposed
route_bicycle_rcn;0000718163 yes
route_bicycle_rcn;00000000001 proposed
route_bicycle_lcn;0000469215 yes
route_bicycle_lcn;00000000001 proposed

route_bicycle_;0000024662 yes
route_bicycle_radweit;0000004604 yes

route_hiking_iwn;0000056005 yes
route_hiking_nwn;0000315813 yes
route_hiking_rwn;0000343219 yes
route_hiking_lwn;0000359332 yes
route_hiking_;0000103733 yes

route_foot_nwn;0000047923 yes
route_foot_lwn;0000135371 yes
route_foot_rwn;0000115325 yes
route_foot_;0000070583 yes

[poutnikl]

It would make sense if access=no would get assigned costfactor 9998, regardless of route status. Route glitches with suppressing occasional access=no may be more needed for cycling.

[Helium314]

The case triggering this issue has been solved, the route was adjusted.

It would make sense if access=no would get assigned costfactor 9998, regardless of route status. Route glitches with suppressing occasional access=no may be more needed for cycling.

I support this.
I guess this issue can be closed, as discussion should take place in poutnikl/Hiking-Poutnik#12?