[OSM-dev] What should the changeset api do?
shaun at shaunmcdonald.me.uk
Sat Oct 11 15:24:49 BST 2008
On 11 Oct 2008, at 01:14, Matt Amos wrote:
> On Fri, Oct 10, 2008 at 8:11 PM, Frederik Ramm <frederik at remote.org>
>> Idea was to increase the bbox
>> by a generous amount each time it has to be increased so that we
>> have a write to the changeset table for each and every edit; too
>> bbox is not a big problem.
> as a later optimisation we can always contract the bbox when the
> changeset is marked closed.
Alternatively if we state that a changeset is private until it is
closed, and has a limited life, then you could simply calculate the
bbox on closing of the changeset. This would also minimise the
processing. We could always use the tile codes, such that changeset
234 is in tiles 3452, 3453, 3456.
For the generation of the bbox we need to get a list of all the nodes
that are affected by the change (including those referenced through
way, relations and relations via ways, then get the min/max latitude/
longitude for that list. Sounds like a variation on the map request.
>> Then there's the question of reading a full changeset (i.e. with
>> 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
> it would be nice to have a call on a changeset which returns a
> reversible diff. is it worth thinking about extending osmchange format
> so that modify elements contain both before and after elements?
One problem we have at the moment, is that the changeset determines
the after state. You can assume that changeset.version-1 is the
previous version. However I'm sure we're not meant to assume that a
>> 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
> all elements in the history should have a changeset_id attribute,
Any time a node/way/relation is returned by the API, it will contain
the changeset and version in addition to what is currently returned.
Currently it is really easy to get the after state of every single n/w/
r (though not currently implemented through the api). However the
previous version is not referenced, so you have to deduce that since
the new version will be old_version+1, that the prior version is
More information about the dev