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 _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
