Flexible Mode - calcWeight result?

Open Source Routing Engine
1

Hello,

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.

41689 edges - return time;
193468 edges - return 10*time;
215221 edges - return 100*time;

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

2

Are you sure you’re just not hitting a memory limit? That’s the sort of
thing I’d expect when the GC can’t cope

3

Tim,

I doubt it… It’s a very small route in Belarus.

Thanks anyway!

4

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)

1 Like
5

Thanks Peter.

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…

6

So you just changed this one return line? Which algorithm did you use? For A* you can adjust getMinWeight accordingly.

7

Thanks Peter.

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’
*/