タグ付けされた質問 「performance」

ArcGIS Engineアプリケーションのデータを整理する最適な方法を決定しようとしています。特に地図の表示とクエリの速度に興味があります。現在、すべてのデータをテーマに基づいて個別のファイルジオデータベースに分割しています。Transportation.gdb、Utilities.gdbなどがあります。データは必ずしもテーマに基づいて整理する必要はなく、すべてを1つのファイルジオデータベースに入れることを検討しています。 私は自分でテストを行いますが、コミュニティに質問を投げかけたかったのです。 一般に、単一のファイルジオデータベースの使用は、複数（約7）の小さいジオデータベースの使用よりも高速ですか？他の賛否両論にも興味があります。 注：ソフトウェアとすべてのデータは、お客様のローカルマシンにあります。Web上またはネットワーク経由でデータが提供されず、データ量がかなり少ない（約100,000個の機能）。

11 arcgis-engine  file-geodatabase  performance 

私の組織は、ArcGIS Engineで実行されるアプリケーションに取り組んでいます。アプリケーションの以前のバージョンでは、道路、区画、建物などを表示するために主にシェープファイルを使用していました。 私は大学の仕事でデータを管理するときにシェープファイルを避けるように教えられたので、ファイルジオデータベースに移行することを提案しました。 Esriは、ファイルジオデータベースがパフォーマンスとストレージ用に最適化されていると主張しています。 私の同僚は、シェープファイルは通常、より高速に描画されると聞いたことを覚えています。 私はこのトピックについて直接話している記事に出くわしなかったので、コミュニティに尋ねると思いました。 私はファイルジオデータベースに傾倒していますが、Shapefilesが提供するものを見逃していないかどうかを知るのは良いことです。

11 arcmap  shapefile  arcgis-engine  performance  map-drawing 

ArcToolboxでPythonスクリプトを実行することとスタンドアロンスクリプトとして実行することの違いを研究した人はいますか？バンド1を抽出して、RGBイメージのセットをシングルバンドに変換するための簡単なスクリプトを作成する必要がありました。スタンドアロンのスクリプトとしてPCに対して読み取りと書き込みを行うと、約350秒で1000の同じサイズのイメージを処理します。ArcToolboxから同じスクリプトを実行するには、約1250秒かかります。 import arcpy import csv from os import path arcpy.env.workspace = in_folder image_list = arcpy.ListRasters() #Create a CSV file for timing output with open(outfile, 'wb') as c: cw = csv.writer(c) cw.writerow(['tile_name', 'finish_time']) #Start the timer at 0 start_time = time.clock() for image in image_list: #Extract band 1 to create a …

11 arcpy  performance  python-script-tool  idle 

ファイルジオデータベースにかなり大きなポイントフィーチャクラスがあります（最大4 000 000レコード）。これは、100mの解像度を持つ通常の点のグリッドです。 このレイヤーで一種の一般化を行う必要があります。このために、各ポイントが4つの「古い」ポイントの中央にある新しいグリッドを作成します。 * * * * o o o * * * * o o o * * * * [*] =元のグリッドのポイント-[o] =新しいグリッドのポイント 新しい各ポイントの属性値は、古いグリッドの4つの近傍の重み付けされた値に基づいて計算されます。したがって、新しいグリッドのすべてのポイントでループし、それらのそれぞれについて、（属性テーブルのXとYの値を比較することによって）隣人を見つけるために、古いグリッドのすべてのポイントでループします。4つのネイバーが見つかったら、ループから抜け出します。 ここには方法論的な複雑さはありませんが、私の問題は、私の最初のテストに基づいて、このスクリプトが完了するまで数週間続くことです... それをより効率的にする可能性はありますか？私の頭の上のいくつかのアイデア： フィールドXとYにインデックスを付ける=>私はそうしましたが、大きなパフォーマンスの変化に気づきませんでした 属性ベースのクエリではなく、空間クエリを実行して近傍を検索します。それは実際に役立ちますか？ArcGISのどの空間関数がその仕事をするべきですか？たとえば、新しい各ポイントをバッファリングすることがより効率的であるとは思えない フィーチャクラスをNumPy配列に変換します。それは役に立ちますか？私はこれまでNumPyをあまり使用していないので、誰かが処理時間を短縮するのに本当に役立つと私に言わない限り、それについて詳しく知りたくありません。 他に何か？

10 arcpy  cursor  performance  indexing 

ArcMapのSQL Serverでクエリレイヤーを使用しています。クエリレイヤーはSQL Serverで即座に実行されますが、ArcMapでの描画に時間がかかりすぎて、システムが約10分以上応答しなくなったように見えます。ArcMapの描画中に、CPUの1つがSQL Serverプロセスで最大になります。 私のクエリは、次のように、ポリゴンフィーチャクラス（Townlands）に対するラインフィーチャ（Shannon）のバッファーのSTIntersectsです。 SELECT TOWNLANDS.TL_ID,TOWNLANDS.Shape FROM dbo.TOWNLANDS as townlands with(index(FDO_Shape)) JOIN dbo.Shannon on townlands.Shape.STIntersects (Shannon.Shape.STBuffer(2.0))=1 クエリは瞬時に186行を返します。これらは問題なくSQL Server Management Studioの空間ペインに描画できます まったく同じ構文でArcMapにクエリレイヤーを構築すると、システムが応答しなくなりますが、最終的に描画されます。おそらく、ArcMapが空間インデックスを使用していないか、SQL Serverと異なるため、SQL Serverでクエリが非効率になり、経過時間を返すように見えます。 誰かが治療法についてアドバイスできますか？ ありがとう ArcGIS Desktop: 10.2 ArcSDE: 10.2 RDBMS: Database and version: SQL Server 2008 OS: Windows Server

10 arcgis-desktop  enterprise-geodatabase  sql-server  arcgis-10.2  performance 

30mの解像度でグローバルラスタを操作および処理しています。合計ラスターサイズは通常[1,440,000 560,000]です。スーパーコンピューターにアクセスできるので、グローバルラスタを扱いやすいチャンクに分割し、いくつかの計算を並行して実行し、それらをディスクに非常に迅速に書き込むことができるコードを作成しました。 しかし、結果を表示することに関しては、壁にぶつかっています。私は通常、地球をカバーするタイルの仮想ラスターを作成し、それをQGISに取り込みます。しかし、それは信じられないほど遅いです（もしそうならロードするのに数分）。そして、パンまたはズームしようとすると、さらに数分かかります。この問題を解決するための最初のアプローチは、gdaladdoを使用して概要を作成することでした。ただし、これらのビルドには（日単位のように）永久にかかるため、アルゴリズムの開発には役立ちません。これが私が試したことのリストと、なぜ/どのように失敗したかです。 vrtの概要を構築します。上記のように、これは8つのレベルで完了するのに2日以上かかります。それは私の目的には受け入れられません。 個々のタイルの概要を作成し、概要を含むvrtに何らかの方法でマージします。タイルのオーバービューを比較的迅速に作成できます（スーパーコンピューター）が、それらを再マージすることはできません。私は試した： 2a。概要付きのタイルのgdal_merge。ただし、概要は出力tiffに保持されません（または少なくともQGISで認識されません）。 2b。概要付きのタイルでgdalbuildvrtを使用しましたが、上記のように、概要は保持されませんでした。[これは正しくありません。編集を参照してください。] 2c。レベル1〜6のタイルの構築概要とvrt（直接オプション2b）でレベル7〜8を直接構築するハイブリッドも試してみましたが、これら2つのレベルだけではまだ時間がかかります。いくつかのテストを行ったところ、タイルの概要が実際にvrtの概要を作成するために使用されていることがわかりましたが、vrtの概要を完了するにはまだ1日ほどかかります。 だから私はここに誰かが私が次にどこに行くべきかについていくつかの提案があることを願っています。ここに私が検討しているいくつかのオプションがあります： 手動でグローバルピラミッドを手動で作成します。それらを.ovrファイルに再結合するのは注意が必要です。 マップサーバー（ジオサーバー）を使用します。私はこれについてほとんど知りませんが、プロセスに複雑さを加えている間に時間のハードルを克服できないのではないかと心配しています。 大陸またはその他の地域によってドメインを分割します。私は本当にこのオプションを避けたいです。 「なぜ地球全体を30mの解像度で表示する必要があるのですか？」1つの例：私は水のピクセルのマスクを（全体的に）取り、それをスケルトン化して川を見つけ、測定を実行します。私のスケルトン化アルゴリズムは少しの調整が必要で（枝刈り、ループの削除、一般的なクリーニングなど）、出力は必ず30mです。川や景観は世界中で多様であるため、実装した変更の影響を確認するには、周囲をパンできる必要があります。 また、QGISを調べて、巨大なラスターをより速くレンダリングするために使用できる設定がないことを確認しましたが、何も表示されませんでした。SSDドライブを購入するのに足りないので、私はそれができるだけ速く動いていると思います。（私のHDDのI / Oは〜250MB / sです）。 個々のタイルで概要を作成し、次にvrtを作成しても概要が維持されていることがわかりました。ファイルのメタデータのQGISの「Pyramid」セクションは空ですが、「Dimensions」セクションには概要の各レベルのエントリがあります（X 720000、Y 140、X 360000、Y 70など）。だから私は2bについて間違っていました。 また、すべてのタイルをQGISにプルしただけでは1分未満でレンダリングされますが、タイルを参照するvrtをプルした場合は、5分以上かかります（処理する）。 SSDを搭載したコンピューターでいくつかのテストを行ったところ、グローバルなvrts（概要なし）を適切な速度で正常に読み込み、表示、レンダリングできることがわかりました。私のコンピューターでも同じことができることを期待して、1TB PCIe SSDを注文しました。結果で更新されます。

10 qgis  gdal  performance  display  gdaladdo 

私のスクリプトは、ラインとポリゴンを交差させています。ライン数が3000を超え、ポリゴン数が500000を超えるため、長いプロセスです。私はPyScripterから実行しました： # Import import arcpy import time # Set envvironment arcpy.env.workspace = r"E:\DensityMaps\DensityMapsTest1.gdb" arcpy.env.overwriteOutput = True # Set timer from datetime import datetime startTime = datetime.now() # Set local variables inFeatures = [r"E:\DensityMaps\DensityMapsTest.gdb\Grid1km_Clip", "JanuaryLines2"] outFeatures = "JanuaryLinesIntersect" outType = "LINE" # Make lines arcpy.Intersect_analysis(inFeatures, outFeatures, "", "", outType) #Print end …

9 arcpy  geoprocessing  performance 

PythonウィンドウでPythonスクリプトを実行する場合と、ArcGIS Desktop 10.0のツールボックスからPythonスクリプトツールとして実行する場合で、パフォーマンスに違いはありますか？ ArcPyを使用してArcGISを実行する必要がある場合があります。私の最近の経験では、ツールボックスとpythonウィンドウで同じスクリプトを実行でき、ツールボックスは少し高速のようです。

9 arcpy  arcgis-10.0  performance  python-script-tool  python-window 

ジオプロセシングを行うクラスライブラリを作成しました。アドインは、非同期プロセスであるクラスを呼び出します。スレッドがSTAであり、arcobjectsがスレッドセーフであること（つまり、アドインから渡されない）であることを確認しました。すべてのアークオブジェクトはスレッド内に作成されます。 これはクラスライブラリであるため、winforms UIにアドインとしてラップしました。コードの両方のセットはまったく同じであり、テストはまったく同じデータを使用して実行されました。winformsとアドインの両方でコードが完成し、望ましい結果が得られ、メモリリークは明らかではありません。アドインの場合、この時点ではマップ期間との相互作用はなく、winformsコードにはマッピングまたは表示要素もありません。 UIの更新は、アドインとUIの両方の進行状況ダイアログの更新のみです。アドインはドッキング可能なウィンドウ（ユーザーコントロールUI）を使用しています。 私が見ている問題は、ライブラリがアドインから呼び出されると、コードの実行がwinformsアプリケーションから呼び出される同じコードよりも5倍遅いということです。 なぜこれが発生しているのか、どこを見ればよいのかについてのアイデア

9 arcgis-10.1  arcobjects  c#  performance  add-in 

ArcGIS Server 10.1またはその拡張機能（3D Analyst、Spatial Analystなど）はGPU処理を利用しますか？ デルには、GPUを含めるオプションがある新しいサーバー、R820があります。したがって、関心。

9 arcgis-server  performance  gpgpu 

ESRI ArcGIS DesktopワークステーションでのSSD（ソリッドステートドライブ）の使用をサポートする定量的な証拠を見た人はいますか？またはそのためのGISワークステーションはありますか？ SSDを使用するとパフォーマンスが大幅に向上する可能性があることを私は読み続けていますが、この主張を裏付ける数値は見ていません。生産性の向上は、シングルモニターセットアップからデュアルモニターセットアップへの切り替えに匹敵する可能性があると感じています。

9 arcgis-desktop  performance  hardware 

私はpostgisの初心者で、クエリのパフォーマンスに問題があります。 この私のクエリ： SELECT DISTINCT ON (userid) userid ,ST_AsText(position), timestamp FROM table1 WHERE ST_Intersects ( ST_GeomFromText('a multiypolygon geom goes here',4326),position) ORDER BY userid, timestamp desc 問題は、私のマルチポリゴンに非常に大きなポリゴン（単語のドキュメントでは600ページの長さです）が含まれていて、実行に2時間以上かかったことです。 クエリを最適化する方法または別の方法を使用する方法はありますか？ どうぞよろしくお願いします！

9 postgis  postgresql  query  optimization  performance 

Pythonを使用してPyQGISプラグインを開発しています。プラグインでのスレッドの実装中に問題が発生しました。使用中のすべてのジオプロセシングメソッドをラップするクラスを含むPythonスクリプトを記述しました。私が直面している問題は、メソッドをスレッドで処理することです。私の問題をより詳しく説明するために、次のようにメソッドを呼び出すUIがありますcalcNDVI()。 self.lst.calcNDVI(self.RedBand, self.NIRBand, None, self.outputRaster, self.sensorType, self.dataType, self.addToQGIS) この関数呼び出しは、すべての魔法を実行し、結果をQGISプロジェクトに追加するcalcNDVI（）メソッドを呼び出します。メソッド呼び出しは、いくつかの引数を渡すことにも関連付けられています。 多くのソースを調べてきましたが、アルゴリズムをスレッド化して実装する方法を理解できません。私が通ったコードはrunメソッドにすべてを実装しているため、クラスで処理するメソッドが複数あるため、実行が困難であり、実行するメソッドをユーザーが選択できるようにしたいUI。 処理に時間がかかりすぎるLandsatデータセットを処理しています。

9 python  pyqgis  qgis-plugins  performance 

ST_Unionコマンドを使用してPostGISで「ディゾルブ」操作を実行しようとしています。 入力層は確かに非常に大きく複雑です。「大きい」とは、57,771のフィーチャを意味し、頂点の数はフィーチャあたり4〜758,018の範囲であり、平均してフィーチャあたり約86の頂点です。頂点の数が10,000を超えるのは約10のフィーチャだけです。「複雑な」とは、ポリゴンに多数の穴、乱雑なオーバーラップ、アイランドなどがあり、大きなポリゴンには、小さなポリゴンの多くをカバーする境界ボックスがあり、おそらくインデックスの有用性が低いことを意味します。 問題は、クエリが非常に遅くなり、使用できなくなることです。私はここでポールの2009年の投稿を読んだので、私のクエリはまだかなり高速であるはずだと思いました。次のコマンドを使用しています。私は露骨に間違っている、または非効率的なことをしていますか？ SELECT ST_Union(f.geom) as geom, column1,column2,column3 FROM "inputlayer" As f GROUP BY column1,column2,column3 編集：私は使用しています： POSTGIS="2.1.4 r12966" GEOS="3.3.3-CAPI-1.7.4" PROJ="Rel. 4.7.1, 23 September 2009" GDAL="GDAL 2.0.0dev, released 2014/04/16" LIBXML="2.7.8" LIBJSON="UNKNOWN" TOPOLOGY RASTER PostgreSQL 9.3.5 on x86_64-unknown-linux-gnu, compiled by gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3, 64-bit 私がdbサーバーを実行しているマシンは、パワーのない仮想マシンです。SET work_mem = 50000のアイデアを試してみて、どうなるか見てみましょう！

8 postgis  geoprocessing  performance  union 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 昨年休業。 私の質問は、に似ているのPostgreSQLデータベースへのosm2pgsql経由遅いインポートおよびOSMデータのosm2pgsql輸入の最適化が、我々は現在、私は新しいものを開き、OSMデータの大規模なセットをインポートすることは非常にいくつかの問題を持っているよう。 大規模なデータセット（OSM Export of Europe）をpostgres DBにインポートする最良の方法は何ですか？ 私たちのコンピューターには32 GBのRAMが搭載されているので、そのすべてを使用できます。 いくつかのパラメーターを試しましたが、成功しませんでした...最後に試したのは osm2pgsql -c -S /usr/share/osm2pgsql/default.style --slim -d osm-europe -U postgres -C 25000 europe-latest.osm.pbf しかし、サーバーに32 GBのRAMが使用可能であっても、メモリーが不足しました。 pending_ways failed: out of memory for query result (7) Error occurred, cleaning up インポートコマンドをどのように改善しますか？ さらに時間がかかる場合でも...しかし、データをpostgres DBにインポートする必要があります。 タスクにEC2を使用することをお勧めしますか、それともセットアップはさまざまなパラメーターで動作しますか？

8 postgresql  openstreetmap  import  performance  osm2pgsql