19
Help us understand the problem. What are the problem?

More than 1 year has passed since last update.

posted at

updated at

WMO(世界気象機関)の格子データ形式GRIB2について

そもそもこれは何ですか

「FM92 GRIB」はWMO(世界気象機関)の定める通報式(WMO code forms)の一種で、主に格子点データに用いられます。

格子点データといっても万人に通じるわけではないので、地理情報システムに詳しい人は、ラスタデータ形式の一種と思ってください。地理情報システム(GIS)では平面上のデータモデルをラスタデータ raster dataベクタデータ vector dataの二つに大別するのですね。

通報式とは何ですかという質問もあるでしょう。そもそもWMOは観測網の確立(条約第2条(a))と気象情報を迅速に交換するための組織の確立及び維持(同第2条(b))をその最大の目的としており、世界気象監視計画(World Weather Watch Programme)により合意された方法で観測・通報・予報を行うべく、WMO総会決議たるWMO技術規則の付属書としてWMO No. 306 Manual on Codes が作られており、そこで定められるデータ形式を code form 通報式と言います。元来は電報によって英数字列でデータを符号化 code して送る形式という意味なのですが、電報がバイナリ化し、通信網がTCP/IP化し、電報ではなくファイルが送信されるのが主流になった後も制度や名前だけが残っているわけです。

このWMOマニュアルが日本では気象庁予報部長依命通達「国際気象通報式」として翻訳されているわけです。日本語「通報式」の由来については知りません。以下、本稿時点の国際気象通報式文書の国立国会図書館WARP収蔵版(気象庁の国際気象通報式・別冊をベースに説明いたします。

他によい参照先がないので通報式の概要

WMO通報式は策定年代により大きく3つに分類されます。「FM」で始まる番号が付いていて、「FM92 GRIB」と呼ばれます。いちばん正式には「FM92-XIV GRIB」のように、制定または改版の行われたCBS(基礎組織委員会)回次番号を付けます;
1. 伝統的文字形式通報式 (TAC: traditional alphanumeric code forms): 電報で伝送できるよう英数字列でデータを表現するもの。FM12 SYNOPからFM88 SATOBまで48種類、データの種類ごとに異なる文法のデータ記述言語だと考えることができます。現行のFM体系はテレタイプ無線電報が主流の1970年代~1980年代に整理されたもので、制度上はTCDF(次項)に移行が完了したので2011年に改正作業は原則凍結されましたが、実際問題として地上観測用の FM12 SYNOP や高層観測用の FM35 TEMP などはいまだに広く使われています。
2. 表参照通報式 (TDCF: table-driven code forms): 主に1980年代後半以降に開発が始まったもので、FM92 GRIB, FM94 BUFR, FM95 CREXの3種類ですべてのTACを置き換えることができるとされました。
3. XMLによる航空関係データ形式 IWXXM。FM201以降の番号が割り当てられています。100番台は何に使うつもりだったのか知りません。

表参照(table-driven)というのは正式な定義がありませんが、汎用的な文法と、電文 message 内部に書かれたデータ構造の記述を組み合わせて、あらかじめ合意されている符号表(電文中のオクテットから構造または意味を与える表)と照らし合わせて解読するというようなコンセプトです。これにより、新しい種類のデータを表現するために新しい文法まで考えなくてよくなるわけです。

そのTDCFは次の3種類があります;
1. FM92 GRIB (Gridded Binary): 格子点データ形式。第0版が1985年、第1版が1989年、第2版(正式名称 FM92-XIV GRIB)が2001年に制定されました。第1版と第2版は互換性がなく、今ではほとんど第2版が使われます。以下で説明します。
2. FM94 BUFR (Binary Universal Form for the Representation of meteorological data): 主に観測報のような地点や軌跡に紐づいたデータに用いられる形式です。
3. FM95 CREX (Character Representation for EXchange of data): バイナリ電文が流せない通信路で BUFR 相当のデータを流せるようにした代替形式。あくまで過渡期の措置という位置づけです。気象庁では「台風解析・予報情報」電文がかつてCREXで配信されていましたが、平成30年3月までに気象庁防災情報XMLに変更されました。

表のバージョンとローカル表について

以下、符号表がたくさん出てきます。符号表はGRIB電文中のオクテットに対して、データ構造や意味のようなものを与えるものです。それが世界共通・永遠不変であれば話は簡単なのですが、残念ながらそうではありません。

まず、新しいバージョンへの変遷。新しい種類のデータを収容するため、新しい符号が追加されていきます。一方で廃止があるかというと「廃止予定」と注記がつけられるに留まっています。また変更については、各符号表の説明文を意味を狭めないように修正するような改正は時折行われています。廃止と変更が皆無であれば、バージョン管理は「常に最新の表を用いる」という運用に単純化されることが保証されますが、現状までの通報式の管理は、事実上その単純化を意図した水準が維持されています。

もうひとつ、世界共通でないローカル符号。各表には「地域的使用のため予約 reserved for local use」と書かれた部分があります。たいてい、符号範囲が0‐255の符号表では192‐254が地域的使用ですが、例外もあります。このローカル符号がローカル表としてとりまとめられ、バージョン番号を付されて管理されることが前提になっています。ローカル表ではない世界共通部分はマスター表と言います。

ローカル表はGRIB第1版では盛んに用いられました。特にパラメタ番号の名前空間が8ビットしかなかったのですぐに枯渇し、同一符号で意味の異なる大量のパラメタ番号を管理する必要があったのです。GRIB第2版で諸々の構造を非互換に変更するにあたり、名前空間が枯渇しないようかなり配慮されたので、日本以外ではあまりローカル表は使われていないと考えています。

低レベルのデータ構造

GRIB電文 message (気象庁訳では message を「報」としますがわかりにくいのでやめました)は可変長の「節 section」が羅列した構造です。現代的に1電文を1ファイルに保存するならば、シーケンシャルファイルということができます。

GRIB第2版の各節には下表のような種類があり、英文規定では GDS, PDS のような名前で呼ばれますが、気象庁の日本語資料では「第3節」「第4節」のように番号で呼ばれます。

節番号 英文名称 構造 内容
第0節 IS (indicator section) 固定長16オクテット 電文先頭に1つ必要です。マジックナンバー"GRIB"、版番号、電文長が記載されます。
第1節 IDS (identification section) 可変長 電文先頭第0節の次に1つ必要です。この電文を他の電文と識別するためのメタデータが記載されます。
第2節 Local use section 可変長 省略可能。各国で独自の情報の記載が認められています。ECMWFではMARSの検索キーを記載すると聞いたことがありますが詳細は知りません。
第3節 GDS (Grid definition section) 可変長 後続の第7節が表現する水平二次元格子を地球上の位置に結び付けるための情報が記載されます。
第4節 PDS (Product definition section) 可変長 後続の第7節が表現するデータが何であるかや、時間・高度などのメタデータが記載されます。
第5節 DRS (Data representation section) 可変長 後続の第7節のオクテット列を二次元配列として記載・解読する形式を規定するためのメタデータが記載されます。
第6節 BMS (Bitmap section) 可変長 矩形格子の一部に欠損値がある場合その位置を記載します。
第7節 DS (Data section) 可変長 二次元配列そのものを、直近の第5節で規定される形式で記載します。
第8節 ES (End section) 固定長4オクテット 電文末尾に1つ必要です。リテラルに "7777" が記載されます。

GRIB第2版の 第0節の構造は次のとおりです。

(注意)以下、各節の中のオクテットの位置は「オフセット0」から数え始めることとします。WMOや気象庁のドキュメントでは「オクテット1」から数え始めますが、プログラマーに負担をかけないように敢えて変えます。

オフセット 内容
0-3 文字列 "GRIB"
4-5 予約
6 符号表0.0 分野番号
7 非負整数 GRIBの版番号(すなわち2)
8-15 非負整数 GRIB電文の長さ(オクテット数)

なお、GRIB第1版では第0節の長さが8オクテットで、オフセット7に版番号(すなわち1)が書かれることは上表と同じなのですが、電文の長さはオフセット4~6の3個オクテットに書かれます。プログラムの入力オクテット列に複数のGRIB電文があり得て、マジックナンバーにより第0節を発見して電文長だけ切り出す、というような処理を書く場合には版数に注意してください。WMOの通報式からはすでにGRIB第1版は削除されています。さしあたっては気象庁の国際気象通報式・別冊を参照してください。

符号表0.0[気象庁訳]は分野を表すものです。第4節ではなく、こんなところで気象・水文・地面・宇宙の区別がされていて、一つのGRIB電文に複数置けないというのは正直あまりよい設計とはいえず、たとえば土壌水分関係の物理量は素朴には地面(分野2)とすべきところ、そうしてしまうとひとつのGRIB2電文に降水量など(気象:分野0)と一緒に格納できなくなってしまうので、便宜上気象分野でパラメタ登録するといったことが行われます(cf.配信資料に関する技術情報第302号)。

第1節~第7節は次の共通構造をもちます。ここは解読プログラムが楽しく書けるところです。

オフセット 内容
0-3 非負整数 節の長さnn(オクテット数)
4 非負整数 節番号(すなわち1~7)
5-(nn-1) (節ごとに異なる内容)

第2節から第7節には繰り返しが認められています。通報式ドキュメントの図示をABNFで書くとこんなふうです。

grib-message = is ids ( 1*(lus collection-data) / collection-data ) es
collection-data = 1*(cube-data)
cube-data = gds 1*(plane-data)
plane-data = pds drs *1(bms) ds

いいかえると、第4節~第7節(PDS, DRS, BMS, DS)がワンセットでひとつの水平面上の二次元配列データを表現し(上記 plane-data)、格子配置が同じで鉛直位置などが異なる水平二次元データの集まり(上記 cube-data)を集めてひとつの第3節(GDS)の後に置き、もし必要ならばさらに格子配置が異なるデータを集めて記載することができる、ということを意味しています。まあしかし、いまのところ、格子配置が異なるデータを単一GRIB電文に集める用例は見かけません。

第1節の構造

オフセット 内容
0-3 非負整数 節の長さnn(オクテット数)。少なくとも21以上。
4 非負整数 節番号(すなわち1
5-6 共通符号表C-11 GRIB電文を作成した中枢の番号
7-8 作成中枢で割当(共通符号表C-12に掲載) GRIB電文を作成した副中枢の番号
9 符号表1.0 GRIBマスター表のバージョン番号
10 符号表1.1 マスター表に付加して使用されるGRIB地域表のバージョン番号
11 符号表1.2 参照時刻の意味
12-13 符号付整数 参照時刻の西暦年。ただし識別テンプレート1.1または1.2が指定された場合にはそこで指定された万年の桁を加算する。
14 非負整数 参照時刻の月
15 非負整数 参照時刻の日
16 非負整数 参照時刻の時
17 非負整数 参照時刻の分
18 非負整数 参照時刻の秒
19 符号表1.3 production status(現業、現業試験、研究などの区別)
20 符号表1.4 資料の種類(解析・予報・摂動・観測などの区別)
21-22 符号表1.5 テンプレート(オフセット23以降の構造)の番号。第1節の長さが21オクテットの場合は本欄は存在しない。
23-(nn-1) テンプレート1.0~1.2のいずれかで規定される構造
  • 第1節の長さは、GRIB第2版制定当初は21オクテットしかありませんでした。オフセット12-13が指示する西暦年が符号付か否かについて明確な定めがなかったため、誤解なく表現できるのは西暦1年から西暦32767年までに限られていました。リアルタイム現業予報ではそれで充分だったのです。
  • 発信者を示す「中枢 centre」は WMO により国家気象機関等に割り当てられます。GRIBだけでなくBUFRなどと共通の符号表なので共通符号表C-11という名前になっています。
  • 各国内で発信者を複数識別したい場合には副中枢 subcentre を各国ごとに割り当てることができて、WMOが取りまとめて共通符号表C-12として公刊されています。日本では207(昭和基地)、240(清瀬)、241(再解析プロジェクト)が割り当てられていますが、知る限り実用されているのは再解析だけです(再解析はいまのところGRIB第1版だけれど同じ表が用いられる)。副中枢の区別を特に用いない場合は 0 が記載されます。
  • 符号付整数は符号ビット方式で、2の補数表現ではないことに注意してください。最上位ビットが1の場合が負数、残りのビットが絶対値となります。

表のバージョン番号のめんどくさい話

  • マスター表のバージョン番号(オフセット9)はWMOでの合意に基づき新しいものが作られ、ローカル表のバージョン番号(オフセット10)は基本的に独立

第2節の構造

オフセット 内容
0-3 非負整数 節の長さnn(オクテット数)
4 非負整数 節番号(すなわち2
5-(nn-1)

日本では使用されませんので、特に紹介すべき情報を知りません。

第3節の構造

第3節のうち、テンプレートによらない共通部分

第3節は後続の第7節が表現する水平二次元格子を地球上の位置に結び付けるための情報を格納するものです。その構造は水平面内で用いられる座標系によって異なりますが、先頭部分は次の共通構造を持ちます。

オフセット 内容
0-3 非負整数 節の長さnn(オクテット数)
4 非負整数 節番号(すなわち3
5 符号表3.0 格子系番号(通常は0にする)
6-9 非負整数 資料点の数
10 非負整数 付加リストの項目毎のオクテット数。本欄が0ならば付加リストは存在しない
11 符号表3.11 付加リストの意味
12-13 符号表3.1 格子系定義テンプレート番号。格子系番号(オフセット5)が非零の場合は本欄を欠く
14-(x-1) 格子系定義テンプレートにより異なる内容
x-(nn-1) 整数列 付加リスト

第3節に必ず存在するのは、オフセット0-11の12個オクテットです。通常は格子系番号(オフセット5)が0であり、オフセット12-13で与えられる格子系定義テンプレート番号によって、その先の構造が決まります。

仮に格子系番号が0でなければ、発信センターがあらかじめ定義した座標系番号表によって座標系を記述するメタデータが与えられ、第3節のオフセット12以降は省略されることになっています。しかしこうしてしまうと自己記述性が劣るため、実際に使われている例は知りません(GRIB第1版の類似機能は海外では使われていたようです)。

付加リストと呼ばれる整数列は、緯度ごとに東西格子数が異なる不規則格子を表現するためのものです。たとえば数値シミュレーションに用いられる Reduced Gaussian Grid がいい例で、高緯度になるにしたがって東西の格子数を減らすことによって東西格子間隔を概ね同じになるようにして、CFL条件を緩和させるためにこのようなものが用いられます。気象庁が対外配信しているGRIB2はすべて経緯度等間隔格子なので、付加リストは用いられていません(GRIB第1版では類似機能を用いた例があります)。

格子系定義テンプレート 3.0(正距円筒図法)

第3節オフセット12-13が 0 となっている場合、格子は等間隔の緯度および経度で配置されます。あるいは正距円筒図法の投影面上で等間隔と言ってもよいでしょう。今のところ、気象庁から配信されるGRIB2は基本的にこの格子系です。

オフセット 内容
14 符号表3.2 地球の形状
15-19 40ビット数値 地球を球とする場合の半径
20-24 40ビット数値 地球を回転楕円体とする場合の長軸
25-29 40ビット数値 地球を回転楕円体とする場合の短軸
30-33 非負整数 Ni ― 緯線に沿った格子点数
34-37 非負整数 Nj ― 経線に沿った格子点数
38-41 非負整数 経緯度の単位(分子)、ただし通常は 0 を記載する
42-45 非負整数 経緯度の単位(分母)、ただし通常は 0xFFFFFFFF を記載する
46-49 符号付整数 La1 ― 最初の格子点の緯度
50-53 符号付整数 Lo1 ― 最初の格子点の経度
54 フラグ表3.3 分解能および成分フラグ
55-58 符号付整数 La2 ― 最初の格子点の緯度
59-62 符号付整数 Lo2 ― 最初の格子点の経度
63-66 整数 Dii方向の格子間隔
67-70 整数 Djj方向の格子間隔
71 フラグ表3.4 走査モード
72- 付加リストがあるとすればここ
  • データ型「40ビット数値」としているところは最初の1オクテットが十進スケールf、残り4オクテットが(おそらく非負)整数vを表わします。真値Lは次式で与えられます(規則92.1.12): L = 10^(-f)・v
  • 地球の形状(オフセット14)は、日本気象庁発のGRIB電文では符号0(半径6371 kmの球)とし、地球の大きさ(オフセット15,20,25)は与えないことが多いです。で、これを座標系の記述と思わないでください。投影面上の長さという概念を経由せず、経緯度だけで考え、球面上だろうが楕円体上だろうが経緯度はすべて同一視する習慣だからです(もうちょっと丁寧に書かないといけないかな…)。
  • 通常はオフセット38-41の値が 0 で、オフセット42-45の値が0xFFFFFFFFとなっており、その場合は経緯度 (La1, Lo1, La2, Lo2) の単位は 1/1000000 度角です。そうでない場合は、オフセット38-41が分子、オフセット42-45が分母の分数で経緯度の単位が示されると文書上は読めるのですが、実例を知りません。
  • 任意の番号の格子の経緯度を求める場合は、(La1, Lo1, La2, Lo2) から案分することをお勧めします。一見すると (Di, Dj) に格子番号をかけて (La1, Lo1) に加算すればよさそうにみえますが、丸め誤差が累積して不正確になることと、不規則格子では通常 Di が欠損値となることからです。
  • 第1節でも書きましたが符号付整数は符号ビット方式であることに注意してください。

分解能及び成分フラグ(オフセット54)は、TBD

走査モード(オフセット71)は、TBD

格子系定義テンプレート 3.〓(メルカトル図法)

TBD

第4節の構造

第4節(英語ではPDS=Product definition section)には、後続の第7節が表現するデータが何であるかや、時間・高度などのメタデータが記載されます。

第4節のうち、テンプレートによらない共通部分

オフセット 内容
0-3 非負整数 節の長さnn(オクテット数)
4 非負整数 節番号(すなわち4
5-6 非負整数 テンプレート直後の鉛直座標リストの長さ
7-8 符号表4.0 プロダクト定義テンプレート番号

プロダクト定義テンプレート4.0(ある時刻の、ある水平面または水平層における解析または予報)

オフセット 内容
9 符号表4.1 パラメータカテゴリー
10 符号表4.2 パラメータ番号
11 符号表4.3 作成処理の種類
12 日本では符号表JMA4.1 背景作成処理指示符号(モデルの識別)
13 日本では符号表JMA4.2 解析または予報の作成処理識別符
14-15 非負整数 参照時刻から観測資料の締め切りまでの時間(時単位、65534以上の場合65534とする)
16 非負整数 参照時刻から観測資料の締め切りまでの時間(分単位)
17 符号表4.4 予報時間の単位
18-21 非負整数 予報時間
22 符号表4.5 第一固定面の種類
23-27 40ビット形式 第一固定面の座標値
28 符号表4.5 第二固定面の種類
29-33 40ビット形式 第二固定面の座標値
  • パラメータとは、物理量の識別のようなものです。分野番号(第0節オフセット6)、パラメータカテゴリー番号(第4節オフセット9)、パラメータ番号(第4節オフセット10)の3個オクテットでマスター表のパラメータが識別されます。主だったものを下に示します。
  • 作成処理の具体的な例は表をみていただきたいですが、数値予報においてはモデルの名前を区別するものです。全球モデル、メソモデル、極地モデルというように解像度の異なるシミュレーションを順次行うことがあり、それらの結果を区別するためにこの欄を用います。
  • 観測資料の締め切り時間というのは、たとえば参照時刻が 0:00 UTCのシミュレーションが 2:30 UTC までに入手できた 0:00 UTC のデータを同化しているならば、締め切り時間が2時間30分となるわけです。日本気象庁では例を知りませんが、締め切り時間の異なるシミュレーションを識別できるようにこの欄が設けられています。
  • ほとんどのパラメタ(たとえば気温)について、第一固定面と第二固定面は同一の値が格納されます。これは厚さのない水平面上における値です。たとえば500 hPa面であれば第一固定面(オフセット22)と第二固定面の種類(オフセット28)が100(等圧面(Pa))、第一固定面(オフセット24-27)と第二固定面(オフセット30-33)の座標値が 50000 となります。
  • 層厚のようにごく一部のパラメタは、上下2つの固定面の間の層に対して定義されるので、第一固定面と第二固定面の座標値が異なることになりますが、日本気象庁ではそのようなパラメタを用いません。

符号表4.2(抜粋)

分野 カテゴリー パラメータ 単位 説明
0 0 0 K 温度
0 0 6 K 露点温度
0 1 1 % 相対湿度
0 1 7 kg.m-2.s-1 降水強度
0 1 8 kg.m-2 総降水量
0 1 200 レベル値 1時間降水量(日本ローカル)
0 1 201 レベル値 10分間降水強度(1時間換算値)(日本ローカル)
0 1 206 レベル値 土壌雨量タンクレベル値(日本ローカル)
0 2 2 m.s-1 風のu成分
0 2 3 m.s-1 風のv成分
0 3 0 Pa 気圧(現地気圧)
0 3 1 Pa 海面更正気圧
0 3 5 gpm ジオポテンシャル高度
0 3 12 m 層厚
0 6 1 % 全雲量
1 2 0 m 内水の水深
2 3 18 K 土壌温度

第5節の構造

第5節(英語ではDRS=Data representation section)には、後続の第7節のオクテット列を二次元配列として記載・解読する形式を規定するためのメタデータが記載されます。

第5節のうち、テンプレートによらない共通部分

オフセット 内容
0-3 非負整数 節の長さnn(オクテット数)
4 非負整数 節番号(すなわち5
5-8 非負整数 全資料点の数(ビットマップがある場合には欠損ではない資料点の数)
9-10 符号表5.0 資料表現テンプレート番号
  • オフセット5-8の解釈についてビットマップの用例で要確認

資料表現テンプレート5.0(単純圧縮)

オフセット 内容
11-14 IEEE754 float32 参照値 R
15-16 符号付整数 二進スケールファクター E
17-18 符号付整数 十進スケールファクター D
19 非負整数 圧縮結果のビット数
20 符号表5.1 オリジナルデータが整数か浮動小数点数かの識別

第7節オフセット5以降のビット列を、第5節オフセット19で与えられるビット数ごとに切り出して数値 X を得たら、本来のデータ Y は次の式で復元できます:

Y = (R + X × 2^E) × 10^(-D)

  • 第1節でも書きましたが符号付整数は2の補数方式ではなく符号ビット方式であることに注意してください。
  • オフセット20を解読時にどう使うのがいいのかはちょっとよくわかりません。

第6節の構造

第6節(英語ではBMS=Bitmap section)はビットマップすなわち1ビットが1格子を表わす形式で、欠損値格子を記載します。

オフセット 内容
0-3 非負整数 節の長さnn(オクテット数)
4 非負整数 節番号(すなわち6
5 符号表6.0 ビットマップ指示符
6-nn バイナリ ビットマップ

欠損値がない場合、ビットマップ指示符は 255 (本プロダクトにビットマップは適用せず)とします。ビットマップを用いる場合、ビットマップ指示符は 0 とすべきです。符号表6.0に定めるその他の値は、自己記述性が劣るため使われるべきではないし、実際そんな用例は知りません。

第7節の構造

第7節(英語ではDS=Data section)は、二次元配列そのものを、直近の第5節で規定される形式で記載します。

オフセット 内容
0-3 非負整数 節の長さnn(オクテット数)
4 非負整数 節番号(すなわち7
5-nn バイナリ 第5節の説明参照
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Sign upLogin
19
Help us understand the problem. What are the problem?