Traces visible in iD are now dashed rather than continuous

[SomeoneElseOSM]

First mentioned here:

https://help.openstreetmap.org/questions/35514/why-are-traces-showing-up-dashed-in-id

and I noticed the same issue here:

http://gps-b.tile.openstreetmap.org/lines/15/16307/10638.png

but drop into P2 and see that that editor's view of the underlying trace is not dashed:

https://www.openstreetmap.org/edit?editor=potlatch2#map=17/53.23830/-0.84558

[e-n-f]

Thanks for the report! I don't know what is going wrong but I will try to figure out.

[SomeoneElseOSM]

Another interesting effect (perhaps related) is that I'm seeing some GPS traces completely missing from iD now. Here's a public trace (added as public; I've not changed it) from a few days ago:

https://www.openstreetmap.org/user/SomeoneElse/traces/1787665

It starts from the car park on this tile and goes north:
https://c.tile.openstreetmap.org/18/130212/85202.png

I do see it in P2 (without a GPX file passed; select "GPX traces" to view underlying ones). I don't see it in iD and I don't see it here:

http://gps-b.tile.openstreetmap.org/lines/18/130212/85202.png

(same tile, but the GPS layer)

[Vanuan]

@ericfischer Any updates? Is it dead? No new visualizations?

[reportingsjr]

I can also report that gps traces that I have uploaded and tagged identifiable are not showing up in the gps background. Should this be opened as a separate bug or logged elsewhere?

[e-n-f]

Sorry to take so long getting to this. I thought the drive might have filled up but it looks like it is OK. The tracks file is getting updated, so it's not completely failing either. I'll keep trying to figure out what is going wrong and will get the data rebuilt.

[ianmcorvidae]

I'm also seeing this -- just for posterity, with the dashed-line issue, here's a specific case:

http://www.openstreetmap.org/user/ianmcorvidae/traces/1695311 at the easternmost edge of it:

(the rest of the trace is also dashed -- this seems to be the case with either whole traces or not at all, from what I can see. but this is a nice place to zoom in on)

I don't see any particular pattern to the dropped segments but maybe there's something more obvious to someone who works on this.

[dbaron]

I spent a bit of time trying to reproduce this set of problems (dashed traces and missing traces) by using the code in this repository and in datamaps and gpx-layer (whose parse-gpx file needs to be import/src/gpx-parse in gpx-updater). I focused on a single tile that I know has both problems, this tile covering the Northern two thirds of Briones park and areas north of it:

After feeding (a) all of my own GPS traces and then later (b) all GPS traces returned by the trackpoints API for the rect covered by the tile into gpx-updater, I was able to generate a perfectly good tile without any of the problems. (However, interestingly, it was missing a number of tracks that are in the tile on the server. This could be a problem with the trackpoints API, I suppose.) My tile is:

(I was using the update script in this repository with the memcached bits commented out, but was manually invoking render rather than using the tile script in this repository. One note of interest is that I don't have the file lines-directional.dm referenced by the update script, so I just omitted the "-f /path/to/lines-directional.dm" bit of the tile script when I ran render locally. I think this is why the colors in my tile are different. But I don't know whether it could be relevant to the bug.)

This makes me suspect the problem might be in the merging code in datamaps, or might be related to handling of traces that I don't have. But I haven't actually investigated what any of that code actually does.

I'd also note that I manually uncompressed some of the traces, since some of the traces returned by the OSM API were in gzip and bzip2 format. But it didn't look like the tools were expecting that, so that could also, I suppose, account for some differences. Perhaps I should try again with the compressed ones, which might feed more garbage into the system.