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

[Shaun McDonald]

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>  
> wrote:
>> 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.
>
> 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  
>> 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.
>
> 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  
new version=old_version+1.

>
>
>> 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
>> /api/0.6/way/1234/changesets?
>
> all elements in the history should have a changeset_id attribute,  
> right?

That's correct.

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  
version-1.

Shaun