Web+GISのアーキテクチャなどを巡る議論

まげぱはらへり @Magepa

@niyalist ありがとうございます。なるほど。2006年以前のWebGISの情報はネットではほとんど発見できないのでGoogleMap以前のWebGISはなかった事になってるのかなと思っていました。

Masaki Ito @niyalist

@wata909 @Mage_Whopper @usuyu WxSとかの想定と全く桁が違うインターネットスケール・実時間の時空間データ処理を議論，設計できる人になりたいな（それにはどういう進路がいいのだろう），とぼんやり思ってます．膨大なデータ処理と圧倒的なさくさく感の実現．

まげぱはらへり @Magepa

@niyalist OpenGISはスケーラビリティーと正反対むいてますからね。。地図屋さんが使いやすいI/Fと既存データをあまり変換しないでstoreできるデータ形式にがんばりすぎて、速度向上や巨大化には全然向いていないように思います。

Masaki Ito @niyalist

入力と出力との間のProcessing（処理）をどう，Webを中心としたインターネットの世界に馴染ませるか，というのは，まだ満足行く提案がないということなのかな（と @_hfu_ さんの問題意識をなぞってみたりする）．

hfu @_hfu_

@tnod789 Web の「限定的」環境でサクサクを実現するための選択肢は「(1)プラグインのようにソフトを強力にする(2)本質的な情報にうまく絞って更に提示を工夫する」のいずれか、だと思ってます。GIS時代と比べて「情報提示」が進化する方向の淘汰圧が掛かっている感じ。

hfu @_hfu_

情報提示を完全に洗練できたときに限り、Geo+WebはHTML5+SVGで実現できることになると思う。実現には、システムの本質を捉えて削りに削るアプローチが必要になる。それは簡単ではない。組織（アップルみたいなところを除く）で考えるレベルを超えてて、個人でとことん考える必要がある

hfu @_hfu_

Web+DBの世界で、DBを突き詰めた結果として、NoSQLという一結論が出ているのと似ていて、Geo+Webの世界で、GISを突き詰めた結果として、NoGISという一結論が出るのではないか。

hfu @_hfu_

そういう大解答が出るまでは、GISの延長線上でのWebGISの上で、苦しんだり妥協したりする期間が続くと思う。苦しんだり妥協したりした人でないと、大解答にたどり着けないのではないかとも思う。現実の時間制約の中では、大解答など考えている余裕がないという側面も大きい。

hfu @_hfu_

Google Maps の場合、大量ベクトル情報の同時提示は意図的に設計外にしている印象。Google Earth への誘導と、ブラウザ能力熟知の故に？期待させない設計に成功、なのかも @tnod789 似たようなKMLをGoogleMapに載せて…たいしたことないと思った記憶

hfu @_hfu_

OpenLayersの場合は背景地図が遅い要因は「(1)通信回線に資源投入できない組織性格(2)プロトコル選択ミス」が考えられ @_hfu_ 的には(2)と言いたいが真相は(1)かもQT @tnod789 OpenLayersは、背景地図の表示速度の遅さで検討候補から外れました

hfu @_hfu_

PCよりもiPad的デバイスがmatterするようになって、期待できる処理能力・帯域の「向上」は当面望めないかな、と個人的には思います。想定ユーザ層によるかもしれません QT @tnod789 データ形式を検討してる間に、PCとネットワークの性能向上で解決されていそうな予感

hfu @_hfu_

「そのうちムーアの法則が解決してくれる」は、90年代には重要な視点であったが、多くのWebサービスが「一台のPCでできる」「クラウドに任せられる」ようになった現在では、それほど重要な視点にならなくなりつつあるのではないか。クラウドは並列化するが処理あたり遅延を必ずしも短縮しない。

hfu @_hfu_

また、Webの世界では「処理あたり遅延」を人間的許容範囲内に収めることの常識化が十分進んでしまったので「成功している」Webの世界では、ムーアの法則的高速化はmatterしなくなっているのかもしれない。開発中途又は未成功のWebに限ってムーア的高速化の議論が有効かも。

hfu @_hfu_

Webでの速度追求は、twitterの中の人がやっているようなソフトウェア側設計の工夫か、Googleの中の人がやっているような群集化によって実現されるが、「ふつうの 」人に手が届くのは、twitterの中の人がやっているようなアプローチであろう。

hfu @_hfu_

メタの水準、設計の水準、細部の水準すべてを見ることが出来ないと(Geo+Webの)大解答にはたどり着かない。広島弁でyoutubeに出ているiPadビデオを見てもそう思う。ところで、メタと細部が直結しちゃっているのがハードボイルドなのか。

hfu @_hfu_

SVG が約束する高度な機能を活用した Geo+Web は、IE9 が出る頃にタイミングを合わせられれば成功する目があると思う。ただし、システム機能数ではなくて用途への特化が重要である。SVGを単なるグラフィック記述言語として使うのではなくてJS付きのアプリのエンジンとして使う。

hfu @_hfu_

それは、高度に特化されているから、既存の地図サービスと競合するものではないし、代替するものでもない。

hfu @_hfu_

[b] YouTube - Apple - iPad - What is iPad? → http://am6.jp/aO8vkL

たんたん @tnod789

NoSQLは「Not Only SQL」http://www.publickey1.jp/blog/10/nosqlsimpledbbigtable.html のことなのかな？ QT @_hfu_ Web+DBの世界で、DBを突き詰めた結果として、NoSQLという一結論が出ている

たんたん @tnod789

NoSQL　でとりあえず見たページ　http://journal.mycom.co.jp/articles/2010/04/26/nosql/001.html　http://itpro.nikkeibp.co.jp/article/NEWS/20091120/340853/

たんたん @tnod789

NoGISは、GISを使わないGeo+Webだと感じたのだけど QT @_hfu_ Geo+Webの世界で、GISを突き詰めた結果として、NoGISという一結論が出るのではないか。

たんたん @tnod789

Geo+Webは、もしかするとGISを使わないというとうことを薄々感じていたけど、それをどう整理すればよいのか

たんたん @tnod789

自分が90年代の人だということに気づいたー QT @_hfu_ 「そのうちムーアの法則が解決してくれる」は、90年代には重要な視点であったが

たんたん @tnod789

そうなんだと気づいた。出口が見えてきそうな気がしてきた QT @_hfu_ クラウドは並列化するが処理あたり遅延を必ずしも短縮しない。

たんたん @tnod789

現時点で大量ベクトル情報を表示させても儲けにつながらないんだろうなと思ってました @_hfu_ Google Maps の場合、大量ベクトル情報の同時提示は意図的に設計外にしている印象。