Routing time differences: full edge vs start within an edge

Open Source Routing Engine
1

Hi,

I’m working on a project for which I calculate the route to list of destinations and save the route’s GPX points via the InstructionList.createGPXList() method.
Later on, I add destinations and update the route starting a new route calculation at one of the previously saved positions along the route.

With the first destinations being the same, the route to those and all single determined points along this route are the same for both calculations (just with the new route starting further ahead along the route).
However, regarding the times, I also calculate the absolute estimated arrival times (relative times from the routing result added to the current start time) and get slightly different results for both routing. Analysing the results more detailed the difference just occurs within the first few positions, all further times and time differences are identical.

My assumption is here, that the difference is cause by the fact that the updated route starts somewhere along one edge that was previously considered as complete edge.

Can this be, that the times are calculated differently by the createGPX method and the original routing, especially regarding the not fully completed edges?
As example, I get five points within one routing instruction along the full edge. Starting the same route from the second point, the result is exactly the same last four points. However, creating the GPXList, the time differences between second and last point are different for both cases (a few seconds, depending on the length of the instruction, but it can be both shorter or longer).

For the routing I’m using the standard settings (speed mode) and Graphhopper 0.8.

Thanks a lot!
Carsten

2

See this discussion: GPS-Precise start end endpoints for mapmatching

3

Hi, thanks for the response! For now, I think I will accept the variance since it does not have any significant affect on my results. I will get back to the GPS-precise map matching if it causes any further problems.

I think I got the general issue here with the map matching with the provided link and the GPS-Precise map matching feature, but I’m still unsure how this can result in sometimes shorter and sometimes longer times between the single GPX coordinates, in particular for getting exactly the same GPX coordinates as results. If the full edge is being returned I would’ve expected to get the points (GPX) for the full edge. Or if just the time is used for the whole edge the first part (not full edge) would always show longer time differences for the (fewer) points.

I’m quite new to this topic and am just trying to understand the connection between the times / the created GPXList and the map matching issue.
Thanks you so much for your help.

Here one more screenshot showing an example GPXList of three times routing the same track from different start points. For the second result, the time differences between the first points are longer than the original ones (highlighted in yellow) and for the third one the first times are shorter (orange):

2017-03-29 11 38 39.png1599×633 33.5 KB