[OSM-dev] OsmChange format and 0.6

[Brett Henderson]

Matt Amos wrote:
> well, in the same way its not possible to create a node, way or
> relation with a specific id via the API. replication to a read-write
> server (like svn up) is going to be A Difficult Problem.
>   
Oh, yes.  I was thinking it was only a problem for changesets but you're 
right, it's an issue for all data types.  So yes, replication via the 
API appears impossible at the moment :-)

But you bring up an interesting topic in replication to read-write 
servers.  A while ago I was hoping to take a look at this but I doubt if 
I'll ever get to it.  It would be a fantastic capability in many 
scenarios.  The main one I'm interested in is disaster response but it 
would also be useful for mapping parties without full-time 
connectivity.  I'd love to see it implemented, but I agree it is A Very 
Difficult Problem.

Below are some random thoughts in case people are interested.

Where I ran into this was during the Myanmar Cyclone disaster where some 
local guys were attempting to set up a local OSM server.  Connectivity 
was only available in central areas, and even then was very 
intermittent.  It would have been great to allow edits to be performed 
against a local server, with regular synchronisation to the main OSM 
server.  With existing tools their only real option was to edit locally 
using JOSM then upload when connectivity became available.  That is 
fairly limiting though because the only way of getting data out of JOSM 
and onto map renderers, GPS devices, and other JOSM instances is via a 
round trip to the central OSM server.

The problem has many parallels to source code management as you've 
pointed out.  Using subversion as a guide may be helpful.  It may also 
be helpful to understand other source control systems such as ClearCase 
MultiSite (which I have some experience with) and git (which I have no 
experience with).  From what I can remember, ClearCase MultiSite uses 
branches with ownership locks to prevent concurrent edits.  A simple 
example is where two sites exist with two independent dev teams.  Each 
dev team works on their own branch.  The two ClearCase servers are 
connected and can replicate all their changes to the other server.  But 
each branch can only be modified at one site (ie. by one server) at a 
time.  The way of synchronising the branches (and thus seeing the 
changes made by the other dev team) is by merging the changes from the 
other teams branch (which is read-only at your site) into your branch 
(which is writeable at your site).  The other team goes through a 
similar process to see your changes.  Without thinking this too far 
through, it might be possible to do something similar in OSM.  The 
master OSM server would always be the master of the "trunk" branch.  
Local servers would in effect be managing their own branch and would 
allocate their own entity ids but would have a read-only view of data in 
the main OSM database.  The two-way merge would be the process of 
uploading local changes to the central OSM server, and introducing 
central OSM edits into your local replica.  It would be necessary to 
maintain a mapping between ids on the two servers.  In our case the 
local server would be the one to maintain the mappings between id sets 
because the central server could not know about all the local dbs in 
existence.  Perhaps the most complicated bit would be to allow edits to 
be visualised and merged where conflicts occur, but perhaps the layer 
support in JOSM could provide some assistance there.  The merge would 
always require manual intervention, but if the local region of interest 
is small it may be manageable.  Anyway, that's about as far as I've 
gotten.  It's firmly in the too-hard basket the moment, the more I think 
about it the harder it seems :-)

Anyway, back to some real work.

Brett