[OSM-dev] 0.6 API clarifications and corrections

Frederik Ramm frederik at remote.org
Thu May 15 16:45:22 BST 2008


>> The very reason for having changesets is to do some grouping and 
>> filtering on the server side, instead of having to let the client do 
>> everything (and incur a lot of server load and traffic along the way).
> I thought the reason for changesets was to have some grouping
> so we could do rollback.

We could do rollback even now without any grouping, but it would incur a 
much higher server load than with convenient change group access.

> I was not aware this is also a server
> load issue. And frankly if this is about server load then there
> are better ways to mitigate that like rewriting the map call as
> a C/C++ apache module...

The map call is not involved.

>> And not: "During changeset 123, the user first idled for 10 minutes, 
>> then moved node A a bit further north, five minutes later moved it back 
>> south, then decided to add a tag; subsequently deleted the whole node 
>> and repeated the procedure with a new one...". This is completely 
>> unnecessary and only confusing for any clients who want to work with the 
>> changeset data.
> Mm. I have a difficult time picturing the difficulty for the
> client.

Use your imagination then. If the user requests, say, a graphical 
representation of the changes effected by change set X, you will not 
want to show the intermediate steps. So you would have to collapse the 
change set - something changed first and deleted later, show it only as 
deleted; something created at position A and moved to position B, show 
it as created at position B; something moved from X to Y and then from Y 
to Z, show it as moved from X to Z.

This collapsing would have to be implemented in every piece of software 
that deals with changesets, and my hunch is that everybody would 
implement it slightly differently. Thus I want it in the server.

> On the contrary my hunch feeling is that rollback is going
> to be easier, more flexible and more robust if the changeset is not 
> mangled but is presented as small piecewise changes. 

Au contraire. Rolling back a changeset requires the very same 
collapsing; if the changeset contained a change from X to Y to Z, then 
you want to rollback from Z to X and not from Z to Y to X.


More information about the dev mailing list