[OSM-dev] 0.6 API clarifications and corrections

Frederik Ramm frederik at remote.org
Thu May 15 13:20:42 BST 2008


> I think it is the client who should filter what to present to the
> user. The response of the database should be as complete as possible,
> including sending intermediate states.

I disagree.

If you wanted "raw" access, then you can have it - just download the 
history of every object. You can do that even now.

Changesets are introduced to lessen the complexity. We want "one big 
edit", ideally associated with a comment where the user says what he 
meant to achieve with this edit.

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

Once a changeset is complete, we should view it as atomic (even if it 
was created in an atomic fashion). Changeset No 1234 changed object A 
from state X to state Y - that's what a changeset should represent.

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.


More information about the dev mailing list