[OSM-dev] 0.6 API clarifications and corrections
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.
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
More information about the dev