Truncation errors in edge-weights can lead to suboptimal routes

[tyrasd]

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:
http://map.project-osrm.org/NN
http://map.project-osrm.org/Pu

[emiltin]

might be related to #246 ?

[DennisOSRM]

Yes, may be related to issue #246. Investigating this right now.