An upcoming change to the website may affect how some of you contribute GPS traces. We mentioned it in a previous monthly update, but we don’t want you to miss it if you aren’t paying close attention to those updates.
Remember to scrub sensitive personal information from the file’s metadata, such as the name of the person you’re visiting. If you upload traces to OSM via a third-party client (such as GPSLogger, OsmAnd, or JOSM’s DirectUpload plugin) or directly via the API, the application may still let you choose Public and Private visibility levels, but the upload will fail if you select them. Please choose Trackable or Identifiable instead. We’ll be reaching out to some developers soon to inform them of this change.
Existing Public and Private traces continue to have the same behavior as before, but we won’t allow new uploads to be Public or Private. Going forward, any improvements to GPS trace management will benefit Trackable and Identifiable traces; we cannot guarantee that Public or Private traces will get these improvements. You can change the visibility of an existing trace to either Trackable or Identifiable at any time. If you want to keep a GPS trace completely secret for your personal editing needs, consider storing it locally on your device instead. These days, most mobile, desktop, and Web editors support working with local .gpx files without uploading them to a server.[1]
This change addresses a concern that Public and Private are unintuitive or misleading. All the raw trackpoint data in a Private trace still goes into the public GPS data available via the API or GPS tiles. Even though we scrub the timestamp associated with each location, making them unordered, it is sometimes possible to deanonymize even that limited data depending on circumstances. Moreover, the legacy levels are contributing to significant performance issues on the website.
We’ll keep you informed about other privacy-related changes as we plan them out further.
In iD, open the Map Data panel on the right side. Click the Edit Custom Data Layer button, which looks like “…” next to Custom Map Data. Click the Choose File button. ↩︎
I agree with this change. “Public” is indeed a very misleading option at first, until you read the whole description, in the wiki. It gives the impression that it connects the track with your username, when in reality only “Identifiable” does it.
So, this change just stops the ability of removing the timestamps from the traces, keeping them ordered always and not just points. Those timestamps are track-related, meaning how much time passed since the recording started, or it really records the actual time of the day aswell? That’s what I don’t really understand with the track timestamps, because besides the server resources improvement that will come with the change, I can’t really see why it was an option to scrub them out in the first place.
A valid .gpx file would include an absolute timestamp on each trackpoint, nominally to millisecond precision, though most location tracking tools will generalize a bit. As it stands, you can download a Public trace with these timestamps as is. You can’t download a Private trace via the file listing, but the individual points are available programmatically.
For backwards compatibility, wouldn’t it make sense that if API clients set a to be uploaded trace as “public”, it will upload as “identifiable” instead?
if all traces must have timestamp, recording GPS while editing map on the go (using iOS/android apps) may leak the user’s identity more easily even as “trackable” (as OP mentioned it could also happen for unordered points though). So for people with determined intention, it’s not hard to track a person’s home/work/routine by user name if the targeted user like to contribute to OSM and GPS traces. For those users the only way is to have temporary accounts and delete after a while, or skip recording near protected areas.
No; no-one is forcing users to upload traces to OSM to be stored there. If they want to record traces separately they can do that in any app or on any device that supports that, and they can then drag and drop traces onto an open iD editor session to use the data there.
Can someone confirm this is still accurate in practice? In my experience only traces set to Public at creation time actually get drawn into the “OpenStreetMap GPS layer”, and switching an existing trace’s visibility to Public afterward didn’t cause it to appear either.
If Trackable and Private traces are genuinely feeding that layer today, that doesn’t match what I’ve observed, so I’d like to understand whether there’s something else going on before assuming the layer keeps working the same way once Public and Private go away.
… and no (at least, not into the OSMF tiles such as https://gps-b.tile.openstreetmap.org/lines/9/254/166.png). Private traces are available via the API though (I map my own “uploaded as private” GPS traces that way all the time).
indeed, and vice versa. It’s a logged but hard to fix bug.
To my opinion uploading traces has the intention to show other users that someone was able to go along this way e.g. in tree covered areas, on newly built streets not yet in imagery etc.
Several similar traces give a good idea of location reliability and may help to improve OSM data.
Point clouds are much less usable.
If privacy is a concern, you better decide which traces to upload at all.
Given what SomeoneElse confirmed above, it sounds like the raster GPS tile layer only ever gets populated from traces uploaded as Public at creation time. If that’s the only path feeding it and Public is going away, what’s the plan for keeping that layer alive?
It’s genuinely useful for spotting coverage gaps at a glance without pulling raw trace data, and if there’s no equivalent pathway from Trackable or Identifiable uploads, new traces will just stop showing up on it once this ships.
The current GPS tiles also include points from Trackable and Identifiable traces. We had been discussing the difference between Public and Private traces is all. Reducing the number of visibility levels will somewhat simplify the task of modernizing or replacing the GPS tileset.
I should emphasize that another motivation from the engineering side is to reduce the complexity of generating the list of traces. Scrapers (and JOSM) have been hammering that list, causing concern for the operations team.
Old tracks are imho not useless if the underlying path/street still exists.
A possibility to filter tracks by date could be useful, but that’s a task for data consumers (editors).
When you have multiple overlapping tracks then anonymous points makes it less obvious what paths was actually taken and could help disguise the nature of essentially radial traces with a bit of planning.
Disconnect points can also be used to generate heatmaps.
I find gps points (the ones without timestamps) basically useless in my (and probably many others) use case. A traced path at least confirms that the imagery alignment is not wacky.
Real timestamps add an additional privacy risk, but there’s already an underlying privacy risk from the trace geometry suggesting a location significant to the user. Of course one takes a similar risk by concentrating edits in a particular location too. We’d just want users to be aware of what they’re getting into when uploading.
