Runtime evaluation of barriers

I am using graphhopper for a custom routing solution for hikers and riders. The barrier types “ford” and “gate” have been the topic of discussions for a long time as they might or might not be relevant depending on how you balance risk and playing it safe.

Therefore I would like to leave the decision to the user. The user sets a parameter for the routing whether fords are treated as barriers or not and the routing takes this runtime parameter into account.

Is this possible? I only know the mechanism where barrier nodes are statically marked as impassable when creating the database. I am using runtime parameters to modify the edge weights, but I am not aware of a way to store barrier types in the database and evaluate barriers at runtime.

I once had this branch but it never went into master because … things :slight_smile:

Maybe you can use and test it for your use case?

But maybe this branch would be even better and more flexible?

Thank you for the branches. I think I might play with the BarrierParser version (on some cold, rainy day). I prefer efficient encoding over totally generic and potentially slower concepts. :slight_smile:

I bet that for barrier nodes (which are rare!) there is no (measurable) speed difference in practice between encoded values and the values from the KVStorage.