tracktype and surface/smoothness not properly evaluated

[utack]

tracktype and surface/smoothness are not evaluated correctly at the moment.
tracktype=grade1 and surface=asphalt are an example where tracktype should not make smoothness of surface worse
Idea to solve:
Allow "brackets" of smoothness cost that go with a tracktype, and only downgrade when tracktype is significantly worse than surface or smoothness

[poutnikl]

In such cases you can use some max/min penalty calculation, instead of linear a/o additive system, something like I use.

For 2 parameters, for a particular value of the parameter 1, the values of the parameter 2 above/below some value will not matter.

[utack]

I was thinking about this.
Introducing some "bracket" system, like "asphalt min/max=0.0/0.2" "mtb scale min/max"
And then at the end evaluating all brackets, detecting mismatches (like surface=asphalt can be 0.0-0.2, but mtb:scale=3 is 1.5 to 2.0), or otherwise somehow "merging" the brackets (for example smoothness=intermediate is 0.5 to 1.0, and surface=cobblestone is 1.0 to 2.0, use the "overlap")
I will have to re-think this properly though

[utack]

That would for example solve this very unfortunate hack:
https://github.com/utack/utack_brouter_data/blob/master/streetbike_touring.brf#L308
surface=asphalt would be something like -0.1 to 0.2 smoothness=excellent would be -0.1 the final logic could find out the brackets are compatbiel, and smoothness "outranks" the surface, and we get the -0.1 case or
surface=cobblestone is 1.0 to 2.0 smoothness=excellent is -0.1 the final logic detects a mismatch, and uses a more pessimistic "cobblestone" value

[poutnikl]

I had in mind with min/max something like

"quality penalty" = max ( function_for_tracktype ( tracktype tagvalue) , function_for_surface ( surface tagvalue ) )

Eventually the terms for smoothness and MTB scale can be added. More generally, particular terms need not to be a function of just a single parameter.

[utack]

Fixed with a new evaluation, will be pushed soon