ArcGIS Web Mapping（JavaScript, Flex, Silverlight）を使用して作成された Web GIS アプリケーションでは、クライアント側で ArcGIS Server から取得した GIS データをグラフィックとして動的に描画することができます。描画されたグラフィックはクライアント側にオブジェクトとして存在するため、ユーザのマウス操作などのアクションによってシンボルを変えるなどの対話的な操作に利用することができます。
一方で、それぞれのレコードをオブジェクトとしてクライアント側に生成、保持する必要があるため、あまりに大量のグラフィックを地図上に描画すると、アプリケーションのパフォーマンスが劣化してしまいます。描画するグラフィックのレコード数によるパフォーマンスの影響は、Esri がホストしている以下のサンプル アプリケーションで体感して頂くことができます。
Display an Arbitrary Number of Points（任意数のポイントの追加）
この Web GIS アプリケーションでは、[Number of points:] に指定した任意の数のポイント グラフィックを地図上に追加することができます。追加するには [Draw] ボタンを、追加したポイントを削除するには [Clear] ボタンをクリックしてください。またポイントに使用するシンボルも Circle（シンプル マーカー シンボル）、Text（テキスト）、Picture（ピクチャ マーカー シンボル）から選択することが可能です。
上記のサンプル アプリケーションの場合であれば、1,000～2,000 ポイントを描画したとしても、パフォーマンスに比較的大きな影響は与えずに地図ナビゲーション操作が可能です。しかし描画するグラフィックのレコード数を増加させるにしたがって、初期表示にかかる時間や地図ナビゲーション操作のパフォーマンスが劣化していくことが確認できます。
描画するグラフィックのレコード数とパフォーマンスの関係には、レコード数だけでなくシステム構成などの様々な要因が影響するため一概にパフォーマンスを維持できる最大レコード数を定めることはできませんが、経験則からいえば、ポイント グラフィックの場合、描画するレコードが 3,000 レコードを超えるとパフォーマンスに影響すると考えることができます。
またポイント グラフィックに使用するシンボルも描画パフォーマンスに影響を与えます。同じ 1,000 レコードのポイント グラフィックを描画する場合でも、単純なシンプル マーカー シンボルを使用する場合よりも、より複雑なピクチャ マーカー シンボルを使用した場合の方が、描画により長い時間を要します。
またここで注意していただきたいのは、たとえ 1,000～2,000 ポイントであればパフォーマンスに影響なく描画できるとしても、それは決して推奨される地図データの描画方法ではないという点です。冒頭でも紹介したように、グラフィックによる地図データの描画は、ユーザのアクションにグラフィックが対話的に反応することを目的としています。ユーザの操作対象となるグラフィックが一つの画面上に数千レコードも存在する設計は、ユーザ フレンドリーなアプリケーションの実装方法とは言えません。一般的な Web GIS アプリケーションでは、描画するグラフィックのレコード数は多くとも数百レコードにとどめるべきです。
大量のポイント フィーチャの分布状況を描画したいのであれば、ヒートマップ、クラスタリング、ダイナミック マップ サービスなどの多くの別の手段が存在します。例えば ArcGIS Server 側で地図画像を生成するダイナミック マップ サービスであれば数千レコードのポイント データでも高速に描画することができます。
Incrementally Add U.S. County Polygons To a Map（任意数のポリゴンの追加）
この Web GIS アプリケーションでは任意の数のポリゴン グラフィックを地図上に追加することができます。基本的な操作は前述のアプリケーションと同じであり、[Number of polygons:] に指定した任意の数のポリゴンを地図上に追加することができます。追加するには [Draw] ボタンを、追加したポリゴンを削除するには [Clear] ボタンをクリックしてください。
ポリゴン グラフィックの場合においても、ポイント グラフィックの場合と同様に、描画するグラフィックのレコード数は多くとも数百レコードにとどめるべきです。
また、ポリゴンやライン グラフィックではアプリケーションのパフォーマンスを最適化するために、描画するグラフィックのレコード数に加えて、地物形状の複雑さを考慮する必要があります。クライアント側で地物形状をグラフィックとして描画するには、その地物形状を構成する構成点の座標値を取得する必要があるため、描画するグラフィックの形状が複雑であればあるほど、サーバ側から取得しなければならない情報が大きくなります。
ArcGIS Web Mapping においてサーバ側からグラフィック情報を取得する一部のクラス（FeatureLayer や Query クラス等）では、maxAllowableOffset と言うプロパティを使用して、形状を単純化した上でサーバ側からグラフィックを取得することができます。以下の例は、maxAllowableOffset プロパティの使用例です。東京都の市区町村界ポリゴンをクライアント側にグラフィックとして描画する際に、maxAllowableOffset プロパティを使用しない場合（図 1）では、取得するデータ量が約 173KB であるのに対して、maxAllowableOffset プロパティを使用した場合（図 2）は、データ量が約 22KB と大幅に削減されます。少しわかりづらいですが、図 2 のほうがポリゴンの輪郭が単純化されています（maxAllowableOffset プロパティの挙動については、上述した任意数のポリゴン追加アプリケーションにおいて、[Use maxAllowableOffset:] のチェックボックスのオン・オフにより確認することができます）。
本稿では紹介していませんが、クライアント側でグラフィックとして地物を描画するには、サーバから取得する属性情報の量も関係します。取得するグラフィックのレコード数、シンボル、図形形状の複雑さ、属性情報といった複数の要素を常に考慮し、ユーザ操作に必要な最小限の情報をサーバから取得することは、サーバ側の負荷を軽減しシステム パフォーマンスを最適化するだけでなく、結果として必要な情報のみを簡潔に伝えることができるシンプルでわかりやすい Web GIS アプリケーションをユーザに提供できることになりますので、ぜひ取得情報のスリム化に挑戦してみてください。