PostGISを使用して複雑なジオプロセシングワークフローを処理する方法

12

私たちの組織は、ジオプロセシングワークフローをPostGISに移行することを検討しています。現在、ArcGISを使用しており、ModelBuilderで使用される多数のカスタムPythonツールを使用しています。ほとんどのデータをPostGISに移動して、さまざまなアプリで使用できるようになりましたが、現在、そこでデータ処理を実行することも理にかなっていますか。

ソフトウェアと互換性があるようにデータを処理します。顧客がソフトウェアを購入し、データを提供すると、ソフトウェアでの使用に最適化されるように処理します。これには、さまざまな品質の入力データを処理するためのさまざまなツールを構築する必要があります。特定の形式またはスキーマでデータを受け取ることは期待できないため、入力フィールドを出力フィールドにマップし、単一のフィールドを複数のフィールドに解析し、複数のデータセットをマージするなどのツールを構築します。フィールドの連結、および他の多くの一般的な操作。PostGISは、すべての処理ニーズを完全に実行できるようです。

PostGISを使用してデータ処理を行う場合、組織、使用するツールなどについて何かアドバイスはありますか？

QGIS python処理と組み合わせて使用しますか？
非Web処理にPython ORMを使用している人はいますか？GeoGISにはPostGIS用のPython ORMがあるため、GeoDjangoの使用に傾倒しています。PostGISを使用してデータを処理する最初のテストでは、Pythonコードに多くの大きなSQLテキストブロックがあり、GeoDjango ORMが管理しやすく読みやすいコードの作成に役立つと考えています。また、PostGISと同様に対話するGeoAlchemy ORM があり、DjangoほどWeb固有ではないようです。

QGISやArcGISを使用している人と同じくらい、PostGISを使用してジオプロセシングを行っている人のことを聞いたことがありません。

— タナー
ソース

1

すべてのプロセスは「バックエンド」ですか？私はDjangoやGeoDjangoのユーザーではありませんが、これらの製品はWebサイトのみを開発するためのものであると考えています（価値がある以上のトラブル、IMHO）。（もちろんUNIX）コマンドラインで、または "cron"を介して定期的に実行されるシェルまたはPythonスクリプトの束ではないのはなぜですか。（私の考えでは、clickey-clickeyの方がずっと良いです。）少なくともこれらを体系的に、少なくとも着信データストリームごとに整理したいと思うでしょう。また、Postgisはおそらく、QGISを使用せずにデータをスライスおよびダイスすることができます。具体的にどのような種類の操作を考えていますか？

— -forkandwait

1

はい、処理はバックエンドです。ただし、最終的には、顧客がデータを表示および編集するためのOpenLayers Webマップが作成されます。アプリのユーザーアカウントと管理者アカウントにDjangoを使用する場合があります。そうだとすれば、Djangoは主にWebサイト用に構築されているにもかかわらず、GeoDjangoを処理のために検討するもう1つの理由かもしれません。このDjangoを使用した大規模処理プレゼンテーションは、DjangoがWebサイトだけではないことを示唆しています：slideshare.net/dibau_naum_h/large-scale-processing-with-django

— タナー

1

バックエンドの作業には、PostGIS、小さなogr2ogr、スクリプト言語（Python、Ruby、Tclなど）、およびUNIXコマンドラインを使用します。データベースと可能な限り互換性を保つため以外は、DjangoをDjangoに混在させないようにします。その後、必要に応じてフロントエンドを配置します。私のルールは次のとおりです。clickeyの削減=生産性の向上（ただし、GISアナリストはclickey-clickeyがらくたの方が快適だと感じていますが...「直感的なインターフェイス」を意味します）。

— forkandwait

スライドシェアについては、非常に複雑に見えますが、処理能力を維持しようとして負荷がかかっている場合は適切かもしれませんが、そうでなければ管理するのは悪夢です。

— forkandwait

1

役に立つかもしれないいくつかの一般的なetlの質問：「空間ETL比較」と「安全なfmeの代替手段はありますか？」

— RyanKDalton

8

ジオプロセシングの目的でPostGISを使用するのが大好きです。

私の2つの主な理由は次のとおりです。

1）多くの場合、データベースで複雑なタスクを実行する方がはるかに高速です。クエリプランナーの助けを借りて正しい順序で処理を実行できるためです。

2）使用したsql行をテキストファイルに保存するだけで、実行した内容の非常に優れたドキュメントが得られます。

私のワークフローでは、タスクに多くの「ステップ」が含まれる場合、次のよう
になります
。1- タスクの性質に応じてクエリの一部またはすべてを構築する実行方法を確認します
3-必要に応じて調整を行います
4-データセット全体でクエリを実行します
5-メモをテキストファイルに行を保存します。
これはすべて、ArcGISを起動してライセンスサーバーからのライセンスを待機するのとほぼ同じくらいの速度です。

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

5

私たちが開発した多数のプロダクションジオプロセシングWebサービスには、PostGISとある種のPythonプログラミング環境を使用しています。苦情はありません！

GeoDjangoは、主に（または排他的に）Webアプリケーションの機能を使用している場合に最適です。PostGIS RasterまたはPostGIS 2.0のラスターデータタイプはサポートしていません。現在、最新バージョンのDjangoがネイティブに付属しています。Djangoでカスタムの生のSQLクエリを使用することにより、ラスターサポートの欠如と全体的な堅牢性を補うことができます。

より堅牢なジオプロセシングアプリケーション、特にオブジェクトリレーショナルモデルを使用する場合は、GeoAlchemy2を試してください。SQLAlchemyを拡張する元のGeoAlchemyライブラリは、機能データのサポートを提供します。GeoAlchemy2は、PostGIS 2.0の新しいラスターデータタイプの（限定的な）サポートを提供することにより、それを拡張します。

そして、GDALとOGRには常にPythonバインディングがあります！

— アーサー
ソース

YMMVですが、オブジェクトリレーショナルライブラリは、単純に古いSQLに実際には何も追加しません。別のコメントで述べたように、詳細を聞くことは最も興味深いでしょう。

— forkandwait

4

ケーススタディ、つまり、火災後の侵食モデルのラスター入力を生成するWebサービスについて説明できます。基本的に、いくつかのラスタをサブセット化し、互いに追加する必要があります。GeoAlchemy2（GA2）を選択して、データが保存されているPostGISとインターフェイスします。GA2を使用して、コンパクトで再利用可能なPostGISクエリを作成できます。1つのクエリは、「焼けた土地被覆」製品（土地被覆、サブセットの再分類）を作成します。この製品は、一部のモデリングに単独で必要ですが、3番目の出力製品を生成するために、別のラスター（土壌レイヤー）に追加されます。GA2を使用すると、Pythonでミキシング、マッチング、シリアル化を行うことができます。

— アーサー

3

可能ですが、データベースエンジンまたはWebフレームワーク内で多くのジオプロセシングを行うことを想像するのは困難です。基礎となるコードライブラリ-geos、proj.4、およびgdalを確認することをお勧めします。3つすべてにPythonバインディングまたはライブラリがあります。検討するもう1つのオプションは、QGISのSextanteジオプロセスプラグインです。これにより、モデル/ワークフローの構築が可能になります。

他の考え：

PostGISの使用を排除しないでください。優れたストレージおよびサーバー機能を提供し、SQLを介していくつかのgeoおよびproj.4機能を公開します。また、言及されている他のツール（Django、QGIS、Python）ともうまく機能します。

前述のSextanteプラグインの使用可能性に加えて、QGISは視覚化に適しており、postgresを操作するためのツールがあり、Pythonコンソールも含まれています。

ORMを探していてWebフロントエンドが必要な場合は、Djangoがそれを行います。それほどセクシーではないインターフェースを気にしない場合、管理ページは比較的少ない労力でCRUDインターフェースを提供します。GeoDjangoを使用している場合はジオメトリ編集も可能です。

— Scro
ソース

2

ジオプロセシングにWebフレームワークを使用しないことに同意しますが、ジオプロセシングにPostGIS（または別のデータベースエンジン）を使用しないことに強く同意します。議論を進めるには詳細が必要ですが、PostGISとSQLを使用して、大量のジオメトリスライス/ダイシングとポイントインポリ解析を行います。

— forkandwait

2

@forkandwaitああ、PostGISであなたに同意します。しかし、私は彼らがプロジェクトごとに異なる方法でチェーンするかもしれないいくつかの小さなスクリプトを使用しているという印象を受けました。私の目標は、基礎となるライブラリを調査してもらい、最適な環境を選択できるようにすることでした。

— Scro

3

見てくださいETLを、具体的には、FME空間操作（またはオープンソースのGeoKettle）。

視覚的なワークフローを作成し、空間操作、結合、マージなどすべてのロジックを分離でき、非データベース形式やさまざまなデータベースで作業できるため、FMEの使用が本当に好きです。多くのことを、簡単かつ迅速に行います。モデルビルダーでの経験がある場合は、すぐに理解できます。さらに、オンラインで多くのドキュメントがあります。

FMEの唯一の欠点は、費用がかかることです。しかし、それは価値があると思います。

FMEを使用する代わりに、おそらくGDALとOGRを使用し、おそらくPythonを一緒に使用します。または、あなたが言うように、それをすべてPostgreSQLで行います。ETLは空間データの争いにおいて強力な役割を果たしており、データベースだけではできない多くのことをしていると思います。

使用していませんが、GeoServerはWPSの実装を提供していますが、これは使用していませんが、他の人がこれがどのように役立つかについてコメントするかもしれません。

GeoDjangoの使用についてコメントすることはできませんが、データを表示するためのフロントエンドのようなCMSであると考えました。

— アレックス・リース
ソース