地理データの Web 流通のパターン言語

geo+web

ロカポブログさんのロカポーター誕生の記録（６）を拝見して、地理データの Web 流通の「パターン言語」なんていうものをエントリしてみたいと思いました。
Geoinoformatics 関係者って、IT のパターン言語のことを知りながら、Christopher Alexander のオリジナルのパターン言語の実例集を作れる立場にいるなあ*1など思いつつ、それはあとで書くことにして、地理データの Web 流通のパターンとして、「パラメータ」「スクリプト」「ドキュメント」「内部データベース」の４つで整理してみます。

「パラメータ」パターン

問題

小さな地理データをクライアント＝サーバ間で受け渡したい。

制約
  • クライアント資源の制限により、「スクリプト」「ドキュメント」パターンを利用できない。
  • 「スクリプト」「ドキュメント」パターンを実装するほど大げさな枠組みを作る必要がない。
解決手法

HTTP GET リクエストのパラメータに地理データをエンコードして送る。すなわち、リソース名に地理情報が載る。

事例

ロカポイント、ロカポーター、http://cyberjapan.jp/cgi-bin/opencjapan.cgi?x=141.2921&y=43.0457&s=15000
現状では、表示位置のような単純な情報を「パラメータ」として扱うことが多い。

「スクリプト」パターン

問題

Web ページに密接に結合したかたちで手軽に地理データを扱いたい。

制約
  • 「ドキュメント」パターンでは same domain 制約などのために面倒が起こる。
  • UI イベントに密接に結合した形で地理情報を提供したい。
  • 他のサービスには簡単にはデータを取り出して欲しくない。
解決方法

地理情報マーカ用の JavaScript API を作り、API 呼び出しにより地理情報をマップサービスに表示させる。すなわち、リソース内に地理情報が埋め込まれる。

事例

Google Maps API、電子国土 Web システム API 揮発レイヤ。
Google Maps で KML ドキュメントを開くための手法は、「ドキュメント」を「スクリプト」で扱う手法である。
ドキュメントが JSON であれば、ブラウザの same domain 制約を回避できるので、「スクリプト」により簡単に「ドキュメント」を扱うことができる。

「ドキュメント」パターン

問題

ある程度複雑な地理情報をサービスに依存しない形で流通させたい。

制約
  • 「パラメータ」で渡すことが難しいほどデータの分量がある。
  • 「スクリプト」ではパフォーマンス上の問題がある。
  • 「内部データベース」では、他のサービスとの連携がはかれない。
解決手法

地理情報を提示するためのフォーマットを作り、インターネット上のリソースとして提供させる。すなわち、リソースそのものが地理情報である。
そのリソースを表示するためのシステムを作り、提供する。

事例

Google Earth における KML、電子国土 Web システムにおける電子国土プロファイル形式。
GML もそうかもしれないが、サービスの機能に足が付いた言語を目指しておらず、また性格づけが曖昧であるため、このパターンに当てはまるかどうかは不明。
多くの 「JSGI 形式」、「JPGIS 形式」も、サービスの機能に足がついた言語を目指しているわけではないので、「GML」と同じく、このパターンに当てはまるわけではない。

他のパターンとの関係

Google マップのマイマップは、「ドキュメント」を「パラメータ」として渡すことができる。すなわち、ドキュメントの ID を URL にエンコードして渡すことができる。
http://portal.cyberjapan.jp/tokushu0604.html に説明されている http://cyberjapan.jp/cgi-bin/opencjapan.cgi?jsgixml=www.domainname.co.jp/sakuzu.xml は、「ドキュメント」を「パラメータ」として渡す方法である。

「内部データベース」パターン

問題

大量のデータを提供したい。

制約
  • クライアント側に描画の機能がない。
  • クライアント側の描画の速度に問題がある。
  • ネットワーク容量が不足している。
  • ベクトルデータを引き抜かれては困る。
解決手法

地理データのレンダリングまでサーバで済ませたものをクライアントにダウンロードさせる。すなわち、リソースが地理情報の Web ブラウザ向けの表現である。

事例

Google Maps を始め、Web 上でプラグイン不要で表示できる地図サービス。電子国土 Web システムの基盤地図。WMS。
WFS を「内部データベース」とするか「ドキュメント」とするか微妙であるが、WFS で地物を RPC 的に取り出すのであれば「内部データベース」に近く、地物をリソースとして取り出すのであれば「ドキュメント」に近いと思う。

注釈

「ドキュメント」と「内部データベース」の境界は曖昧である。この二者は技術的特徴ではなくて利用規約により区別したほうがよいかもしれない。

感想

書いていて、これはパターン言語のテンプレートには必ずしも当てはまらないかも知れないとも思いました。しかし、自分の頭の整理にはちょっと役立ったかなと思います。

*1:すでにやっている人がいるかもしれません。