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:

od2net/lts/src/allowed.rs

Lines 31 to 38 in b3fb828

	if tags.is_any("highway", vec!["footway", "path"])
	&& tags.is("footway", "sidewalk")
	&& !tags.is("bicycle", "yes")
	{
	msgs.push(format!(
	"Cycling not permitted on highway={}, when footway=sidewalk and bicycle=yes is missing",
	tags.get("highway").unwrap()
	));

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.