[OSM-dev] Minute Diffs Broken

[Brett Henderson]

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 
> 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.
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.