Skip to content
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.

trackpoints joins anonymous tracks together #3340

Closed
openstreetmap-trac opened this issue Jul 23, 2021 · 6 comments
Closed

trackpoints joins anonymous tracks together #3340

openstreetmap-trac opened this issue Jul 23, 2021 · 6 comments

Comments

@openstreetmap-trac
Copy link

Reporter: ralfhergert
[Submitted to the original trac issue database at 7.36am, Tuesday, 16th November 2010]

Requesting http://api.openstreetmap.org/api/0.6/trackpoints 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.

@openstreetmap-trac
Copy link
Author

Author: TomH
[Added to the original trac issue at 5.34pm, Tuesday, 16th November 2010]

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.

@openstreetmap-trac
Copy link
Author

Author: ralfhergert
[Added to the original trac issue at 6.27pm, Tuesday, 16th November 2010]

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.

@openstreetmap-trac
Copy link
Author

Author: TomH
[Added to the original trac issue at 7.03pm, Tuesday, 16th November 2010]

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.

@openstreetmap-trac
Copy link
Author

Author: ralfhergert
[Added to the original trac issue at 6.01pm, Wednesday, 17th November 2010]

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

@openstreetmap-trac
Copy link
Author

Author: TomH
[Added to the original trac issue at 6.20pm, Wednesday, 17th November 2010]

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

@openstreetmap-trac
Copy link
Author

Author: TomH
[Added to the original trac issue at 6.39pm, Wednesday, 17th November 2010]

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?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant