[OSM-dev] What should the changeset api do?

Frederik Ramm frederik at remote.org
Fri Oct 10 20:11:30 BST 2008


> I have a problem in some further implementation on what the changeset 
> controller should be doing, as the api page is just representing ideas. 
> I would much prefer to implement things knowing that's how the community 
> wants them, rather than how I think the community wants them.

Not sure what the community wants but if you care for my two cents - the 
changeset API needs to support basic CRUD stuff of course, then some 
sort of lifetime extension operation that is triggered by adding changes 
to it but might also be called on its own (e.g. an editor session still 
ongoing but not adding changes or so), and the changeset also has to 
track its own bounding box (i.e. whenever a change is added to the 
changeset, check whether that change is fully inside the current bbox 
and if not, extend; make sure to look at before and after state of the 
object being changed to determine bbox). Idea was to increase the bbox 
by a generous amount each time it has to be increased so that we don't 
have a write to the changeset table for each and every edit; too large 
bbox is not a big problem. Then of course the "list changesets" call 
that returns a list of changesets and should support *at least* a 
bounding box as parameter (give me all changesets that affect this 
bbox[*]), or even better also support a time range (before..., 
after...), and if you have fun you could also throw in filtering by 
user. Then the changeset can have any number of tags and they must be 
changeable as long as the changeset is still open.

Then there's the question of reading a full changeset (i.e. with changed 
objects) - should we have a call that gives you the before and after 
state of each object? Would be very usable for change monitoring I guess.

I'm not sure about the reverse lookup we need or do not need - how can I 
find out which changesets have affected Way #1234? Will this be 
contained in /api/0.6/way/1234/history? Or a new 

Phew. That's what you get for asking politely ;-) I find it excellent 
that you have made yourself the champion of 0.6 (it badly needed one). 
I'm very willing to chip in my part of coding but I'd need some guidance 
as I have lost track of what still needs to be done.


[*] such a call would probably simply test for intersection of the 
changeset bbox with the given bbox (some quadtile artillery required) 
and would thus return many false positives (make a change to Berlin and 
Madrid in one changeset and your bbox is half of Europe) but I guess 
that is acceptable for the moment and any alternative too expensive.

Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"

More information about the dev mailing list