タグ付けされた質問 「big-data」

次のワークフローでポイントシェープファイルを取得するように設計されたPythonコードがあります。 ポイントをマージ 互いに1 m以内のポイントが1つのポイントになるようにポイントを統合します フィーチャレイヤーを作成します。z<10のポイントが選択されています バッファポイント ポリゴンからラスター1mの解像度 再分類、ここで1-9 = 1; NoData = 0 各シェープファイルには、約5x7 kmをカバーする約250,000〜350,000ポイントがあります。入力として使用されるポイントデータは、ツリーの位置を表します。各ポイント（つまりツリー）には、クラウン半径を表す「z」値が関連付けられており、バッファプロセスで使用されます。私の目的は、最終的なバイナリ出力を別のプロセスで使用して、天蓋カバーを記述するラスターを作成することです。 4つのシェープファイルでテストを実行したところ、700MBのラスターが生成され、35分かかりました（i5プロセッサと8GB RAM）。このプロセスを3500個のシェープファイルで実行する必要があるので、プロセスを合理化するためのアドバイスをいただければ幸いです（添付コードを参照）。一般的に、ジオプロセシングビッグデータを処理する最良の方法は何ですか？より具体的には、効率を高めるのに役立つ可能性のあるコードまたはワークフローの調整はありますか？ 編集： ジオプロセシングタスクの時間（全体の％）： マージ= 7.6％ 積分= 7.1％ Lyrへの機能= 0 バッファー= 8.8％ ポリゴンからラスター= 74.8％ 再分類= 1.6％ # Import arcpy module import arcpy # Check out any necessary licenses arcpy.CheckOutExtension("spatial") # Script arguments temp4 = arcpy.GetParameterAsText(0) …

34 arcpy  geoprocessing  big-data 

私はPostGISに大きなシェープファイル（100万件以上のレコード）をインポートする必要があり、それを行う最善の方法について疑問に思っていました。 私の質問では、ツールの代わりに「ハック」という言葉を意図的に使用しました。これは、どのツールではなく、使用するステップまたは構成設定の問題であると思うからです。これまで、SPITプラグイン（QGIS）、shp2pgsql Postgisツール、GDAL ogr2ogrツールを試しました。この投稿で私の完全なレビューを見ることができます。これまでのところ、大規模なデータセットを処理する場合、それらのすべてが本当に応答していません。誰かが同様の問題を経験したかどうか、そしてアプローチについて何かを共有できるかどうか疑問に思っていました。

21 postgis  database  big-data 

NumPy配列を利用してジオプロセシングを最適化する方法を学ぶことに興味があります。私の仕事の多くは「ビッグデータ」に関係しており、ジオプロセシングでは特定のタスクを完了するのに数日かかることがよくあります。言うまでもなく、これらのルーチンを最適化することに非常に興味があります。ArcGIS 10.1には、arcpyを介してアクセスできる次のような多くのNumPy関数があります。 NumPyArrayToFeatureClass（arcpy.da） RasterToNumPyArray（arcpy） TableToNumPyArray（arcpy.da） 例として、NumPy配列を利用した次の処理集中型ワークフローを最適化するとします。 ここでの一般的な考え方は、ベクトルとラスタベースの操作の両方を移動する膨大な数のベクトルベースのポイントがあり、その結果バイナリ整数ラスタデータセットが得られるということです。 このタイプのワークフローを最適化するためにNumPyアレイをどのように組み込むことができますか？

16 arcgis-desktop  python  arcpy  numpy  big-data 

デスクトップコンピューターで利用可能なマルチコア処理能力を最大限に活用するための学習方法に興味があります。Arcは、ユーザーがバックグラウンドジオプロセシングで複数のコアを利用できると述べていますが、タスクは基本的に前のタスクが完了するまで待機する必要があります。 Arc / Pythonで並列またはマルチスレッドのジオプロセシング手法を開発した人はいますか？個々のタスクでマルチコア処理を妨げるハードウェアのボトルネックはありますか？ Stackoverflowで興味深い例が見つかりましたが、これはジオプロセシングの例ではありませんが、興味を惹きました。 from multiprocessing import Pool import numpy numToFactor = 976 def isFactor(x): result = None div = (numToFactor / x) if div*x == numToFactor: result = (x,div) return result if __name__ == '__main__': pool = Pool(processes=4) possibleFactors = range(1,int(numpy.floor(numpy.sqrt(numToFactor)))+1) print 'Checking ', possibleFactors result = pool.map(isFactor, …

12 python  arcpy  parallel-processing  big-data 

大きなECW（詳細は以下）をクリップしようとしていますが、ラスターファイルが大きすぎて完全に処理できません。 以下のECWの詳細 ドライバー：ECW / ERDAS圧縮ウェーブレット（SDK 5.0） ファイルサイズ：50 GBサイズは450000、565081ピクセルサイズ：0.15 0.15 COLORSPACE = RGB COMPRESSION_RATE_TARGET = 9 VERSION = 2バンド数：4 クリップしたい領域は、元のファイルの約1/5です。 ここに私が成功せずに試した方法があります： Arcgisを使用してecwをtiff /他の形式に保存しました...（すぐにあきらめました） Qgisとそのクリッパーツールを使用しました...ファイルの作成は約40％で止まっています。 Qgis以外のオプションでOSGeo4Wのgdal_translateを使用しました。（Qgisを使用しないで一部のメモリを解放する可能性があるという考えがトリックになるだろうと考えてみました） 画像をバラバラに切り、必要なものを取得すると考えてgdal_retileを使用しました。コマンド「gdal_retile -ps 10000 10000 -of ecw -tileIndex tile.shp -targetDir input.ecwこれはさらに速くクラッシュしました」 誰かがアイデアを持っていますか？ 参考までに、16GBのRAMを搭載したi5-3470 3.2GhzでWindows 7 64ビットを実行します。

9 raster  gdal  clip  ecw  big-data