WMSについてごちゃごちゃ言ってみる

雑談 GIS

id:hfu:20100218 に触発されて、ちょっと考えてみました。

WMSで地図配信はキモチワルイんとは思うんだ…

RPC対RESTを整理するなら、個人的には、2要素間の結合度の疎密で選択が変わるのではないかと思ってます。疎ならREST、密ならRPC。かなりざっくりですが。
この場合で見ても、WWW地図アプリケーションでは疎となる場面が圧倒的に多いでしょうから、RPC的アプローチであるWMSは不適切なのは確かです。キモチワルイと。
ただし、現実面で、どうにもならない壁があり、私にはそれを崩すだけの力を持ち合わせていないので、当面はフタをしておくしかありません。

それは無茶だ

理想論の世界ではむしろ、画像生成のキューがサーバから提供されていて、中断可能な分散クライアントが適宜キューからタスクを取得し、クライアントがサーバからソースデータを取り込んで分散して画像生成し、サーバに地図画像を戻すモデルのほうが現実的です。

クライアントを信用できるかどうかが重要です。その機構を考えるだけでも大変になるでしょう。
そもそも一方向の流れをぶった切ると、そうとう話がややこしくなります。

生成・配送の明確な分割を私はキーとしたい

正直、地図画像生成とそれの配送を分離すれば十分だと思います。WMSは配送向きでないのに、それを配送も含ませているから、WMSがおかしいと感じるんじゃないかと。
具体的なプロダクト名を挙げると、GeoServerやMapServerといったWMSサーバと、GeoWebCacheといった地図画像キャッシュサーバとを組み合わせるというもの。
地図画像を逐次生成させたくないなら、GeoWebCacheに全部のキャッシュを作らせれば十分ことが足ります。これは、サーバにスタティックな画像をアップロードするのと等価でしょう。配送速度に違いがでるでしょうけれども、通信自体のボトルネックに埋もれる可能性もある程度とみてます。そうでなくても、少なくとも今後の計算機の能力向上で対応できるレベルかなと。

REST, RPC は設計思想の差とみたほうが良いのではないか

ところで、GeoWebCacheのレベルでは、タイリングWMSとTMS(GeoWebCacheはTMSとかも出せるらしい)とで、計算量で決定的な違いは出ません、たぶん。
計算量で決定的に効いてくるのは地図画像生成で、GeoWebCacheは地図画像生成に関与していませんから。
もちろん、TMS等のようなREST的アプローチの方が、すっきりします。できれば変えたいぐらい(変えてないのは勉強不足なためと思ってください)。
「RESTが良いのが結論なんか、どっちでも大差無いのが結論なんか、どっちやねん」と言いたくなるかも知れません。ややこしいですね。
REST的アプローチとRPC的アプローチとのどちらを選ぶかは、あくまで設計思想の差、サービスの見通しやすさのための選択なんでないかと。計算量ではないんじゃないかと。