[PATCH] EditGpx: keep relative time difference between anonymized points

[synack]

The EditGpx plugin has the option to anonymize the GPX track data by setting each point's timestamp to the POSIX Epoch (1970-01-01T00:00:00Z). Unfortunately, this destroys speed data, which can be useful for determining speed limits, features (e.g., stop light), mode of transport (hiking vs. mountain biking), etc.

It would be nice if the plugin kept the relative time between points. For example, if the data had points with the following timestamps:

1. 2012-09-04T03:07:58Z
2. 2012-09-04T03:07:59Z
3. 2012-09-04T03:08:02Z

then the anonymized points would have the following timestamps:

1. 1970-01-01T00:00:00Z
2. 1970-01-01T00:00:01Z
3. 1970-01-01T00:00:04Z

Attached is a patch that does this.

[synack]

patch to keep relative time differences in anonymized points

[bastiK]

In [o28689].

Thanks.

Btw., assert has no effect with default JVM options, you can throw AssertionError if you really want it to fail.

[Gnonthgol]

I do not see an option to disable this feature. It would be nice to have the option to either keep the relative time or to anonymize those as well.

It would also be nice if it would reset the counter if there are no datapoints in a while. The relative times between different traces are not that usefull and should be anonymized.

[anonymous]

Replying to Gnonthgol:

I do not see an option to disable this feature. It would be nice to have the option to either keep the relative time or to anonymize those as well.

Agreed. Perhaps a new ticket should be filed for this?

What do you suggest for the UI? A third "Convert to GPX layer" menu choice?

It would also be nice if it would reset the counter if there are no datapoints in a while. The relative times between different traces are not that usefull and should be anonymized.

It might be hard to define "a while" -- I'm worred that any heuristic we choose will be wrong more often than users would like. Besides, I would expect that truly independent tracks would be edited and converted back to GPX separately. But I'm open to taking a crack at adding such a feature if we can come up with a good design.

Maybe the right approach is to expose the separate tracks as sublayers within the layer (does JOSM have built-in support for hierarchical layers?), add the ability to merge/split tracks, and reset the counter for each track.