[OSM-talk] Code of conduct for automated (mass-) edits

[Dave Stubbs]

On Tue, Sep 30, 2008 at 3:58 PM, Hendrik T. Voelker
<hvoelker at nutrimatic.de> wrote:
> Guys,
>
> after we now had a longer discussion I guess several things are clear:
>
>   We agree that as a first step a code of conduct concerning mass changes is
> a very good idea and maybe Frederik can draft one and add it to the wiki as a
> proposal.
>
>   Following that most agree that a code of conduct alone might not be enough
> and we would need to define some more potent means to prevent disasters.
> Several were named, like a sandbox and test suit for verifying the tool works,
> like some kind of certification and authorisation for mass changes, and
> including the self-evident things like logs and undo files.
>
>   It has become evident, that to most feared problems are stupid edits and
> the loss of data because older sources (planet files) are used as the change base.
>
> In today's IT business it is normal in these kinds of situations, to not only
> work on most current data sets - like Paolo's approach does - but also to lock
> the record being worked on to prevent race conditions.
>
> If we all the names requirements we maybe could think about the following
> solution:
>
> OSM is providing the framework and execution means for mass changes.
>
> To get something done, one has to create a Java class that described the bot.
> That then is submitted to the OSM bot execution facility - or what ever you
> want to name it. The framework that executes that class provides for record
> selection and locking, and also provides the means to roll back instead of
> commit the changes in case of errors. And also the means for logging and
> presenting the results officially on the wiki or where ever. As this can run
> directly on the DB this is faster and more reliable than an HTTP(S) connection.

Please take a look at the API 0.6 changes being worked on.

Two features included in that will help here:
 1) Optimistic locking of OSM objects -- it will no longer be possible
to accidentally upload an earlier version from a planet etc as the
version number will have changed
 2) Diff upload -- you can supply an entire file of changes to be made
within one atomic transaction

These aren't quite the same as what you suggest, and is somewhat less
powerful, but a heck of a lot easier to manage than arbitrary code.

Dave