イメージサービスは単に画像を提供するだけでなく、連鎖したラスター関数を使用して複数の重なり合うラスター データセットに対して動的なピクセルレベルの解析を行うこともできます。 イメージサービスは、特にタイルキャッシュから提供される場合、事前処理されたソース画像により非常に高速なパフォーマンスを提供します。 一方、動的イメージサービスは、サーバーにかかる追加の処理負荷のために応答が遅くなることがあります。 動的イメージサービスでは、ユーザーがマップをパンまたはズームするたびにデータが自動的に再処理されるため、高いパフォーマンスが重要です。 動的イメージサービスは通常、単純なタイプの解析であれば1秒未満の応答を生成します。 しかし、処理チェーンの複雑さや入力データセットの数によっては、より複雑な解析にははるかに長い時間がかかることがあります。 そのような状況でどのようにパフォーマンスを向上させることができるでしょうか？ この質問に答えるために、以下の要因が動的イメージサービスのパフォーマンスにどのように影響するかを調べる一連のテストを実施しました:<\/P>
<\/P>
この記事では、それらのテスト結果とパフォーマンス最大化のためのいくつかの提案を紹介します。 私のテストマシンはWindows 7 SP1およびArcGIS 10.2.1を実行するデスクトップコンピュータで、18GBのRAMと3GHzで動作するクアッドコアIntel Xeon W3550プロセッサを搭載しています。 テストデータは、それ以外は空の2TB SATAハードドライブに保存されており、テスト前にデフラグおよび統合されています。 テストはさまざまな条件下でサービスの平均応答時間を測定するよう構成されました。 「応答時間」とは、サービスがソースデータを取得し、処理し、出力画像を送信するまでの時間を指します。 送信時間はテストアプリケーションをサーバーマシン上で直接実行することで最小化しました。<\/P>
この情報は中級から上級のGISユーザーを対象として書かれています。 読者がイメージサービス、ラスター データと解析、ラスター関数、ジオプロセシング、モザイク データセット、地図投影、およびマップサービスキャッシュについて一般的な理解を持っていることを前提としています。<\/P>
マップスケールとソースデータ解像度<\/STRONG><\/P><\/P>動的イメージサービスによって解析用に処理されるピクセルは通常、ソースデータセットに格納されているピクセルと同一ではありません。 代わりに、ソースデータピクセルはまず現在のマップスケールに基づいてオンザフライで新しいサイズにリサンプリングされます。 この式は、データのマップ単位がメートルの場合のマップスケールとリサンプリングサイズとの関係を示しています:<\/P><\/P>リサンプリング後ピクセルサイズ = マップスケール * 0.0254\/96<\/A><\/P><\/P>リサンプリング後ピクセルサイズはジオプロセシング フレームワーク内の「解析セルサイズ」パラメーターに類似しており、「リクエストのピクセルサイズ」と呼ばれることもあります。 ズームアウトして小さいマップスケールになるにつれてリサンプリング後ピクセルサイズは増加し、最終的にはサービスがピラミッド内のピクセルからリサンプリングします。 ピラミッドからリサンプリングすることで、さまざまなマップスケール範囲でサービスのパフォーマンスが比較的一定に保たれます。<\/P><\/P>チャート1. 複数マップスケール範囲でバイナリオーバーレイ解析を行うイメージサービスのパフォーマンス.<\/P><\/DIV>パフォーマンスは依然としてマップスケールによって変動し、通常チャート1と似た傾向になります。 私は特定のマップスケールで100回連続してマップをパンする単一ユーザーをシミュレートするよう構成されたアプリケーションを使用してこれらの結果を生成しました。 チャートは異なるマップスケールで出力画像を処理および送信するためにサービスが要した平均時間を示しています。 この特定のサービスはモザイク データセット内の11個重複ラスター上でバイナリオーバーレイ解析を行うラスター関数テンプレートで構成されていました。 ソースデータセットのピクセルサイズは91.67〜100メートルでした。 ラスター関数テンプレートはバイナリ結果（各出力ピクセルが「適合」または「不適合」に分類される）を返すよう設定されていました。<\/P><\/P>応答時間が急激に低下する水平軸上の3点をご覧ください。 それらのマップスケールではリサンプリング後ピクセルサイズがソースデータ内ピラミッドのピクセルサイズと同じです。 リサンプリング処理時間が最も短い理由はソースデータピクセルとリサンプリング後ピクセル間でほぼ1対1対応しているためです。 この特定サービスを使用するクライアントアプリケーションは、そのスケールのみ使用するよう制限すれば劇的に高速な応答時間になります。 一つの方法としてタイルベースマップレイヤーを使用することがあります。 タイルベースマップを使用するWebマッピングアプリケーションは一般的にそのスケールのみ利用可能です。 最も一般的なタイル方式はArcGIS Online\/Bing Maps\/Google Mapsタイル方式（以下「AGOLタイル方式」と略称）です。 チャート内赤点線縦線はこのタイル方式レベル7〜12のマップスケールを示しています。 残念ながらこれらスケールはこのサービスが最も良好な性能となるスケールとはあまり近くありません。 ソースデータピクセルとタイル方式スケール整合には2つ選択肢があります:<\/P><\/P>データピクセルサイズと一致するカスタムタイル方式でカスタムベースマップを構築する.<\/LI>ベースマップタイル方式と一致するピクセルサイズになるようデータをサンプルまたはリサンプリングする.<\/LI><\/OL><\/OL>チャート2. 異なるソースデータピクセルサイズによるバイナリオーバーレイ解析サービス性能<\/P><\/DIV>チャート2 の水平軸はチャート1 のようなマップスケールではなく「リクエストのピクセルサイズ」を表しています。 オレンジ色グラフは青色グラフ（最初と同様構成）とは異なりResample<\/_geoprocessing_tool_> を使って38メートルピクセルへアップサンプルされたソースデータセットを使用した別サービス応答時間です。 ピクセル38mへのアップサンプルによってAGOLタイル方式スケールとの整合性が取れ、そのスケールで約1.5秒から約0.5秒へ処理時間が大幅短縮しました。 &amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;ampamp;さらにほぼすべてのスケールでパフォーマンス向上が見られました（最大スケール除く）。これはおそらくすべて38m解像度（91.67m,92.5m,100m の3種ではない）になったこと、および／または共通起点点設定（「Snap Raster」環境設定）によってソースデータ間でもピクセル整合性が取れたためと思われます。
リサンプリング後ピクセルサイズはジオプロセシング フレームワーク内の「解析セルサイズ」パラメーターに類似しており、「リクエストのピクセルサイズ」と呼ばれることもあります。 ズームアウトして小さいマップスケールになるにつれてリサンプリング後ピクセルサイズは増加し、最終的にはサービスがピラミッド内のピクセルからリサンプリングします。 ピラミッドからリサンプリングすることで、さまざまなマップスケール範囲でサービスのパフォーマンスが比較的一定に保たれます。<\/P>
正直言ってResampleツールによる解析用データ準備は元データより精度劣化した二次生成データとなるため理想的ではありません。この方法でも初期調査レベル解析用途には十分ですが可能なら望ましいピクセルサイズで新規一次生成データ作成がおすすめです。例えば土地分類ポリゴン利用可能なら既存土地分類ラスター再サンプルではなくPolygon to Rasterツールで望み解像度一次生成ラスター作成できます。
38m ピクセル時どれほど性能向上したか評価するため各スケール平均応答時間変化率計算し複数スケール平均値算出しました。
38m ピクセルへのアップサンプルによって最も悪い対象マップスケールで63.8% 応答時間短縮できました！38m は例示用選択肢一つでした。他にも他タイル方式スケール対応サイズ選択可能です。以下表にはAGOL タイル方式全マップスケールおよび対応するメートル・フィート単位ピクセルサイズ一覧記載しています。 小数度。 右側の3つの列は、ラスター データのサンプリングに対する推奨された値を提供します。 これらの提案は絶対的なものではありません。 データをこれらの推奨サイズに正確にサンプリングする必要はありません。 重要なのは、ターゲットのタイル スキームのスケールのサイズのいずれかよりわずかに小さいサイズを選択することです。<\/P>
ArcGIS Online\/Bing Maps\/Google Maps タイル スキームの地図スケールとピクセル サイズ<\/EM><\/P><\/A><\/P><\/P>ちなみに、データのピクセル サイズをベースマップ タイル スキームと一致させることは、タイル化されたベースマップ上に静的画像を重ねるワークフローにも役立ちます。 <\/SPAN>その場合、小縮尺で表示するためにラスター ピラミッドの代わりにモザイク データセット オーバービューを構築できます。 <\/SPAN>モザイク データセット オーバービューの優れた点の一つは、オーバービューの基本ピクセル サイズとスケール ファクターをターゲット タイル スキームに合わせて定義できることです。 <\/SPAN>この方法では、特定のタイル スキームに対応するためにソース データを新しい基本ピクセル サイズにリサンプルする必要がありません。<\/P>リサンプリング メソッド<\/STRONG><\/P><\/P><\/P>画像サービス リクエストで指定されるリサンプリング メソッド<\/A> <\/SPAN>もパフォーマンスに影響します。 <\/SPAN>どれを使用するかの選択は主に分析で使用されるデータの種類に基づくべきです。 <\/SPAN>チャート 3 は、異なるリサンプリング メソッドでのバイナリ オーバーレイ分析サービス（38 メートル データ）のパフォーマンスを示しています。<\/P><\/A>チャート 3. 異なるリサンプリング メソッドによるバイナリ オーバーレイ分析サービスの応答時間<\/P><\/DIV><\/P><\/P><\/P>バイリニア リサンプリングがデフォルト メソッドです。 <\/SPAN>他のメソッドの応答時間がバイリニアと比較して、テストした5つの地図スケールで平均すると次のようになりました:<\/P><\/A><\/P>ラスター フォーマット<\/STRONG><\/P><\/P>データの保存形式はパフォーマンスに大きな影響を与える可能性があります。 例えば、すべての地図スケールで平均した場合、バイナリ オーバーレイ分析サービスの応答時間は、ファイル ジオデータベース管理ラスターよりも GeoTIFF フォーマットで保存した方が36%短縮されました。 データ ソースとフォーマット<\/A> セクションでは、ASCII のような低速なフォーマットでない限り、元のフォーマットでデータを保持することを推奨しています。 内部タイル付き GeoTIFF は再フォーマット時に推奨される選択肢であり、ファイル全体の一部だけをカバーする長方形領域への高速アクセスを提供します。ピクセル タイプと圧縮<\/STRONG><\/P><\/P>ピクセル タイプはデータ内に格納される値の精度を決定し、パフォーマンスに大きな影響を与えます。 一般的に整数型は浮動小数点型より高速であり、低精度型は高精度型より高速です。 イメージ圧縮は状況によってパフォーマンスを向上または低下させる可能性があります。 圧縮がファイル サイズに与える影響については、Image Management ガイドブック内の「データ ソースとフォーマット」セクションをご参照ください。 ローカル ハード ドライブ上に保存されたデータのピクセル タイプと圧縮がパフォーマンスに与える影響を評価するため、15 のラスター データセットで非常に集中的なオーバーレイ分析を実行するよう構成された一群の画像サービスをテストしました。 サービスは分析データのピクセルおよび圧縮タイプ以外は同一設定でした。 テストはデータのピクセル サイズに対応する地図スケールで実施しました。<\/P><\/>チャート5＆6. 複雑なオーバーレイ分析を実行する画像サービスの平均応答時間とストレージサイズ対圧縮タイプ
ちなみに、データのピクセル サイズをベースマップ タイル スキームと一致させることは、タイル化されたベースマップ上に静的画像を重ねるワークフローにも役立ちます。 <\/SPAN>その場合、小縮尺で表示するためにラスター ピラミッドの代わりにモザイク データセット オーバービューを構築できます。 <\/SPAN>モザイク データセット オーバービューの優れた点の一つは、オーバービューの基本ピクセル サイズとスケール ファクターをターゲット タイル スキームに合わせて定義できることです。 <\/SPAN>この方法では、特定のタイル スキームに対応するためにソース データを新しい基本ピクセル サイズにリサンプルする必要がありません。<\/P>リサンプリング メソッド<\/STRONG><\/P><\/P><\/P>画像サービス リクエストで指定される
チャート 3. 異なるリサンプリング メソッドによるバイナリ オーバーレイ分析サービスの応答時間<\/P><\/DIV>
バイリニア リサンプリングがデフォルト メソッドです。 <\/SPAN>他のメソッドの応答時間がバイリニアと比較して、テストした5つの地図スケールで平均すると次のようになりました:<\/P>
ラスター フォーマット<\/STRONG><\/P><\/P>データの保存形式はパフォーマンスに大きな影響を与える可能性があります。 例えば、すべての地図スケールで平均した場合、バイナリ オーバーレイ分析サービスの応答時間は、ファイル ジオデータベース管理ラスターよりも GeoTIFF フォーマットで保存した方が36%短縮されました。
チャート5＆6. 複雑なオーバーレイ分析を実行する画像サービスの平均応答時間とストレージサイズ対圧縮タイプ
以下の表は、再フォーマットされたデータセットと元の倍精度浮動小数点データセットとの応答時間変化率を示しています。
オンザフライ投影
オンザフライ投影は ArcGIS プラットフォームの非常に重要な機能です。 私たち GIS ユーザーが地図内のすべてのデータセットが同じ座標系で保存されていることを確認する必要がなくなり、多くの作業時間を節約してくれました。 しかし、高速なパフォーマンスが求められる場合、この柔軟性と利便性がコストになることがあります。 以下のチャートはそのようなケースの一例です。
チャート8. 重み付けオーバーレイ分析を実行する動的画像サービスのパフォーマンス
チャート8 は Albers 投影で6つのデータセット上で重み付けオーバーレイ分析を実行するサービスのパフォーマンスを示しています。 上部グラフはサービス出力が Web Mercator (Auxiliary Sphere) に設定されている場合、下部グラフは出力座標系がデータと同じ場合です。 Web Mercator に再投影しない場合、すべての地図スケールで平均45% パフォーマンスが向上しました。 これはかなり極端な例です。 再投影によるパフォーマンスコストは入力および出力投影法の数学的複雑さに関連しています。 Albers のような等積投影法は Mercator のような円筒投影法より数学的に複雑です。 私はこれを証明するテストは行っていませんが、UTM と Web Mercator のような2つの円筒投影間で再投影するコストはこの例より少なく、地理座標から Web Mercator に単純投影するコストはさらに少ないだろうと予想しています。
オンザフライ投影を避けるには、ベースマップも含めてすべてのデータが同じ座標系であることを確認しなければなりません。 現在 Esri が ArcGIS Online 上で提供しているほとんどすべてのベースマップ サービスは Web Mercator (auxiliary sphere) にあります。 したがって、それらベースマップを使用する場合には、自分のデータも同じ座標系に変換しなければなりません。 これは状況によって許容できる解決策ですが、その結果として元々より位置精度が劣る二次生成データになりますので注意してください。 あるいは、自分自身で自分のデータと同じ座標系でベースマップを作成し、それを ArcGIS Server サイトへ公開するか ArcGIS Online にホスト マップ サービスとしてアップロードできます。この方法では、自分のデータ ピクセル サイズに合ったスケール レベルでカスタム タイル スキームによるキャッシュ ベースマップ作成がおすすめです。
リクエスト サイズ
リクエスト サイズはアプリケーション内地図ウィンドウサイズと直接関係し、REST APIでは出力画像内ピクセル行数および列数として指定されます。その影響測定には、一連テストを実施しました 再投影オンザフライテストに使用したweighted overlay analysis serviceでの異なるリクエストサイズにおけるパフォーマンスについて。リクエストサイズは400x400から2200x2200まで、100ピクセル刻み（例：500x500、600x600など）で増加させ、平均応答時間を測定しました。すべてのテストは、ソースラスター データセットの30メートルピクセルサイズに対応する1:113386の地図スケールで実行されました。<\/P>
チャート9. weighted overlay serviceの異なるリクエストサイズに対するMP\/sの平均スループット。<\/P><\/DIV>
チャート10. weighted overlay serviceの異なるリクエストサイズにおける平均応答時間。<\/P><\/DIV>
チャート9は、このサービスのスループットが約1000x1000ピクセルのリクエストサイズで約1.5～1.6 MP\/sで頭打ちになることを示しています。チャート10は、リクエストサイズがパフォーマンスに線形の影響を与えることを示しています。このサービスは、最大約1,440,000ピクセル（1200x1200のリクエストサイズ）までサブ秒応答時間を提供可能です。<\/P>
まとめ<\/STRONG><\/P><\/P>ラスター解析は多段階のデータ処理と分析を含むことがあります。複雑なオンザフライ処理チェーンはサーバーに重い処理負荷をかけ、パフォーマンス低下の原因となります。データをより効率的な形式に事前処理することで、再サンプリングやオンザフライ処理時の大幅なパフォーマンス向上が得られる場合があります。<\/P><\/P>タイル化されたベースマップ レイヤーを使用するアプリケーションでは、データのピクセルサイズをベースマップのタイルスキームのスケールに合わせることで最も大きなパフォーマンス向上が期待できます。「Map Scales and Source Data Resolution」のセクションではこのアプローチの理論と、ArcGIS Online／Bing Maps／Google Mapsタイルスキームを使用するアプリケーション向け推奨ピクセルサイズの表が説明されています。あるいは、開発者はカスタムタイルスキームでベースマップを構築し、解析データの既存ピクセルサイズに合わせることも可能です。<\/P><\/P>場合によっては、解析データのオンザフライ投影を避けることでサーバーへの処理負荷を大幅に軽減できます。これはベースマップと解析データが同じ座標系であることを保証することで実現します。オンザフライ投影のパフォーマンスへの影響は入力・出力座標系によって異なり、「On-the-fly Projection」のセクションで説明されています。<\/P><\/P>解析データのファイル形式、ピクセルタイプ、および圧縮タイプもパフォーマンスに大きな影響を与えます。GeoTIFF（内部タイル付き）は遅い形式からデータを再フォーマットする必要がある場合に推奨されます。低精度ピクセルタイプは高精度タイプよりも良好なパフォーマンスを示します。ピクセル圧縮は、データがサーバーによってどのように格納・アクセスされるかによってパフォーマンスを向上または低下させる可能性があります。これらのトピックは「Raster Format」および「Pixel Type and Compression」のセクションで説明されています。<\/P><\/P>クライアントアプリケーションも動的イメージサービスのパフォーマンスに影響します。サービス応答時間は最近傍補間指定時が最も短く、その次にバイリニア補間指定時となります。また、サービスパフォーマンスとアプリケーション内地図ウィンドウサイズには直接的な関係があります。これらは「Resampling Method」および「Request Size」のセクションで説明されています。<\/P><\/BODY><\/HTML>
I think you have the right idea. It's great that you are getting good performance at 1:10,000, even though one of the pyramid levels in your source data corresponds to a map scale of 1:10,500. That's the power of Image Server at work! Image Server is highly optimized out-of-the-box. For typical service configurations and usages, details like the pixel sizes of the source data are not significant factor in overall performance. However based on my results, I expect you would get even better performance if the pyramid in your data was at 9,500 instead of 10,500. Although it's possible that the improvement may not be easily perceived at the human level in your case. Putting this in perspective, the service I used to generate my results performed a server-side analysis on 11 different raster datasets. So the performance impact of resampling from 11 datasets with sub-optimal pixel sizes was greatly amplified. Typical image services do not require this amount of heavy lifting. But for cases like mine where performance was not satisfactory, this is one approach that can potentially bring huge gains in performance.
I had to find this post again after I realised I potentially have an image service with pyramids at inappropriate levels with respect to our basemap levels. Luckily, we are on the right side of this performance pattern and resampling is not required. However, this goes against my understanding as I thought we were going to have performance implications.
Let's say your basemap tiling has a level 14 at 10,000, should the pyramid be at 9,500 or 10,500? I had assumed (potentially incorrectly) that you would want 9,500 for the pyramid so that the resampling up to 10,000 when drawing in the web is minimal. What my tests showed was that our image service drew quickly at 10,000 even though the pyramid was at 10,500.
You are very welcome. Thanks for the compliment!
Six years later and this is still a phenomenal post. Thank you.
サインインしたメンバーは投稿、更新のフォローなどができます。初めてですか？無料アカウントを登録してください。
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.
