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

パフォーマンスは、コンピューティングシステムがリソースをいかに効率的に使用するかに関係します。

7
GISCloudのようなレンダリングパフォーマンスでベクターポリゴンを作成しますか？
私は、ホバーイベントで各ポリゴンを異なる色で表示できるようにすることを目的に、そのようなデータを永遠にロードすることなく、Webマップを作成し、ベクトルポリゴンをオーバーレイできる堅牢なソリューションを探していました。 私の知る限り、キャンバス、SVG、Flashのいずれかでこれを達成するための3つの特定のオプションがあります。 Flashは、最速のレンダリングと最もクリーンな表示を提供するように思えるので、Apple iphone / ipadsで動作する場合、最良のソリューションになるようです。Canvasは2番目に最適な選択肢のように見えますが、マップ上に何百ものポリゴンが表示されている場合は非常に時間がかかりますが、SVGのレンダリングにはさらに時間がかかります。 私はほとんどこの問題の解決策を見つけることに希望を失ったが、今日、私はGISCloudという会社に出会いましたhttp://www.giscloud.com（現在は無料登録してベータ版）。 この会社は、SOMEHOWが地図上に数百のベクターをほぼリアルタイムでレンダリングする驚くべき方法を見つけ出しました。私は彼らのアプローチに驚き、コミュニティへの私の質問は、リーフレット、オープンレイヤー、ワックスなどの既存のテクノロジーで使用するために彼らのアプローチをどのように複製できるかに関するものです... この素晴らしいデモを見て、自分自身を見てみましょう：http : //www.giscloud.com/map/284/africa ページ上の任意のポリゴンにカーソルを合わせ、ズームコントロールをテストして、これらのポリゴンが実際にベクトルであることを確認してください。 firebugでリクエストを見ると、マップが特定のjsonファイルをリクエストしていることに気付きました。ズームレベル/エリアによっては、複数のjsonファイルが要求されているようです。 また、giscloudがページ上のデータを読み込むと、ベクター上にホバーすると、新しいリクエストを作成せずにすぐに色が変更されることをここで言及する必要があります。 例： http://cft1.giscloud.com/t/1316509973/map284/layer1156/3/3/3.json http://cft1.giscloud.com/t/1316509973/map284/layer1156/3/5/3.json http://cft1.giscloud.com/t/1316509973/map284/layer1156/3/4/4.json http://cft1.giscloud.com/t/1316509973/map284/layer1156/3/3/4.json http://cft1.giscloud.com/t/1316509973/map284/layer1156/3/5/4.json url構造は標準のタイルサービスロジック（たとえば、ズームレベルである3番目から最後のフォルダー）に従うと仮定しています。 いずれにせよ、これらのjsonファイルの実際のデータを分析しましたが、使用しているロジックは、これらのデータ値に基づいてベクターを作成する何らかのタイプのロジックに従っているようです。 幅/高さ：各JSON要求で提供されるデータの幅と高さを定義します ピクセル：ここでは、一般化されたポイントレベルの一般的なx / yピクセル座標に何らかの関係があると想定しているピクセル値を定義しますか？私は彼らが何らかの方法でズームレベルに応じて自動的に領域を単純化する方法を持っていると推測しています。私は、ピクセル座標を使用して、緯度/経度データと比較してロードする必要のあるデータのサイズを劇的に削減していると推測しています。 スタイル：ここでは、2つのRGB css値を定義します。「F」はポリゴンファイルの色を表し、「S」はポリゴンの境界線の色を表します。 geom：ここでは、マップコンテナウィンドウに基づいてデータが定義されている場所で、読み込まれているタイル内の各ポリゴンを明確に定義していると推測しています。また興味深いのは、各エントリがオプションの属性または機能リンク値として使用されると想定している「S」値を持ち、各エントリの最後に特定のベクトルごとのIDを定義するように見える領域があることです私が推測しているレイヤーIDは、呼び出されている各jsonタイルリクエストからのデータを何らかの形で結合するために利用されます。 また、要求されたタイルにロードする必要があるデータのサイズに応じて、各タイルにロードする必要があるデータを自動的に決定および分割する方法を何らかの方法で見つけたと想定しています。 以下は、これらのリクエストの内の1つを抽出した内訳です。 {"width":256,"height":256,"tile": {"pixels": [0,6461,-1,0,5,148,0,509,-1,10715,-1,1,-1,251,-1,1,-1,1,-1,251,-2,3,-1,255,-1,249,-2,5,-2,247,-1,509,-3,251,-1,2,-2,253,-2,252,-2,254,-1,255,-1,254,-1,255,-1,1276,-2,13,-1,233,-1,2,-1,253,-1,1,-1,255,-1,247,-1,1306,-1,1533,-1,1269,-1,1276,-1,2303,-1]}, "styles": [{"f":"rgb(99,230,101)","s":"rgb(5,148,0)","lw":"0"}], "geom": [ {"s":0,"p":[4,143,5,144,3,146,1,146,2,143,4,143],"c":"layer1156_5098"}, {"s":0,"p":[-2,143,0,140,2,141,2,144,1,146,-2,144,-2,143],"c":"layer1156_5067"}, {"s":0,"p":[7,143,5,144,4,143,2,143,2,141,5,138,6,139,5,141,7,143],"c":"layer1156_5051"}, {"s":0,"p":[10,141,11,137,12,137,14,137,12,142,9,143,9,142,10,141],"c":"layer1156_5041"}, {"s":0,"p":[1,136,0,140,-2,143,-2,136,1,136],"c":"layer1156_5038"}, {"s":0,"p":[8,143,5,141,5,137,8,136,10,137,10,141,8,143],"c":"layer1156_5033"}, {"s":0,"p":[5,137,2,141,0,140,1,136,1,136,2,135,3,136,5,137],"c":"layer1156_5028"}, {"s":0,"p":[10,134,12,136,11,138,8,135,10,134],"c":"layer1156_5020"}, {"s":0,"p":[-2,133,0,136,-2,136,-2,133],"c":"layer1156_5005"}, {...} ... ] …
7
実稼働環境向けにPostGISをチューニングしますか？
実稼働環境向けにPostGISをチューニングするときに役立つPostGISのドキュメントはありますか？ DBAと協力して、実稼働に適したPostgresql / PostGISインストールをセットアップしたいと思います。これを達成するためにいくつかの調整が必要であることを読みましたが、屈折のWebサイトで答えを見つけたいと思っていました。 これまでのところ、OpenGeoサイトでこのような参考資料を見つけました。 そして、この古いフォーラムの投稿は、私が役に立つと思った種類の情報です。これはおそらく基本的なDBのものですが、私にとっては良いものです。 PostGISの安定した実稼働インストールを達成する上で、他の人がどのリソースを助けているかを知りたいと思います。
4
ArcGISScriptingおよび大規模な空間データセットのパフォーマンス
現在、arcgisscriptingモジュールを使用して、少数のテーブル（合計8つ）で正規化されたかなり大きなデータセット（合計で約10,000レコード）を処理するPythonスクリプトを作成しています。このプロセスは、座標タプル（x、y）に基づいて機能を作成し、他の7つの表にある関係を使用してグラフ（ノードと線）を作成することで構成されます。最終的な出力は、関係を視覚的に表すノードおよびエッジの空間データセットを持つパーソナルジオデータベース（pgdb / fgdb）です。 私の最初の試みは、新しいジオデータベーステーブルとSearchCursorレコードセットのクエリを使用して、発生する多対多のリレーションシップのリンクテーブル（InsertCursor）を作成することでした。15〜20分の処理時間を除いて、これは非常にうまく機能しました。 PythonでcProfilerモジュールを使用すると、検索クエリを実行してリンクテーブルにカーソル（検索カーソルと挿入カーソル）の要求を取り込むときにパーソナルジオデータベースを「スラッシング」すると、パフォーマンスがひどくなります。 少しのリファクタリングで、処理時間を2.5分未満に抑えることができました。トレードオフは、コードでのジオデータベーススキーマの部分的な構築と、すべての関係が照合された後のarcgisscriptingカーソルの要求をInsertCursorsに制限することでした。 私の質問はパフォーマンスです。 大規模なデータセットを扱う際に、合理的な計算時間を維持するために人々が使用したテクニックは何ですか？ 最適化の検索で見逃したESRI推奨の方法はありますか？ 特にパーソナルジオデータベースからの場合は、アークギスクリプティングカーソルを作成するときに発生するオーバーヘッドを理解していますが、このサイトとGoogleからパフォーマンスに関連する回答を長時間検索した後、パフォーマンスは人々の努力の最前線ではないという印象を受けています。 ESRI製品のユーザーとして、これらのパフォーマンスラグを予想し、容認しますか？ 更新 この製品でいくつかの作業を行った後、空間情報を適切な形式からジオデータベースに変換するプロセスを採用した最適化手法のリストを蓄積しました。これは、パーソナルジオデータベースおよびファイルジオデータベース用に開発されました。ちょっとしたこと： データを読み取り、メモリ内で合理化します。これにより、時間を半分に短縮できます。 メモリ内にフィーチャクラスとテーブルを作成します。フィーチャデータセットキーワーク「in_memory」を使用してメモリをRAMディスクとして使用し、そこで機能を実行してからディスクに書き込みます ディスクに書き出すには、フィーチャクラスにはCopyFeatureclassを使用し、テーブルにはCopyRowを使用します。 これら3つのことには、100,000以上のフィーチャを30分から30〜40秒にジオデータベースに変換するスクリプトが必要でした。これには、リレーションシップクラスが含まれます。それらは軽く使用されるべきではありません。上記の方法のほとんどは大量のメモリを使用するため、注意を払っていないと問題が発生する可能性があります。
5
Rの多数のポリゴンによる切り抜き、マスク、およびラスターの抽出の速度を上げますか？
数千のポリゴン境界に基づいて、さまざまな土地利用タイプの面積と被覆率をラスタから抽出しています。個々のポリゴンを繰り返し処理し、特定のポリゴンのサイズまでラスターをマスクして切り取ると、抽出機能がはるかに高速に動作することがわかりました。それにもかかわらず、それはかなり遅いです、そして、誰かが私のコードの効率と速度を改善するための提案を持っているかどうか疑問に思っています。 私はこれに関連した見つけた唯一のものです。この応答使うことを提案ロジャーBivandによるGDAL.open()とGDAL.close()だけでなく、getRasterTable()とgetRasterData()。私はそれらを調べましたが、過去にgdalに問題があり、それを実装する方法を知るのに十分なほどよく知りません。 再現可能な例： library(maptools) ## For wrld_simpl library(raster) ## Example SpatialPolygonsDataFrame data(wrld_simpl) #polygon of world countries bound <- wrld_simpl[1:25,] #name it this to subset to 25 countries and because my loop is set up with that variable ## Example RasterLayer c <- raster(nrow=2e3, ncol=2e3, crs=proj4string(wrld_simpl), xmn=-180, xmx=180, ymn=-90, ymx=90) c[] …
3
PostGISでバウンディングボックスクエリを実行していますか？[閉まっている]
閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 地理情報システムスタック交換のトピックになるように質問を更新します。 去年閉鎖されました。 ほぼ200万行のPostgreSQLテーブルcoordinatesがあり、フォーム内にlong-lat フィールドがありますPOINT(-73.4938 33.2405)。 そのフィールドに地理空間インデックスがあると仮定すると、任意の境界ボックス内のすべての行を選択する最も効率的で最速の方法は何ですか？ ボックスはのようなものですSW long-lat: -74.0042 40.7688、NE long-lat: -73.8809 40.7984。
4
注入速度を最適化するにはどうすればよいですか？
osm2pgroutingで作成されたpostgisデータベースでpgroutingを使用しています。限られたデータセットで非常に優れたパフォーマンスを発揮します（3.5kの方法、20ミリ秒未満のすべての最短パスA *検索）。 ただし、europe.osmからより大きなバウンディングボックス（122kウェイ）をインポートしたため、パフォーマンスが大幅に低下しました（最短パスのコストは約900ミリ秒）。 A *を使用すると、これらのエッジのほとんどは、邪魔にならないため、決してアクセスされないと思います。 速度を改善するためにこれまでに行ったこと： ジオメトリ列にインデックスを配置します（顕著な効果はありません） メモリーを8GBから16GBに増やしました postgresqlのメモリ設定（shared_buffers、effective_cache_size）を（128MB、128MB）から（1GB、2GB）に変更します（顕著な効果はありません） ほとんどの作業はグラフが作成されているC Boostライブラリで行われているので、postgresqlを最適化しても良い結果が得られないと感じています。検索ごとにA *に選択した行のセットに小さな変更を加えると、ブーストライブラリはグラフをキャッシュできず、毎回122kのエッジをすべて再構築する必要があるのではないかと心配しています（非常にクエリごとの限定サブセット）。そして、実際の最短パス検索と比較して、それを行うのにどれだけの費用がかかるかわかりません。 122k以上のOSMデータセットでpgroutingを使用している人はいますか？どのようなパフォーマンスが期待できますか？どの設定がパフォーマンスに最も影響しますか？
6
非常に大きなシェープファイルのレンダリングパフォーマンスを改善する方法
100MBの.dbfと500MBの.shpファイルコンポーネントを持つポリゴンシェープファイルがあります。それがとても大きい理由は、それが地区全体の土地基地として分類されているからです。 ArcCatalogまたはArcMapでファイルを表示し、ビューウィンドウを少し移動するたびに、ファイル全体を最初から再描画する必要があります。空間インデックスとジオデータベースへのインポートを試みました-どちらのアプローチも、レンダリングに関して顕著なパフォーマンスの改善を提供しません。 Esriのヘルプページは、シェープファイルのパフォーマンスを向上させるために、ユーザーがファイルを一般化できることを示唆しています。これは明らかに機能しますが、情報を失いたくありません。ファイルを分割することは、その領域全体で多くのジオプロセシング/クエリを実行しているため、理想的ではありません。領域全体を一度に表示することは避けることができると思いますが、たとえば、クエリがファイルのどの部分を選択したかを確認した方がよい場合もあります。 レンダリングのパフォーマンスを改善するために他に取れる方法はありますか？ （理論的には、シェープファイルの「ピラミッド」を構築することが理想的です。ArcGISがこのようなアプローチをサポートしたことがない理由はわかりません-少なくとも私は知っています...）
2
以前のバージョンと比較して、データアクセスカーソルのパフォーマンスはどのように向上していますか？
データアクセスモジュールは、ArcGISバージョン10.1で導入されました。ESRIは、データアクセスモジュールを次のように記述します（ソース）： データアクセスモジュールarcpy.daは、データを操作するためのPythonモジュールです。編集セッションの制御、編集操作、改善されたカーソルサポート（高速パフォーマンスを含む）、テーブルとフィーチャクラスのNumPy配列との変換、バージョン管理、レプリカ、ドメイン、サブタイプのワークフローのサポートが可能になります。 ただし、カーソルのパフォーマンスが以前の世代のカーソルよりも向上した理由に関する情報はほとんどありません。 添付の図は、新しいdaメソッドUpdateCursorと古いUpdateCursorメソッドのベンチマークテストの結果を示しています。基本的に、スクリプトは次のワークフローを実行します。 ランダムポイント（10、100、1000、10000、100000）を作成します 正規分布からランダムにサンプリングし、カーソルを使用してランダムポイント属性テーブルの新しい列に値を追加します 新しいUpdateCursorメソッドと古いUpdateCursorメソッドの両方について、各ランダムポイントシナリオを5回繰り返し、平均値をリストに書き込みます 結果をプロットする daカーソルのパフォーマンスを図に示されている程度まで改善するために、更新カーソルを使用して舞台裏で何が行われていますか？ import arcpy, os, numpy, time arcpy.env.overwriteOutput = True outws = r'C:\temp' fc = os.path.join(outws, 'randomPoints.shp') iterations = [10, 100, 1000, 10000, 100000] old = [] new = [] meanOld = [] meanNew = [] for x in iterations: arcpy.CreateRandomPoints_management(outws, 'randomPoints', '', …
6
ArcGISとQGISのパフォーマンス速度がそれほど異なるのはなぜですか？
OK私はプログラマーではなく、多才なGISユーザーです。QGISはC ++およびArcGISで記述されていることを知っていますか？しかし、最近のほとんどのタスクでは、無料であるだけでなく、ユーザーエクスペリエンスが非常に優れているため、常にQGISを使用しようとしています。 そこにあるすべてのGISの達人は、これら2つのシステムの速度が異なる理由をいくつか教えていただけますか？正直なところ、ArcGIS 10を使用すると、その速度のために苦労します。また、8 GBのRAMを搭載したPCがあります。
3
ラスターデータベースのクエリを高速化する方法は？
私はこれらの列を持つpostgresql / postgisにラスターデータベースを持っています： （ID、rast、data_of_data）。 「ラスト」は、WKT形式のラスターファイルがある列です。WGS84システム（30.424、-1.66）および2002-01-09のポイントのDN値を検索するクエリの例は次のとおりです。 SELECT st_value(rast,(st_GeomFromText('POINT(30.424 -1.66)', 4326))) as val FROM my_table WHERE date_of_data='2002-01-09' これらの種類のクエリを高速化する方法（空間インデックスなど）はありますか？
3
GISベンチマークを実行していますか？
目的ではなく、時間のかかるタスク（陰影起伏の生成、ラスターの再投影、トポロジの構築など）で異なるGISソフトウェアのハードウェアパフォーマンス（特にCPU）を示すベンチマークをWebで検索しました（ただし、見つかりませんでした）。異なるGISソフトウェアを比較しますが、異なるCPU、マルチスレッド化の影響、ssdなどのパフォーマンスを比較します。それから始めた場合、誰でも結果を試すことができるように、公に利用できる標準化されたデータセットが必要だと思います しかし、そのような比較がすでにどこかに存在するかどうか誰もが知っていますか？
2
PostgreSQL / PostGIS空間インデックス-スピードアップなし
PostgreSQL / PostGISデータベースに空間テーブルがあります。その中のすべての行はポリゴンを表します。次の形式です。 +----+--------+ |gid | way | +----+--------+ |241 | 01030..| 幾何学的列は、ポリゴンのジオメトリを含む「ウェイ」です。WKTでは、POLYGON（（ '....'））です。2つのポリゴンが相互に含まれているかどうかをテストするために、このテーブルで多くのST_Containsクエリを実行しています： Select ST_Contains(a.way, b.way) From table AS a, table AS b Where a.gid = 15 And b.gid = 16 このクエリを高速化する方法を疑問に思っていて、テーブルに空間インデックスを追加しました。 CREATE INDEX table_way_gist ON table USING gist(way); しかし、実際にはスピードアップは見られません。ST_Containsクエリを実行する前に、テーブルにすべてのポリゴンを入力した後、インデックスを作成します。テーブルを埋める前にインデックスを追加する必要がありますか？インデックスを操作するためのテーブルには特別な要件がありますか？幾何学的列のウェイの投影（srid）は900913に設定されます。 私は使用しています：psql（PostgreSQL）9.1.4 / POSTGIS = "1.5.3"
1
ArcPy Cost Path AnalysisツールがArcObjectsよりも高速である理由を理解できますか？[閉まっている]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 閉じた3年前。 Pythonを使用してジオプロセシングスクリプト/サービスを作成しましたが、ArcObjectsを使用して同等の操作を実行するとパフォーマンスが向上するという印象を受けました。 私が投稿したのArcGIS ServerのGPサービス- RasterIO.dllクラッシュのArcSOC.exeをし、ArcGISのジオプロセシングスクリプトは、デスクトップに罰金を実行しますが、ジオプロセシングサービスとしてクラッシュしますか？Spatial Analystツールを使用してジオプロセシングサービスとして機能するジオプロセシングスクリプトを取得する方法について、過去数日間にわたって説明しました。私の締め切りはすぐに近づいているので、希望の機能を達成するためにSOEルートに行くことにしました。 .NET ESRI.ArcGIS.SpatialAnalyst.RasterDistanceOpClass、特にCostDistanceFull（）およびCostPath（）メソッドを使用すると、ArcObjectsでコストパス分析を取得するのは比較的簡単でした。 私が物事をどのように行っているかのコードスニペット： Python # Get Cost Path Origin and Destination Points inputPointsShp = 'D:/RasterStuff/test_points.shp' arcpy.MakeFeatureLayer_management(inputPointsShp,"origin",' "TYPE" = \'ORIGIN\' ') arcpy.MakeFeatureLayer_management(inputPointsShp,"destination",' "TYPE" = \'DESTINATION\' ') # Check out the ArcGIS Spatial Analyst extension license arcpy.CheckOutExtension("Spatial") # Execute CostDistance outCostDistance = CostDistance("origin",SOURCE_RASTER,"#","backlink") # …
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.