[OSM-dev] What should the changeset api do?
shaun at shaunmcdonald.me.uk
Sat Oct 11 16:44:21 BST 2008
On 11 Oct 2008, at 15:53, Frederik Ramm wrote:
> Shaun McDonald wrote:
>> Alternatively if we state that a changeset is private until it is
>> closed, and has a limited life, then you could simply calculate the
>> bbox on closing of the changeset.
> Yes but the original plan was based on the idea that changesets do
> not require an explicit close, they have an implicit close (if their
> validity expires). The elegance of that is *not* requiring a huge
> clean-up deamon that closes changesets and computes bounding boxes
> and dies every now and then ;-)
If the consensus is to store the closing time of the changeset, then I
will update the migrations and other code as required. Determining
whether or not a changeset is closed, would be determined by whether
the closing_timestamp is less than the current time. Is this
comparison significantly slower than checking a boolean? You would
still be able to close a changeset manually as the api would set the
closing_timestamp to Time.now.
>> One problem we have at the moment, is that the changeset determines
>> the after state. You can assume that changeset.version-1 is the
>> previous version. However I'm sure we're not meant to assume that a
>> new version=old_version+1.
> You might change the same object twice within the same changeset,
> then the changeset would have old_version=new_version-2...
True. However what I say still applies for the first change of that
object. You wouldn't be able to use the last change of the object (if
there are multiple) to determine the prior version, as someone else
may have made an edit in between, or you have edited that object in
between in another editor, thus that edit went into a different
More information about the dev