[OSM-dev] 0.6 API clarifications and corrections

bvh bvh-osm at irule.be
Thu May 15 10:42:03 BST 2008

On Thu, May 15, 2008 at 11:31:13AM +0200, Frederik Ramm wrote:
> >> Under the current plan, yes. We didn't think it was reasonable to
> >> push that assumption down to the clients thought.
> > Why would that be unreasonable? In what (futuristic) scenario would
> > version numbers not increment monotonically one by one?
> In the current scenario, you are basically not allowed to upload a new 
> version of an object if you haven't got the previous version.
> This is unnecessarily strict.
> For example, two people could download version 1 of a node; one adds the 
> foo tag, another adds the bar tag, both upload. With the plans for API 
> 0.6, one of the uploads will simply fail.
> In theory, both uploads could be accepted without conflict, and we would 
> then have one change that goes from v1 to v2, and one change that goes 
> from v1 to v3.

But one of them will be accepted first and the other will later
be judged as sufficiently different, right? So the actually history
in the database will have two transitions, one from v1 to v2 and
the other from v2 to v3.

> It is also possible to change the same object multiple times within the 
> same changeset, so one single changeset might catapult the object 
> version from 1 to 15.

Wouldn't it be better then to just throw away consecutive changes to
the same object and only keep the last one within each diff?

cu bart

More information about the dev mailing list