I'm about to go to bed (and leave town in the morning) but I like the idea here, though I don't have time for a full review right now.  This is a lovely use of our new time features.

Please consider doc and test cases.z

We probably could go sub-second by losing mkgmtime and friends.

If it's more natural to express distances in some units other than meters/sec, perhaps we should do that instead of scaling.  But I wouldn't block on that.

Add doc and test cases and I'd probably submit it without change unless others have ideas how to make it more awesome.


On Thu, May 22, 2014 at 9:56 AM, "Christian Müller" <cmue81@gmx.de> wrote:

could someone please review this patch and apply it to gpsbabel svn?

It's primarily useful for tracks that have been clicked together by a user or generated by a routing algorithm, were the distance between consecutive points is variing and no timestamp information exists.

Also, if a segment of a track is lost due to (temporary) battery or equipment failure, this comes in handy to recreate the gap from human memory after a tour, if needed.

Let there be two track segments, the first ends at time A, the second starts at time B in history, then the time difference in seconds is:
  timediff_of_gap_in_seconds = toseconds(B-A)

When reconstructing the missing segment that fills the gap between A and B, it is desirable to let that segment appear as if it had been traveled at:
  avg speed = distance of missing segment / timediff_of_gap_in_seconds

To achieve this, the (un-timestamped) points of the user (or routing algo) generated track, are normalized first, using the "interpolate" trackfilter:
  -x interpolate,distance=0.001k

After that all points are roughly 1 m apart, except the few ones set even closer by the user, that is.  To achieve constant speed, gpsbabel needs a step value argument to faketime that is:
  step = number_of_points_in_1_m_interpolated_track / timediff_of_gap_in_seconds

For many use cases people travel farther than 1 m per second, so the ability to pass a fractional step value to faketime is needed, e.g.:
  -x track,faketime=f20140518162500+0.25  (roughly 4 m per second)

I suspect that it is not useful to interpolate a track with a distance of more than 1 m between consecutive points, since users and routing algos alike will digitize complex intersections or sharp curves with points apart between 1 and 2 m.  So to not let gpsbabel deviate too much from the avg speed for that time frame a frequency of 1 m is probably a good choice.

Of course, another option would be to enhance faketime to accept faketime.start and faketime.end value and distribute timestamps in a way that respects the unequally distributed distance between consecutive track points.  This would obsolete the need to interpolate (normalize) distances of the track points in a first step, as above.

For this to work, faketime function needs to know about the whole length of the track in advance and needs info about the length traveled so far, while the algorithm advances from point to point.