Norme de stockage des métadonnées humaines dans des bases de données spatiales

Existe-t-il une approche standard, universelle et existante (et, espérons-le, des outils existants qui prennent en charge leur gestion) pour stocker les métadonnées géospatiales dans des bases de données spatiales non ESRI parallèlement (et donc capables de voyager lorsqu'elles sont exportées) les données elles-mêmes.

J'espère identifier une approche qui repose simplement sur des tables et des relations et pourrait donc être utilisée dans des bases de données comme PostGIS, Spatialite, Oracle, SQL Server, etc. Ici, les métadonnées désignent les informations narratives sur les données (par exemple, US FGDC ou ISO 19139 informations de type de métadonnées géospatiales) - pas le BBOX et les éléments internes.

Les utilisateurs d'ESRI disposent désormais de plusieurs formats XML qui peuvent décrire et accompagner universellement les données, qu'il s'agisse de fichiers (Shapefiles) ou de géodatabases. Cependant, quelles options existantes existent lorsque le logiciel ESRI n'est pas utilisé? Oui, bien sûr, je pourrais concevoir mes propres tables, structure de données, etc. Mais pourquoi réinventer une roue qui doit sûrement exister.

MISE À JOUR:

Les composants architecturaux complexes comme Geonetwork (ou tout ce qui implique nécessairement un serveur) est exactement ce que je dois éviter. De plus, les métadonnées cohabiteraient avec les données, et non comme une base de données distincte. Les exigences sont ci-dessous et j'aurais dû le dire au début.

Configuration requise: 1. L'architecture ne doit rien de plus que QGIS et une base de données spatiales - en partie parce que l'organisation n'est pas assez sophistiquée pour exécuter quoi que ce soit sur un serveur et n'a pas d'argent pour acheter quoi que ce soit ou faire construire / déployer quoi que ce soit.

Exigence fonctionnelle: 1. Les données doivent être facilement distribuées à de nombreuses personnes et la documentation ne doit pas être facilement séparée des données - ce qui signifie qu'elles doivent vivre et être facilement distribuées ensemble afin que je sache toujours ce que sont les données et pourquoi elles ont été créées, etc - si j'ai les données j'ai la documentation. 2. Comme les données elles-mêmes, la documentation des métadonnées doit être facilement modifiable et maintenue à l'aide d'outils de bureau intuitifs et par du personnel non technique.

Cas d'utilisation: 1. Bobby l'étudiant volontaire (et juste en train d'apprendre le SIG) crée des données de sites de surveillance dans le cadre d'une étude. 2. Bobby enregistre les entrées qu'il a utilisées, l'explication de ses étapes de traitement et d'autres informations qui aident les autres à comprendre la lignée des données. 3. Bobby obtient un vrai travail et part, laissant ses données sauvegardées sur CD-ROM. 4. Deux ans plus tard, quelqu'un trouve les données et les juge très utiles car il peut lire la documentation contenue dans les données.

Si vous venez d'organisations sophistiquées, vous diriez: «Mec, quelle situation foirée. Gérez simplement les données de la bonne manière (quelle qu'elle soit). Mais les scénarios associés sont en fait assez courants dans mon monde.

Geonetwork Opensource est un catalogue de métadonnées très complet pour les données spatiales qui prend en charge de nombreuses normes MD L'installation par défaut utilise Mckoi, mais il peut être configuré pour utiliser Oracle, PostgreSQL (ou PostGIS), MySQL etc.

Cependant, si je comprends votre question, vous souhaitez que le MD accompagne l'ensemble de données en tant que fichier de base de données distinct? Cela pourrait être possible en vidant les tables particulières de votre base de données, mais je ne sais pas à quel point cela serait utile sans Geonetwork.