You can clone with
HTTPS or Subversion.
When calculating the weights of edges in extractor.cpp, the exact weight (expressed in tenths of seconds) is simply casted (thus floored) to integer.
This is a systematic error, which later on leads to a bias towards routes with more but shorter edges against straight routes (as there occurs more truncation in the first case). This could lead to osrm routing over a winding mountain pass instead of the motorway around it.
This is solved by rounding instead of flooring the exact weight to integer:
int intWeight = std::max(1, (int)std::floor(0.5+ (edgeIT->isDurationSet ? edgeIT->speed : weight)) );
Also, this rounding errors are quite large. (I did a very quick&rough estimation with some osm-data: I found the truncated weight to be a few %, typically; but it can be more than 20% in worst case!)
As it doesn't harm to use centi- or milliseconds for the weight of an edge (or does it?) I would consider to do that:
double weight = ( distance * 1000. ) / (edgeIT->speed / 3.6);
Examples of affected routes:
might be related to #246 ?
Yes, may be related to issue #246. Investigating this right now.
Implements issue #324. Thanks tyrasd.