台風の暴風域に入る確率 あるいは2つの日時を引数にせざるを得ない関数（2つの時間次元とは別）

ある種のデータは、あたかも日時型（＝年月日時分秒）の引数を２つとる関数のように複数の時間に依存する。しばしば「ＧＩＳみたいに簡単じゃなく複数の時間があるのだ」という言葉を自分でも使うのだけど、そのありようが一様ではなく、いろいろの様相があるなあと考えさせられた。

１つめの類型は、OGC WMSで予報データを扱おうとする場合、経緯度に加えて起算日時（initial time あるいは観測などに一般化するために参照日時 reference time と
いうこともある）と対象日時（valid time）を与えないとデータが特定されないよ、というような話。OGCについてはウィキ（http://goo.gl/BO54w）以上に新しい資料があったような気がするが失念して申し訳ない。データ構造としてはデータベースのキーに日時型のカラムが２つ設けるとか、配列の添字に起算日時と予報時間（対象日時と起算日時の差で得られる時間単位つきのスカラー数値）に結びついた番号を用いるといった実現のされかたをする。

２つめの類型は、1時間積算雨量であったり、30年平均値であったり、なにしろ時間方向の統計処理から生み出されるとされるデータ。

第1類型と第2類型は、排他に起こるわけではなく、たとえば降水量の予報ならば、都合3つの日時（起算日時、積算開始日時、積算終了日時）がある。

これらについて最も壮麗な体系を持っているのはGRIB第2版で、参照日時と予報時間が記述できるほかに、第4節というところに任意個の統計処理のリストを記述できて、それぞれに単位付きスカラー数値のパラメタを最大２つ記述することができる。そしてそのベースとなる量（GRIB用語ではパラメタ）は時間ひとつの関数となるような物理量でなければならない（つまり降水量ではなく降水強度のようなものが基底でなければならない）という仕組みにしようとしていた（2008年頃まで）。

なぜ統計処理がリストかというと、4月の毎日19時台の降水量の平均値を過去30年間にわたって平均したもの、みたいな概念がありうるから。

しかし、この偉大なミニマリスト・プログラムはもう悲しいくらいに理解されていない。通報式マニュアルにおいてすらひどい混乱があったので読みとることさえ困難だったくらいである。現実のユーザ受容としては、特に積算値については、たとえば9日23時から10日0時の降水量といわず9日24時の1時間降水量と言いたがるように、「1時間降水量」というパラメタ付き物理量があって、それが瞬間値として与えられるといういいかたが文章上行われるし、データもその概念を反映してほしいと思う人が多い。

べつになにもGRIB2だけをdisりたいわけではなく、他の気象データ形式においても、次元リストをビルトインの固有名詞にしようとする限りは本質的に同じ問題が発生している。19世紀の言語学では言語は総合から分析に進化するなんて言われたけどどうもそうじゃないように、ここではどうも分析至上主義の旗色が悪くて、日射強度の時間積算なんて言わせようとすると嫌がられる。

ここまでは既知の話。いや、まあ、どこにもまとまった議論なんかないだろうが。

さて、今日、「台風の暴風域に入る確率」「熱低が接近する確率」について議論（http://goo.gl/PokKS）していて気がついたのだけれど、３つめの類型かな、と思ったのは、このようなイベント生起確率。

このような量はある日時範囲に対して定義されるのだけれど、それを日時ひとつだけの関数の統計処理として書き下すことが困難である。「ｔ時間の間に暴風域に入る確率」をｔについて微分したものをナントカ確率密度と定義するのは数理的には自由だけれども、実務上は意味不明になるばかりである。

つまり、本来的に日時を２つ引数にとる関数で表わさざるをえない量があることがわかった。少々おおげさに言えば、日時を１つだけ引数にとる関数と統計処理リストに分解しようとするGRIB2のミニマリズムが原理的に否定されるのである。

まあ、システム屋的には、そんな意地悪をいっていても仕方がないので、「統計じゃないことを示す統計処理番号」（実は日本の天気ガイダンスや発雷確率ガイダンスがそうなっている）を導入して追加的メタデータ記述欄を設けるのがいいのだろう。

さて、ECMWFの熱低遭遇確率GPVはどうなるだろうか。