モデル重視・実装軽視であった地理情報技術業界のこれからについて

いつも読ませていただいているブログ「ここのことはなかったことにするかも (d:id:yellow_73)」の「レンダリングにありえない時間がかかった理由 (id:yellow_73:20071210)」に、こんなコメントを書かせていただきました：

こんにちは。スターをつけさせていただいている hfu です。いつも有益な記事、ありがとうございます。
データ元を明らかにされていない時点でも、いくつか貴重な情報があり、大変参考になりました。また、今回さらに踏み込んで情報を開示いただき、ありがたかったです。これからも、可能な範囲でいろいろエントリいただけるとうれしいです。
これから、何か教えていただきたいことが発生した場合には、コメント欄あるいはトラックバックなど利用して、シグナルを送るようにしたいと思います。
「マルチポリゴン1レコードで作られている海岸線データ」というようなデータが出現した背景には、地理情報標準のような規格が先行して、データハンドリングのレベルでの知見より、モデルレベルの美しさが優先される風潮があるように思われます。
本来、交換用のデータは確かにモデルレベルの美しさを追求したものであるのがよく、運用レベルのデータに落とし込む（たたき込む？）際に運用レベルの最適化がされるのが美しいこととされているのですが、実際には運用レベルに落とす際にそれほどの工夫をするような余裕はなく、また、運用レベルで必要な最適構造というようなものは、実際にはほとんどのアプリケーションで共通であるために、実は交換データレベルで運用レベルの工夫を盛り込んでおいたほうがよい場合も多いとも考えられます。
「タイリング」などという概念も、いわゆる地理情報業界は、図郭独立というかけ声で、おそらく90年代だか2000年代の初頭に、努めて排除してきたものですが、逆にメインストリーム IT のほうから来た Google Maps に、タイリングの本質的な重要性を教えられるはめに陥りました。
最終的には、モデルの美しさと運用の効率性を両立するシステムが求められることになると思います。それまでは、この間での行ったり来たりがあるのではないかと思っています。
（誤字・脱字をいくつか修正させていただきました。）

ここから先は、id:yellow_73 さんのエントリの文脈からかなり遊離した内容になります：
地理情報業界で流通する地理情報は、かつて FORTRAN を想定しているかのようなバイナリ・テキスト混成ファイル*1が多かったような気がします。その後、CSV および CSV 相当の XML データ形式に移行しましたが、これらは直接利用することを念頭に置いていないようです。実質上、直接利用に耐える唯一の交換フォーマットとして Shapefile があり、これが栄光あるレガシーとして、いまだにこの地位を脅かせる交換フォーマットがありません。
交換専用フォーマットとして、WKT および WKB を幾何表現のコアとし、その方向で進展させていくという道もあったかもしれません。しかし、実際には ISO 19100 の流れがその後を支配し、現在では UML モデルと XML Schema にあふれた、大変複雑で誰も一式 (suite) としては実装できていないモデルが表向きの地理情報の「支配者」になっています。交換用データだけではなく、Web マッピングの方面でも、あからさまに RPC 寄りの思想による OGC WMS が表向きの「支配者」となっています。
しかし、これらの「支配者」は、そのままでは*2実装に向いた運用に適さないのです*3。
Google Maps の立ち上げ当時の成功は、OGC WMS を結果的に完全に黙殺し、運用に適したタイルベース・リソース指向の設計を貫徹させることによって、他社サービスにはない運用スピードを実現させたところにも要因があると思っています。
90年代から 2000 年代にかけ、地理情報業界がそのようにしているうちに、UML モデルだとか XML Schema だとかいうものが、メインストリームの IT でも「クールとは限らない」ものとして整理され、より実装者より、より運用よりの技術が「クール」とされる風潮がでてきています。地理情報業界の、最前線部隊のような部分の人々はともかく、本隊のような部分の人々は、その流れを感じることができているでしょうか。
この話題は、とても大きな話題なので、書こうとするといつも、野のものとも山のものとも付かない、愚痴のようなエントリにしてしまいます。いくつかの論点を分離できていないこともその原因だと思います。これから少しずつ、あとで整理して書いていきたいと思います。

*1:DM など、「全角文字のみ」の制約のもと、裸の JIS コードで地名データが入るなど、結構「おもしろい」規定がされていたように記憶しています。

*2:絶対に実装に向かないとは言いません。ただ、データ量やユーザ数に対してスケールすることが必要な領域では、別の層（タイリングだとか、短縮記法だとか。）を挿入する必要があると観測しているところです。それぞれの領域について、あとで書くことをしないとしっかりしたことは言えませんが。

*3:なんといっても、UML は「実装独立」です。XML Schema は実装を考慮した仕様であるはずと思いますが、実際は実際の通りです。