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