大量の地理空間データを管理していますか？[閉まっている]

地理空間データをどのように管理しますか？何百ものデータセットに広がるテラバイトのデータがあり、各データセットのドメイン名ベースのアーカイブディレクトリにリンクするプロジェクト内のシンボリックリンクを使用するアドホックソリューションがあります。これはほとんど機能しますが、独自の問題があります。

また、リビジョン管理システムで地理空間データを管理している人がいるかどうかも聞きたいです。現在、コードと小さなデータセットには1つ使用していますが、完全なデータセットには使用していません。

株式/明白な答えは、空間データベース（PostGIS、Oracle、SDE、MSSQL Spatialなど）をesriのGeoPortalやオープンソースのGeoNetworkアプリケーションなどのメタデータサーバーと組み合わせて使用​​することだと思います。最高のソリューション。ただし、プロジェクトベースのスナップショット/ブランチ/タグが常に必要になる可能性があります。より高度なデータベースの中には、これらを管理する方法がありますが、一般的にユーザー/管理がそれほど簡単ではありません。

データベースの外に保存するもの（大きな画像、プロジェクトベースのファイル）の場合、キーは一貫した命名規則と、メタデータレジストリ（スプレッドシートのようなローテクでも）を追跡して、それらが適切に管理されていることを確認してください。たとえば、プロジェクトベースのファイルの場合、これは、レコード管理ポリシーが指示したときにそれらを削除するか、プロジェクトの完了時に中央リポジトリにロールすることを意味します。

私はいくつかの興味深い解決策を見ましたが...

BC州環境省がArc / Infoカバレッジから物事を実行していたとき、彼らは適切なrsyncベースの双方向同期プロセスを実施していました。集中管理下にあったカバレッジは毎晩地域にプッシュされ、地域データはプッシュバックされました。このブロックレベルの差分転送は、56kリンクを超えても非常にうまく機能しました。Oracleベースの属性データベースを複製するための同様のプロセスがありましたが、それらは通常、ダイヤルアップではあまりうまくいかなかったと思います:)

私の現在の職場では、同様のハイブリッドソリューションを使用しています。各データセットには信頼できるコピー（Oracleの一部、MapInfoの一部、パーソナルジオデータベースの一部）があり、FMEを使用して夜間にクロスETLされます。ただし、メンテナンスに関してはかなり大きなオーバーヘッドがあります。新しいデータセットを作成し、組織の可視性を確保する努力は、本来よりもかなり高くなります。このオーバーヘッドを回避するために、何らかの統合方法を見つけることを目的としたレビューを行っています。

ここではメタデータが最も重要な問題です。メタデータが誰、いつ、なぜ、どこで受け入れられるメタデータレコードであるかを答える場合。

わずか数人のGISユーザー（約30人）を抱える大企業での実務経験により、データ、特にバージョンと権限を管理する上で大きな問題がありました。この一方は、データ（メタデータ）の詳細なドキュメント化で解決でき、他の問題はPostGISが輝く中央リポジトリで解決される可能性が高いです。

GeoNetworkは、メタデータの問題を処理するための良い出発点です。中央リポジトリの解決は、データベースの設計/保守に専門家が必要になる可能性があるため、より複雑です。

複雑な問題は、これらのデータセットとそのメタデータのQA / QC を誰が担当するかです。コンピューター駆動のプロセスはうまく機能しますが、優れたデータマネージャー/データキーパーほど厳密ではありません。現在、メタデータを確認/コミットし、DBMSに集中化されていない地理空間データを整理するための専任者がいます。

階層的に編成されたファイルシステムを使用しました。-地理的範囲（国または大陸）-データプロバイダー、ライセンサー-ドメイン/データセット-日付/バージョン

その後、社内で作成した派生データセットからソースデータ（プロバイダーから取得したCD / DVDと同じ形式）を分離するポリシーがあります。

ファイルシステムにより、顧客からのデータの取り込みが非常に簡単になり、物理ストレージの観点からもある程度の柔軟性が得られます。より頻繁に使用されるデータセット。

プロジェクト内の管理を容易にするために、シンボリックリンクを使用します。ベクターをデータベース（Oracle）に保持し、顧客（およびプロジェクトの複数のユーザー/スキーマ）ごとに少なくとも1つのデータベースインスタンスを持つことをルールにします。ただし、データベースの外でもスペースを取りすぎる傾向があるため、データベースに多くのラスターを保持していません。また、データベースインスタンスをできるだけ軽量に保ちたいと考えています。

そして、はい、私たちは全体を「ポリシング」する担当者がいるので、面倒になりすぎません。

現在、このセットアップでの最大の問題は、全体の概要を把握するのに役立つ優れたユーザーインターフェイスがないことであり、その上にメタデータストレージを含めることを計画しています。ここで選択肢を検討しています。

コードにバージョン管理を使用しており、ドキュメントにも使用していますが、特にデータセットがほとんどバイナリファイルである場合は、大規模なデータセットに対してバージョン管理が実際に行われないことが判明しているため、お勧めしません、ただし、GMLまたは同様のテキストのようなものを処理している場合を除きます（問題には、サーバー側のディスク使用量の巨大なオーバーヘッドと、巨大なリポジトリをチェックアウトする際のクライアントのクラッシュが含まれます）。

@JasonBirchが言ったように、バージョン管理は大きな問題です。

また、適切なワークフローが非常に重要であることがわかりました。たとえば、フィールドデータを収集する場合、マスターデータセットにマージする前にフィールドデータをQAできるステージングデータベースを使用する傾向があります。ただし、QAが必要なデータの量によっては、常にオーバーヘッドが発生します。

また、もしまだ見ていないなら、少なくともデータモデリングに関して言わなければならないことについては、Lars BrodersenによるGeo-communication and information design ebook をご覧になることをお勧めします。

他の人が言っているようにPostgresはずっとですが、もしあなたがそれをポータブルで移動しやすいものに保ちたいなら、SQLite + Spatialite拡張の使用を常に見ることができます。

管理ツールの点ではPostgresほど使いやすいものではありませんが、QGisは問題なく空間データ対応GISデータベースと直接対話できます。

私は実際にバックアップにSQLite + Spatialiteを使用し、PGSqlインスタンスを監視し、外部USBドライブにあるさまざまなSQLite DBにGISデータをミラーリングするバックグラウンド（カスタム作成）で実行されるWindowsサービスを使用しています。

PGのもう1つのヒント、スキーマを使用する

私が知っている多くの人々は、すべてを「パブリック」にドロップし、それで完了しますが、データベースを正しく編成すると、世界が変わります。

たとえば、私の「Ordnance_Survey」データベースには、VectormapDistrict VectormapLocal Topo50 LookupGrids CodePointWithPolygons CodePointOpenのスキーマがあります

すべての関連データを保持します。

一方、ジオメトリ列などのメタデータテーブルはすべてパブリックにのみ存在し、Postgis拡張機能もパブリックスキーマでのみ有効になりますが、使用中の他のすべてのスキーマからアクセスできます。

前の投稿で言及したように、空間DBとメタデータサーバーは通常のセットアップです。覚えておくべき重要なことの1つは、「1つのサイズがすべてに適合するわけではない」ということです。最終的には、Oracle、ファイルサーバー、SQLサーバーなどに最適なデータが得られます。私はすべてのデータの必要性を1つのソリューションにまとめてみましたが、通常は失敗します。

データに適合するさまざまなソリューションを使用し、それらを計画することを期待してください。これは、Geo-portal（メタデータサーバー）が実際に登場する場所です。

私は、地理空間データの管理においてメタデータが大きな役割を果たすべきであるという上記の「George」に同意する必要があります。本当にどんなデジタルデータでも、メタデータは重要です-適切なメタデータなしでデジタル写真ファイルを管理しようとする写真家を考えてください。物事を宗教的にタグ付けし、データを利用できる優れたソフトウェアを持っていると、人生はずっと楽になります。現在、「地理空間データの管理」に関する元の質問はかなり広範です-これは、保存するデータ形式、命名規則、データセットと機能の階層、ロールと特権の編集などです。

地理空間データのストレージパターンは、クエリの方法/処理方法によって異なります。検討できるいくつかのツールを次に示します。

Postgres + PostGIS：地理空間インデックスと想像できるあらゆる種類のクエリをサポートします。テラバイト単位のデータを管理するには、シャーディング、クエリの最適化などを適用する必要があります。書き込みの負荷が大きい場合はお勧めしません。

MongoDB：これは大量のデータをサポートします。単純な保管、検索、および限定された地理空間クエリに最適です。

ファイルストレージ：本当にアーカイブシステムであり、クエリにデータの一部のみを使用する場合、データをファイルとして保存するのが経済的かもしれません。バージョン管理の要件は、これで十分に満たされる可能性があります。

Redis：上記のオプションのいずれかとRedis Geoサポートを組み合わせて、頻繁にアクセスする必要がある少量の「ホット」データをredisに保存できます。これをキャッシュと考えてください。