London data corrupton

At https://www.openstreetmap.org/#map=14/51.5510/-0.0173 I'm seeing what appears to be large scale corruption of map data, with a pattern of closely spaced vertical roads being shown. It looks like it might be programaticaly created? Is anyone looking at trying to revert it all?

Re: London data corrupton

(for the avoidance of any doubt) - yes, the oroblem was fixed around midday yesterday. Depending on what map you're looking at, where it gets its data from and how any tiles are cached you might still see a problem, but it'll get fixed as soon as the problem tiles are refreshed (something that happens periodically as edits are made).

I orginally suspected a "JOSM node drag" (of which we've had a few before) but as Richard on IRC noted, it's more likely a pre-existing .osm file (with numbers that matched existing nodes) was involved. That might explain how it hit nodes in both London and Oslo from the same

Re: London data corrupton

Re: London data corrupton

SomeoneElse wrote:

kreuzschnabel wrote:

How on earth could this happen?

I orginally suspected a "JOSM node drag" (of which we've had a few before) but as Richard on IRC noted, it's more likely a pre-existing .osm file (with numbers that matched existing nodes) was involved. That might explain how it hit nodes in both London and Oslo from the same

I happened to notice that both this recent changeset and the ones in August seem to only move nodes with id's roughly in the range between 106000 and 118000. Does this suggest a JOSM or OpenStreetMap API bug? Or is there a more likely explanation? Could the JOSM option to upload the data in chunks be related somehow?Both users seem to use JOSM version 15238, although that could be faked I suppose.

Hopefully a better understanding of the causes of these changes can avoid future problems.

Re: London data corrupton

alphensebezorger wrote:

SomeoneElse wrote:

kreuzschnabel wrote:

How on earth could this happen?

I orginally suspected a "JOSM node drag" (of which we've had a few before) but as Richard on IRC noted, it's more likely a pre-existing .osm file (with numbers that matched existing nodes) was involved. That might explain how it hit nodes in both London and Oslo from the same

I happened to notice that both this recent changeset and the ones in August seem to only move nodes with id's roughly in the range between 106000 and 118000. Does this suggest a JOSM or OpenStreetMap API bug? Or is there a more likely explanation? Could the JOSM option to upload the data in chunks be related somehow?Both users seem to use JOSM version 15238, although that could be faked I suppose.

Hopefully a better understanding of the causes of these changes can avoid future problems.

Likely

- JOSM or API bug- broken stealth import script

unlikely

- actually moving the nodes.

Unluckily it is practically impossible to determine what went wrong without cooperation from the contributor in question (and even then there is no real way to do a proper root cause determination).

Simon

PS: SomeoneElse the thing is that the node ids are extremely low and essentially sequential, aka very very early data and very unlikely to be present in any accidental extract, so likely something is going very wrong with the placeholder ids in one of the three potential culprits.

Re: London data corrupton

alphensebezorger wrote:

I happened to notice that both this recent changeset and the ones in August seem to only move nodes with id's roughly in the range between 106000 and 118000.

I've just looked at the August one and that includes node IDs over 25,000,000 so I don't think it's the same sort of thing. I suspect that that was a "normal" node drag that is all too easy to do in JOSM.

alphensebezorger wrote:

Does this suggest a JOSM or OpenStreetMap API bug?

I don't think it's an API bug - that pretty much just does what you tell it to, and if it "occasionally updated the wrong object" we'd know about that by now.

With JOSM you could argue the case that it should at least have displayed a suitable warning dialogue in front of the user, but of course we don't know that that didn't happen. With a DWG hat on I often use JOSM to break referential integrity in the data when doing a revert, because "how well things are mapped" will still be better afterwards than before. JOSM's conflict resolution dialogues are actaully enough of a pain for me to tend to use the perl revert scripts for larger reverts, and patch up the problems afterwards. It's really a question to which there is no right answer.

alphensebezorger wrote:

Both users seem to use JOSM version 15238, although that could be faked I suppose.

Although faked version numbers of JOSM (and iD) are definitely a thing that spammers et al sometimes use, I have no reason to believe that either user here was using other than a "normal" copy of JOSM.