都市地震防災情報統合GIS(インターネット版)

       基本概念


1.JAVAを用いた都市地震防災情報統合GISの構築
 JAVAでは、HTMLから呼び出される「Applet」クラス、 GUI構築のための「awt」パッケージ、 ネットワーク先のサーバー上のファイルにアクセスできる「URL」クラス、 種々の書式でファイルI/Oができる「io」パッケージ等が充実しており、 これらを組み合わせることで、 X-プログラミングと同等のことがブラウザ上でも可能となる。 図1にAppletの動作原理を示すように、Appletは、HTMLから呼び出され、 他のJAVAクラスを呼び出すことができる。 従って、Appletを継承したJmapAppletを構築することにより、 HomePage上でGISが稼働可能となる。



          図1 Appletの動作原理

2.基本クラス構成
 JAVAはオブジェクト指向言語なので、 文献2)の都市地震防災情報統合GISのクラス設計(図2)をより素直に表現できる。 本システムでは、JAVAの基本クラスライブラリを継承し、 図3のような設計を行った。
 本システムは、地図システムと個別システムを基本クラスとし、 個別システムを継承して各データベースを追加していく枠組となっている。 地図システムと個別システムのインターフェイスは、 「build」、「draw」、「pickup」の3つである。
 「build」では、パラメーターボックスを構築する。 このパラメーターボックスは、 地図ウィンドウの「Database」からプルダウンすることにより、 呼び出される。 パラメーターボックスの内容は、サブクラスである各個別システムに任されている。
 「draw」では、条件を満たすオブジェクトの描画を行なう。 地図ウィンドウの「再描画」のタイミングに呼び出される。 描画順序は、地図システムに登録された順(先に描画された方が下)だが、 描画する図種別(4:文字列, 3:シンボル, 2:線, 1:面)を利用することにより、 描画順序を調節でる(数字が大きいほど上)。 描画内容は、サブクラスである各個別システムに任されている。
 「pickup」では、オブジェクトの指定に対する反応を行なう。 すなわち、マウスが指したオブジェクトの詳細情報を表示したり、 マウスが指した位置に関する情報を表示したりする。 優先順位は、「draw」で上に描画された順を基本とする。 地図ウィンドウ内でのマウス一番ボタンに関する 「MOUSE_DOWN」、「MOUSE_DRAG」、「MOUSE_UP」 イベントのタイミングで呼び出される。 反応内容は、サブクラスである各個別システムに任されている。
 例えば、「名古屋地盤システム」で言えば、 「build」で各種地図選択のためのポップアップメニューが構築され、 「draw」ではメニューで選択された地図が125mメッシュで描画され、 「pickup」ではマウスドラッグにより指定された範囲が、 断面図ウィンドウとなって描画されるといった具合である。



          図2 クラス構成の基本概念



          図3 JmapAppletの基本クラス構成

3.実行時のデータの流れ
 実行時のデータの流れを図4に示す。パラメーターボックスでは、 全データの中から描画したいデータの抽出を行なう。 抽出されたデータは、地図ウィンドウに描画される。 描画されたデータのうち、マウスによりピックアップされたデータは、 個別にウィンドウを開くなどにより、詳細情報を表示したり、 さらに詳細な分析につなげていくことが出来る。 インターネット版では未実装だが、波形情報は、 波形解析システムに取り込まれ、 FFT解析等を行なえるような枠組を構築予定である。



          図4 実行時のデータの流れ

4.実装方法に関する検討
 インターネット上でシステムを構築する場合、インターネットに どのようなデータを流し、サーバーおよびクライアントのそれぞれに、 どのような処理を行なわせるか、の設計が非常に重要となる。 本システムでは、図4に示すように、サーバー側の処理は、 要求されたデータをファイル単位で送信するのみにとどめ、 パラメーターボックスの解釈から、描画データの選別、 描画倍率の計算、ピックアップ処理などは、 全てクライアント側で行なっている。
 本システムの実装には、他に、 クリッカブルマップの繰り返しによる実装などが考えられるが、 両者を比較した場合、本システムの利点は2点ある。 1つ目は、JAVAのみの知識で、クライアント側の記述のみでの 分かりやすいシステムを構築できることである。 HTMLのINPUT機能とWebサーバーと各言語(C言語やPerlなど) にまたがるCGIの概念を習得し、 文字列処理や画像処理を行ないながら運営するシステムを構築するには、 かなりのインターフェイス設計能力を有する。 まして、JAVAに匹敵するようなGUIを構築する場合には、 かなりの知識と技術を要し、システムも繁雑になりがちである。 その点、JAVAは、もともとクライアント側の処理として、 サーバーのファイルを読み込む記述ができるので、 サーバーからデータファイルを読み込み、 クライアント側で処理することにしてしまえば、 従来のXウィンドウプログラムと大きく変わることなくシステムが構築できる。 2つ目は、サーバーのハード負担が軽いことである。 サーバー側でいくつもプロセス起動することをしないので、 一度に多くのアクセスがきてもメモリー負荷が少ない。 さらに、クライアント側のインコアに、一度読み込んだデータを貯めておけば、 表示パラメーターの変更や拡大・縮小・移動などに対して、 毎回サーバーにアクセスすることなく、高速に反応することができる。
 一方、欠点もいくつかある。 まず、クライアントの性能に大きく依存することである。 本システムの場合、MacやWindowsでの動作確認は殆んどしていないが、 不具合なく動くかどうかは疑問である。 また、メインメモリーやCPUなどのハード要求が高くなりがちである。 データ検索などをクライアント側で行なうため、 ファイル単位のデータを、一旦全部クライアントに送りつけねばならず、 余分なデータもインターネット上を流れることになる。 (ファイルを最小単位に分割するのにも限度がある)。 また、データをインコアに持たすとなると、 クライアント側にかなりのメモリースペースが要求されることになる。
 現状では、クリッカブルマップを用いたシステムは実装していない。 それぞれを用いて同レベルのシステムを構築し、 両者を比較することは、興味深いと考えている。 また、サーバー側でもJAVAを用いて検索転送システムを立ち上げ、 パフォーマンスの比較検討を行ないたいと考えている。

5.オンラインドキュメントの作成
 JAVAでは、図5に示すように、 ソースプログラムからHTML形式のオンラインプログラマーズマニュアルを ジェネレートするドキュメントシステム「javadoc」が充実している。 本システムでも「プログラマーズガイド」を試作・公表している。 このような枠組みにより、複雑になりがちなGUIプログラムも、 複数の開発者間で、認識を共有しながら開発を進めることができる。




          図5 ドキュメントジェネレートシステム
6.実行イメージの例



          図6 実行イメージの例 (拡大図はこちら)
目次へ戻る