WMSとSVG Mapの関係
以前の記事で指摘したように、WMSには問題点があります。SVG Mapは相補的にそれを解消する手段を提供することができます。そこで、以下にSVG MapとWMSの仕様の具体的な整合点を記載します。
仕様の相互参照：
- WMSにとって、SVGは地図描画形式の一つとして規定されています。
- SVG Mapにとって、WMSのGetMapプロトコルはURLのquery partの拡張の一つとして扱うことができます。
従って相互に整合しているといえるでしょう。
地図の地理座標：
- SVG Mapは地図データにメタデータとして地理座標を埋め込みます。
- WMSでは地図の地理座標はプロトコルのquery partに現出します。
WMS仕様のサーバからダウンロードした地図は、リクエストしたパラメータを地図データとは別に記憶しておかないと地理座標を失ってしまいます。SVG Mapはこの問題を解決するでしょう。
タイリング：
- SVG Mapは、コンテナSVGデータを作ることで、タイリングをサポートします。コンテナSVGデータはタイルデータをURLによって参照します。
- WMSは任意の区画のタイルを生成することができます。タイルは拡張されたURL(GetMapリクエスト)によってアクセスすることができます。
SVG MapのクライアントはコンテナSVGデータに記載されたタイルデータのURL以外へのアクセス方法を知りません。すなわち、これらのURL以外のアクセスは起きないので、WMSのサーバはコンテナSVGデータに記載したURLをキャッシュすることで、高速化を実現できます。
レイヤリング：
- SVG Mapは、コンテナSVGデータを作ることで、レイヤリングをサポートします。コンテナSVGデータは各レイヤーをURLで参照します。
- WMSは任意のレイヤーを生成することができます。レイヤーは拡張されたURLによってアクセスすることができます。
一方、サーバ側でのレイヤリングのサポートは性能面で難題です。
以上より、WMSの拡張されたhttpプロトコルの規定とSVG Mapは良く整合し、補完関係を持つことができるでしょう。
ＷＭＳの固有なＸＭＬ言語：
しかし、SVG MapはSVG形式以外のデータを基本的にはサポートしません。（ただし、PNGとJPEGはサポートします。）すなわち、WMSで規定されたXML言語（GetCapabilityやGetFeatureInfoリクエストのレスポンスデータ）の解釈は、SVG Mapの仕様の範囲外です。しかし、その言語が実現するかなりの機能は、コンテナSVGに変換することができるでしょう。この変換はデータ作成時のバッチ処理、サーバ側の動的処理、クライアント側のjavascriptによる処理などで実現できるでしょう。変換可能な具体的な機能は以下の通りです。
- サーバが提供する地図の範囲：SVG Mapビューアは、コンテナSVGとして展開されたURL以外へのアクセス方法を知りません。すなわち、地図サービスの範囲はコンテナSVGとして展開することでクライアントに伝達できます。
- サーバが提供するレイヤーの種類：SVG Mapビューアは、コンテナSVGとして展開されたURL以外へのアクセス方法を知りません。すなわち、地図サービス提供するレイヤーの種類はコンテナSVGとして展開することでクライアントに伝達できます。
GetMapプロトコル：
一方、SVG Mapのプラットホームにとって、ビューアの地理的なビューボックスの値をサーバに通達するケースはしばしば考えられるでしょう。従ってその手段の共通化は有意義でしょう。そして、この手段としてhttp GETのquery partを用いることは妥当です。その具体的な仕様として、WMSの拡張されたHTTPプロトコルのうち、GetMapリクエストを利用することができるでしょう。この仕様をSVG Map Profileの仕様として公開する予定です。
