Time Stamps in GPXList Inaccurate?

Open Source Routing Engine
1

When routing from A to C one passes a point B mentioned in the GPXList of the PathWrapper of the best route. Let’s call the timestamp when B is reached in the GPXList tB.

If we now request a route from A to B, then we’d expect that the result of getTime(), let’s call it tAB, called on the PathWrapper of the best route will result in the identical, or at least nearly the same, time as tB.

However, there are cases when this is not the case and these times differ by several seconds (e.g. 9 seconds).

Is this intended behavior? Is there any way to disable these seeming inconsistencies?

Note: tBC, the time for the route between B and C, plus tAB do sum up to the same time as the time of the route from A to C for this sample.

I use Grahphopper-Reader-OSM and Graphhopper-Core, both version 0.10.3, set hopper.setMinNetworkSize(200, 200), and set the weighting to “fastest” and the vehicle to “car” for all requests.
In case it is requested, I can provide an example of points where this issue occurs.

2

Might this behavior actually be considered a bug in GraphHopper?

3

Can you try to explain this again? I’m unsure when you do map matching and when you do A-B routing. Or do you do map matching in all cases?

4

Sorry for the ambiguous wording. There is no map-matching involved.

What I do is the following:

  1. Query a route from A to C with GH
  2. Obtain the best route (error handling omitted)
  3. Get the instruction list
  4. Create the GPXList
GHResponse resp = hopper.route(request);
PathWrapper path = resp.getBest();
InstructionList instructionList = path.getInstructions();
List<GPXEntry> gpxList = instructionList.createGPXList();

Then I iterate over the entries in gpxList. Now for an entry entry, corresponding to a point B (defined by getLon() and getLat() ), I would expect that that entry.getTime() is the same as the result of an additional request to GraphHopper of a route from A to B, querying the path.getTime() function on the corresponding PathWrapper object.

In other words: I expect that the time stamp of any entry in the gpxList should be the same as the duration of a route from the origin to this entry’s point.
(Assuming that both requests are using the “fastest” weighting).

Sometimes, this is not the case, however.

So, am I making a wrong assumption or did I encounter unexpected behavior?

5

Ok, have removed the category then

I would expect that that entry.getTime() is the same as the result of an additional request to GraphHopper of a route from A to B , querying the path.getTime() function on the corresponding PathWrapper object

This should be indeed the case and sounds like a bug. Do you have some coordinates (link to GH Maps)? (best would be a short route with the maximum difference :slight_smile: )

6

I am using this map of New York.
The points are:

// coordinates of A
double aLon=-73.98092441077337;
double aLat=40.76430041974964;
// coordinates of C
double cLon=-73.97697526686977;
double cLat= 40.77482200729787;
// coordinates of intermediate point B
double bLon=-73.98149275738358;
double bLat=40.7682578809915;

When requesting the route from A to C (with a duration of 118945 milliseconds), point B occurs in the GPXList at index 13, getTime() at this index returns 58597.
Requesting the route from A to B results in a duration of 69159, different from the value in the GPXList (i.e. not as expected).

As an additional info: Requesting the route from B to C results in a duration of 49786; so the last two numbers would add up to the duration of the route from A to C (as expected).

7

Thanks.

Requesting the route from A to B results in a duration of 69159 , different from the value in the GPXList (i.e. not as expected).

And what does the last entry in gpxList say for this route?

As an additional info: Requesting the route from B to C results in a duration of 49786 ; so the last two numbers would add up to the duration of the route from A to C (as expected).

Ok, good. So there is likely a bug in createGPXList

8

The last entry in the GPXList is:

time=118945
lon=-73.97697526686977
lat=40.77482200729788

The previous one (i.e. the second to last one) is:

time=73502
lon=-73.98057540462707
lat=40.76991116486291

The difference between these time stamps is 45443, but the duration of the route between these points is 37470 milliseconds, according to another GraphHopper call.

9

How is the status? Could you reproduce the issue?
Should one open a bug ticket regarding this problem?

10

Yes, and if you could create a failing test with the latest master this would be appreciated.

12

Ok, so you may have a look at the attached JUnit test. It fails with the current master. The map file used in the test is the one I mentioned before.

Should I open an issue on Github or will you do it?

GraphHopperCreateGPXListTest.java (2.3 KB)

13

So I had a look at the source code of createGPXList.

Thre createGPXList() method in InstructionList calls the fillGPXList() method in the Instruction class. fillGPXList() calculates the duration between two GPXEntries as the distance between the two entries’ points, divided by the overall distance of the Instruction and multiplied with the overall duration of the instruction. This assumes that the duration and the distance are proportional within a instruction instance. If the speed does not remain the same for the entirety of an instruction, this will lead to inaccuracies.

The routing algorithm itself, i.e. the GraphHopper.calcPaths(), uses the FastestWeighing.calcMillis() method to calculate the duration for an edge. Maybe a possible solution is to store the edge durations in the PathWrapper and the InstructionList, to be able to use them in the GPXList?

14

Yes, please create an issue for this. This method needs probably a bigger refactoring.

It is a bit strange that it differs at the end as it might differ but should be ok for the start and end point of every instruction.

15

Ok! Here’s the issue on GitHub.

It is a bit strange that it differs at the end

There might be a misunderstanding.
To clarify: For the example I gave, the time stamp of the last entry did not differ from the overall time of the route. The time stamp of the second to last one differed from the accurate value. This only resulted in a inaccurate time difference between the second to last and the last point in the GPXList.

1 Like