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