[OSM-dev] Minute Diffs Broken

[Frederik Ramm]

Hi,

Brett Henderson wrote:
>> 3. Make a semantic change to the way we handle diffs: Let the diff for 
>> interval X not be "all changes with timestamp within X" but instead 
>> "all changes that happened in a changeset that was closed within X". 

[...]

> I think this would introduce far too large a delay.  What is the maximum 
> age of a changeset?  That is the delay that may occur between making an 
> edit and it appearing in replica databases.  

The maximum age is one day. I would not view this as a big problem 
though. For me, a changeset is like a change commit in version control 
system. I do not expect others to see my changes until I have committed 
them, and it would be perfectly fine for me if downstream mirrors did 
not see my changes until I close the changeset. (The difference between 
this and a VCS being obviously that direct queries to the main API would 
see my "un-commited" changes while downstream system would not yet have 
them but hey.)

> I don't think that would be 
> suitable for tiles at home and mapnik for instance. 

I don't see why these systems should show data from un-closes 
changesets. The way I like to think of changesets, this might even be 
misleading - think of someone deleting a road because he wants to 
re-draw it from a better GPX trace. I would of course do both inside one 
changeset called "replace road XY by better version", and when that 
changeset is closed, both the deletion of the old road and the new data 
will be propagated. With interim propagation, the old road will vanish 
from the map for a while and perhaps unnecessarily upset people.

If someone has an urgent change he wants shown quickly - then just close 
your changeset and you're fine.

> It would be simple to 
> implement though.  This was my original plan until I learnt that 
> changesets weren't going to be atomic.

You would effectively introduce atomic changesets for downstream systems 
this way. Not the worst thing to happen I'd say.

Bye
Frederik

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