WMSは小規模な地図配信と地図画像生成に限って有効である
id:wata909 さんに触発されて、WMS に対する id:hfu の考えをまとめてみました。
d:id:wata909:20090217 ありがとうございます。ハイチでの地図作成作業において、主に衛星画像を編集者向け提供する手段として WMS が使用されたことは、「WMS は地図配信プロトコルとしては非現実的である」という論調を取る id:hfu にとってはショッキングな出来事でした。ただし、実例を調べる中で、考えを整理できるような気がしましたので整理してみます。
以下、id:hfu の blogsphere でのポジション上 、WMS の功績への言及や WMS への肯定的評価は省略していますが、WMS の功績は大きく、個人的に大きく感謝もしているのです。しかし、一方で、WMS を超えていくことでこそ Geo+Web の進展*1があると考えています。
ハイチに関しても、一般ユーザへの地図配信フェーズでは、やはり WMS は使われていない
d:id:wata909:20090217 で紹介されている、http://haiti.openstreetmap.nl/ を、多くのブラウザの付属機能である通信内容表示機能（例えば Safari であれば Web インスペクタ）で確認してみると、地図画像は http://live.openstreetmap.nl/haiti/15/9803/14662.png といった URL で配信されていることが分かります。これは、OpenStreetMap / OpenLayers で多用されているスタティックなタイル画像配信方法（d:id:hfu:20090402 及び d:id:hfu:20090407 参照）であって、WMS ではありません。
これは、一般向け提供に必要なデータ提供量は編集者向け配信とは桁の異なる量であり、そのデータ量を処理するのに WMS プロトコルでアフォードされる RPC 的な処理（ここで、「RPC vs REST」あるいは「SOA vs ROA」のライトモティーフを入れて下さい :-) ）では間に合わないことによるのではないかと推測します。
一般向け提供と編集者向け提供（あるいは専門家向け提供、つまり小規模な地図配信）との区切りですが、恐らく一専門分野を配信対象とするのであれば、それは一般向け提供ではなく、WMS が好適なプロトコルとなるのではないでしょうか。例えば、研究者向けの地図配信であれば、WMS は間違いなく好適です。この好適さを否定するわけではまったくない一方で、一般向け提供には WMS は好適ではないことは、明確にしておく必要があると考えています。
WMSは小規模な地図配信と地図画像生成に限って有効であるが、それらの用途に適切なプロトコルとも限らない
WMS プロトコルが RPC 的な処理をアフォードするために一般向け地図配信には向かないのであれば、小規模な地図配信や地図画像生成には WMS は理想的なプロトコルなのでしょうか。
小規模な地図配信には、WMS は理想的なプロトコルであるような気がしています。しかし、地図画像生成には WMS は理想的なプロトコルとは言えない気がしています。
地図画像生成には、WMS とはサーバとクライアントの立場が逆であるプロトコルが理想（ここ、脱線部）
というのは、地図画像生成においては、画像生成というメモリとCPU timeを消費するステップを分散化したいわけなのですが、WMS は画像生成部分をサーバとするプロトコルなのです。
地図画像生成を効率的に実施するという理想論からすれば、画像生成をクライアントで実施して、画像生成のキューイングをサーバで実施したいのです。WMS では、サーバとクライアントの向きがあべこべです。
もちろん、大量のサーバが一つのクライアントにぶら下がっているという頓智も可能ですが、自然ではないため、現実の仕様を書き下そうとしていくと、いろいろと無理が出てくることになります。既存の WMS サーバが、設置に時間と資源を要するものばかりということも、この頓智を実施するには足かせとなります。
理想論の世界ではむしろ、画像生成のキューがサーバから提供されていて、中断可能な分散クライアントが適宜キューからタスクを取得し、クライアントがサーバからソースデータを取り込んで分散して画像生成し、サーバに地図画像を戻すモデルのほうが現実的です。たとえば、beanstalkd と mapscript と PUT 可能な HTTP サーバ (sinatra とか) があれば、この処理モデルを非常に自然かつ低コストに書き下すことができるでしょう*2。こういう自然な構成をとることで、個々のクライアントをいつでも止めることができるなどの利点を簡単に実現できます。１クライアント・多WMSサーバという頓智的構成では、サーバの死活監視まで手作りでクライアントに実装しなければならなくなるなど、頓智のツケを払わさざるを得ないことになるでしょう。
理想と現実
このエントリは、プロトコルのアフォードする処理モデルまで含めた理想論ですが、現実論として、WMS を普及せざるを得ない、WMS を採用せざるを得ない、または普及している WMS を無茶して使っちゃったほうがむしろコストが安いという状況はあり得ます。例えば、Google が JavaScript にてこ入れした（AJAX のライトモティーフを入れて下さい）という過去の成功事例は、現実論ベースの選択です。このエントリを鵜呑みにして、理想論だけで技術的判断することも失敗の原因となります。
このことは、煎じ詰めると、正しい・正しくないは、成功する・失敗するとは別の軸であるということにすぎません。
