[OSM-dev] Minute Diffs Broken
frederik at remote.org
Tue May 5 02:17:11 BST 2009
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.
Frederik Ramm ## eMail frederik at remote.org ## N49°00'09" E008°23'33"
More information about the dev