umrlastig / tracklib Goto Github PK

Hi,

I'd like to begin by thanking you for this very powerful and ambitious library I've had the pleasure of discovering recently.

However, in my usage of the library, I've encountered a problem when importing some GPX files that were generated by a fairly high frequency GPS logger that has a sampling frequency of 4 [Hz].

Below is an excerpt of a sample .gpx

<trkseg> <trkpt lat="47.7252015" lon="-3.3494651"> <time>2023-10-15T06:33:22.500000Z</time> <speed>0.2</speed> </trkpt> <trkpt lat="47.725207" lon="-3.3494624"> <time>2023-10-15T06:33:22.750000Z</time> <speed>0.1</speed> </trkpt> <trkpt lat="47.7252121" lon="-3.3494586"> <time>2023-10-15T06:33:23Z</time> <speed>0.1</speed> </trkpt> <trkpt lat="47.7252154" lon="-3.3494555"> <time>2023-10-15T06:33:23.250000Z</time> <speed>0.1</speed> </trkpt> <\trkseg>

In order to import this data I've tried setting the time observation read format, with the following command :

trk.ObsTime.setReadFormat("4Y-2M-2DT2h:2m:2s.2zZ")

However, because of the following lines in the readFromGpx() function, the track I load doesn't contain the milli-seconds part of the observation times.

This is problematic for the workflow I intend to to apply to the track, where for instance I try to compute the speed, which becomes "nan" when two sucessive observations have the same timestamp.

What I would have expected is that trk.ObsTime.setReadFormat would allow to load the data from this format, but the code doesn't allow it.

One fix would be to completely bypass the aformentioned lines (as well as

)?

Another would be to let the readFormat be an optional user supplied argument to readFromGpx().

I've never contributed to a public github repository before, so I don't really know the workflow, but if you are interested I can try to contribute a commit that could implement one of these solutions?