GDALPolygonizeがArcGIS Raster to Polygonよりもはるかに遅いのはなぜですか？

PythonスクリプトでGDALPolygonize（）を使用してラスターをポリゴン化しようとしています。スクリプトは、昨日の午後5時にポリゴン化を開始し、現在も午前9時30分にポリゴン化しています。どれだけ進んでいるかはわかりませんが、Windowsエクスプローラーを更新すると、出力シェープファイルのファイルサイズの変化を確認できるので、まだ進んでいることがわかります。

私のラスターはかなり大きいですが、それでもそれほど長くかかるとは思いません。私のラスターは35,486列、23,682行で、セルサイズは1メートルです。これは、値1がデータを表し、0がNoDataのバイナリラスタです。

ArcGISで、Conversion ToolboxのRaster to Polygonを使用してポリゴン化した場合、56秒かかりました。結果のシェープファイルは200MBですが、GDALPolygonizeによってまだ作成されているシェープファイルはまだ100MBしかありません。そのため、GDALは終夜実行した後、半分ほどの作業が完了したと思います。

仕様：Windows 7 64ビット、8 GB RAM、GDAL 1.10 64ビット、ArcGIS Desktop 10.2、64ビットバックグラウンドジオプロセシングfor ArcGISデスクトップ、Python 2.7.3 64ビット

更新 2日目-GDALPolygonizeはまだ実行中です。それは一晩で2晩続けて、終わらなかった。ArcGISは56秒かかりました。

同じ経験があります。巨大なラスターのアルゴリズムは実際には低速ですが、小さなラスターの場合はかなり高速です。考えられる回避策が1つあります。

1. gdalwarpによって巨大なラスターファイルを小さなファイルに分割します（-teを使用して各ファイルの範囲を定義します）。

gdalwarp -te 12.08 48.5 12.5 51.1 original_file.tif part1.tif

2. それぞれを個別のシェープファイルにポリゴン化します。

gdal_polygonize.py part1.tif -f "ESRI Shapefile" part1.shp

3. シェープファイルをマージします。

ogr2ogr -f "ESRI Shapefile" -update -append merge.shp part1.shp -nln merge

4. 新しいシェープファイルを溶解します。

ogr2ogr "output.shp" "input.shp" -dialect sqlite -sql "SELECT ST_Union(geometry), field FROM input GROUP BY field"

私は知っている、それは地獄のようにクレイジーですが、最後の時間ははるかに速かったです。

スタンリー