Request for improvement to reported <time>

7 views
Skip to first unread message

Kris Buelens

unread,
Apr 8, 2025, 1:53:45 AMApr 8
to gpsess...@googlegroups.com
GPS Essentials is working correctly again for me.  Great, a happy user.

There's one more thing that could be improved too.

Together with a friend, I started to create a Visual Basic program to manage the GPX files we collected throughout the years.  For example to make a global GPX or KML for for example; all routes we travelled through in France (for that goal, I can reduce the number of track points, like 1 point every KM and/or every 1 minutes)

Part of this process is maybe cleaning up bad track points.  My program tries to find them by looking at the speed: I know when the calculated speed between two points is e.g. 140km/h something is wrong, I never drive that fast.  Looking at its report, we found impossibilities: too fast where we know we didn't speed at all.
Here an example: point 101, 109 and 127 (screenshot of GPS Track Editor)
image.png
100km/h is not impossible, but I saved this screenshot from the discussion with my friend where we came to the conclusion: one can see that the points are nicely spread, roughly one every 58meters.  Our conclusion was that these sudden jumps to 100km/h can be explained by that the <time> tag is rounded to seconds.  At line 101, the reported time difference is 2 secs, line 102 is 3sec the calculated speeds 104 resp 52
The GPX specs allow for decimals in the <time> tag.  For example <time>2022-09-12T16:43:48.786Z</time>  So it would be better to use decimals.  Then the speed for sections by e.g. a car would become better.  GPS Essentials uses decimals in some <time> tags, but much to my regrets never in the <trlkpt>

Kris Buelens,
     --- VM/VSE consultant, Belgium ---
-----------------------------------------------------------------------
Reply all
Reply to author
Forward
0 new messages