[OSM-dev] 0.6 API clarifications and corrections

bvh bvh-osm at irule.be
Fri May 16 06:47:46 BST 2008

On Thu, May 15, 2008 at 05:45:22PM +0200, Frederik Ramm wrote:
> > 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.

No, but it is probably 1000x more likely to be called than
doing a changeset rollback. Hence a better target for optimization.

> > 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.

It is trivial to do that kind of stuff on the clientside.

> > 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.

First of you might want to do rollback from Z to Y only because
you want to keep Y to X. Or even worse, maybe there was a bug in
the client that mangled only certain operations so you want to
rollback only those. Or you misinterpreted something on the
wiki and put in nodes at crosssections that shouldn't have them
but you want to keep the other changes you did at the same time.

cu bart

More information about the dev mailing list