Debugging driving time results

I am coming back on this topic because we recently implemented the workflow and we are testing different correction parameters.
In short, our target is to tweak the input data coming from OpenStreetMap to take into account traffic. We do so by applying corrections to maxspeed based on geographical estimation of traffic in the following manner:

  • We modify OSM data with our estimated maxspeed values.
  • All the road segment have a maxspeed assigned.
  • We build the OSR instance with the modified data. In this way we can build several machines with different maxspeed settings.
  • We test the matrix service of the different machines on an origin-destination test dataset and we compare it against a benchmark to find the optimal maxspeed settings.

Let’s say we have machine A and B built with different maxspeed settings; B with the maxspeed values halved compared to A. So, A and B are parametrised exactly the same but built on two different OSM data that differ only on the maxspeed tags. We use the default car profile.
We would expect the times returned by B on the test dataset to be longer than the times returned by A on the same dataset.
We find the opposite behaviour, B with lower maxspeed returns remarkably shorter driving times than A.

It seems to me that we might have a data problem or some bug in our code but I find it hard to understand the inputs behind the computations. I have two questions whose answer could help me with the debugging:

  1. If all the maxspeed are filled and not missing, is there any other heuristic or other parameter that can affect the final results when calculating driving time ?
  2. Do you suggest any way to debug the results of the matrix service or to extract the data that is used to compute the driving time ? Ideally the graph with the final speed that is used to compute the final result (we are thinking, for example, of using the direction service to return the geometry and then fetch the corresponding segments from the graph that was used to build the ORS machine)

Thank you very much for your attention,
Duccio Aiazzi

Are you sure that the actual routes from machine A and B are exactly the same? In my experience speeds can make a longer route shorter in time and vice versa. Which means that the result really depends on the combination of length and speed. The only way that the times on B would be longer is if you can force it to use the exact same roads - but since ORS is looking for an optimal route, it is very likely that the routes will not be the same.

Comparing travel times in relation to maximum speed is probably better done using isochrones, not a route from one point to another point - unless, like I said, you can force it to use a specific route.

Hello, thank you for you reply.
I can check the route with the API ‘directions’. They do change sometimes but the changes do not justify the magnitude nor the direction of change in the driving times. We also check changes in the isochrones and the results are the same: we reduce maxspeed and the driving time goes down.