[OSM-dev] Minute Diffs Broken
brett at bretth.com
Tue May 5 02:36:05 BST 2009
Frederik Ramm wrote:
> 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
> 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.
I'm fairly uncomfortable with this approach. It could be very
confusing. But I'm prepared to be swayed, it is certainly simple :-)
Also, there's a potential flaw with this approach. Lets say I create
node 100 with version 1 in changeset 10 in Potlatch and leave my
changeset open. You then come along with JOSM and edit node 100
creating version 2 within changeset 11 and close your changeset
immediately. Osmosis will pick up changeset 11 after 5 minutes and
distribute node 100 version 2. A day later Osmosis will pick up
changeset 10 and distribute it node 100 version 1. Downstream systems
consuming those diffs would apply the wrong version of the node to their
database. One way around this might be to force all consumers to check
the version id before applying changes but this is not done currently to
the best of my knowledge, at least osmosis doesn't.
More information about the dev