Satellite API Instances

Satellite API Instances is an idea which has often been discussed. This is a brainstorming page. As far as actual implementations go, perhaps POSM is the closest we've come (The edit merging feature is described in this blog post)

The idea is to code something which offers the ability to have an offline instance of the OpenStreetMap database and API able to resync/replicate (2-way) with the central OpenStreetMap instance.

This is needed for use in remote locations, especially for Humanitarian operations, where connectivity is erratic yet the local service needs to be reliable

Field workers come back to their office with a GPS full of Tracks & Waypoints which they want to quickly dump along with a set of notes. An administrator will use these to create an updated basemap (including Contours) which is then downloaded onto each GPS unit & the waypoints data wiped (since the data is searchable using the POIs in the basemap).

The software should be configured as a Virtual Machine containing PostGIS, Rails port, iD/Potlatch2, Sahana, mkgmap, Osmosis, Mapnik.

We imagine most of the edits to be done using iD/Potlatch2. If *all* edits are done in this way, then simple negative IDs can be used. However if we allow offline editors to be used on this offline instance then we need a more complex scheme to handle this (add the server instance into a hash? Allocate pools of IDs?). We can use an Osmosis plugin to convert our non-std system to the std system in central db if necessary, however we don't want to maintain diffs of clients like JOSM.

• I don't see why which editor you use in the satellite instance makes any difference to anything - either way you are going to wind up with objects created locally whose IDs conflict with the main server and are going to have to resolve those conflicts somehow. TomH 16:16, 23 November 2010 (UTC)

• If using Potlatch2 then there is only 1 level indirection, so the initial IDs can be replaced by the central/final ID after replication. If using JOSM there are 2 levels of indirection & things get messy if the local server changes it's IDs in the middle of a JOSM editing session. FranBoon

• Potlatch does cache downloaded data as well you know - only as long as the applet is running sure, but it is still caching it. I think you will need to maintain a persistent mapping between local and remote IDs and give new objects from the main database a different ID in the mirror. TomH 16:37, 23 November 2010 (UTC)

Replication conflicts should be skipped to allow other edits to proceed - thus allowing just the few

The edits in the main DB can be set as coming from a generic account (e.g. oxfam-haiti)

• This is discouraged - best practice is for all edits to be properly attributed to their author. TomH 16:16, 23 November 2010 (UTC)

• Anything which makes the system more fragile in a situation of high staff turnover & low access to technical support/training is to be highly discouraged. FranBoon