私の質問は、PostgreSQL、PostGIS、QGIS、およびGDALなど、いくつかのソフトウェアツールを組み合わせて使用およびパフォーマンスすることに関するものです。
私は、ArcGIS、Python、Rの長年のユーザーであり、無料のオープンソースGISエコシステムとLinuxへの多様化にも関心があります。最近、QGIS（ver 2.8）をPostgreSQL（ver 9.4）およびPostGIS（ver 2.1）と一緒に使用することに非常に興味があり、Windows 8.1 x64を搭載したコンピューターにコンピューターにソフトウェアをインストールしました（コンピューターの仕様：ThinkPad 2.1GHzコア2、8GB RAM、および240GB SSDを搭載したX200）。空間データ（〜100GB相当）の管理方法を学んだら、このマシンでUbuntuを実行したいと思います。
現時点では、シェープファイルとラスターを確実に保存および取得しようとしています。これまでのところ、シェープファイルをPostGISに読み込むことに成功していますが、ラスターはより問題が多いことが判明しています。小さなgeoTIFFおよびGRIDファイルの単一およびバッチインポートを正常に完了しましたが、大きなラスター（たとえば、ディスク上のサイズが156MBの15619x14655セルIMGまたはTIFFファイル）がPostGISにロードされるまでに時間がかかります。空間インデックスを構築し、これらのパラメーターを使用してタイルによってラスターを読み込むために、raster2pgsqlツールを読んで構成しました。
raster2pgsql -s 3161 -C -I D:\PostGIS_data\dem.img -t auto raster.dem | psql -h localhost -U postgres -p 5432 -d postgresインポートのパフォーマンスは依然として非常に低く、ハードウェアは問題ではありません。QGISでのPostGISラスターの視覚化はさらに悪く、せいぜい小さなラスターをゆっくりロードするか、完全にフリーズします。私が述べたような大きなラスターは、QGISで視覚化することは不可能です。ドキュメントとフォーラムの議論から、この欠点はQGIS自体ではなく、GDALのPostGISラスタードライバーによるものと思われます。フォーラムでの議論ではこの問題について簡単に言及しており、ラスタをPostGISに保存すべきではないと示唆する人もいます（ラスタをスムーズに処理できない空間データベースのポイントは何ですか？）。それでも、私は日常的にESRIのファイルジオデータベースを使用して、非常に大きな（〜70GB）ラスターをすばやく簡単に保存、視覚化、分析し、ArcGIS 10.1はそのような日常的な操作によってフリーズまたはスローダウンすることはありません。
ここで不足しているもの、対処していないボトルネックはありますか？PostGISのパフォーマンス上の利点を実現するために、PostgreSQLをチューニングする必要がありますか？探してコンパイルする必要があるGDALのバージョンがありませんか？特に、QGISでのシェープファイルとラスターのPostGISパフォーマンスと視覚化を改善するにはどうすればよいですか？Linuxターミナルを使用して、包括的かつ迅速な空間データ管理の栄光を享受するにはどうすればよいですか？この問題に関する助けを歓迎します！
Duncan Golicherがこのガイドに従いました：https ://duncanjg.wordpress.com/2012/11/20/the-basics-of-postgis-raster/
私は元々自動設定のタイルを使用していましたが、タイルを行ごとに100x100セルにリセットし、ガイドに示されているようにピラミッドを含めました。
raster2pgsql -s 3161 -d -C -I -M -l 4 D:\PostGIS_data\dem.img -t 100x100 raster.dem100 | psql -h localhost -U postgres -p 5432 -d postgres870MB IMGラスターを適切なタイミングで正常にインポートし、アプリケーションを遅くしたりクラッシュさせたりすることなく、QGISで表示することができました。レンダリング時間は思ったほど簡単ではありませんが、許容範囲内です。適切に使用するために、-lパラメーターについて詳しく説明します。
ちなみに、dem.imgファイルをdem100テーブルとしてインポートすると、「o_4_dem100」という別のラスタテーブルが作成されました。QGISでレイヤーとしてインポートすると、201から524の範囲の値を持ち、dem100レイヤーの範囲は36から524の範囲になります。より低い解像度に集約された結果としての値の範囲？
不十分なハードウェアが問題だとは思わない。ここに私がこれまでに見つけたものの簡単な要約があります。
GDALのPostGISラスタードライバーには、過去のパフォーマンスの問題があります（こちらも参照）。これらの問題は2012年に指摘されましたが、QGIS 2.8で見つかったGDAL 1.11.2にはまだこの問題があるのでしょうか。ラスターの視覚化と保存にQGISとPostGISを使用している他のユーザーはいますか？
関連する可能性のあるメモでは、QGISでPostGIS属性テーブルを〜4.7mレコードのテーブルで開くときにパフォーマンスの問題が発生しました。そのスレッドでいくつかの提案を行った後、問題を修正せずに、最終的にQGISにバグレポートを提出しましたが、最終的には閉じられ、次の同様のバグレポートにリンクされました。バグレポートは閉じられていますが、修正されていないようです...
これまでの私の努力をまとめると：
- 空間データ用にPostgreSQLサーバーを最適化しました。
- ジオメトリテーブルの空間インデックスを作成し、VACUUMを実行しました。
- 大きな属性テーブル（約4.7mレコード）を開くためのQGISの動作は、瞬時に表示するためのサブセットを返すのではなく、すべてのレコードを読み取ろうとするようです。これはパフォーマンスの低下につながります。
大規模なPostGISジオメトリテーブルのレンダリングのパフォーマンスは問題ではないようです。
raster2pgsqlを使用すると、PostGISでラスターにインデックスが付けられ、タイル化され、ピラミッドを持つラスターテーブルとしてインポートされました。
- 妥当なサイズのラスターは、PostGISへのインポートが非常に遅く、QGISで開いたり移動したりするのはもちろんです。
また、大きなラスターをインポートしたり、PostGISで大きな属性テーブルを開いたりすると、raster2pgsqlとqgis-binのメモリ消費量が1GBを超えることにも注意してください。@Michaelと@Paulが私の最初の質問への回答で言及したように、PostGISはラスターの格納に利点があるとしても、それをもたらすものではないようです。ただし、その時点で、特にESRI fileGDBがラスター属性、モザイクデータセット、およびジオデータベースによって促進されるその他のラスター操作を有効にしている場合、GISニーズに合わせてQGIS + PostGISを実行する理由を疑問視します。そのため、何かが本当に不足しているか、QGISとPostGISがGISのニーズを満たしていない可能性があります。後者は信じがたいと思う。
