ほとんどのユーザーは、マップやアプリを通じて地理空間リソースを操作します。 これらのマップとアプリは、レイヤーと Web サービスに依存しており、ユーザーのニーズに合わせて、これらの各タイプのリソースの設定を最適化できます。
Web GIS コンテキストの Web アプリケーションは、通常、Web サーバーから配信され、クライアント ブラウザーでレンダリングされる静的 HTML、JavaScript、および CSS ファイルで構成されます。 多くの標準アプリケーションは ArcGIS Online または ArcGIS Enterprise デプロイメントの一部としてホストされますが、外部で開発されたアプリケーションは、ArcGIS Web Adaptor をすでにホストしている Web サーバーを含む任意の Web サーバーでホストできます。 Web アプリケーションを最適化する方法について、以下に説明します。
アプリケーションをデプロイする前に、構築プロセス (縮小またはバンドルも含まれ、縮小化やバンドルと呼ばれることもあります) を使用して、アプリケーションの静的アセットのサイズと複雑さを減らしたり、これらのファイルから不要な情報を削除できます。 正しく適切な構築プロセスを作成する方法は多数ありますが、これらのプロセスは多くの場合、Web アプリケーションの作成に使用されるアプリケーション フレームワークと密接に関連しています。
ArcGIS Online でホストされている Web アプリケーションは、デプロイメント前に自動的に構築されますが、カスタム アプリケーションでは、静的アセットを最適化するために追加のプロセスが必要になる場合があります。
Web アプリケーションのパフォーマンスを最適化するため、Web アプリケーションの静的アセットに対して HTTP 応答のキャッシュを有効にする方法も使用できます。 この構成では、エンド クライアントが Web サーバーからの応答ヘッダーを受け取り、静的アセットをクライアントにキャッシュできることと、そのアセットをキャッシュできる期間が示されます。 これによって、そのファイルの内容はすでにクライアント コンピューターにローカルに保存されており、キャッシュの有効期限に達するまでそのまま再利用されることで、クライアント ブラウザーがアプリケーションを再読み込みするとき、完全なラウンドトリップのリクエストは必要ありません。
HTTP レスポンスのキャッシュは、Web サーバー、リバース プロキシー、またはアプリケーション アクセラレーション ソフトウェア レイヤーを通じて、特定のファイル タイプに対して選択的に有効化できます。 静的アセットのレスポンス キャッシュを有効にすると、リピート ユーザーのアプリの読み込みが速くなり、全体的なエクスペリエンスが向上します。
ArcGIS では、Web マップは共有されるように設計されているため、ユーザーは共通の興味や関心のあるエリアを視覚化して操作できます。 Web マップは、あらゆる種類のデータや解析結果を対象ユーザーに広める効果的な方法です。 Web マップの対象範囲は広い場合があるため、Web マップを作成する際には、さまざまな設計の側面を事前に考慮することが重要です。
Map Viewer でマップ レイヤーのスタイルを設定する場合、スタイル ウィンドウにデフォルトで表示されるスタイル設定オプションは、データの性質によって決まります。 カラー ランプ、ラインの太さ、透過表示、シンボルなどのグラフィックス エレメントを選択してみて、選択したエレメントがどのようにマップ上に反映されるかをすぐに確認することができます。 シンボルを効果的に選択することで、マップ ユーザーはマップ内の情報を理解しやすくなります。
シンボルは、描画のパフォーマンスにも影響します。 複雑なマルチレイヤー シンボルは、レンダリングに大量の計算リソースを消費する可能性があります。 カスタム シンボルでは、レイヤーを描画するために追加のクエリーが必要になる場合があります。 クライアントごとにシンボルのレンダリング方法が異なるため、マップのレンダリングが求められるすべてのクライアントでパフォーマンスをテストする必要があることに注意してください。
Web マップでのレイヤーのスタイル設定の詳細については、次のリソースをご参照ください。
特定の縮尺で表示される個々のフィーチャが多数あるレイヤーは、描画に時間がかかり、空間パターンの識別が困難になる可能性があります。 クラスタリングやビニングなどのクライアント側の集約手法により、描画する頂点の数を減らして、パフォーマンスを向上できる場合があります。
たとえば、レイヤーに 100,000 個のポイントが含まれていて、100 個のクラスターに集約されている場合、クライアントは 100,000 ポイントではなく 100 ポイントを描画するだけで済みます。 フィーチャを集約すると、マップ ユーザーは大規模データセットの空間パターンも確認しやすくなります。 ほとんどの場合、クラスタリングまたは集約されたフィーチャは異なるズーム縮尺で再レンダリングされるため、ユーザーは適切な縮尺に達した後も個々のフィーチャにアクセスしたり、その分布を確認したりできます。
クライアント側の集約の詳細については、次のリソースをご参照ください。
コンテンツが描画されるズーム レベルの指定は、表示範囲の設定または縮尺の依存関係の構成と呼ばれます。縮尺の依存関係を適切に構成すると、Web マップ内のレイヤーは、レイヤー内のフィーチャがマップ ユーザーに関連する縮尺の範囲でのみ描画されるようになります。 たとえば、表示範囲プロパティを使用して、個々の建物を区別できる縮尺にマップを拡大した場合にのみ、個々の建物フットプリントが描画されるようにすることができます。
表示範囲の設定の詳細については、次のリソースをご参照ください。
Web マップ内のレイヤーには、特定のユース ケースに必要となる以上の情報が含まれていることがよくあります。 マップがリクエストおよびレンダリングする必要のあるフィーチャの数を減らすには、属性フィルターを使用します。 フィルターを使用すると、マップのレンダリング パフォーマンスが向上するだけでなく、マップ ユーザーがユース ケースに関連する情報に集中しやすくなります。
時間でフィルターするときに、多数のユーザーがマップにアクセスする場合は、「先週」などの動的な相対時間クエリーは避けてください。 このようなクエリーは、現在の時刻に対して常に再評価される必要があるため、キャッシュを効果的に使用できません。 代わりに、レイヤーのテーブルに格納されている属性に対して絶対クエリーを使用してみてください。
フィルターの使用の詳細については、次のリソースをご参照ください。
Web マップ内のデータが更新されても、マップはデフォルトで更新されません。 ただし、レイヤーごとに更新間隔を定義して、レイヤーをデータで更新し続けることができます。 更新間隔を設定すると、Web マップはマップ インターフェイス全体を再読み込みすることなく、定期的なスケジュールでレイヤー データを取得します。 この構成により、マップ ビューを最新の状態に保つことができますが、サーバーの負荷も増加します。 経験則として、更新間隔は、ユーザーが Web マップまたはアプリケーション セッション中に変更を確認する必要があるほど頻繁に変更されるデータに対してのみ使用し、変更頻度の低いデータではマップの更新または新しいセッションを利用します。
更新間隔の構成の詳細については、次のリソースをご参照ください。
シンボル、フィルター、表示フィールドなどのレイヤーの構成設定は、Web マップ、レイヤーのデフォルト ビュー、またはレイヤーへの参照 (元のサービスを参照するフィーチャ レイヤー) として保存できます。 1 つのレイヤーを複数の Web マップで使用できる場合は、構成をレイヤーまたは参照レイヤーに保存して、新しい Web マップごとにレイヤーを再構成しないようにします。 レイヤーには、最適化されたジオメトリーや属性インデックスなど、Web マップとは別の独自の構成設定もあります。 レイヤーに保存された最適化は、そのレイヤーが追加されるすべての Web マップにデフォルトで適用され、個々の Web マップは、独自のコンテキストでこれらの設定をオーバーライドすることもできます。
レイヤー設定の保存の詳細については、次のリソースをご参照ください。
レイヤーにはいくつかの異なるタイプがあり、それぞれのタイプで最適なユースケースが異なります。 以下は、ArcGIS Online と ArcGIS Enterprise の両方で使用できる最も一般的なレイヤー タイプの一部です。
レイヤー タイプの詳細については、次のリソースをご参照ください。
ArcGIS Online と ArcGIS Enterprise の両方のホスト フィーチャ レイヤーから、ホスト フィーチャ レイヤー ビューと呼ばれる個別のアイテムを作成できます。 このビューは、同じデータを参照しながら、基になるホスト フィーチャ レイヤーとは異なる設定を使用できます。
ビューの一般的なユース ケースは、基になるホスト フィーチャ レイヤーに加えられた更新が自動的に反映される読み取り専用レイヤーを作成することです。 ビューには独自の共有および編集設定があるため、読み取り専用ビューを組織全体と共有すると同時に、編集可能なホスト フィーチャ レイヤーを編集者とのみ共有できます。
ビューは、レイヤーの異なるユースケースが複数ある場合にも適しています。 それぞれ独自のシンボルまたはフィルター設定を使用するか、または原点レイヤーの特定の属性のみを含むさまざまなビューを構成できます。
ソースのスワップを使用してビューを更新することで、大規模なデータ更新を行う際の中断を簡単に最小限に抑えることもできます。 ソース データを直接更新する代わりに、新しいデータを使用して新しいホスト フィーチャ レイヤーを作成し、その新しいレイヤーをビューのソースとして設定できます。 この戦略により、ソースをスワップする前に新しいレイヤーを十分にテストし、ビューを使用するユーザーに影響を及ぼす前に、更新されたデータの問題を修正できます。 また、ソースのスワップは、大量のデータをレイヤーに追加したり、レイヤーを上書きしたりするよりもはるかに高速です。
ホスト フィーチャ レイヤー ビューの詳細については、次のリソースをご参照ください。
一部のライン レイヤーとポリゴン レイヤーには、使用される縮尺で必要となる以上の頂点があります。 ArcGIS Online のホスト フィーチャ レイヤーの場合、これ以上の頂点が必要ない縮尺まで縮小表示したときに、レンダリングする頂点の数を減らすようにレイヤーを最適化できます。 これと同じ戦略をホストされていないレイヤーに適用するには、詳細データをジェネラライズし、縮尺の依存性を使用して、ジェネラライズされたレイヤーを小縮尺で表示することで、最大解像度のデータが大縮尺で表示されるようにします。
時間対応レイヤーを使用すると、時間に関するクエリーとフィルター処理が容易になります。 この機能により、ユーザーは特定の時間に何が起こったか、または将来何が起こるかを確認できます。 また、クライアントがリクエストしてレンダリングするデータを、関心のある期間に関連するデータのみに制限することで、レイヤーのパフォーマンスを向上させることもできます。 時間対応は、マップ/フィーチャ/イメージ サービスおよびレイヤーに対して構成できます。
時間対応レイヤーの詳細については、次のリソースをご参照ください。
マップ内のレイヤーを使用すると、ユーザーは Web サービスの機能にアクセスできます。 ArcGIS Enterprise に公開されている一部のサービスには、サービスを最適化するために個別に構成できる独自の設定があります。
ArcGIS Server では、マップ サービスとイメージ サービスは、サーバー インスタンス プロセスのプールを使用して実行されます。 次のリンクでは、サーバー リソースのパフォーマンスとリソース使用率を最大限に高めるためのこのプールの構成と調整について説明します。
実行中の各サービス インスタンス プロセスは、リクエストをアクティブに処理していない場合でも、メモリーを消費します。 マップ サービスとイメージ サービスは、共有リソース プールを利用することで、複数の異なるサービスにサーバー プロセスの単一のプールを使用できます。 共有インスタンスを利用すると、リクエストをアクティブに処理していないサービスのメモリー使用量が減少します。
ArcGIS Enterprise での共有インスタンスの使用の詳細については、次のリソースをご参照ください。
イメージ サービスは通常、一般的なデータ ストレージの最適化を利用できるジオデータベース オブジェクトであるモザイク データセットから構築されます。 さらに、イメージ サービス固有の最適化手法もいくつか検討すべきです。
イメージ サービスとモザイクの最適化に関するその他のリソースについては、ArcGIS Imagery Workflows の Web サイトをご参照ください。