[OSM-dev] 0.6 API clarifications and corrections
richard at systemeD.net
Fri May 16 10:35:36 BST 2008
Dair Grant wrote:
> If an editor wants to monitor individual edits in order to provide
> or feedback to users, that's best done by watching user actions as
> happen and providing feedback based on that (recording that info in
> the DB
> for every action for every user is pointless, as who would ever
> really go
> back and process it?).
This discussion seems to have gone a bit bizarre.
The initial issue, unless I've got confused somewhere along the way,
was for "live" editors like Potlatch where a changeset covers more
than just one commit. See http://lists.openstreetmap.org/pipermail/
So saying "recording that info in the DB for every action for every
user" isn't the issue - we already do that.
Frederik wants, AIUI, the server to deliver such a changeset in just
its final form, collapsing all the intermediate edits into one. (See
I disagree, largely because it seems a shame (and "non-OSM") to
impose a certain model on rollback clients when we don't yet know how
they'll be used. There may be circumstances - some we know already,
some we haven't thought of yet - where the extra information is
necessary. One example that springs to mind is that splitting and
joining ways are common user operations that have to be "interpreted"
by the editor (there's no dedicated API method for either) and
frequently result in editing mistakes. Having the intermediate
changes visible could help a rollback client interpret these, thereby
helping its user to see what mapping error occurred, if it was
designed to do so. (Frederik thinks this is best catered for by using
the existing history features, I think. I can see some logic in that,
but there might need to be some additional API work to make the
linkage between atomic history and changesets more explicit.)
Bart disagrees, too, but has other reasons. Ultimately, of course, he
who commits the code has the final say.
 anagram of "evil".... hmmm.
More information about the dev