[OSM-dev] Why are so many changeset so large?

[Paweł Paprota]

On 10/17/2012 03:30 PM, Andy Allan wrote:
>
> Basically, I see no need to worry about the extent of bounding boxes,
> and no need to move to having bboxes on uploads instead of changesets
> or other complications. No matter what we do, if your interest in a
> changeset extends beyond the details of its extent, you need a
> mechanism (again, e.g. OWL) to detail the actual locations of the
> edits to the entities, and different interests (and different
> entities) will have even have different buffers of interest around
> them. Lets focus on things like that.
>

Exactly. What I do right now with the Activity Server is I store the 
whole geometry of a changeset. When a bounding box query comes, I use 
ST_Intersects between the bbox and geometries. This has the desired 
effect you write about: that is, with a changeset that contains changes 
in Sydney and in Canada, you will only get it in the query result for 
those two places, not for anywhere in the world like it is right now in 
the History tab.

I am bit concerned about scalability of this, Matt clearly stated in one 
of the earlier discussions that dumping every changeset to one table 
won't scale.

I'm now looking to dig into OWL's code and see how my work relates to it 
- I think it potentially could make sense to somehow bring the two 
projects together or at least integrate them at some level (OWL 
publishing activities to the Activity Server?).

Paweł