Ok, yes, indeed. Useful also to really overwrite initial speed values (unlike `limit_to`

).

What would be the advantage of this?

that you can avoid the `"if": true`

workaround and be more clear about the intent.

I probably donâ€™t understand the problem yet

The problem is not about the `set_to`

operator but the fact that it contains a â€śdynamicâ€ť encoded value. And we need to ensure the correctness of A* and if the encoded value contains values bigger than 1 (maximum priority) for some edges and we use

`set_to: bike$my_encoded_value`

then the priority in the graph can be lower than what we estimate with getMinWeight which could lead to suboptimal routes for all A* algos.

I would be ok to enforce a limit_to for all queries with an encoded value in its expression but it would have to be an unconditional limit_to with a static value:

```
{
"priority": [{
"if": true,
"set_to": "0.5 + bike$priority"
}, {
"if": true,
"limit_to": 1.5
}]
}
```

It would be less ugly when the `"if": true`

is omitted as we would also need this for multiply_by and limit_to with expressions.

Another solution would be to log the maximum value of the EncodedValue. Or we use the maximum possible value via getMaxInt or getMaxDouble, but then the performance could be affected if this maximum value is far above the used maximum e.g. if a max speed of 140km/h is required we could have a maximum of the underlying EncodedValue of 256km/h due to the bit range. Or we store an additional max value in every EncodedValue - could also be useful for things like: Max speed can get exceeded due to rounding error Â· Issue #2322 Â· graphhopper/graphhopper Â· GitHub. But the problem is then that we mix application and storage too much (we did this with the default value and this was something we had to get rid of fast).