[OSM-talk] Brainstorming: Simple Revert-Tools

[Peter Miller]

On 3 Sep 2009, at 14:04, Andy Allan wrote:

> On Thu, Sep 3, 2009 at 10:36 AM, Peter Miller<peter.miller at itoworld.com 
> > wrote:
>
>> I agree that there should be a 'easy revert' for a single changeset.
>> This might result in a 'clean' revert (where none of the features  
>> have
>> been touched since),
>
> Just want to point out that there's more to life in OSM than
> particular features, and practically no changeset can be cleanly
> reverted. Two examples:
>
> 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.

Could you put these as validation 'use cases' onto the wiki so that a  
tool can be tested against them? It will be very useful to have all  
the delinquent cases available for consideration before work starts on  
the code.

I guess that the tool should ideally be able to check for manual  
reinstatement of the same or similar features.

>
> Not what you wanted.
>
> 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.
>
Again, lets have this on the wiki please.

We also need to consider how relations can interact in difficult ways  
with the data.

> Not what you wanted either.
>
> The version numbers only apply to the primitives, not the state of the
> system (which has both relationships between primitives and spatial
> relationships). This makes hands-off reverting very tricky.
>
Sure, so possibly it should be 'hands on'. I am not getting into how  
it works or the solution at all, only that we need to get on with  
solving this interesting and tricky problem sooner rather than later.



Regards,


Peter



> Cheers,
> Andy