[OSM-dev] What should the changeset api do?
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