[OSM-dev] OsmChange format and 0.6
zerebubuth at gmail.com
Mon Feb 9 12:14:51 GMT 2009
On Mon, Feb 9, 2009 at 1:06 AM, Frederik Ramm <frederik at remote.org> wrote:
> I have come across a strange logic twist and want to confuse you
> with it. (Maybe it was clear to anybody anyway, don't know.)
> API 0.6 supports uploading OsmChange files, with the additional
> requirement that each node/way/relation contained in the change file be
> given an extra "changeset" attribute. (Escapes me now why we did not
> have that in the header but I remember there was a valid reason for it.)
the valid reason is simply that we re-use the node/way/relation XML
readers and these require the changeset ID. in fact, the diff doesn't
even need the changeset ID in the header as the URL already contains a
valid changeset ID.
at some point in the future it might be worth taking the changeset ID
out of the element parsers and putting it into the controller. whether
we want to make the change while 0.6 is so close to release, i'll
leave for others to discuss ;-)
> Now one should think that if I have two API server and generate a diff
> from server #1 with Osmosis, it should be possible to upload that to
> server #2 through the API (after amending every object with a changeset
> But that doesn't work: API 0.6 of course expects the uploader to report
> the current version of each object they have, to make sure it matches
> the database version before incrementing the version number and storing
> the new data. Whereas Osmosis of course writes the current version
> number to the file.
in this, i lean towards both versions being in the file - the new one
for <create>, the old one for <delete> and both for <modify>, but
these are probably ideas to be kept for a future version of the
> So, if you wanted to upload an Osmosis-generated .osc to another server,
> not only would you have to add changesets, but you would also have to
> decrement each version number!
yup. this is the disadvantage of the warning in
"There is no guarantee that newversion == oldversion+1". so
decrementing the version number is not even guaranteed to work!
> Come to think of it, you would also have to replace the IDs of all newly
> created objects in the osc file by negative IDs so that the destination
> server can issue its own IDs... so it seems that, while superficially
> the same, there is a world of difference between an osc file as created
> by Osmosis and one as read by the API. - Maybe we should have opted for
> a wholly different format to make this clearer. Sigh.
actually, you don't have to do this - the server treats all incoming
IDs in <create> blocks as placeholders, whether they're negative or
however, you'd lose all the timestamp and user information in those
.osc files to be overwritten with whatever user you're logged-in as
and the current time.
you're right, maybe we shouldn't have tried to re-use a
server-to-server sync format for client-to-server communications,
where things like the allocation of new IDs and setting user and
timestamp info are not trusted - we could have just omitted them from
the file. on the other hand - do we really want YAOCF (yet another OSM
change format) when there are already three?
More information about the dev