I realised that using the weighting “curvature” and “turn cost true” and switching start and end position in my routing query has a huge difference in the calculation time (sometimes factor up to 20 , i.e. from 350ms to 7000ms) also if the calculated route remains exactly the same but of course inverted.
I am sure that “turn cost true” is causing the difference as I made some tests and turning it off produces the same calculation time.
I am using Graphopper 4.0 on a local server with motorcycle as vehicle and curvature as weightning and turn costs as follows:
- name: motorcycle
vehicle: motorcycle
weighting: curvature
turn_costs: true
u_turn_costs: 120
I also included graph.flag_encoders: motorcycle|turn_costs=true in the config file.
I am using the LM mode with default settings.
Interestingly that does not always happen, to reproduce it I use Graz (AT) as start and Salzburg (AT) as destination and viceversa. The number of visited nodes also goes from ~ 30000 in one direction to more than 6 millions in the opposite direction.
These strange behaviour does not affect profiles with weighting custom, based on my test.
I imagine this is not the default/expected behavior.
Am I missing some options that I should consider, maybe something like “storeTwoDirections true”?
Do you have the exact steps to reproduce this? (pbf you are using and coordinates for the route)
And can you try with the latest version 6.0?
btw: in master or in future 7.0 there is a curvature feature that can be used in a custom_model, so that you can tweak it to your liking in GH Maps and when you are fine with it move the custom_model to the server-side and enable CH or LM.
I just tried with the 6.2 version and the problem seems gone.
In the 4.0 version I did some (in my eyes) minor modifications to the motorcycleflagencoder.
I will try to add the same modifications in version 6.2 and check if they are the cause of the problem.
so I did some tests and I think I identified at least a parameter that causes the problem also with GH 6.2.
If the factor in
(VehicleEncodedValues.java)
DecimalEncodedValue curvatureEnc = new DecimalEncodedValueImpl(getKey(name, “curvature”), 4, 0.1, false);
is increased, for example 1.5 instead of 0.1 in combination with “turn cost true” then the calculation time of some routes is different then start and end position are switched.
I can not really understand why, I though that the factor increases the accuracy following
the speedFactor means by which factor the speed should be divided before storing
(e.g. 5 for car and 1 for bikes for more precision).
It is not a good idea to increase the factor to 1.5. To make the curvature more precise you have to decrease the factor and (potentially) increase the bits.