[OSM-dev] 0.6 API clarifications and corrections
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
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