[OSM-dev] 0.6 API clarifications and corrections

[Richard Fairhurst]

Dair Grant wrote:

> If an editor wants to monitor individual edits in order to provide  
> coaching
> or feedback to users, that's best done by watching user actions as  
> they
> 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"[1] editors like Potlatch where a changeset covers more  
than just one commit. See http://lists.openstreetmap.org/pipermail/ 
dev/2008-May/010346.html .

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  
http://lists.openstreetmap.org/pipermail/dev/2008-May/010354.html.)

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.

cheers
Richard

[1] anagram of "evil".... hmmm.