On Sat, Oct 11, 2008 at 3:24 PM, Shaun McDonald <[EMAIL PROTECTED]> 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 _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
