Le sujet de la gestion des données géospatiales dans un sens plus général a déjà été évoqué ici. Le sujet de la gestion des versions a également été mentionné, mais pas vraiment traité.
La collecte et la maintenance des données géospatiales traditionnelles n'ont besoin que de gérer les versions en interne, car la base de données est uniquement mise à jour depuis l'organisation. Ce n'est pas le cas dans les géodatabases crowdsourcées comme OpenStreetMap. Là, tout le monde peut venir et ajouter, modifier ou supprimer des objets. Dans OpenStreetMap, cela est traité de manière rudimentaire: chaque objet a un numéro de version entier, et seul l'objet avec la version la plus élevée est exposé dans la base de données en direct. La base de données utilise un verrouillage optimiste, les utilisateurs doivent donc résoudre tous les conflits qui se produisent lors du téléchargement manuel des contributions.
Tout cela fonctionne assez bien tant que les contributions humaines via les éditeurs ( JOSM , Potlatch ) sont le seul mode de contribution - mais elles ne le sont pas. De plus en plus, des importations de données ouvertes sur le secteur public sont effectuées. Cela rend les problèmes de version plus complexes. Considérez le scénario suivant:
- Un objet de construction est importé à partir d'un ensemble de données du secteur public ouvert
- Le bâtiment reçoit quelques modifications par des contributeurs humains (attributs, géométrie, ou les deux)
- Une nouvelle version des données du secteur public devient disponible et est importée.
Actuellement, à l'étape 3. les contributions humaines seraient perdues, à moins que chaque bâtiment qui a reçu des modifications de la communauté soit fusionné manuellement avec la nouvelle importation.
Comment OpenStreetMap peut-il gérer cette situation? Faut-il considérer le contrôle de version distribué dans le développement logiciel? Comment les méthodes de DVC peuvent-elles être adaptées pour gérer la maintenance des données spatiales distribuées?