Better wording "ordered points" instead of "unordered points" in gps visibility options

[iriman]

Please see here

[tomhughes]

Why would we change it to be incorrect? When a trace has that visibility it is mixed in with all the other traces with the same visibility an an unordered point cloud.

[scaidermern]

Since JOSM is able to use these points in an ordered line it can't be an unordered point cloud. I would expect an unordered point cloud to have a random point order, for example by randomizing the GPS trace once during upload. Otherwise it still remains a list of ordered points, doesn't it?

[tomhughes]

That may, by chance, happen, but I can assure you that there is nothing in the way the API sorts the points that guarantees any kind of ordering.

[tomhughes]

So actually it turns out that (accidentally) those points were being ordered but they very definitely shouldn't have been and I have pushed a fix for that in cdb42d2.

[don-vip]

Hi,
It seems to break display of GPX traces in JOSM: https://josm.openstreetmap.de/ticket/16963
Could you please revert this change until we adapt JOSM in consequence and release a new tested version at the end of the month?

[tomhughes]

No - this was a serious security/privacy issue that had to be fixed as a matter of urgency.

[scaidermern]

Deliberately waiting until the end of the month would be indeed a bad choice. A broken GPX trace in JOSM is bad but not as bad as a privacy issue.

[don-vip]

It was there for like what, 10 years, and nobody ever complained? If that's the case it doesn't look like so serious we couldn't wait three more weeks, but ok. What is the ratio between each type of track? I wonder how much tracks we won't display anymore.

[systemed]

Fixed (FSVO fixed) in P2: systemed/potlatch2@550aab4

[mmd-osm]

@tomhughes : according to this forum post (https://forum.openstreetmap.org/viewtopic.php?id=64575), this change affects the GPX layer on osm.org as well. I guess this would be something for the https://github.com/openstreetmap/gpx-import repo, as long as there's no Rails implementation available yet?

[tomhughes]

First no, the gpx layer on osm.org is nothing to do with that tool.

Secondly, the gpx layer works from the raw traces so is unaffected by this.

[tomhughes]

Those lines are the wrong way to be this I think - this produces horizontal lines not vertical? More likely that is just a bad trace that has unordered points.

[tomhughes]

The gps tile layer is updated by https://github.com/ericfischer/gpx-updater/blob/master/update which polls the RSS feed and downloads the traces so doesn't depend on the API at all.

It does use a customised version of gpx-import (https://github.com/ericfischer/gpx-import) to decode the traces but again that is working from the raw traces which haven't changed.

[mmd-osm]

Many thanks for the quick feedback. You're of course right, the gpx importer has direct access to the gps_points table and gets the raw data, so isn't affected at all. The other issue mentioned in the forum post about JOSM is the already known issue discussed earlier here.