[OSM-talk] Brainstorming: Simple Revert-Tools

[Peter Körner]

I thought about these cases and I think for some of them a tool could do 
the check anyway.

> Bad changeset #123: delete the node "London". Was node 456 v10, now
> 456 v11 (deleted)
> (Intermediate changeset: add a node for London)
> Revert changeset #123: node 456 hasn't been touched since, so reinstate.
While reverting the tool could look for nodes at the original location 
(+ some bbox around) that were created in a later changeset. It could 
compare the tags of both nodes and alert if they are similar (>75% 
match). It could then offer the possibilities to
  - keep both nodes
  - delete the new
  - delete the old
  - merge tags onto the old node and delete the new
  - merge tags onto the new node and delete the old
  - merge tags onto a node right between the two

Of couse if node "London" gets deleted and is created some miles away, 
this would not work - but it wouldn't work in an editor, too.

> Bad changeset #333: moved node #1234 (v2->v3) in way #4567 (v15 - not
> changed in this changeset)
> (Intermediate changeset: remove node #1234 from way #4567, but the
> node isn't itself deleted)
> Revert changset #333:  node #1234 hasn't been touched since, move it
> back to where it started.
> 
> Not what you wanted either.
What do you want? The big question is: is the fact that Node #1234 is 
not longer part of way #4567 connected to the position of the node or not?

The problem I see here is a technical: When it comes to reverting, I'm 
not able to fetch from the api if the list of ways node #1234 is in has 
changed since the changeset. If this could be possible we could also 
offer meaningful uptions here, like
  - revert node, leave the way alone
  - re-add node to the way and revert the nodes original state

Peter