Mettre en œuvre un système de contrôle de version pour les données géospatiales? [fermé]

Non pas que j'aie immédiatement besoin d'une bonne réponse, mais j'ai récemment vu des efforts pour introduire le concept de "systèmes de contrôle de version (distribués)" pour les données géographiques. Quelques exemples (que je connaisse) sont les trois livres blancs d'OpenGeo ( 1 , 2 & 3 ) et le projet " Geosynkronisering (géosyncronisation)" des éditeurs norvégiens de logiciels SIG et de l'agence norvégienne de cartographie. J'ai également trouvé des versions distribuées de données géospatiales? , qui mentionne GeoGit (par OpenGeo), et Application du contrôle de version aux modèles ArcGIS ModelBuilder? sur le contrôle de version dans ArcGIS.

En tant que développeur, je sais (au moins assez pour pouvoir les utiliser) comment fonctionnent les systèmes de contrôle de version pour le code source (comme SVN et Git), et mon expérience en géomatique me dit qu'il y a des défis uniques avec les données géographiques qui rendent le approche pas complètement similaire à la façon dont le code source (qui est essentiellement du texte) est géré.

Quels sont les défis liés au (d) VCS pour les données géographiques, comment les résoudriez-vous, en avons-nous besoin et y a-t-il d'autres tentatives pour résoudre ces problèmes que celles que j'ai mentionnées?

Je sais que les livres blancs d'OpenGeo répondront à certaines de mes questions, mais ce que je recherche vraiment, c'est une réponse plus "pédagogique", dans le style de "dis-moi comme si j'avais 10 ans", de sorte que Je peux orienter les gens vers une excellente explication des défis et des solutions que les données géographiques apportent au mélange.

J'espère que quelqu'un avec un peu de perspicacité prendra le temps de faire quelques réflexions sur la question, car j'ai dit que je ne cherche pas actuellement à résoudre un problème particulier, mais ce sujet est celui qui m'intéresse.

Nous travaillons actuellement sur une refonte complète de nos géodatastores. Je dois dire que leur évolution a duré plus de 20 ans jusqu'à présent. Nous avons identifié les principales caractéristiques suivantes dans la gestion des données géospatiales:

• montage simultané
• autorisations de lire ou d'écrire des parties de données
• mise à jour à chaud lors de l'exécution de services qui s'appuient sur des données (transactions et paradigme ACID)
• schéma interne et externe (la modification du schéma interne ne devrait pas affecter les services)
• possibilité de stocker et d'accéder à de grandes quantités de données (téraoctets de raster et centaines de gigaoctets de données vectorielles)
• cohérence des données entre les différentes couches (chaque parcelle appartient à un district, etc.)

Nous avons évalué les approches suivantes, voici ce que je peux en dire:

1. Géodatabase ESRI Enterprise(ArcGIS 10.1); à peu près le même que ce que nous avions avant (SDE), mais avec une utilisation intensive de la fonction de gestion des versions pour gérer les transactions. Mais ce n'est tout simplement pas vraiment une géodatabase d'entreprise, à mon avis, SDE ne fonctionne que dans un groupe de travail en tant que serveur de géodonnées, où les gens travaillent de 8h00 à 20h00, et vous pouvez le mettre hors ligne pour les tâches de maintenance, validation de transaction (réconciliation des versions et publication dans le discours ESRI), réplication, etc. Si vous créez des services au-dessus de ces données, vous devez gérer une base de données intermédiaire (où le travail est effectué) et une base de données de production répliquée. C'est à peu près la même chose que construire / tester et déployer dans la programmation. Bien que le package riche en fonctionnalités qu'ESRI offre soit assez agréable, il manque de flexibilité (changements de schéma ou tâches de maintenance pendant que les gens travaillent, création d'index par exemple).

2. Fichiers plats et système de contrôle de versionnous choisissons Git (ne savait pas qu'il existe déjà un GeoGit). Oh oui, certains de mes amis et moi-même venons aussi du génie logiciel. Tout pourrait être si simple. Je pense que c'est son problème: c'est comme un mécanicien automobile qui construit une voiture. Ce sera simple à entretenir pour lui, mais ce sera aussi ennuyeux à conduire et sacrément laid à regarder à coup sûr. Je pense que cela a aussi quelques inconvénients majeurs: Comment contrôler la version d'un Rasterdataset 2 TeraByte (ou même plus, binaire)? Et dans quel format? Les données vectorielles peuvent être facilement contrôlées par la version si vous utilisez des formats basés sur du texte (GML par exemple), mais il est également difficile de travailler avec un jeu de données d'un milliard de lignes. Je ne sais toujours pas si nous pouvons gérer efficacement les autorisations des utilisateurs, car tout le monde ne devrait pas être autorisé à tout modifier ou même à tout afficher. Et comment fusionner un jeu de données vectorielles qui a été édité de manière intensive par 4 utilisateurs en même temps? Au moins, vous devez être un véritable informaticien / programmeur pour faire tout cela efficacement ... nos utilisateurs SIG sont des planificateurs, des géomètres, des géologues, etc. C'est tout simplement un problème pour eux de penser aux lignées de versions comme le font les programmeurs, ou d'utiliser les branchements comme il est censé le faire. Néanmoins, penser les banques de données comme des référentiels partagés est une idée intéressante.

3. Base de données à plat comme simple conteneur. La même chose que SDE le fait, mais sans les trucs SDE. Difficile à maintenir, car vous ne profitez pas des avantages d'un SGBDR. Oui, c'est très simple de tout charger dans une base de données, mais ce n'est pas du tout la gestion des données.

4. Bigdata et NoSQL . Mêmes problèmes que les fichiers plats et les tables plates. À mon avis, une API de système de fichiers simple à utiliser sur le Web. Oui, cela fonctionne bien sur le Web, et oui, il est facile de simplement jeter vos documents, mais je pense que si je veux effectuer une analyse des données spatiales sur des téraoctets de données (éventuellement raster), j'aime qu'il ne soit pas sérialisé et désérialisé sur l'interface HTTP.

MISE À JOUR 2018: Voici beaucoup de nouvelles choses créant beaucoup d'élan. Pour n'en nommer que quelques-uns:

• Stockage en mode cloud et HDFS
• Python / galbé / Dask Stack

• Apache Spark

  • GeoMesa / GeoWave pour les données vectorielles
  • GeoTrellis pour les données raster

• et beaucoup plus

  5. Modélisation de base de données classique complète(avec un SGBDR). Le principal problème est qu'il est difficile de simplement déposer des données n'importe où et d'espérer qu'elles correspondent à tous les besoins futurs. Mais si vous mettez du temps à spécifier un modèle de données robuste (OSM l'a également fait en fait) dans une base de données, vous êtes en mesure de profiter de tous ses avantages. Nous pouvons éditer et mettre à jour des données dans des transactions distribuées, nous pouvons également modifier leur schéma de base, tandis que les services s'appuient toujours sur des schémas externes des mêmes données, nous pouvons les maintenir, nous pouvons vérifier leur cohérence, nous pouvons autoriser et refuser des autorisations, nous sommes capable de stocker de très grandes quantités de données alors que nous pouvons toujours y accéder rapidement, nous sommes en mesure de construire des modèles de données d'historisation et de les déclencher de manière transparente, etc. Parce que nous utilisons le serveur SQL, il nous manque toujours un type de raster natif, mais d'autres fournisseurs de bases de données le proposent déjà.

Eh bien, je pense que le modèle de base de données relationnelle vient de faire son apparition dans le monde spatial avec des types de données spatiales au cours des deux dernières années (avant cela, il contenait BLOB Containers) et est toujours la forme la plus flexible et professionnelle de stockage de données. Cela ne signifie pas qu'il ne devrait pas être complété par des approches VCS ou NoSQL, mais je vois ces approches plus probablement comme une forme de distribution de données dans des groupes d'utilisateurs que comme une forme de gestion professionnelle centralisée des données spatiales. OSM a également centralisé de nombreuses tâches, que la foule ne peut tout simplement pas fournir, comme l'importation de grandes quantités de données (la plupart des données OSM en Autriche ont été importées en une journée, pas de crowdsourcing) et la génération de tuiles. La partie collaborative (crowdsourcing) est certes très importante, mais ce n'est que la moitié de l'activité.

Je pense que je dois reformuler beaucoup de cela et fournir plus de faits. Il est difficile de répondre à une question comme celle-ci en quelques heures, j'essaierai d'améliorer la qualité de ma réponse les prochains jours