Performance with fixed speed

[matias-harari]

Hi,
I am getting very rare responses when using fixed_speed.

Example: https://valhalla.openstreetmap.de/directions?profile=car&wps=89.512996673584%2C24.40963901896311%2C89.55084800720215%2C24.41905678369688

Some of the responses according to speed:

1. Response with fixed_speed between 1 and 5 kph:
   

2. Response with fixed_speed between 6 and 7 kph or more than 19 kph:
   

3. Response with fixed_speed between 8 and 9 kph:
   

4. Other weird responses between 10 and 18 kph...

I expected that option 2 would be the optimal path regardless of the value of fixed_speed, but this is only true when the speed exceeds a certain threshold (19 in this case). I noticed that this 'threshold' value is higher for longer routes. Is this a bug, or is there something I am not understanding?

Thanks

[kevinkreiser]

Is this a bug, or is there something I am not understanding?

thats a tough question. the truth is its more of a feature

but seriously the real answer is that the routing engine is designed to allow the user to change different parameters and get different routes out. what happens to accomplish that is we compute the weight of traveling on an edge in the graph and the weight of transferring from one edge to another edge via a node in the graph and the sum of those weights dictates what is the "shortest" path.

it is highly likely that when we implemented fixed_speed we neglected some other component of this weight computation (we call it costing, cost==weight). to really figure this out we have to mess around with looking at those costs that are computed and see why one path is higher than the other or at what point it becomes higher and due to what component of the overall cost.

one thing that just occurred to me is that when we are using fixed_speed we should update the a* heuristic to match. having a slow speed but having the heuristic be vastly faster could cause some strange behavior though typically it would just lead to lower performance rather than strange routes (thats usually when the a* heuristic underestimates the cost to get to the goal).

tldr; yeah i guess you could say its a bug in that we dont want to return obviously wrong routes BUT the truth is with so much control over how to pick the type of routing you want it is very hard for us to QA the costing functions sufficiently for stuff like this.

in the end we need to debug it. side question @nilsnolde what version of the code is running on the osm server, we're not doing anything experimental there?

[matias-harari]

Thank you for the clear answer, Kevin. I understand your point about QA. I am using Valhalla for a research project, and we do not want to consider what OSM tags say about highways. We just want to evaluate how the shortest path changes for different values in other cost/penalty parameters (such as ferry_cost for taking a ferry, for example). However, I think I could clean those highway tags in my local .pbf so that I won't need the fixed_speed parameter here.

tldr; yeah i guess you could say its a bug in that we dont want to return obviously wrong routes BUT the truth is with so much control over how to pick the type of routing you want it is very hard for us to QA the costing functions sufficiently for stuff like this.

[nilsnolde]

fixed_speed is updating the heuristic already IIRC. Nope, we run a version from August or so, didn’t update in a while. For reference, unless it’s super safe (like the tobler stuff a while ago), I never run anything else than master or release.

[kevinkreiser]

looks like we use top_speed_ for the a* heuristic, which makes perfect sense:

valhalla/src/sif/autocost.cc

Line 275 in 602c8ab

return speedfactor_[top_speed_];

but it seems top_speed_ does not get the value of fixed_speed_ when the latter is set, which, i think maybe it should right:

valhalla/src/sif/dynamiccost.cc

Line 157 in 602c8ab

top_speed_(costing.options().top_speed()), fixed_speed_(costing.options().fixed_speed()),

i even checked the costing parsing stuff and indeed it seems top speed is going to be the default or whatever you set for top speed in the request but it wont get forced to play nicely with fixed_speed.

all that said still i dont think that this would fix the OP's issue but its a clean up item we can do just in case! or maybe i misread the code and its somewhere else super tricky that i didnt notice 😄