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. >From the example given in http://wiki.openstreetmap.org/wiki/OsmChange <osmChange version="0.3" generator="Osmosis"> <create version="0.3" generator="Osmosis"> <node id="-1" timestamp="2007-01-02T00:00:00.0+11:00" lat="-33.9133118622908" lon="151.117335519304"> <tag k="created_by" v="JOSM"/> </node> <node id="-2" timestamp="2007-01-02T00:00:00.0+11:00" lat="-33.9233118622908" lon="151.117335519304"> <tag k="created_by" v="JOSM"/> </node> <way id="-3" timestamp="2007-01-02T00:00:00.0+11:00"> <nd ref="-1"/> <nd ref="-2"/> <tag k="created_by" v="JOSM"/> </way> </create> </osmChange> 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? If not, then using timestamps to define an order will create history snapshots that will *split updates that are guaranteed to be atomic*. Or, what if clients inject historical timestamps? If those are not rejected, then the history is forever mutable as future data with old timestamps arrives. Does any historical data violate these rules? If the history is to obey the atomicity constraints and be immutable, the only feasible way for timestamps to be used for ordering, is if they are set by the server, upon upload of the OsmChange, and the same for each element. They must be set by the server because only the server can create timestamps that are guaranteed to never be in the past. A separate question is whether the performance and space costs of the profusion of more versions, one for each distinct timestamp, is worth the benefits. Scott _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
