[OSM-talk] An old question about GPX traces

[matthew-osm at newtoncomputing.co.uk]

On Wed, Sep 13, 2006 at 10:55:43PM +0100, Tom Carden wrote:
> > #! /usr/bin/perl
> > $time = (time()-(2**21)) + int(rand()*2**22);
> > while (<>) { @t = gmtime($time);
> >   $o = sprintf '%4d-%02d-%02dT%02d:%02d:%02dZ', 1900+$t[5],
> >      $t[4], $t[3], $t[2], $t[1], $t[0];
> >   s/<time>\d{4}-\d\d-\d\dT\d\d:\d\d:\d\dZ<\/time>/<time>$o<\/time>/g;
> >   print; $time += int(rand()*15)+1;
> 
> Can anyone tell me why randomised time data would be better than all
> zero time data?
> 
> Strikes me as totally stupid, and possibly even something that should

This code does the following ("design" decisions):

 * leaves the time near to where it was originally (within a month)
    -> if a road changes over time, you still have an idea when the track
       was created
    -> exact time at a particular location is not possible to deduce [privacy]

 * leaves the trackpoints in the same temporal order as before
    -> I didn't know if the timestamp was the method osm uses to order the
       trackpoints: this means it is still possible to find the direction of the
       track

 * randomises the number of seconds between points
    -> speed [privacy] *

So there was at least _some_ thought to it, rather than being "totally
stupid". :-)

I can think of two reasons why the time data might be useful; maybe there are
others:

  * Check to see when the track was created to see if it is out of date (roads
    can change, etc)... one track that is 10 years older than another track that
    is slightly different is possibly not as reliable.
    
    Leaving dates at a fixed value from before GPS existed does not help here
    (and neither does not storing the date).

  * Post-processing and correction of GPS positions (DGPS for example).

    Just too risky... You don't necessarily know if someone has already done
    this, so a second correction could mess up the data. Yes, I do want
    trackpoints that are as accurate as possible... :-)

Hence the reasons for the above, rather than setting all to "0"!

Thanks,

-- 
Matthew


* a fairly accurate guess could possibly be made in certain circumstances, on
  the assumption that the gps was logging at integer second intervals