[davis プロジェクト][ワークショップ]
- 日時
- 場所
- 趣旨
- 内容は、ひとことで言えば「地球流体業界のデータの嵐を乗りきるため
のブレーンストーミング」です。ベースは先秋応募した科研費特定領域
「情報爆発」の公募課題で、その中で提案したプロジェクトをたたき台
に、皆さんに考えて頂こうという次第です（次のメールに計画調書を添
付します）。なお、今回会場をお世話頂いたお茶大の渡辺知恵美さんは、
諸般の事情で科研費分担者にはなってませんが、大きく協力頂いてます。
(時空間)データベースが専門で、情報／DBしろうとの地球物理学者の強
力な味方です。一方、渡辺さんにとってはアプリケーション分野のネタ
になり得るということで、両者 win-win シナリオになればと思ってます。
- 出席者
- 林祥介, 小高正嗣, 石渡正樹, 森川靖大, 高橋芳幸, 杉山耕一朗(北大), 塩谷雅人、堀之内武、西澤誠也、栗林晴男、小石和成(京大)、渡辺知恵美(お茶大)、水田亮(気象研)、中野満寿男(九大)、後藤謙太郎(シングラム), 榎本剛(JAMSTEC),
- Davis プロジェクト概観
- Ruby を使う利点
- インタプリタ言語なので開発効率が高い
- 再利用性の高いソフトを開発しやすい
- C, Fortarn ライブラリの再利用もできる
- 文字処理得意
- 数値用多次元配列クラス Narray を使うことで, 数値計算にもそこそこ使える
- dennou-ruby プロジェクト
- 質疑
- ruby-ispack
- ruby の web ページの日本語文字コードが変
スライド
- dcmode プロジェクト
- 1 次元から 3 次元までさまざまな種類の地球流体モデルを階層的に開発
- 日々の営み
- F90 の数値モデルでデータを書く
- dennou ruby ツールで絵を書く
- web にまとめる
- web にまとめるところは基本的に力技, 体力勝負, 賢いツールは使っていない
- 具体例
- 大気大循環モデルを用いたパラメータ変更実験
- 研究グループ内で図, データを交換し, 議論
- サーバにおける図とデータの置き方
- 図とデータは実験ごとにディレクトリをわけて管理
- 変数ごとにデータファイルを作成
- 質疑
- データベースは使っていない?
- 使っていない. 基本的に作成者の頭の中に入っている
- nc ファイルの大域属性には実験設定などの情報は記載されている
それによってディレクトリ名くらいはわかる
- web ページの作成はどの程度自動化されているか?
- 図のサムネイルページを作りを自動化 (dcmodel-sub.rb)
- 図のテーブルの下にもコメントが書けるようにして欲しい
- XML を使えば図とデータの情報管理を一括でできるのでは?
- XML 用のスタイルシート(?)がある
- RSS は便利?
- どう使えば便利かどうかは議論する必要がある. どのくらい楽になるの?
- HTML も XML も生テキストは見たくないし, 直接編集する気にはならない
- そもそも図にどのような情報を付帯させておけばよいかが不明瞭
- 保存しておきたい期間は十分長い
- 図を生成するのに必要な最低限資源は残してはある
- 図と HTML ファイルとをつなぐ情報は保存されているが,
データから図を作成する際の情報が人間の頭の中にしかない.
- あらかじめどういう図を書いたらよいかわかっていないことが原因の一つ
- 図を作るために設定情報(物理量, 時間, 領域, 等値線間隔, 平均操作など)
も保存する
- XML の嬉しさって...
- 一つの XML を用意すると他の目的に使い回せる
- 1 行書き換えるだけで HTML の見え方を変えることができたりする
- 名前の管理を XML でやればよいかは考慮の余地あり
- ディレクトリ構造 + αの情報を XML で管理する
- + αの情報は何が必要なのか?
単に作図した際のコマンドオプション, パラメータだけではないだろう
- 自動化するツールを用意する
- どこまでがんばるか?
- 図に付随させるコメントは netCDF ファイルの大域属性から読み出すようにする
- 図を書く際の試行錯誤を残しておきたいこともあるのではないか?
- 作業しながら 図の作り方, データの切り出し方を決める
- 地球観測衛星とデータ
- 何が変わったか?
- 測機そのものの性能は 30 年前と変わらない
- 大量のデータを伝送できるようになった点が違う
- データフォーマットは HDF
- HDF を使っているからといって自己記述性を持つわけではない.
規約を決めておかなくてはならない.
- 再解析データ
- 日常の作業
- ゾンデデータ
- レーダデータ
- ファイル形式は一般にまちまち
- 例: EAR (赤道大気レーダ)のデータ
- 一部のサイトでは検索機能を強化しているところも一部ある
- 質疑
- 沢山の観測点データを netCDF にするのは不向き
- ゾンデ・レーダデータは, フォーマットはばらばら, 置き方もばらばら,
検索もままならない, なんとかしたい
- UCAR
- THREDS/DOS
- UNIDATA の開発した, 遠隔データアクセスシステム
- ネットワークを介してデータへアクセス, 手もとで描画
- 利用者は元のファイルフォーマットの違いを気にしなくてよい
- DODS
- OPENDAP
- IDV
- dennou データサーバ
- 計画に挙げた項目
- Ruby によるデータの統一的解析可視化ライブラリ
- メタデータのデータベース化の研究
- Ruby on Rails による web データベース開発とパッケージ化
- データベース構築ライブラリー開発
- ユーザインターフェース開発
- パッケージ化
- 自分の(パーソナルな)データを格納したデータサイトも
大規模なデータサイトも同じように(お手軽に)立ち上げられないか?
- 企画調査
- デスクトップ-遠隔データ統合
- 直観的ユーザインターフェース
- 地理情報システム (GIS) はどうなっているか
- Google Map, Google Earth
- Ajax を使った web アプリケーション
- ブラウザ + 専用 GUI
- このような大気海洋データ提供サイトってないのかな?
- STARS
- 村田＠愛媛大さんの開発しているメタデータデータベース
- 質疑
- GIS に詳しい人々に加わってもらうとよいのでは
- 「なぜ気象業界では使わないの?」と言われることがある
- NOAA の dchart
- データへのアクセス制御, アクセスユーザの管理
- 全くアクセス制御ができないと困る
- とても厳密なユーザ管理をしたいとは考えていない
- 不特定多数の人にも見てもらうこともあるし, グループ内だけで見たい場合もある
- 商業的に価値のあるデータをあまり持っていない
- データのアップロードを自動化しようと考えるとすると, 何らかの対策が必要では
- どのようなシステム?
- Ruby on Rails
- 関係データベースを持つ web アプリケーション開発フレームワーク
- http://www.rubyonrails.org
- webrick という簡易 web サーバ立ち上げツールも含む
- 参考書
- Agile Web Development with Rails A Pragmatic Guide
Dave Thomas and David Heinemeier Hansson with Leon Breedt, Mike Clark, Thomas Fuchs, and Andreas Schwarz
ISBN: 0-9766940-0-X, Programatic Bookshelf
- http://www.alistapart.com/
- デモ実演
- フラットに並んだ netCDF ファイルを操作する web アプリケーションを
比較的簡単に作れる
- 過去に使ってきた可視化のスクリプトを埋め込み, 再利用することができる
- 質疑
- テーブルのリストを増やすときは作り直し. 手間はかからない.
- 我々の要求をみたすテーブル作りは可能か?
- XML タグの名前のつけかた
- SPASE
- データカタログの作成方法
- データはフラットにならべ, メタデータだけで検索
- データを格納しているディレクトリ階層を生かす
- データ共有
- どこが問題点なのか明確に
- データをデータベースサーバに登録するときはできるだけ楽にしたい
- ファイルサイズが大きい場合には, データの付帯情報だけを登録する方法もある
- データの属性などから SQL を作るプログラムを用意しておけばよい
- データ検索も楽に
- SQL 文をできるだけ使わないようにするには?
- 拡張可能データベースマネージメントシステム(DBMS)を使えばよい
- PostgreSQL, MySQL は拡張可能 DBMS
- 自分で型を用意できる
- gphys の関数を呼び出すプログラムを C で書く
- Gphys のデータ構造をそのまま使うときには...
- 問い合わせの最適化
- 関係データの直積データを作ってから問い合わせを行うと, 時間がかかってしまう
- Gphys のデータオブジェクトに対する問い合わせ最適化は既存の DMBS はしない
- HDF-EOS データモデル
- 衛星のスキャン方向に対して平行, 垂直, 鉛直な軸をもつ 3 次元データ
- 各軸方向にデータの切り出しが可能
- 質疑
- データ共有
- データサイズの問題
- サイズが大きい場合には, データ内の変数に対する問い合わせが fale する場合がある
- データ検索
- どのような検索をしたいのか?
- データの有無だけが知りたいだけ?
- データの値をスキャンする必要がある検索がしたいのか?
- 例) 下部成層圏で 190 K 以下となっている場所はどこ?
- netCDF ファイルの大域属性だけでもデータベースに登録し, それを検索するようなシステム は作れないか?
- netCDF Operator (NCO) ってのもある
- C でプログラム書くのはつらい
- netCDF には向かないデータ
- 我々はどうしたいか?
- どのようなデータベースが欲しい
- 対象は大衆? それとも身内?
- 同じ指向性をもつ人には使ってもらいたい
- public なような public でないような...
- 身内といってのネットワーク的には分散している
- 身内といっても実際にやっていることはさまざま
- 観測データを初期値に数値シミュレーションを行いたい,
その際データの摺合わせは自動的にやってほしい
- 新たなデータベースを作る上で考慮すべきこと
- そこそこ先進的
- そこそこ枯れた手法, 技術を使う
- あまり手間にならない
- 小回りの効く構造