On Mon, Aug 23, 2010 at 5:40 PM, Scott Crosby <scrosby at cs.rice.edu> wrote:
> On Mon, Aug 23, 2010 at 9:48 AM, Lars Francke <lars.francke at gmail.com> wrote:
>>> Creating a true history is impossible. The information about the
>>> concurrent updates across different non-atomic changesets is
>>> presumably lost.
>>>> You can easily recreate that by sorting everything by timestamp. Which
>> I think is the easiest/most obvious ordering there is.
>> Maybe, but the examples and specification of the API and OSMChange
> format make me cautious using timestamps for this purpose, given the
> data model I see for uploading changes and the definition of
> OsmChange. For instance:
>> An upload by 'POST /api/0.6/changeset/#id/upload' is guaranteed to be atomic.
Yes. That only means that either everything succeeds or everything
fails. No partial updates etc.
> The timestamp field is both explicitly specified by the client, and
> specified independently for each element. If the two elements have
> different timestamps, will the data be rejected by the server?
No. You may provide any timestamp you like. It is replaced with the
current time by the server when you upload it. If that isn't
documented it probably should be.
As I said: The easiest way to get an ordering for all elements in OSM
is by ordering them by timestamp. Disregard changesets, they are just
a very loose "wrapper". Changesets are in no way atomic, I'd not even
be sure if they are ordered in any way (at least for all those auto
generated changesets)
Cheers,
Lars