ArcGIS関数のカスタム実装


9

ArcGIS関数のカスタム実装を作成するために必要なものを知りたいのですが。特に、GeoAnalyst.ISurfaceOp2.Visibility()を実装して、実行を高速化したいと考えています。現在、Visibility()の呼び出しごとに最大3秒かかります。私の限られた理解から、ボトルネックは一時的なラスターのファイルシステムへの書き込みです。これがインメモリで実行できれば、処理時間が大幅に短縮されると思います。私は.NETプロジェクトでこれを行っていますが、任意の言語のソリューションを歓迎します。


一時的なラスタをRAMディスクに書き込むだけではどうですか。そうすれば、可視性操作を最初からコーディングする必要がなくなります。これには独自のリスクとコストが伴います。
whuber

それはいいです。どうすればいいですか?これは、@ Radarが以下の回答で不可能と述べていることではありませんか?
ロスファーマン

4
システムにRAMディスクをインストールします。詳細はOSによって異なります。次に、ArcGISスクラッチフォルダーを指定します。特にラスターが巨大である場合や、RAMが少ない場合は、SSDを使用してもほぼ同じことができます。
whuber

RAMディスクのアイデアが好きです。SSDはすぐに使い果たされる可能性があるため、一定の読み取り/書き込み操作には適していません。
レーダー

2
フラッシュベースのSSDは、1〜500万回の書き込み(@Radar)に耐えますが、DRAM SSDは「消耗」しません。(多くの)詳細については、storagesearch.comにアクセスしてください。
whuber

回答:


5

この回答は、コメントでの議論の一部を記念して拡張しています。RAMディスクは、コンピューティングシステム内のRAMの一部を使用して外部ディスクドライブをエミュレートします。インメモリキャッシングに匹敵する速度で読み取りと書き込みを行うことができますが、変換プロトコルがディスク指向のコマンドをメモリ指向のコマンドに変換するためのオーバーヘッドはわずかです。RAMディスクは、特別なオペレーティングシステムレベルのソフトウェアである「デバイスドライバー」を実行することによって作成されます。オープンソースと無料のRAMディスクは、Windowsを含む多くのオペレーティングシステムで利用できます。

したがって、中間ディスクI / Oによるボトルネックをスピードアップする1つの方法は、RAMディスクをセットアップし(必要に応じて追加のRAMを購入)、そこにスクラッチフォルダーを配置することです。(これは通常、ソフトウェア設定です。)

別のオプションは、ハイエンドDRAMソリッドステートデバイス(SSD)をインストールすることです。SSDは、本質的にはディスクドライブのように機能する電子インターフェイスを備えた個別のパッケージにRAMのブロックです。これは、ディスクドライブの代わりにコンピューティングシステムにインストールされ、追加のソフトウェアなしで別のディスクドライブとまったく同じように動作しますが、メモリアクセスとほぼ同じ速さで読み書きします。これらは比較的高価ですが、非常に大きな中間ラスターストレージの場合でも、必要なのは小さなものだけです。

これらの手順を実行する前にプロファイル作成することが重要ですボトルネックが実際にどこにあるかを確認するプロセス。(Windowsには、近年ますます強力なプロファイリングアプリと監視アプリが付属しており、Win 7ではタスクマネージャーとリソースモニターのペアとして利用できます。もちろん、他のOSでも同様のアプリが多数利用できます。)多くのシステムは自動的に構成されます。ディスクの読み取りと書き込みを短時間RAMにキャッシュするように構成できます。キャッシュはRAMディスクとほぼ同じように機能しますが、おそらくもっと高速です。ソフトウェアは中間ファイルをディスクに書き込むと見なしますが、OSはそれらを一時的にRAMに書き込み、ディスクにはアクセスせず、すぐに同じデータが読み込まれ、削除されます。この場合、物理的な書き込みは必要ありません。

完全な可視性の計算に必要な計算量(単純なアルゴリズムでは、すべてのセルの可視性を各視点で1回検査する必要があります)を考えると、ディスクI / Oではなく、計算速度が問題であると少なくとも疑う必要がありますここに。その場合、RAMディスクまたはSSDは時間とお金の無駄になります。代わりに、基礎となるアルゴリズムの分析と改善に努力を向けるべきです

RAMディスクのパフォーマンスがArcGISに役立つかどうかについての議論が別のスレッドで出てきました。


+1すばらしい反応。私はGIS関係者も、グラフィックスプロセッシングユニット(GPGPU)の汎用的な使用に注意を払う必要があると思います。ほとんどの一人称シューティングゲームは、GPUを利用してシューティングゲームの場所からのオブジェクトの可視性を決定していると思います。この問題のOpenCL実装を見るとすばらしいでしょう。おそらく、GISがGPUをさらに使用すると、ビデオゲームをプレイして育った子供たちの注意を引くかもしれません。
Kirk

また、ISurfaceOp2.Visibilityが行うのと同様の、隠された表面の決定などを行うためにGPUが最適化されていることにも言及しました。
Kirk Kuykendall

@Kirk、良いアイデア。ManifoldはNVIDIA GPUを使用しています(数年間使用しています)。この面に関する独立した研究もあります。私は、GPUベースのマップ代数演算の実装を開発するためのいくつかの助成金提案の取り組みに参加しています。
whuber

これは素晴らしい答えです。提案されたプロファイリングを実行したところ、ディスクI / Oのボトルネックが発生している可能性あります。そこで、RAMディスクを使用するソリューションを実装しました(IMDiskを選択しました)。結局、これはプロセスを完了する時間を短縮しませんでした。
ロスファーマン

改善がなかったとのこと、申し訳ありません。可視性は高価な計算です。原則として、DEM内のすべてのセルをオブザーバーごとに検査する必要があり、検査プロセスでは、オブザーバーとDEMセルの間のセルの行全体を見なければならない場合があります。控えめな(メガピクセル)グリッド上でもオブザーバー。計算時間が問題である場合、2つの最適なオプションが考えられます。(1)作業を並列化します。ワークステーション間でオブザーバーを分割し、可視性を計算し、結果を結合します。(2)独自の可視性コードを記述します。
whuber

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.