On Tue, Sep 30, 2008 at 3:58 PM, Hendrik T. Voelker <[EMAIL PROTECTED]> 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 _______________________________________________ talk mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk
