[OSM-talk] An old question about GPX traces

Joerg Ostertag (OSM Munich/Germany) openstreetmap at ostertag.name
Thu Sep 14 08:04:29 BST 2006


> > 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]

But how does someone else recognize the track was manipulated when he later 
downloads it. And knows he cannot rely on this data for speed calculation?

>  * 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] *

That's the same osmfilter does. Randomize the time between trackpoints.

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

Sorry if you got my posting this way. I didn't want to tell it is stupid, i 
only wanted to tell, that if you change the timestamps it should be easy to 
recognize for people downloading the track, that the timestamps are not 
original.

> 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).

Well maybe we can (if the user wants to) start all track exactly at midnight 
(or midnight of the 1st of the month) if it has faked timestamps. Shouldn't 
be too hard to implement into osmfilter.pl with another option.

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

You cannot post process DGPS with gpx tracks. You simply would need every 
single Satellite timing, but this won't be written into a gpx file nor would 
it be written into a nmea file.


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


-- 
Jörg (Germany, Munich)

http://www.ostertag.name/
TeamSpeak2: ts2.ostertag.name, user: tweety, Channel: "GPS Drive"
irc://irc.oftc.net/#osm




More information about the talk mailing list