ArcGIS 開発者ツールが扱う範囲の広さと Web サービスのコーディングに必要な作業は、経験のないユーザーが SOE (サーバー オブジェクト エクステンション) および SOI (サーバー オブジェクト インターセプター) を理解する妨げとなります。 このトピックでは、従来は GIS 開発者がカスタム コードを作成していた一般的な Web GIS タスクを示し、SOE や SOI の記述を必要としない代替手法について説明します。
印刷用のレイアウトの作成
Web アプリケーションに高品質な印刷機能を設置するような場合、多くの開発者はカスタム コードを使用して、マップ サービスの Layout オブジェクトにアクセスしていました。 これまでは ArcObjects を使用して、高品質のマップと周辺のエレメントを操作したり、大判の印刷可能なドキュメントを生成したりすることができました。
これに代わって、Python モジュールの arcpy.mp (ArcGIS Pro) を使用して、レイアウト作図およびマップ印刷のスクリプトを作成できるようになりました。 作成したスクリプトは、ジオプロセシング サービスまたは Web ツールを通して公開できます。 ArcPy を使用すると、レイヤーをマップに動的に追加したり、シンボルを更新したりするなど、マップ ドキュメントの詳細な操作が可能になります。 マップのレイアウトにアクセスして、テキストや画像などのエレメントを操作することもできます。
次のチュートリアルは、カスタム印刷レイアウトを共有する方法を示します。
シンボルとレンダラーの変更
これまで開発者がカスタム コードを必要としてきた別の理由は、マップ サービスで特定のレイヤーのシンボルを変更するためでした。 多くの場合、このワークフローではプールされないサービスを使用する必要があり、アプリケーションのスケーラビリティが制限されました。 一部の開発者はプールされるサービスを使用してこれを管理していましたが、複数のユーザーからのリクエストを処理するためにサービスの状態を切り替えることはパフォーマンスの低下につながる場合があり、開発者はマップ インスタンス自体の状態を正常に維持するために大きな責任を負う必要がありました。
ArcGIS Web API を利用すると、クライアント側のフィーチャ レイヤーまたはグラフィックス レイヤーを使用してフィーチャを簡単にシンボル表示でき、これらのレイヤーのレンダリング プロパティをいつでも変更できます。 表示可能なフィーチャのジオメトリと属性がすべてクライアントにダウンロードされるため、クライアントではアプリケーション開発者が定義した色、幅、またはクラス閾値を使用して簡単にフィーチャを描画できます。
フィーチャ レイヤーの手法は、フィーチャの対話操作やハイライト表示などを行う主題マッピングで特に効果的です。ただし、数千にのぼるフィーチャや非常に複雑なポリゴン フィーチャを操作する場合には適していません。 これらの場合は、シンボルの変更をサービス レベルでリクエストし、マップ サービスでマップ イメージをレンダリングするのが最も適した方法です。 この方法を行うには、これまで ArcObjects が必要でした。
マップ サービスのコンテンツとシンボルを実行時に変更できます。 マップ サービス レイヤー上でシンボルを変更するために、より詳細なカスタム コードを使用する必要はなくなりました。 これらの手法の代わりに、作成するマップで使用するコンテンツやシンボルをリクエストごとに決定できます。
マップ サービスでレイヤーのシンボルを実行時に定義するには、マップを描画するための Web サービス リクエストに、レイヤーの表示設定や範囲などの一般的な情報に加え、レンダラー情報を含めます。 ArcGIS Web API には、コンテンツ、レンダラー、クラス閾値、シンボルなどを簡単に定義できるよう、ユーティリティ クラスが含まれています。
マップ サービスでコンテンツとシンボルをリアルタイムに変更する方法の詳細については、「ダイナミック レイヤーについて」をご参照ください。
Web 編集
ArcGIS Server の初期のリリースでは、Web 経由でのデータの編集は、常にローカル (DCOM) 接続を利用するカスタム コードを通して実行する必要がありました。 フィーチャ サービスの導入により、このエクステンションを作成する必要がなくなりました。
REST API を使用すると Web 上でフィーチャ サービスのフィーチャを編集できます。 REST を通した編集が可能になっただけでなく、多くの一般的な編集メソッド (切り取り、切詰め、拡張、自動完成ポリゴン、形状変更など) がジオメトリ サービスの REST 実装を通して公開されているため、カスタマイズにも有用です。 フィーチャ サービスでは、バージョン対応の編集もサポートされています。
レガシー:
ArcGIS 10.1 よりも前のバージョンでは、ロング トランザクション モデルに従って、プールされないサービスを利用して編集を実行できました。 フィーチャ サービスでは、すべての操作はステートレスです。つまり、データベース レベルではロールバックできません (ただし、アプリケーションのビジネス ロジックではロールバック可能です)。 ArcGIS Web API と同様に、操作を元に戻したりやり直したりすることはできます。
ジオプロセシングによるビジネス ロジックの実行
一部の GIS アプリケーションは、一連のツールを使用して詳細な GIS ビジネス ロジックを実行します。 これらのツールでは、森林からの木材生産量の予測、レストランに適した立地の判定、有毒な雲の拡散予測などが行われます。 多くの開発者は、カスタム コードを使用してこれに適応してきました。
多くの場合、これらのプロセスは、ツールをグラフィカルに連結できる ModelBuilder で表現できます。 これらのジオプロセシング モデルは Web サービスとして公開でき、Web アプリケーションから使用できます。 この方法の利点は明らかで、ジオプロセシング サービスを使用することによりコード作成の多くを省略できます。 また、独自の SOE コードを記述する場合は難しい作業となる、ジオプロセシング サービスの非同期実行を利用することもできます。
ModelBuilder で結合できる多数の標準ツールによる柔軟性に加え、ジオプロセシングではカスタム ツールを開発することもできます。 最も簡単な方法では、単独で、またはモデル内の他のツールと組み合わせて実行する Python スクリプトを作成します。 このトピックの説明では、ArcPy を使用して Web 経由で高品質のマップを作成する方法の例を示しました。
Python またはその他の言語のどちらを使用する場合でも、カスタム ツールを作成することの利点は、作成したツールを別のワークフローで再利用できることです。作成したツールは他の標準ツールと同様に動作します。 また、カスタム コードは、ジオプロセシング サービスの非同期実行モデル内で実行できます。この点は、長期的に実行されるプロセスで非常に有効です。
ジオメトリ演算の実行
ジオプロセシング サービスは便利ですが、ジオメトリ操作の実行には不要になりました。
ArcGIS Maps SDK for JavaScript や ArcGIS Runtime SDK などの Esri クライアント API は、投影を実行したり距離を計算したりできる充実したローカル ジオメトリ ライブラリを提供します。
これらのクライアント API を使用しない場合は、SOAP ベースまたは REST ベースのジオメトリ サービスが必要な方法を提供しているかどうかを確認してください。 ジオメトリ サービスは、バッファー処理、空間リレーションシップの決定、距離と面積の計測などの基本的な GIS 操作を実行できます。 ジオメトリ サービスで一連のメソッドを呼び出し、マップ サービスの検索機能およびクライアント側のロジックと組み合わせる方が、ジオプロセシング サービスを使用するよりも簡単で高速な場合もあります。