While upgrading from GraphHopper v2 to v5 I have noticed that the behaviour of barriers (e.g. gates) has changed significantly and it is unclear to me if there is anyway to restore the previous behaviour. On v2 the block_barriers boolean flag could be set in the flag_encoders to either prevent or permit travelling through barriers. However in v5 this flag is not observed and the behaviour is now to permit travelling through barriers unless the “locked” flag is true. It seems that there is no way to override this and any barrier that is locked can never be travelled through. Are there any other options/suggestions to control this behaviour? Ideally I would like to ignore all barriers (including those flagged as locked) in v5.
Do you mean it change significantly for your customized GraphHopper code or also using the default settings? If you like to ignore all barriers maybe the easiest option is to simply adjust/override the isBarrierNode in OSMReader. If this just returns false all the time no barriers will ever be considered.
On a more fine-grained level the barrier handling code uses a set of barrier values that will be blocked. So for example the car flag encoder adds kissing_gate and fence (and many more) to the barriers set and those will be blocked. And they are also blocked if there is no “locked” flag.
But it looks like you are right that if locked=yes you cannot open the barrier by adjusting the flag encoder without changing the code in AbstractFlagEncoder. Also the block_barriers configuration option was indeed removed between GH 3.0 and 4.0
Thanks for your reply Easbar. It changed when using the default OSMReader and default AbstractFlagEncoder. The block_barriers flag may have been set to true for many/most users but I needed it to be false, which is perhaps why I struck this issue during the upgrade to v5 when other users did not.
If there is no way to achieve the original behaviour of block_barriers=false in v5 with config I will change the approach to customise the code or the data.