| ||||||||||||
| ||||||||||||
|
本資料はもともと外部への公開を目的としたものではなく、ブレーンストーミングの叩き台として作った(くだけた?)資料ですが、「デジタル台風」プロジェクト10年のあゆみを振り返るために、ここに(恥をしのんで)ほぼ原型をとどめた形で公開することにしました。
前回の打合せでは、過去データからのデータマイニング的アイデアとして、「過去データの蓄積を用いた天気予測(特に局所的な天気予報サービス)」や、「パターン間の相関を見出すための支援システム」などが提案された。いずれも興味深いテーマであるが、これらを実現するためには、まず対象とするデータの種類を決めておく必要がある。
そこで研究対象としては「気象データ一般」を扱うのではなく、気象現象の一つである「台風」に対象を絞りこむことを考えている。このように対象を狭くした方が、研究対象がより明確になって研究を進めやすい、という考えが強まってきたからである。
「台風」のみに特化することの利点としてまず第一に挙げられるのは、中心位置情報が詳細に記録されている点である。このデータと気象衛星画像という異種のデータを組み合わせることによって、台風周辺の雲だけを切り出した「台風画像データベース」が構築できるはずである。また台風の形状が一般に「コンマ型」と形容されるように、台風形状のバリエーションは無限の多様性を持っているわけではなく、例えば温帯低気圧一般などに比べれば形状が定まっているとみなすことができる。従って台風画像の方が、気象衛星画像一般よりも扱いやすいと期待することもできよう。
そこで本稿では、「台風画像データベース」の実現可能性について重点的に考察していくことにする。
発生期 | 発達期 | 最盛期 | 衰弱期 |
---|
台風の一生を図1に示す (*1)。このように台風の形状は、発達段階によってそれぞれ特徴を示すが、大まかに言ってその形状はコンマ型、または回転コンマ型と言えるだろう。ただしその形状は、台風の周囲に絹雲によってかなり変化することがある。
台風がどの発達段階にあるかは、必ずしも雲の形状だけで決まるものではない。時間の経過に伴って台風がどのような動きと発達を示したか、という時系列的な特徴も重要である。ゆえに、台風画像データベースを作る際には、単に画像を切り出すだけではなく、その画像がどのような状況(文脈)にあったかを併せて記録しておく必要があろう。
(*1) http://www.kishou.go.jp/know/typhoon/1-2.html
台風の典型的なパターン | 実際の衛星画像の例 |
---|
台風を解析するための代表的な方法として、Dvorak法がある。この方法は衛星画像の雲の形からパターン認識により台風の強度を推定する方法であり、アメリカ大気海洋局 (NOAA) のハリケーン(台風)研究者 V.F. Dvorak により開発された[1]。もちろん衛星画像よりは飛行機観測の方が正確な数値が得られるが、現在では米軍の飛行機観測が大西洋を除けばあまり行なわれなくなっている。そのため、正確な台風情報を得るための方法として、現在もDvorak法を基本に改良を加えた方法が用いられている。日本の気象庁で用いられているDvorak解析は「予報作業指針 台風予報(気象庁予報部)」に基づいているが、その詳細は気象庁外には公表されていないので不明である。しかし聞くところによると、アメリカではDvorak法をコンピュータで自動処理しているものの、気象庁では人間が目で見ながらマニュアルで解析をしているそうである。
Dvorak法では、台風の雲の形状やテキスチャの特徴量、またそれらの時間変化を観察することにより、台風の強度や発達段階を判定する。台風の強度はT (Tropical)番号を用いて1〜8の段階で表され、台風になりそうな段階の熱帯性低気圧(T1)から、最強の台風(T8)までをランク付けする。これらの過去の時間変化パターンを追跡することによって、将来の台風強度の変化予測も可能となる。またもう一つの数値としてC.I. (current intensity)番号がある。こちらも1〜8の段階で表され、T番号が主に雲特徴量から導かれるのに対し、こちらは雲と直接関係のない要因も考慮している点が異なる。大まかに言えば、C.I.番号は中心付近の最大風速と、T番号は中心付近の最低気圧と関連付けることができる。
Dvorak法で用いられる、台風の典型的パターンを図2に示す。横軸は台風の強度を表すT番号、また縦軸は台風パターンの種類を示す。これは中心部分とバンド部分の関係の違いなどによって分類されている。基本的には、この図と実際の衛星画像とを比較し、それに若干の補正を加えることで、現在の台風の強度、すなわちT番号を決定することができる。また雲の特徴量として、中心特徴量(CF)および外側バンド特徴量(BF)を測定するが、これらは図から定性的に読み取れる性質に対して、定量的な側面から中心強度の推定を助ける役割を果たす。
ただし、図2のどこの特徴に注目して判定すればいいのか、素人である私にはよくわからない。とりあえず似ているパターンを図中から探し出すと言っても、そう簡単ではないという印象を受ける。ましてやこれをパターン認識手法によって自動的に分類するというのは、かなり高度で難しい問題になるという気がする。
私がこれまでWWWを探索してみた限りでは、「台風のみ」を対象とした画像データベースは発見できなかった。すなわち、
などは既に複数が運用を行なっているものの、両者を組み合わせたサイトが未だにないようなのである。気象関係の研究所では、もしかすると内部でこのようなデータベースが構築されているのかもしれないが、少なくとも公開はされていないようである。
従って、現段階で「台風画像データベース」を構築し公開できれば、いちおう世界初の(?)目新しいサービスと呼ぶことができるだろう。そこで以下では、画像データベースを構築するために必要となるデータをまず点検する。
気象衛星画像としては、気象衛星「ひまわり」の画像が好適である。なぜならば、赤道上空約36,000kmから1時間おきに観測し、また毎回の観測範囲が同一であるため、常に台風をトラッキングできるからである。画像の例を図3に示す。この画像は赤外画像であるが、その他にもひまわりのVISSR (Visible and Infrared Spin Scan Radiometer)センサでは、以下の3種類の波長帯で観測を行なっている。
このうち昼夜を問わず観測でき、しかも雲の形状をよく観測できるのは赤外画像である。そこでこの画像をアーカイブの中心としつつ、昼間に関しては可視画像も収集するという方針が望ましいだろう。このひまわり画像は、東大生産技術研究所で受信しているデータ(*2)を入手できるよう、そちらにお願いする考えである。
一方気象衛星NOAAの画像であるが、こちらもできればこの画像データベースに入れたい。そもそもこのプロジェクトでは、タイのアジア工科大学で受信したNOAA衛星画像を取り込むことを想定していたからである。そこで以下のような理由に基づき、この台風画像データベースにNOAA衛星画像を取り込む考えである。
すなわち図3を見るとわかるように、タイ付近はやや画像の端に位置しているし、インド洋はさらに端である。直下点から離れたこれら地域の空間分解能はかなり悪化しており、また斜め上方から観測することによる悪影響も加わっている。そこで気象衛星NOAA画像で観測した画像を加えることにより、ひまわりでは観測しにくい地域の台風画像もアーカイブできるようになるので、NOAA画像はたいへんに有難いデータである。
このように異種の衛星画像を組み合わせる場合、センサの特性の違いをどう考慮するかが大きな問題となる。例えば、空間分解能の違い、観測波長の違いなどであるが、これらについては今後により詳しく検討する。
(*2) http://www.tkl.iis.u-tokyo.ac.jp/SatIAN/
(*3) http://www.acrors.ait.ac.th/
気象庁が決定した台風の位置、中心気圧、最大風速などがまとめられている、「お天気教室」というページがある。このページの作者に直接問い合わせたところ、これは気象業務支援センターが出版している「気象庁天気図CDROM」に入っているらしいので、おそらくここから正式な情報も入手できるだろう。
また、ここよりも情報量の充実したサイトとして、Unisys Weather: Hurricane/Tropical Dataがある。ここでは、「大西洋」、「北東太平洋」、「北西太平洋」の3海域に発生した台風の中心位置を、古いものでは1886年の記録から蓄積している。ただし台風の中心位置の記録が6時間おきであるため、データの精度の面で上記サイトよりは劣ることも注意する必要がある。
これらのデータを入手すれば、台風中心位置のトラッキングは十分に可能である。このように、気象衛星データに加えて、台風中心位置データという「外部データ」を組み合わせるところに、この「台風画像データベース」の鍵があると言える。
(*4) http://w3.ktarn.or.jp/kamahori/typhoon/TC-track.html
(*5) http://weather.unisys.com/hurricane/
以上のようなデータを揃えることによって、台風画像データベースを構築するための準備は整った。次に台風画像データベースを構築する際に問題となる点について、以下では詳細に検討しつつ実現可能性の見通しを探る。
各時刻ごとの中心位置を用いて、台風および周囲の雲領域を衛星画像から自動的に切り出す問題が生じる。ここでは以下のような処理が必要である。
もっとも台風画像の自動切り出しだけを行なうならば、1は必ずしも必要ではないかもしれない。また1および2に関しては確立した手法があるわけではないが、技術的新規性に関して目玉となりうるほど困難な処理ではないだろう。3に関しては、精度の点で検討は要するものの、既に確立したアルゴリズムがあるので問題はない。
切り出した台風画像に、画像検索用のインデックスを付与する問題が次に生じる。ここでは以下のような処理が必要である。
以上のような「台風表現モデル」に必要とされる条件は以下のようなものであろう。
なおこの画像データベースは、先述の Dvorak 法の自動化を目的とするものではない。むしろ Dvorak 法で用いられる台風の典型的パターンなどを参考にしながら、そのようなパターンをうまく表現できるようなモデルを検討する方に関心がある。もちろん一旦そのようなモデルができれば、そこから何らかのルールを導くことができるかもしれないが、それはあくまで主要な目的ではない。つまり気象予測に役立てるという目的は、当面は考慮の対象から外すことにする(後述「社会的ニーズ」も参照)。
どのような検索方法が実現できれば嬉しいかは、もちろんプロフェッショナルと一般ユーザによって異なるはずである。プロフェッショナルにとっては、正確な情報を入手できることがまず第一に重要となるだろう。また、台風解析に用いられているDvorak法と関連性の深いデータが提供できれば、プロフェッショナルにとってもある程度は役立つ情報となると期待できよう。これらを発展させたものとして、データマイニング的な機能の提供も考えられる。
一方の一般ユーザにとって便利な機能とは何だろうか。想定できる検索要求をいくつか列挙してみると、以下のようになる。
参考までに、丸善から出ている「CD-ROM 台風の事典」[2](画像検索機能なし)では、以下のようなメニューが提供されている。
台風の経路情報だけでは、その台風がどのような台風だったのか、いまひとつ実感が湧いてこない。従ってこのようなデータベースに気象衛星画像を組み合わせることによって、一般ユーザにとってもさらに有用なデータベースが実現できることが期待できる。
台風画像の検索結果はWWWブラウザ上に表示する。単一の画像やアニメーション、グラフなど、検索結果の提示には種々の方法が想定できるため、JAVAなどを用いたインタフェースを構築する必要があるかもしれない。これはプログラミングの問題となる。
また以前から関心のある課題として、雲画像の立体表示という手法がある。図4のように、気象衛星画像を立体的に表示する方法を用いることにより、雲のテクスチャや立体感がより明確に把握できるようになる、という手法である。特に台風画像の場合には、時系列的に変化を追跡することで、立体化の効果が大きいことが予想できる。この課題も、検索結果の提示というプレゼンテーションの問題の一つとして、時間ができれば研究をしていきたい。
台風は大きな災害をもたらす気象現象の一つであることから、台風は気象研究 の中でも重要性が高い。例えば気象庁気象研究所 (*6)の部門構成は以下のようになっている。
このように、「台風」は単なる気象現象の一つであるにもかかわらず、それだけに一部門が割り当てられていることから、専門的にも台風は非常に重要な気象現象であることがわかる。「台風画像データベース」は台風の予報精度の向上に直結するものではないため、専門家にとってどの程度のニーズがあるのかは不明だが、大量の画像を集めることができれば、専門家にとっても何らかの発見をもたらすような画像データベースが実現するのではないだろうか。
一方、台風に関する一般的な関心も相当に高い。特に災害の軽減という観点からは大きなニーズがある。CD-ROM [2]の解説には以下のような記述がある。
台風が接近してきたときに、過去の台風から似ている台風(類似台風)を選び出し、その台風でおきた災害等の教訓を防災活動に役立てるということは、昔から行なわれてきました。しかし、この方法はかなりの経験と手間がかかる方法です。
従って「台風画像データベース」を活用することによって、このような経験的方法が容易に適用できるようになれば、災害の軽減にも間接的に結び付けることが可能かもしれない。また画像データベースを通じて台風に関する知識を深められれば、それだけでも効果は十分である。
このように台風に関する一般的関心の高さを示す一つの例として、WeatherNex: Software Libraryのページ(*7)がある。このページには気象関係のソフトウェアが紹介されているが、台風のトラッキングを目的とした専用ソフトウェアがいくつも開発されているのである。その例を以下に示す。
いずれも画像データベースのような機能はないが、中心位置のトラッキングデータを用いて種々の特徴的なサービスを提供するものが多い。このように台風のトラッキングということが、かなり大きな関心を集めているのである。これは主にアメリカ人を対象としたソフトウェアであるが、日本も台風が頻繁に来襲する国の一つであり、台風に関する関心はもともと非常に高い。そしてそのようなニーズに答えるように、台風に関するCD-ROM [2]も出版されている。台風画像データベースは一般的にも高い関心を得られると考える。
(*6) http://www.mri-jma.go.jp/
(*7) http://cirrus.sprl.umich.edu/wxnet/software.html
最後に、このような「台風画像データベース」を構築するために必要な設備を見積もってみる。上記「お天気教室」のページから得られたデータを参考とする。
まず年平均で発生する台風の数は、1951年から1997年までの平均で27.23個、次に台風の平均寿命は、1970年から1997年までの平均で8.73日となった(ただし熱帯性低気圧の期間が含まれている可能性がある)。ゆえに、一つの台風あたりの観測機会は、毎時の観測を仮定すると約200回、1年間では約540 回となる。すなわち1年間に5400枚の画像が増えていくことになる。
次に画像の大きさについて検討する。台風の大きさとして、風速15m/s以上の領域の半径がよく用いられるが、これは大型の台風で800km以下程度である。台風のサイズは台風によって異なるが、非常に大まかにこの値を目安にすると、おおよそ半径1000kmの領域を切り出せばよいということになる。ひまわり(赤外画像)の空間分解能は直下点で5kmとなっているので、これは400×400のサイズの画像を切り出すことに相当する。この画像を濃淡8bitとして保存しても、約160KByteのサイズである。これに先ほどの画像枚数をかけると、おおよそ1年間に1GByteのペースとなる。これは決して大きな数字ではない。ひまわり「可視画像」は解像度がこの4倍であるが、夜間は保存しないため、それほど大きなデータ量とはならないだろう。さらにNOAA画像の方だが、解像度は1kmと高いものの、観測頻度がひまわりよりもかなり少なくなるため、それほどの量にはならない。
画像検索のために必要なインデックスは少なくとも原画像よりは小さくなるはずであるため、結局のところ1年間に3GByte程度の領域を確保できれば、十分にデータベースは実現可能であると考えられる。10年分ならば30GByteとなる。むしろデータを処理するための一時的な蓄積場所の方が、大きな問題になる可能性が高いと考えられる。
以上のように、「台風画像データベース」のために必要な計算機とハードディスクは、画像検索用と処理用とを分けて考える必要がある。しかし画像検索用に関してはそれほど大規模な設備は必要ではない。従って今後は、どのような検索手段が想定されるかをよく検討し、また検索インデックスのためにどのような画像処理手法が適切かに関する検討が重要となる。
|