[OSM-dev] 0.6 API clarifications and corrections

Dave Stubbs osm.list at randomjunk.co.uk
Thu May 15 18:00:50 BST 2008

On Thu, May 15, 2008 at 5:13 PM, Dirk-Lüder Kreie <osm-list at deelkar.net> wrote:
> Hash: SHA1
> Dave Stubbs schrieb:
>> It's also possible for another changeset to edit the object in between
>> as well, so this probably shouldn't be as transparent as "catapult"
>> might suggest. The changeset data download will have to take this into
>> account.
> How do you handle rollback in such a case?

You either:
- ignore it (the changeset is atomic per object approach), or
- you treat it like a conflict and only roll back as far as the other
changeset's change. The user then gets to resolve the remaining
changes by whatever conflict resolution the editor provides (the same
as they're going to have to for edits that effect the object since the
changeset closed)

The changeset data download can make one approach easier than the
other, but as each object still has it's own queryable history, you
can continue to do either. The basic types of changeset query I can
think of are:
 - atomic objects: you get before, and you get after for each changed object
 - grouped objects: each consecutive change made by this changeset is
grouped together with only before and after for each group. So each
time another changeset gets involved we get a new before/after set.
 - raw edits: every single edit is returned

Some are going to be easier to implement than others.


More information about the dev mailing list