[GPX export] Consecutive and very close points with same timestamp

[fbonzon]

There are GPX exported files with very close points having the same timestamp.

Example

See also Discussion on GraphHopper forum.

[karussell]

Hmmh, could be related to the roundabout code or even to this old issue here #290

[karussell]

Hmmh, cannot reproduce it with my/your link anymore. But this seems to produce duplicate endpoint which is not what you reported: https://graphhopper.com/maps/?point=46.585689%2C6.604812&point=46.585658%2C6.604792&locale=de&vehicle=car&weighting=fastest&elevation=true&layer=Omniscale

Do you have a link where your duplicate time entry can be reproduced? And I guess you have to avoid this to calculate the speed?

[fbonzon]

In this GPX file exported from GraphHopper Maps at this link, it happens 20 times, at timestamps:

1455839471 = Thu, 18 Feb 2016 23:51:11 GMT
1455853603 = Fri, 19 Feb 2016 03:46:43 GMT
1455884451
1455888346
1455891000
1455910397
1455921077
1455926778
1455927963
1455928381
1455930288
1455932171
1455933715
1455934153
1455939655
1455940148
1455941314
1455949053
1455957112
1455962816

Zoom on Sample 1
Corresponding GPX data with duplicate timestamps:

<trkpt lat="52.513156" lon="13.326987"><ele>41.8</ele><time>2016-02-18T23:51:11Z</time></trkpt>
<trkpt lat="52.51314" lon="13.326976"><ele>41.8</ele><time>2016-02-18T23:51:11Z</time></trkpt>

This one is actually not at a roundabout.

Yes, division by 0 occurs when calculating speed. Luckily, my code is easy to fix, by first checking for 0 time span. GraphHopper should probably not generate such GPX files in the first place.

[karussell]

Yes, division by 0 occurs when calculating speed. Luckily, my code is easy to fix, by first
checking for 0 time span. GraphHopper should probably not generate such GPX files in the first place.

Well, although there might be a bug e.g. with the previous example this very close example makes sense to use identical timestamps as the resolution is just seconds, but even if ms there can be cases where the speed "too fast" for the close distance ...

[fbonzon]

Whether it's a bug or intended is up to you. I'll give my opinion, and maybe other readers here will too, and in the end you decide :)

As far as I could research , a GPX file having points at different locations but with the same timestamp is not a violation of the spec. It makes little sense though, as you can't be physically at the same time in different places. Some clients or code reading such GPX file with same timestamps will have trouble, in the worse case even crash. We should avoid generating such problematic files.

(For reference, I was using such client which didn't expect same timestamp in different points, it's bentasker/PHP-GPX-Ingest#6.)

My preferred option:

1. Do not output points with same timestamp. In case there are close points with same time, keep only the middle one. In case there are even number of points, like 2 in my example, middle is 1st or 2nd depending on how you decide you round, just choose up or down and stick to it for determinism. In case of odd (e.g. 3), middle is clear (i.e. 2nd point with my example).

Other option, less preferred:

2. Increase timestamp resolution to ms for all points. This significantly lowers the chance of duplicate timestamp. In case you add "supersonic plane" as new travel mode in GraphHopper, the same algorithm as in 1) is applied to remove points at same timestamp with ms.

3rd option, least preferred:

3. Keep current behavior. Add in GraphHopper documentation that exported GPX files may contain close points with the same timestamps.

[karussell]

Thanks - really interesting issue :) !

We should avoid generating such problematic files.

I'm not sure anymore. As we will have to remove these points in a kind of a preprocessing and loose geometric precision. The problem is not that a vehicle is at two points at the same time, the problem is that the time precision is not high enough.

This significantly lowers the chance of duplicate timestamp.

Sounds good, but I doubt it will remove the chance in every case.

A 4th option could be to add a parameter like "gpx.post_processing=remove_dup_timestamps"