[Rebuild] Coordinates of deleted nodes

Andy Allan gravitystorm at gmail.com
Mon Jul 9 10:04:11 BST 2012


On 8 July 2012 17:50, Richard Fairhurst <richard at systemed.net> wrote:
> On 06/07/2012 21:06, Andy Allan wrote:
>>
>> I see three options
>> A) Modify rails_port so that deleting a node updates the lat/lon
>> B) Modify rails_port so that lat/lon of a deleted node is not visible
>> on the website or via any api calls
>> C) Modify the bot so that any node deletions are preceeded with a
>> separate modify, i.e. modify(lat,lon), then delete
>>
>> Which is best?
>
>
> I'd go for B. It's inconsistent that we currently show 'content' (lat, lon,
> tags) for deleted nodes:
>         http://www.openstreetmap.org/browse/node/102291199
>
> but we don't do so for ways:
>         http://www.openstreetmap.org/browse/way/14944497
>
> nor relations:
>         http://www.openstreetmap.org/browse/relation/2171573
>
> Making the node behaviour consistent with that of ways and relations would
> be a (very modest) improvement to the existing API.

After much thought over the weekend, I also now think B is the right
way of doing things. Note that it's slightly different from what you
say above - we do remove the tags when deleting nodes, just not their
lat/lon. For ways and relations we remove everything (tags, nodes,
members) from the objects.

> I also struggle conceptually with the idea that a deleted node can _have_ a
> lat or lon. By definition, if it's deleted, it doesn't exist any more. The
> lat and lon was a property of whatever it used to be, and that remains
> accessible via the object history.

Yep, that's my belief too - I can't see how, conceptually, a deleted
node could have a location, especially given it has no tags, and
deleted ways have neither tags nor nodes to describe their geometry.

So at the moment for version X of a node, where X is the deleted
version, we're actually exposing the coordinates from version X-1,
which I think simply stems from "not null" constraints on the database
rather than well-reasoned decision.

So I'm going to propose that we stop showing coordinates of deleted nodes.

However, to stop tools which are expecting "lat/lon" attributes on all
(XML) node elements, I propose we keep the attributes, but just show
lat/lon as 0/0 for deleted nodes. We can then remove the attributes
from the XML in API 0.7. I'm also going to propose that we don't
change what's going on in the database, so there's no changes to
column constraints or anything like that, and behind the scenes the
current_nodes table will still have coordinates in there, just not
exposed. It makes the change as low-risk as possible, and easy to
revert if we need to.

Cheers,
Andy

P.S. What made me change my mind, especially when most support was for
C? It's the logic that the deleted version contains no copyrightable
information, which is a reasonable assumption in my eyes. The
situation where a decliner adds a node and later deleted it should
therefore lead to the first version being redacted, and nothing more.
But under C we'd need to (falsely) resurrect the node, in order to
edit it, to move the now-visible node to the mid-atlantic, to then
delete it a second time, and then redact all these unnecessary edits.
That growing level of complexity seems out of place, and hints that
it's not the right approach to take.



More information about the Rebuild mailing list