Gérer de grandes quantités de données géospatiales? [fermé]

Comment gérez-vous vos données géospatiales? J'ai des téraoctets de données réparties sur des centaines de jeux de données et une solution ad-hoc utilisant des liens symboliques au sein de projets qui renvoient à un répertoire d'archives basé sur le nom de domaine pour chaque jeu de données. Cela fonctionne principalement, mais a ses propres problèmes.

Je suis également désireux de savoir si quelqu'un gère ses données géospatiales dans un système de contrôle de révision; J'utilise actuellement un pour mon code et petits jeux de données, mais pas pour les jeux de données complets.

Je pense que la réponse évidente serait d'utiliser une base de données spatiale (PostGIS, Oracle, SDE, MSSQL Spatial, etc.) en conjonction avec un serveur de métadonnées tel que GeoPortal d'esri ou l'application open source GeoNetwork. la meilleure solution. Cependant, vous aurez probablement toujours besoin d’instantanés, de branches et de balises basés sur des projets. Certaines des bases de données les plus avancées ont des moyens de les gérer, mais elles ne sont généralement pas si faciles à gérer.

Pour les éléments que vous stockez en dehors d’une base de données (images volumineuses, fichiers basés sur un projet), je pense qu’il est essentiel d’avoir une convention de dénomination cohérente et, encore une fois, un registre de métadonnées (même quelque chose de low-tech comme un tableur) qui vous permet de les suivre et de les suivre. assurez-vous qu'ils sont correctement gérés. Par exemple, dans le cas de fichiers basés sur un projet, cela peut signifier de les supprimer lorsque la politique de gestion des enregistrements le spécifie ou de les insérer dans le référentiel central à la fin du projet.

J'ai vu des solutions intéressantes cependant ...

À l'époque où le ministère de l'Environnement de la Colombie-Britannique utilisait des couvertures Arc / Info, il disposait d'un processus de synchronisation bidirectionnel vraiment cool basé sur rsync. Les couvertures qui étaient sous contrôle central ont été repoussées vers les régions chaque nuit et les données régionales ont été repoussées. Ce transfert différentiel par bloc a très bien fonctionné, même avec plus de 56 000 liens. Des processus similaires ont été utilisés pour répliquer les bases de données d'attributs basées sur Oracle, mais je ne pense pas qu'ils se soient trop bien comportés après une connexion commutée :)

Mon lieu de travail actuel utilise une solution hybride similaire. Chaque jeu de données a sa copie faisant autorité (certaines dans Oracle, d'autres dans MapInfo, d'autres dans des géodatabases personnelles) et celles-ci sont multi-ETL'd nocturnes à l'aide de FME. Cependant, il y a des frais généraux assez importants en matière de maintenance; les efforts visant à créer de nouveaux jeux de données et à assurer une visibilité organisationnelle sont considérablement plus élevés que prévu. Nous sommes en train de procéder à un examen dans le but de trouver un moyen de procéder à une consolidation pour éviter ces frais généraux.

Les métadonnées sont de loin le problème le plus important ici. Si les métadonnées répondent à qui, quand, pourquoi, où est un enregistrement de métadonnées acceptable.

Ayant une expérience professionnelle dans de grandes entreprises avec seulement quelques utilisateurs de SIG (environ 30), nous avons eu de gros problèmes pour contrôler les données, spécialement les versions et les autorisations. Un des problèmes peut être résolu grâce à une documentation détaillée des données (métadonnées) et les autres problèmes sont probablement résolus avec un référentiel central, dans lequel PostGIS se démarque.

GeoNetwork est un bon début pour gérer les problèmes de métadonnées. La résolution du référentiel central est plus compliquée, car la conception / maintenance de la base de données peut nécessiter l'intervention d'une personne spécialisée.

La question complexe est de savoir qui sera responsable de l'AQ / CQ pour ces ensembles de données et leurs métadonnées. Bien que les processus pilotés par ordinateur fonctionnent bien, ils ne peuvent pas être aussi rigoureux qu'un bon gestionnaire de données / archiveur de données, ce qui a été fait dans cette entreprise dans laquelle j'ai travaillé. Maintenant, il y a quelqu'un exclusivement là-bas pour examiner / valider les métadonnées et organiser les données géospatiales qui ne sont pas centralisées dans un SGBD.

Nous avons utilisé un système de fichiers organisé hiérarchiquement par: - étendue géographique (pays ou continent) - fournisseur de données, donneur de licence - domaine / ensemble de données - date / version

Après cela, nous avons pour politique de séparer les données source (dans le même format que sur n'importe quel CD / DVD fourni par le fournisseur) des jeux de données dérivés que nous avons produits au sein de notre société.

Le système de fichiers facilite l'ingestion des données du client et offre également une certaine flexibilité en termes de stockage physique - nous conservons nos archives sur des disques plus gros et plus lents, et nous disposons de serveurs de fichiers spéciaux (liés de manière transparente à la hiérarchie). les jeux de données les plus fréquemment utilisés.

Pour faciliter la gestion au sein des projets, nous utilisons des liens symboliques. Nous conservons nos vecteurs dans une base de données (Oracle) et nous avons pour règle d’avoir au moins une instance de base de données par client (et plusieurs utilisateurs / schémas pour les projets). Nous n'avons pas gardé beaucoup de rasters dans une base de données, car ils ont tendance à prendre trop de place, même en dehors de celui-ci. Nous souhaitons également que nos instances de base de données soient aussi légères que possible.

Et oui, nous avons quelqu'un qui est chargé de «contrôler» le tout pour que cela ne soit pas trop compliqué.

Le problème le plus important que nous ayons avec cette configuration est actuellement l’absence d’une interface utilisateur agréable qui nous aiderait à avoir une meilleure vue d’ensemble, et nous avons prévu d’inclure un stockage de métadonnées au-dessus de tout cela. Nous envisageons toujours nos options ici.

Nous utilisons le contrôle de version pour notre code et nous l'avons utilisé pour les documents, mais il s'avère que le contrôle de version n'est pas vraiment conçu pour les grands ensembles de données, en particulier s'il s'agit principalement de fichiers binaires. Je ne le recommanderais donc pas. , sauf si vous utilisez du GML ou un format similaire (les problèmes incluent des frais généraux énormes liés à l’utilisation du disque côté serveur ainsi que le blocage des clients lors de l’exploration de référentiels énormes).

Comme @JasonBirch l'a dit, le contrôle de version est un énorme problème.

Nous avons également constaté qu’un flux de travail approprié est extrêmement important. Par exemple, lorsque nous collectons des données de terrain, nous avons tendance à utiliser des bases de données intermédiaires dans lesquelles les données de terrain peuvent être soumises à un contrôle de qualité avant d'être fusionnées dans le jeu de données maître. En fonction de la quantité de données devant être contrôlée, cela engendrera toujours des frais généraux.

De plus, si vous ne l'avez pas déjà vu, je vous recommande de jeter un coup d'œil au livre électronique sur la géo-communication et la conception de l'information de Lars Brodersen, du moins pour ce qu'il a dit sur la modélisation des données.

Postgres comme d'autres l'ont déjà dit, mais si vous voulez rester portable et facile à déplacer, vous pouvez toujours utiliser SQLite + l'extension Spatialite.

Pas aussi facile à utiliser que Postgres en termes d’outils de gestion, mais QGis peut communiquer directement avec une base de données SIG compatible avec spatialite.

En fait, j'utilise SQLite + Spatialite pour la sauvegarde. J'ai un service Windows qui s'exécute en arrière-plan (écriture personnalisée) qui surveille mon instance PGSql et reflète mes données SIG dans diverses bases de données SQLite résidant sur des lecteurs USB externes.

Encore un conseil avec PG, utilisez des schémas

Je sais que beaucoup de gens abandonnent tout en public et finissent avec cela, mais si vous organisez correctement votre base de données, le monde de la différence en sera grandement amélioré.

Par exemple, ma base de données "Ordnance_Survey" contient des schémas pour VectormapDistrict VectormapLocal Topo50 LookupGrids CodePointWithPolygons CodePointOpen

où je garde toutes les données associées.

Pendant ce temps, les tables de métadonnées, telles que les colonnes de géométrie, etc., ne résident que dans Public, l'extension Postgis est également activée uniquement sur le schéma public, mais est accessible à partir de tous les autres schémas utilisés.

Comme mentionné dans l'article précédent, une base de données spatiale et un serveur de métadonnées constituent la configuration habituelle. Je pense qu’un élément clé à retenir est qu’une «taille unique ne convient pas à tous». Vous obtiendrez des données qui conviennent le mieux à Oracle, aux serveurs de fichiers, au serveur SQL, peu importe. J'ai essayé de regrouper tous les besoins en données dans une solution unique, qui échoue généralement.

Attendez-vous à utiliser différentes solutions qui correspondent aux données et planifiez-les. C’est là que le Geo-portail (serveur de métadonnées) entre vraiment.

Je suis d'accord avec "George" plus haut que les métadonnées devraient jouer un rôle important dans la gestion des données géospatiales. Vraiment, quelles que soient les données numériques, les métadonnées sont essentielles: imaginez un photographe qui tente de gérer ses fichiers photo numériques sans les métadonnées appropriées. La vie devient tellement plus facile si vous étiquetez des objets avec religion et utilisez un bon logiciel qui peut utiliser les données. Maintenant, la question initiale à propos de «gérer les données géospatiales» est assez large: il peut s'agir de formats de données à stocker, de conventions de dénomination, de hiérarchie de jeux de données et d'entités, de rôles d'édition et de privilèges, etc.

Le modèle de stockage des données géospatiales dépend de la manière dont vous souhaitez l'interroger / de ce que vous voulez en faire. Voici quelques outils que vous pouvez envisager:

Postgres + PostGIS: prend en charge les index géospatiaux et toutes sortes de requêtes imaginables. Pour gérer vos téraoctets de données, vous devez appliquer le sharding, l'optimisation des requêtes, etc. Si votre charge d'écriture est importante, je ne le recommanderais pas.

MongoDB: Ceci supporte de grandes quantités de données. Idéal pour le stockage simple, la récupération et les requêtes géospatiales limitées.

Stockage de fichiers: si vous n’êtes qu’un système d’archivage et que vous n’utilisez qu’une partie des données pour interroger, il peut s'avérer économique de stocker vos données sous forme de fichiers. Vos exigences en matière de contrôle de version pourraient bien être satisfaites.

Redis: vous pouvez combiner l’une des options ci-dessus avec le support Redis Geo pour stocker dans Redis une petite quantité de données «chaudes» auxquelles vous devez accéder fréquemment. Pensez à cela comme votre cache.