[OSM-dev] Reading OSM History dumps

Scott Crosby scrosby at cs.rice.edu
Mon Aug 23 16:40:46 BST 2010


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.

>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



More information about the dev mailing list