Time stamps calculated by createGPXList() are sometimes inaccurate

[jerhard]

The time stamps of a GPXList obtained from createGPXList() are sometimes inconsistent with the results of another GraphHopper call. The duration of a route from the origin to the the point of the entry in the GPXList can differ from the time stamp of the entry by several seconds.

This happens even when all requests are using the "fastest" weighting. See here for a failing test of createGPXList().

This issue occurs with Graphhopper versions 0.10.3, 0.11.0, and the master branch as of the time of this writing.

[jerhard]

My suspicion is that these inconsistencies between times calculated by createGPXList() and the path durations calculated by GraphHopper.calcPaths() are due to the different way they are computed. The fillGPXList() method in Instruction assumes that the durations between two points in an instruction are proportional to the distance. However, this might not be the case, e.g. due to differing speed on the edges of one instruction.

The GraphHopper.calcPaths() method uses the FastestWeighting.calcMillis() method to compute the duration of an edge. In particular, this method considers the speed that is possible on an edge. Storing the durations computed by calcMillis() in a Path/PathWrapper/InstructionList might allow to use them in the createGPXList() method.

[jerhard]

Can you give any estimations on when you will be able to fix it?

[boldtrn]

Can you give any estimations on when you will be able to fix it?

Just a note, you can always speed the process by providing a PR :)

[jerhard]

The GraphHopper.calcPaths() method uses the FastestWeighting.calcMillis() method to compute the duration of an edge. In particular, this method considers the speed that is possible on an edge. Storing the durations computed by calcMillis() in a Path/PathWrapper/InstructionList might allow to use them in the createGPXList() method.

Additional remark regarding this: The edges of a path (calculated by calcPaths()) seem to have a different granularity than the GPXList. While the GPXList for this route contains 18 points, there are 20 edges in the Path, corresponding to 21 points.

Thus it might not be so easy to go with a solution that builds on storing the edge durations.

[jerhard]

@boldtrn

Just a note, you can always speed the process by providing a PR :)

Yes, I certainly would like to patch this on my own, yet I don't know how to fix this bug (see my comment above). Maybe you have an idea on how to implement it?
As I rely on this feature for a student project, I would like to know whether it's realistic that this will get fixed within the following weeks or not. Depending on this timeline I'd have to figure what to do in my project.

[michaelwittmann]

@michaz Thanks for solving this issue!
If i got it right GPXEntry has now moved to web-bundle. Will this fix also be availble in graphhopper-api-0.13.0?

[michaz]

@michaelwittmann It is now in graphhopper-web-api. GPXEntry is meant only as a serializer for the web service, when we create actual GPX output. So I removed the inaccurate time stamps and the GPXEntry from the core API.

We do not provide timestamps on intermediate points of the route. We still don't. The reason the timestamps on the GPXEntry were inaccurate is that they were just interpolated.

It's just not part of the API at the moment.

[michaz]

@michaelwittmann The Instructions still have timestamps, of course, and they are accurate. Maybe that's enough for your use case?