シェープファイルデータをデータベースに集中化する

さまざまなGISプロジェクトから何百ものシェープファイルを取得し、それらを単一のデータベースプラットフォームに統合したいと考えています。現在、Postgres / PostGISでこれを試みています。

標準化されているデータはほとんどありません。つまり、同じデータ型がたくさんありますが、特定の属性名/型は一致しません。

どこでこれに取り組むべきですか？各シェープファイルを最初に移行するための標準モデル（Hydro_line、transport_line、Hydro_poly標準など）を開発する必要がありますか？

別の方法は、各シェープファイルを個別にPostgresにインポートすることです。したがって、各shpはデータベース内のテーブルになりますが、パフォーマンスと組織の観点からはこれについてはわかりません。避けられないことを遅らせるようなものです...

この困難な作業に対処するためのアドバイスはありますか？

— コールマン
ソース

回答:

Spatial ETLソフトウェア（Extract-Transform-Load）をご覧ください。これらはそのようなタスク専用です。最も有名なのはSafeのFMEですが、SDI（Spatial Data Integrator）やGeoKettleなど、いくつかのオープンソース（部分）の代替が利用可能になりました。

— ローラン・ジェグー
ソース

以前の質問で比較を求めたので、このルートに行く場合は、書き上げてください。 gis.stackexchange.com/questions/5049/spatial-etl-comparisons

— RyanKDalton

FMEの試用版を入手し、SDIとGeoKettleの両方をインストールしました。私はそれらを試して、それらを理解できるかどうかを確認します。FMEはスープからナッツへのソリューションのように見えますが、最初に学習曲線を乗り越える必要があります:)。

— コールマン

@ colemanm-これで何をしましたか？どの製品が最も便利だと思いましたか？

— RyanKDalton

ハロー

最初にPostGISにインポートします。個々のテーブルに複数の形状をロードするツールがあります。QGISスピット拡張機能は1つです。PostGISトランクまたは実験的バイナリの新しいグラフィカルshp2pgsqlは、別の選択肢です。または、shp2pgsqlを使用してバッチスクリプトを作成することもできます。

そこから始めて、すべてをoriginalなどのスキーマにインポートします。それから、データを構造化します。必要に応じてテーブル内で結合します。

そのようにすることの良い点は、これらの変換を行うために使用するすべてのクエリを保存すると、データの履歴に関する優れたドキュメントが得られることです。必要に応じて、やり直しも非常に簡単です。整理作業の準備ができたら、スキーマのバックアップを「オリジナル」にダンプし、どこかに保管します。

これは、構造化されたクリーンな方法だと思います。前に述べたように、どのフィールドが名前を新しい名前に変更したか、元のテーブルがその新しい新しいテーブルにどのようにマージされるかなど、非常に堅実なドキュメントを取得できます。

もちろん、FMEやそのようなソフトウェアでは、行ったことを保存することもできますが、内部データベースクエリに比べて非常に遅いことに加えて、SQLクエリとして行われることを文書化する一般的な方法ではありません。テキストファイルとリレーショナルデータベースがある限り、それらは使用可能で読み取り可能です。

私は次のようなテキストファイルで終わるのに使用します：

-- A query to merge all roads in Norway

Create table road_tables.all_roads as
SELECT id as roadid, status, the_geom from original.big_roads
union all
SELECT rid as roadid, condition as status, the_geom from original.small_roads;

等々。これはテキストファイルとして保存され、数年後に大きな価値があります。

よろしくニクラス

— ニクラス・アベン
ソース

+1これは非常に良いアプローチだと思います。すべてがPostgres内で行われ、非常に透明で、必要に応じて簡単に再現できます。

— 暗闇

ESRIベースのGISには適していません。オープンソース「のみ」はこれで問題ありません。ESRIには、この方法ではアクセスできない依存関係がさらに多くあります。interop、gisサーバー、またはarcsdeなしでは、postgisへの直接接続は許可されません。

— ブラッドネソム

@ブラッドうーん、それは透明で再現性のある速い方法で物事を行うことに対する議論なのか、それとも私と私のデータの間にsdeを入れてロックアップすることに反対する議論なのか...

— ;

@ブラッド：colemanmはESRIに言及しなかったので、答えは良いようです。

— 暗闇

ESRI SdeフィーチャクラスとSQL Server 2008（ネイティブジオメトリを使用）でこれと同様の作業を行いました。最初にフィーチャクラスを作成してから、一連の挿入ステートメントを読み込みます。IIRCでは、新しいオブジェクトIDを正しく生成できなかったため、最後にフィーチャクラスを新しいフィーチャクラスにエクスポートする必要がありました。一度やったら、いつものようにビジネス。

— ジェイカミンズ

私の提案は、より重く使用されるデータレイヤー（シェープファイル）を2〜5個選択し、それらをrdbmsに移行することです。
これらのデータのワークフローを調査して実装します。rdbms対ファイルベースのデータの制限と要件に慣れる。

制限には、必要なエクスポート、ランディングゾーン、coordsys、コラボレーションのファイルタイプが含まれます。

あなたが提案しているものには多くの利点があります。
サイドノート：（おじいちゃんは両親に、購入前に家を探すために6分の1を費やすように言った）あなたがあなたのデータのために家（長期）を探していると考えてください。好きじゃない

私の推奨事項は、データソースのツリーリストを書き留め（デジタルまたはアナログ）、全体像を表示することです。これにより、データをより簡潔なグループに整理できるようになります。

異種データを統合する方法がarcgis内にあります（私の仮定：好みのシステムを指定していません）。

優れた設計手法の学習に興味がある場合は、この情報の一部を試すことができます...

ジオデータベース設計の概要
 ジオデータベースのドキュメント
Arc 10にも同様のリンクがいくつかあります。
Resource Center
arc10ジオデータベース

— ブラッド・ネソム
ソース