データ自体とともに地理空間メタデータを非ESRI空間データベースに格納する（したがって、ダンプ時に移動できる）既存の標準的な普遍的なアプローチ（および、できれば管理をサポートする既存のツール）があります。
テーブルとリレーションに単純に依存するため、PostGIS、Spatialite、Oracle、SQL Serverなどのデータベースで使用できるアプローチを特定したいと考えています。ここで、メタデータとは、データに関する説明情報（つまり、US FGDCまたはISO 19139地理空間メタデータタイプ情報）-BBOXおよび内部データではありません。
ESRIユーザーは、ファイル（Shapefiles）であろうとジオデータベースであろうと、データを普遍的に記述および付随できるいくつかのXML形式を持っています。ただし、ESRIソフトウェアを使用しない場合、既存のオプションは何ですか？はい、もちろん、独自のテーブル、データ構造などを設計できます。しかし、なぜ確実に存在するはずのホイールを再発明するのでしょうか。
更新：
Geonetwork（または必然的にサーバーに関係するもの）のような複雑なアーキテクチャコンポーネントは、まさに避ける必要があるものです。また、メタデータは、個別のデータベースとしてではなく、データとともに存在します。要件は以下のとおりであり、最初に述べておかなければなりませんでした。
システム要件：1.アーキテクチャは、QGISとSpatialiteデータベースのみを必要とします-一部は、組織がサーバー上で何かを実行するほど洗練されておらず、何かを購入したり、ビルド/デプロイしたりするお金がないためです。
機能要件：1.データは多くの人々に容易に配布されなければならず、ドキュメントはデータから簡単に分離されてはなりません。つまり、データが何であり、なぜ作成されたかを常に把握できるように、それらは一緒に配布されるべきです。など-データがある場合、ドキュメントがあります。2.データ自体と同様に、メタデータのドキュメントは、直感的なデスクトップツールを使用して、非技術スタッフが簡単に編集および保守できる必要があります。
ユースケース：1.ボビー学生スチューデント（およびGISの学習）は、調査の一環として監視サイトのデータを作成します。2.ボビーは、使用した入力、処理ステップの説明、および他の人がデータの系統を理解するのに役立つその他の情報を記録します。3.ボビーは実際の仕事を得て退職し、彼のデータはCD-ROMにバックアップしたままにします。4. 2年後、誰かがデータを見つけて、データ内のドキュメントを読むことができるため、非常に有用であると判断します。
あなたが洗練された組織から来たなら、あなたは言うだろう。しかし、関連するシナリオは実際、私の世界では非常に一般的です。