Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#3340 closed defect (wontfix)

trackpoints joins anonymous tracks together

Reported by: ralfhergert Owned by: Tom Hughes
Priority: major Milestone:
Component: api Version:
Keywords: trackpoints anonymous track Cc:


Requesting for a designated bounding box will return a response in which all anonymous tracks are attached to a single anonymous track (per page). Due they are not segregated into different track segments (trkseg) they became connected all together, creating a single huge track, which in real does not exist. The size is not a problem, but the fact the "end of the previous anonymous track" and the "begin of the next one" get connected to each other. And that is not correct. For instance, a client receiving this reponse will not be able to separate the (different) anonymous tracks and thereby is forced to interpret the (not existent) connections between them as "line of the track".

I my opion this behavior is wrong, because it creates line segments which does not exist and which are also non deterministically dependent on the order of tracks in the database.

Two solutions are possible: (1) use a new trkseg for each anonymous track. (2) give each anonymous track its own trk-element.

I prefer the second solution, because:

  • anonymous tracks are also transfered via pgx-files from the user to the server. Each gpx-file may contain multipe track segements. The container for tkrseg is trk.
  • it leads to more clean code, because the anon_track-singletons are obsolete.
  • the grade of anonymity is the same in both solutions.

I have prepared and attached an implementation of the second solution. Please have a look at lines 53-100. Thanks.

Attachments (2)

app_controllers_api_controller.rb (10.6 KB) - added by ralfhergert 10 years ago.
changed implementation of trackpoints method
rendering.png (151.1 KB) - added by ralfhergert 10 years ago.
rendering of received tracks - tracks should not be connected

Download all attachments as: .zip

Change History (8)

Changed 10 years ago by ralfhergert

changed implementation of trackpoints method

comment:1 Changed 10 years ago by Tom Hughes

Resolution: wontfix
Status: newclosed

This is entirely deliberate and is done to preserve the level of anonymity expected by people that uploaded tracks before we introduced the extra privacy options.

We cannot and will not be changing this.

Changed 10 years ago by ralfhergert

Attachment: rendering.png added

rendering of received tracks - tracks should not be connected

comment:2 Changed 10 years ago by ralfhergert

Resolution: wontfix
Status: closedreopened

Reopened. You missed the point, Tom. Please have a look at the attached "rendering.png". It is a rendering of all the tracks in trackpoint's response. Obiously there is an error in trackpoint's implementation.

comment:3 Changed 10 years ago by Tom Hughes

Resolution: wontfix
Status: reopenedclosed

No, that is entirely deliberate.

The points in the selected area which come from anonymous tracks are deliberately mixed up and returned out of order and all in one track so that no information about the movements of the person who created it can be discovered.

comment:4 Changed 10 years ago by ralfhergert

Resolution: wontfix
Status: closedreopened

But the api does already remove timestamps of all gps-points of each "non-trackable track". Why are all those tracks additionally appended to a synthetic track? I don't see an aditional advantage here.

(When uploading a track with visibility "private" then the description of private says "displayed as an unsorted list of points". But that is currently not implemented. Even in this synthetic track the all points of the same "non-trackable track" are still in the order, they were while uploading. So what is the advantage of appending all non trackable tracks together? It doesn't improve the information obfuscating any further. Or may it be that the feature of "unsorting all points of a non-trackable track" is not implemented yet?)

The current implementation of "trackoints" synthetically creates a track which contains points connections which does not exist. It would at least be nice to mark this track, to give clients a chance ignoring it, because it has not the same quality like the real (trackable) tracks.

(Why did I wrote this bug ticket: The gpx tracks are foundation of all highways as well as evidence for OSMF, that a mapper has surveyed this way. I'm currently trying to create a validation tool to measure how well a way is covered with tracks and to give a response where a survey might be necessary. The anonymous track which is currently delievered by the api is a problem here, because it implies track segments which are not conform to the original uploaded tracks. Since this this is a feature and not a bug I will ignore anonymous tracks for analysis. But the question may be allowed, why were those tracks uploaded, when they are intended to not being usable by anyone?)

comment:5 Changed 10 years ago by Tom Hughes

Resolution: wontfix
Status: reopenedclosed

Look - this is the way it has always worked and we can't retrospectively change it because that would violate the expectation that people had when they uploaded the data.

That's why we added the extra options - to allow people that are happy to reveal additional information to do so whilst leaving things the same for existing data.

As to ordering, well you may find that the points of a given track are in order but that is an implementation detail and not something that we guarantee.

As to the question of tracks acting as evidence, they can do that perfectly well without being joined up - just look at a point cloud picture of an area (ie without points joined up) to see how clearly the structure of the roads stands out even without joining anything up.

There really is really nothing you can do to convince me to make this change off my own bat. I wouldn't even contemplate making a change like this without at the very least having explicit authorisation from the OSMF board

comment:6 Changed 10 years ago by Tom Hughes

It has been pointed out to me that we could produce a file which doesn't change anything from a privacy point of view but which avoids the zig-zag line effect by putting each point from the anonymous section in a separate trkseg. Would you be happy with that?

Note: See TracTickets for help on using tickets.