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

hfu @_hfu_

プラットフォームは出来るだけ大きなデータを扱えるべきというのには同意しますが、一方でこの 700kB のポイントデータのデータ量、Web の情報提示としていかがなものか、という視点もあるように思います QT @tagchan @tnod789 700KBのデータも表示できなくて

ひとちゃん @hitochan_t

その視点もありますね。 RT: @_hfu_: プラットフォームは出来るだけ大きなデータを扱えるべきというのには同意しますが、一方でこの 700kB のポイントデータのデータ量、Web の情報提示としていかがなものか、という視点もあるように思います。

たんたん @tnod789

地理院の非プラグイン電子国土は140kBでもダメでしてhttp://bit.ly/bNcT4h　QT @_hfu_ 700kB、Web の情報提示として QT @tagchan @tnod789 700KBのデータも表示できなく

たんたん @tnod789

地理院の電子国土で戦艦大和のようなものを作っているんだという自覚はある。だからどうする？

たんたん @tnod789

開発コストを下げるのにブラウザを選ぶのもアリだと思うので非とも言えない思っています。ただ、非だと思われても仕方ないとも思います QT @_hfu_: ブラウザを選ぶようでは電子国土側に非はある

たんたん @tnod789

非プラグイン電子国土、古めのノートPC（WinXP）上Firefoxで表示させるとloadingの後半でCPUの負荷が100%になり数分止まります、IEは割と早く表示できました QT @_hfu_: 私の Mac では、ネイティブ化140kBも表示してくれています

たんたん @tnod789

非プラグイン電子国土、loadingの後半の処理速度はクライアントPCの性能に相当依存しているようです。古めのノートPC（WinXP）も十分表示できないと誰でも使えないなぁ QT @_hfu_: 私の Mac では、ネイティブ化140kBも表示してくれています

たんたん @tnod789

誰でも簡単にブログをはじめられるのに、Web上に手持ちの地図データを表示させるためには、いろいろなシステムのことを調べなければならない。簡単に表示できるまで待つべきか？　待てない状況なので調べているんだな、きっと

たんたん @tnod789

味気ないと感じなくなっていた自分に気づきましたー QT @netartjp: おー、ありがとうございます！お役所っぽくてちょっと味気が無いですけどｗ RT @tnod789: @netartjp フリーのアイコンに「ｇコンテンツ用アイコン」ってどうでしょう

たんたん @tnod789

データ形式を検討してる間に、PCとネットワークの性能向上で解決されていそうな予感 QT @_hfu_: あの程度の情報にどうしても700kBを必要とするのか、データ形式にも検討の余地があるかもしれません @tnod789 @tagchan

たんたん @tnod789

OpenLayersは、背景地図の表示速度の遅さで検討候補から外れました。電子国土もそうだけど地図調整業界でもなじみがなさそうです。 QT @_hfu_: ちなみに、例えば OpenLayers

たんたん @tnod789

似たようなKMLをGoogleMapに載せてサクサクでなく、GoogleMapもたいしたことない（電子国土もイケる？）と思った記憶があります。 QT @_hfu_: GoogleMaps は、同様な情報を載せたときに非プラグイン電子国土と比べてサクサクかご存じでしょうか

たんたん @tnod789

これ以上の処理でサクサクを実現するためには、クライアントPCにプラグインを入れきゃダメなんだろうなというのは、薄々感じてます QT @_hfu_: OpenLayers や GoogleMaps は、非プラグイン電子国土と比べてサクサクか。 Google Earth はサクサク

たんたん @tnod789

OpenLayersをとりあえず知るために見たサイト　http://sourceforge.jp/magazine/08/12/26/0151203

たんたん @tnod789

制限内では表示されるが、サクサクかどうかは別。Google マップでの KML レンダリングのサイズと複雑さの制限　http://code.google.com/intl/ja/apis/kml/documentation/mapsSupport.html

Nobusuke Iwasaki@つくば @wata909

んと、WMSってやっぱり画像提供なわけで。そうするとサーバーAから提供されたデータと、サーバーBから提供された画像を重ねあわせて表示することは出来ても、演算して表示することは出来ないわけだ。

Nobusuke Iwasaki@つくば @wata909

そうするとやはり、サーバーから提供されるのはバイナリーデータで、演算や描画がクライアントというモデルは、単にデータ総量とか、サーバーへの負荷という問題だけでなく、データの利用という側面からも意味があるモデルになるんだろう。

Nobusuke Iwasaki@つくば @wata909

例えばサーバーAはリアルタイムで降水量データを提供して、サーバーBはDEMを提供する。そして、OSMのデータ組み合わせて、クライアント側で道路の冠水予測をする。こんな運用って出来たら楽しいと思う。最近流行りのクラウドの方向性とは逆行するんだろうけどw

まげぱはらへり @Magepa

@wata909 それって普通に降水量データが提供されるサーバAPI+OpenLayersではないでしょうか。RESTの外部I/Fがもうすこし統一されてるとやりやすくなるでしょうね。

まげぱはらへり @Magepa

画像つってもPNGなんて普通のZIPファイルみたいなもんだから、内部構造を無理矢理定義すればWMSでバイナリデータ配布も、受けとる事もできる。でもそんな無茶するよりJSONみたいに双方で構造が読み取れるデータをシリアル化してやった方がみんなが幸せ。

まげぱはらへり @Magepa

WMSはテキストも扱えます。データを配るだけならサーバWMS、クライアントOpenLayersで十分実現可能。JSとかPHPは数値<->テキスト変換は余裕なので、データが有ればクライアント側の実装次第。しかし肝心のデータがほとんどないですね。特にリアルタイムのデータ提供は皆無。

まげぱはらへり @Magepa

OpenLayersのtextレイヤー。http://bit.ly/bEFnVu Ajaxの知識がちょっとでも有ればとんでもない可能性があるのはわかるんじゃないかなーと。しかし全くと言っていいほど使われてない。

YU @usuyu

.@wata909 そうなると、やっぱりWFS、WCSってなっていくんじゃないでしょうか。で、処理はWPSって。でも実際、処理負荷や通信負荷は心配。

Masaki Ito @niyalist

@wata909 @Mage_Whopper @usuyu 2001年頃に，Webサービス，SOAみたいなアイディアがあってWFS, WPSなどでGISに特化する形で規格化されたのだと思います．ただWebの方はAPIを通じたデータの流通はクラウドの陰で限定的なままですね．

Masaki Ito @niyalist

@wata909 @Mage_Whopper @usuyu Webサービスはエンタープライズ分野ではまだ生き残ってるんでしょうかね．大規模な（必ずしも正確でなくてよい）データ処理のノウハウは，googleの独擅場で，WxSのスケーラビリティ議論はあまり見たことがないのが残念．