Replace key hardcoded parameters with config files

[Robinlovelace]

Currently settings such as the tags associated with paths on which cycling is forbidden are hard coded in .rs files:

https://github.com/Urban-Analytics-Technology-Platform/od2net/blob/b3fb828f1a9f213b30d62b3231910e4b6da4f151/lts/src/allowed.rs#L31-L38

Would it be possible to replace such settings with config files in json for easier editing and less Rust code reading? Aligns with the aim set out in #28 to make this more accessible (and in this case configurable) for others.

Use case: places like Norway and I believe Japan where cycling on footpaths is allowed, or for uses where we want to route cycling on a wider part of the network to inform investment decisions.

[dabreegster]

This was also raised during the SotM workshop! It needs to be configurable per area for sure. It logically belongs as part of the LTS classification; it's just refactored a bit here. Someone can already write a custom function to determine LTS. I don't think changing out just this piece and leaving the rest (the Bike Ottawa logic right now) would work, because that logic won't assign an LTS to this. I also don't want to invent a configuration language to express LTS rules, since people can run any arbitrary command to calculate LTS.

So... not sure yet, will think about this more

[Robinlovelace]

I guess an issue is that the rules defining routing are often more complex than a set of nested key-value pairs. You need to be able to compute on the values as shown in https://github.com/Project-OSRM/osrm-backend/blob/master/profiles/bicycle.lua which contains functions such as oneway_handler

[Robinlovelace]

Which values are most likely to be needed by users that will affect the overall score, e.g. the 'stress multiplier'? Identifying those and splitting out as a config file could be good for many users while of course more advanced users can change how the values are used. Something I guess Chris Conlan's (cannot find GitHub tag immediately) work will shed light on.