Augmented diffs: way w/ newly deleted node includes coordinates

[mojodna]

[adiff:"2018-02-13T20:53:00.000Z","2018-02-13T20:54:00.000Z"];
way(561040198);
(._; >;);
out meta geom;

The <new> way in the response includes valid coordinates, despite the second node (5410169836) having been deleted. This either results in an invalid state (a visible way referring to a deleted node) or something else is going on...

<?xml version="1.0" encoding="UTF-8"?>
<osm version="0.6" generator="Overpass API 0.7.54.12 054bb0bb">
<note>The data included in this document is from www.openstreetmap.org. The data is made available under ODbL.</note>
<meta osm_base="2018-02-16T19:10:03Z"/>

<action type="modify">
<old>
  <node id="2006812879" lat="45.5270083" lon="10.5510287" version="2" timestamp="2018-02-13T16:09:51Z" changeset="56327450" uid="5631066" user="osm_fede"/>
</old>
<new>
  <node id="2006812879" lat="45.5267951" lon="10.5513489" version="3" timestamp="2018-02-13T20:53:20Z" changeset="56334244" uid="73405" user="ciclista"/>
</new>
</action>
<action type="delete">
<old>
  <node id="5410169836" lat="45.5268377" lon="10.5512585" version="1" timestamp="2018-02-13T16:09:45Z" changeset="56327450" uid="5631066" user="osm_fede"/>
</old>
<new>
  <node id="5410169836" visible="false" version="2" timestamp="2018-02-13T20:53:27Z" changeset="56334244" uid="73405" user="ciclista"/>
</new>
</action>
<action type="modify">
<old>
  <way id="561040198" version="1" timestamp="2018-02-13T16:09:49Z" changeset="56327450" uid="5631066" user="osm_fede">
    <bounds minlat="45.5268377" minlon="10.5510287" maxlat="45.5270083" maxlon="10.5512585"/>
    <nd ref="2006812879" lat="45.5270083" lon="10.5510287"/>
    <nd ref="5410169836" lat="45.5268377" lon="10.5512585"/>
    <tag k="highway" v="steps"/>
  </way>
</old>
<new>
  <way id="561040198" version="2" timestamp="2018-02-13T20:53:24Z" changeset="56334244" uid="73405" user="ciclista">
    <bounds minlat="45.5267951" minlon="10.5512585" maxlat="45.5268377" maxlon="10.5513489"/>
    <nd ref="2006812879" lat="45.5267951" lon="10.5513489"/>
    <nd ref="5410169836" lat="45.5268377" lon="10.5512585"/>
  </way>
</new>
</action>

</osm>

Looking at the OsmChange for the changeset itself, it looks like the way was actually deleted: https://www.openstreetmap.org/api/0.6/changeset/56334244/download

<delete>
<way id="561040198" visible="false" version="2" changeset="56334244" timestamp="2018-02-13T20:53:24Z" user="ciclista" uid="73405"/>
</delete>

[mmd-osm]

I’d suggest to get in touch with Roland by email for immediate attention, as he hasn’t really responded to any of the open github issues for several months now. Otherwise this showstopper probably slips under the radar and never gets fixed.

[mojodna]

Thanks, good to know. I thought you'd been working on this as well (thanks for everything!).

I've been working around the various augmented diff issues but wanted to at least document them for whenever someone gets a chance to dive in.

[mmd-osm]

Not exactly, I stay away from any of the attic stuff as much as I can. Only Roland has a clue how this really works and it’s barely documented. I have long since given up making sense of this particular part of the coding 😎

[drolbr]

Thank you for reporting the bug.

On first analysis, this looks like the database content is involved. On the upside, this probably only affects special constellations. The object must have been undeleted and changed in the same minute, in this case by moving a node.

I will investigate the issue further.

[drolbr]

I am pretty sure it has been fixed in 3aa6f76236db22576e061dc62940c71005f3e4ed

However, to get that fixed in all the museum data, I would have to rebuild the database. Given that this takes some days to some weeks on a dedicated machine, I will delay this to include other database changes in that rebuild.

[gy-mate]

I will delay this to include other database changes in that rebuild.

@drolbr Has the database been rebuilt since then? If not, could you please start it soon? https://github.com/tyrasd/overpass-turbo/issues/367 and #478 are also dependent on this.

Thank you very much in advance!

[mmd-osm]

@gy-mate : no, the database hasn't been rebuilt, since it's too time consuming and costly to do so. We're talking about at least two months of processing time here.

[gy-mate]

@mmd-osm Gosh, that's a lot! I totally understand it.