The topic of managing geospatial data in a more general sense has come up before here. The topic of versioning was mentioned there as well, but not really dealt with.
Traditional geospatial data collection and maintenance only need to deal with versioning internally, as the database is only updated from within the organization. This is not the case in crowdsourced geodatabases like OpenStreetMap. There, anyone can come along and add, modify or delete objects. In OpenStreetMap this is dealt with in a rudimentary way: each object has an integer version number, and only the object with the highest version is exposed in the live database. The database uses optimistic locking, so users must resolve all conflicts that occur when uploading contributions manually.
This all works reasonably well as long as human contributions through the editors (JOSM, Potlatch) are the only mode of contribution - but they aren't. Increasingly, imports of open public sector data are conducted. These make for more complex versioning issues. Consider the following scenario:
- A building object is being imported from an open public sector dataset
- The building receives some modifications by human contributors (attributes, geometry, or both)
- A new version of the public sector data becomes available and is imported.
Currently, in step 3. the human contributions would be lost, unless each building that received community modifications is manually merged with the new import.
How can OpenStreetMap deal with this situation? Do we need to look at distributed version control in software development? How can methods of DVC be adapted to deal with distributed spatial data maintenance?