[OSM-dev] 0.6 API clarifications and corrections

[Dave Stubbs]

On Fri, May 16, 2008 at 9:18 AM, Frederik Ramm <frederik at remote.org> wrote:
> Hi,
>
>> > 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.
>
> Not trivial, and a benefit for all if implemented server-side.


Umm.. maybe I missed something but surely this is trivial?

For any OSM object where we have N states: o1, o2, o3 ... oN
we can easily collapse the change to o1, oN

osm objects are atomic is this respect.



>
>> First of you might want to do rollback from Z to Y only because
>> you want to keep Y to X.
>
> Changesets are a grouping of edits that make things easier because one
> only has to work with the groups - e.g. not show all individual edits,
> but show the group as a whole, etc.
>
> A changeset can only be rolled back as a whole. The rollback of a
> changeset leads to a new, "inverted" changeset that should be tagged
> in a way to express the fact that it is a rollback of changeset X.
>
> If you want to do partial rollbacks, then you don't need changesets at
> all - you might as well go with the already implemented "restore
> historic version" function in Potlatch.
>
> In that case you lose the changeset being rolled back - you do "some
> changes" but you don't do a "rollback of a changeset".
>
> It is fully ok for clients to use the history of individual objects to
> return them to any state they were in at some time before, like
> Potlatch does, but this has nothing to do with rolling back
> changesets.
>
> I'm a bit tired of this. I understand that you're unhappy about not
> having been at the hack-a-thon but can we perhaps now proceed with the
> work at hand instead of making an endlessley protracted discussion
> about every single aspect of the new API. (The longer this goes on,
> the more reason there is for those that will one day do 0.7 to *not*
> discuss things on the lists, citing this discussion as an example that
> nothing good comes of it.) Rollback and the retrieval of changeset
> data aren't even on the critical path, they can be implemented at
> *any* *later* *time* without changing the API. We don't have to find a
> solution today.
>
> You want changesets as some universal access and documentation method
> for the history of everything, and I want them as closed, near-atomic
> changes. I'd say the person who codes it gets to decide, but as I
> said, it doesn't even have to be decided now.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"
>
>
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
>