Gdal Dataset.ReadAsArray（）がPythonをクラッシュさせる

Windows 7 64ビットにインストールされたNumpy 1.3およびGdal 1.9.1でPython 2.6.5（32ビット）を使用しています。800 MBのImagine（.img）ラスターデータセットをNumpy配列に読み取ってラスター代数を実行しようとしていますが、次のコードを実行するとすぐにPython.exeがクラッシュします。

from osgeo import gdal

g = gdal.Open(r'path\to\dataset', gdal.GA_Readonly)
b = g.GetRasterBand(1)
data = b.ReadAsArray()

Python.exeはb.ReadAsArray()呼び出し時にクラッシュします。Google検索をいくつか行って、Gdal 1.6からWindows 7 64bitでこの問題に言及している記事を見つけましたが、当時の最新の開発バージョンで修正されたと述べました。

他の誰かがこの問題を抱えていましたか？回避策はありますか？

更新：

PyDevでコードをデバッグして、どこでエラーが発生しているかを特定することにしました。私が伝えることができる（まだエラーメッセージが表示されない）ことから、gdal_array.pyの22行目で失敗しています。

_mod = imp.load_module('_gdal_array', fp, pathname, description)

上記のコード行に足を踏み入れると、numpyのinit .pyモジュールに移動します。numpyの最後に到達したとき。__ init __ .pyモジュール、上記のコード行に戻ります。次に、ステップインボタンを押すと、gdal_array.py内の次の行に移動しますが、スクリプトはエラーメッセージも何も表示されずに終了します。

更新＃2：

GDAL 1.9.1をアンインストールし、Python CheeseshopおよびOSGeoのWindows BinariesからGDAL 1.6.1をインストールしました。まだ同じ問題がありました。

— ブライアン
ソース

私はこの問題を抱えていました。gis.internalsでTamasのgdal pythonバインディングを使用していますか？その場合、PATHに追加したものを先頭に移動します。他のライブラリが問題を引き起こしていました。

— ジェイローラ

彼の内部からダウンロードしたと思います。明日オフィスに着いたら、道を調整しようと思います。アドバイスをありがとう。

— ブライアン

-それは仕事をしない場合、私は最近、これらのパッケージの使用に切り替えlfd.uci.edu/~gohlke/pythonlibs

— ジェイ・ローラ・

システムパス（WindowsのPATH環境変数）をうまく動かしてみました。また、GDALのバージョンをアンインストールし、提供したリンクにGDALのバージョンをインストールしましたが、依然として同じ問題がありました。

— ブライアン

うーん......私がリンクしたバージョンはバインディングだけだったので、まだTamasのGDALコアが必要です。他の呼び出しが機能した場合、それはうまく機能しています。試してみる3つのことは、ロングショット（「長さ」の順）です。Numpyのバージョンを更新します。2）gdal_translateをgtiffに変換し、その画像でコードを試してください。3）ReadAsArray（）に.astype（numpy.float32）を追加します。画像は公開されていますか？マシンでテストできます。これらのどれも動作しない場合、スタックトレースを投稿できますか？

— ジェイローラ

回答:

多くのコメント者が疑っているように、これは私のインストールの問題でした。どうやら、GDALとPython Bindingsをインストールするときに十分な注意を払っていなかったようです。

私はgisinternals.comからGDAL Coreとプラグイン（dll）をインストールしましたが、どういうわけかそこからPython Bindingsもインストールしようとは思いませんでした。私がインストールしたPythonバインディングは、別のサイトからのものでした（この時点でどれを覚えているかはわかりません）。

gisinternals.comからGDALとPython Bindingsをすべて再インストールすると、ReadAsArrayを正常に作成できました。

コメントして答えてくれたすべての人に感謝します。私の無知をおIびします。

— ブライアン
ソース

メモリの問題である可能性があります。ReadAsArrayを使用すると、データがメモリに格納されます。800mbは大容量ではありませんが、小さくもありません。配列をチャンクで読み取ってみましたか？

data = b.ReadAsArray(x_offset, y_offset, x_size, y_size)

配列をループして一度にチャンクを処理できる必要がありますが、実行している処理によっては、エッジの影響を避けるために、重複する領域での読み取りを検討する必要があります。

— om_henners
ソース

チャンクを使用してみました。私data = b.ReadAsArray(0,0, 500, 500)は同じ結果で試しました。

— ブライアン

うーん。他の画像形式を試したことがあると思いますか？また、特定のエラーメッセージがありましたか？

— om_henners

他のフォーマットはまだ試していません。エラーメッセージはなく、「python.exeが動作を停止しました」というポップアップだけが表示されました。

— ブライアン

今朝、.imgファイルをGeoTIFFに変換して、再試行しました。運がありません。

— ブライアン

gdalからファイルをメモリマップする方法はありますか？

— CMCDragonkai

申し訳ありませんが、このパーティーには遅れていますが、基本的な問題は、32ビットPythonが非常に大きなラスターをメモリに格納できないことです。大きなラスターをビットサイズのチャンクでメモリに読み込むことができますが、ディスクへの非常に非効率的な/頻繁な読み取り/書き込みをせずに効率的に処理できるものに関してはかなり制限されます。

代わりに（ディスクの読み取り/書き込みのためにある程度の効率を犠牲にして）私がすることは、必要なgdalメソッドの64ビットgisinternals.comバージョンを（EXEラップを介して）呼び出すことです。Pythonのサブプロセスモジュールをループで使用することに注意してください（つまり、サブプロセスを順番に呼び出したい/必要な場合があります）。ウィンドウボックスに対して誤って多くのオープンスレッドを生成し、不吉なシステム警告を受け取る可能性があります。このgdalアプローチでは、ディスクの読み取り/書き込みの方法を少し犠牲にしますが、処理効率は（つまり、ボックス/ライブラリがサポートできる場合は、高速なメモリ内計算に比べて）約1倍低下します。 10。

— クセド
ソース