I just wanted to check if anyone seen/could comment on the following behavior… It seems like is a correlation between the result of calcWeight and the number of times the method is called. I have tested on FastWeighting by multiplying the time variable.
What is the optimum? Or it actually depends upon the algorithm itself and how all weights stack up?
Just optimizing my weighting class that depends upon up to 8 parameters; so the number of times the method is called seems like the lowest hanging fruit.
master@Revision: b4f3b829e66761aa90ae28ad7ca6feb7e581ac3f
Date: 11/04/2018 6:32:59 AM
Without more details we can only guess. But usually if you increase the weighting of a certain edge class only then this behaviour is logical. E.g. if you avoid highways (factor 10) and your fastest route is through a highway then this could lead to 10² more nodes if there is no alternative. (10² is just a wild guess but usually the number of more nodes correlates with the the area of a circle, for bidirectional Dijkstra it will be less, much less for ALT and CH)
I was actually referring to com.graphhopper.routing.weighting.FastestWeighting; the implementation has only one return statement so I was expecting the method to be called the same number of times.
I have also tested on a naive implementation that only relies on edge.getDistance() and observed the same behavior…
I have also added chFactoryDecorator.setEnabled(false); as I wanted to disable CH real quick. For some reason prepare.ch.weightings: no did not work off the bat.
Yes, just that line in the FastestWeighting.
AStarBidirectonal.java
Are you suggesting I should override getMinWeight? Seems like it’s the min Weight one can get providing the best combination of factors.
/**
* Used only for the heuristic estimation in A*
*
* @return minimal weight for the specified distance in meter. E.g. if you calculate the fastest
* way the return value is ‘distance/max_velocity’
*/