On Mon, Aug 23, 2010 at 5:40 PM, Scott Crosby <scro...@cs.rice.edu> wrote: > On Mon, Aug 23, 2010 at 9:48 AM, Lars Francke <lars.fran...@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 _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
