Qu'est-ce qu'une bonne taxonomie ou convention de dénomination pour les fichiers et dossiers contenant des données SIG? [fermé]

Mon entreprise a collecté environ 30 To de données SIG au cours des 8 dernières années, et je me retrouve toujours à poser les questions suivantes:

1. De quel type de données disposons-nous pour une zone géographique donnée?
2. Quels sont les détails de ces données (par exemple, la résolution en mètres par pixel)?
3. Où les données existent-elles sur le disque dur pour que je puisse réellement les utiliser?
4. Avons-nous déjà traité les données, ou est-ce sous une forme inchangée à partir de la source?

Jusqu'à maintenant, j'ai essayé de répondre à ces questions en concevant un dossier et un fichier de taxonomie / hiérarchie appropriés. Quelqu'un a-t-il des idées / suggestions sur des façons compréhensibles, voire standard, d'organiser les données SIG à l'aide de fichiers et de dossiers?

Je suis également disposé à en savoir plus sur les avantages de l'utilisation d'une base de données pour mon entreprise; nous sommes des développeurs de logiciels, pas des experts SIG, donc je soupçonne que nous sommes un peu en retard sur la meilleure façon d'aborder le problème du stockage / de l'organisation des données SIG pour la facilité d'utilisation. J'ai vu la question Meilleures pratiques pour la gestion des données géospatiales, mais je n'ai pu tirer qu'une utilisation marginale des réponses parce que je ne suis pas familier avec les géodatabases.

MISE À JOUR: La semaine dernière, j'ai passé pas mal de temps à lire sur les bases de données SIG et j'ai commencé à me familiariser avec PostGIS. À long terme, je pense que nous finirons par évoluer vers l'emploi d'une base de données et d'un serveur de métadonnées, comme l'a recommandé JasonBirch dans Meilleures pratiques pour gérer les données géospatiales .

Si vous essayez réellement de modifier des données ou de développer une carte, vous devrez garder les données sur lesquelles vous travaillez activement distinctes des données avec lesquelles vous avez commencé. Lorsque je démarre un projet, je crée un dossier SourceData, avec des sous-répertoires nommés par le type de données (DEM, Orthophoto, Hydrologie, etc.) Cela contiendra toutes les couches que j'utilise simplement comme référence. Toutes les données sur lesquelles je travaille seront copiées dans un autre dossier appelé Working. Le dossier de travail contient des données, des MXD et tout ce que je modifie ou crée dans des sous-répertoires qui correspondent généralement à une phase du projet (MXD, RoadEdits, Delivery, etc.)

En plus des données SIG réelles, vous devez créer un dossier Communications ou Spécifications pour contenir tous les documents de votre client / client interne / professeur. Cela peut servir de métadonnées lorsque vous revenez au projet à une date ultérieure, ainsi que de créer un emplacement centralisé où tout le monde peut voir ce qui est censé se produire.

Il me semble que vous avez besoin d'un ensemble de métadonnées pour stocker ces informations et d'un système de récupération qui utilise les métadonnées pour vous permettre d'extraire des données sur la base des informations.

Je pense que vous voudriez une solution prenant en charge un service de catalogue OGC, pour une interopérabilité maximale. J'ai vu des collègues utiliser Deegree - bien sûr, il existe d'autres solutions que vous devriez vérifier.

Voici un exemple de la façon dont nous avons lié Deegree à notre logiciel (la démonstration en direct est en cours de maintenance pour le moment - vous ne savez pas! - mais devrait être de retour la semaine prochaine)

En ce qui concerne la dénomination des fichiers, si vous avez un service de catalogue et un mécanisme de livraison, il y a moins de problèmes quant à la dénomination des fichiers et à leur emplacement. Sinon, je pense que cela dépend de la façon dont vous recherchez les données. Commencez-vous d'abord par restreindre la zone géographique ou le type de données? Cela déterminera si la hiérarchie commence par diviser les données en tuiles, puis les types de données par tuile; ou en le divisant en types de données, chacune ayant un ensemble de tuiles.

Bien sûr, avec une base de données spatiale, vous n'avez pas les mêmes problèmes de division des données en tuiles, c'est donc souvent une méthode préférentielle - à condition que l'application d'utilisation finale prenne en charge l'utilisation de ce type de données.

Je choisirais SpatiaLite qui est une base de données à un fichier où vous pouvez insérer tous vos fichiers de formes, rasters et tables. Ensuite, en tant que base de données SQL relationnelle, vous avez la puissance des requêtes SQL à votre disposition pour effectuer toutes les actions nécessaires (joindre, sélectionner, fusionner, réunir, diviser, etc.) entre les attributs et les fichiers.

SpatiaLite est également accessible à partir de langages de programmation tels que Python pour un plus grand degré d'automatisation. Le ciel est la limite.

Documentation et tutoriels SpatiaLite

Je trouve utile de créer des documents Word intitulés "Nom ou thème de la carte - Commentaires sur les métadonnées.doc". Documentez les principales modifications et workflows par ordre chronologique (AAAA-MM-JJ) pour chaque thème de carte et / ou de jeu de données. Si vous avez besoin de comprendre l'historique d'un ensemble de données: i) Inclure la date de modification / la date de création des fichiers associés qui sont utiles comme références historiques ou fichiers source potentiels. Incluez un bref résumé du contenu de chaque fichier (noms des couches, nombre d'enregistrements) tout en prêtant attention aux similitudes ou différences générales (c'est-à-dire ce qui est nouveau dans chaque version d'une carte ou d'un ensemble de données). Conservez le fichier "- Commentaires sur les métadonnées" dans le même dossier de travail que la version la plus récente de la carte ou de l'ensemble de données. Placez les anciennes versions de la carte ou des données dans un sous-dossier Archive. Le processus en trois étapes fonctionne bien pour le développement de logiciels, développement de bases de données et gestion de fichiers: 1) Développer (& documenter); 2) Test (& document); 3) Publier (y compris les métadonnées). 1) dossier de travail; 2) sous-dossier d'archivage; 3) Version publiée.