On 11 Oct 2008, at 15:57, Matt Amos wrote: > 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.
When I said changesets are private, I meant that when you do a call to api/0.6/changeset/:id, you will get a 403 forbidden until the changeset is closed. The data would still be returned by the api, just you wouldn't be able to see everything else that is in that changeset. Should the changeset be shown if the user is anonymous? > > > 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... Do we deal with areas properly anyway? If you download a bbox and a way crosses the corner of it, with now node inside it, then it isn't downloaded. Should this be any different? Maybe we need to re- introduce that area type? > > >> 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. 8-) > > >>> 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. I'm thinking about the implementation of showing before and after states here. > 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 :-) > That would require getting the history for every item in the changeset, which I thought is what we are trying to avoid. > cheers, > > matt _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
