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

Frederik Ramm frederik at remote.org
Sun Oct 12 00:32:51 BST 2008


Matt Amos wrote:
>> 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?
> well, changesets would - they'd bound all of the nodes, so a point in
> the centre of an area would hit the bounding box, but it might not hit
> all the tile codes of the circular ways. its not a massive problem,
> but we should be aware of all the pros and cons.

I would suggest to provide an API call where you can submit a bounding 
box and ask for all changesets that somehow "may" have something to do 
with the bounding box.

The caller would be advised that due to indexing restrictions it might 
be possible that he receives a number of changesets which don't actually 
have edits inside the area specified (just surrounding it somehow) and 
that further processing on his part is required. The caller can assume 
that the smaller a changeset's bounding box, the more relevant that 
changeset is likely to be for him.

We could then operate with a very simple bbox technique at first, and 
later seamlessly upgrade the rails code to do better filtering/indexing 
if it turns out that most of these requests return 95% useless material. 
That would then, however, not require any change in the clients or the 
API spec.

>> That would require getting the history for every item in the changeset,
>> which I thought is what we are trying to avoid.
> yeah, maybe its worth having a previous_version column in
> current_(nodes|ways|relations) for efficient lookup?

Mh. *That* would always be version-1 (version is auto-incremented on 
every update).


Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"

More information about the dev mailing list