[OSM-dev] OsmChange format and 0.6
zerebubuth at gmail.com
Thu Feb 12 13:01:16 GMT 2009
On Thu, Feb 12, 2009 at 12:18 PM, Brett Henderson <brett at bretth.com> wrote:
> Matt Amos wrote:
>> 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 ;-)
> If changesets were truly atomic then I'd be all for this.
thankfully the diff upload is atomic and can only reference one
changeset, so that makes the API code much easier to write! osmosis
has to deal with all the nasty corner cases ;-)
> Slightly longer term, if I ever get around to implementing proper changeset
> replication (ie. keeping the mysql changeset table synchronized) then you
> won't be able to replicate to the API anyway because I'll have to enhance
> the *.osc file format to include changeset details and there's no way (that
> I'm aware of) of creating a changeset with a specific id via the API.
well, in the same way its not possible to create a node, way or
relation with a specific id via the API. replication to a read-write
server (like svn up) is going to be A Difficult Problem.
>> 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?
> We could get extra funky and create complex schemas that define base types
> with the common data attributes then extend them for each specific purpose
> but the effort involved is fairly considerable and doesn't provide much
> value that I can see. I'd stick with what we have in 0.6, see how it works
> and look at refactoring things in 0.7 once we have some experience with it.
> PS. I've written this so long after the fact that it is probably largely
> irrelevant to the discussion now :-)
it'll be relevant when it comes to the 0.7 discussion, i promise :-)
More information about the dev