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

Matt Amos zerebubuth at gmail.com
Sat Oct 11 15:57:40 BST 2008


On Sat, Oct 11, 2008 at 3:24 PM, Shaun McDonald
<shaun at shaunmcdonald.me.uk> wrote:
> On 11 Oct 2008, at 01:14, Matt Amos wrote:
>> 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.

since changesets are non-atomic, couldn't that lead to a case where
elements committed, but linked to a private changeset, are returned in
a map request? then either "private" data is leaked, or the map
response would be incomplete.

using tile codes is an interesting idea - it means that a changeset
containing small edits in alaska and australia wouldn't need to cover
the whole world. however, finding the all the tile codes of a way
means inspecting the tags to find out if its an area...

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

yep - it'd have to be the same basic queries with the initial node set
provided by the changeset, rather than a bbox, and adding in all the
extra ways and relations at the appropriate points in the query.

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

providing the before & after in modify would give both version
numbers. in the api request only the after version is used for
optimistic locking.

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

the previous version number appears in the history, though, so it is
possible to get this information with a single api call - no
deductions are necessary :-)

cheers,

matt




More information about the dev mailing list