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 _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
