はじめに
リアルタイム気象情報を扱う上では、たびたびWMO（世界気象機関）全球通信システム（GTS）に由来する電文ヘッダというものが現れます。気象庁から気象業務支援センター経由で配信される電文の「データ種類コード」もその延長線上にあります。
GTSとは
WMO（世界気象機関）が気象の観測および予報の結果を迅速に国際交換するために維持している通信網です。古くは無線テレタイプ放送が国際通信の基幹でしたが、1980年代からは有線通信の電報で実現されるようになりました。有線だと相手が固定化されるので、下図のように誰が誰と通信するかが決められて、世界各国で発信された電報が主要国間で中継されて世界中に届けられる、という store and forward メカニズム（ethernet の説明でも同じ用語が使われますが、無関係）となりました。その後2000年前後のTCP/IP化、2010年代のFTP PUT化を経ても基本的には「電報を送る」という概念を最新インフラでエミュレートして業務を組み立てていることは変わりません。
（図：気象庁ホームページ https://www.jma.go.jp/jma/jma-eng/jma-center/rth/RTH_Tokyo.html より）
GTSに関する取り決めは、WMO Manual on GTS https://wiswiki.wmo.int/tiki-index.php?page=ManualGTS という形でとりまとめられています。
電報とは
そもそも電報ってなんですかという話になりますよね。電気通信事業法でいう電信と技術的には同じルーツをもつものです。実際、電気通信事業法でいうところの国際電信電話会社の承継人たるKDDIさんは引き続き国際電報をやっておられまして、約款をみると混雑時に優先するものとして気象電報が挙げられているあたりに往時の名残をとどめています。
技術にもどって、KDDIさんのサイトに結婚祝電の例が挙げられているんですが、形式面ではWMO気象電報との類似点が多くて興味深いです。
- 元来はプレーンテキストのメッセージを送るもの
- 使える文字について後述します。のちにWMO気象電報はバイナリに拡張されていったけれど
- 先頭が
ZCZC、末尾がNNNN- WMOもIA2電報（後述）はそうでした
- なぜこの文字列かは知らないけれど、ナブテックス受信機（例）のようにロール紙で電報がプリンタから出てくるなら、
NNNN/ZCZCという目立つパターンを切り取り線に使えるでしょうね。
- 総じてルーティング情報とペイロードの概念が未分化
- メッセージの先頭のほうにルーティング情報がある（UDPメッセージをIPヘッダから全部印字したみたいな状態）
- 今日のTCP/IPプロトコルスタック上でファイル（任意のバイト列）を伝送するプロトコルに慣れた目でみると、どこからどこまでがペイロードかはっきりしない
- そもそも伝送路で改行を勝手にいれてよいなど、バイト列ではなくテキストを送るものという建付け
文字コードの話。KDDIさんが国際電報で使えるとしている数字、英大文字と11記号の文字集合は、ITU-T勧告S.1「International Telegraph Alphabet No.2」 と同じものです。今はITA2と略称するのでしょうが、CCITTがITUに改組する前は International Alphabet No.2 と言っていて、WMO GTSマニュアルでいう CCITT IA2とはそのことです。
WMO気象電報は後に使える文字が CCITT International Alphabet No.5 すなわち ITU-T勧告T.50 （概ね US-ASCII と思えばいいです）に拡張され、またバイナリも送れるように拡張されていきます。バイナリが伝送できるようになってGRIB（概要を以前にQiitaに書きました）のようなデータ形式が作れるようになったわけです。
いくつか生きた実例をお見せするといいでしょう。
- GMDSS第XI領域の海上警報 http://www.gmdss.org/XI.html
- そのうち日本の出した全般海上警報 https://www.wis-jma.go.jp/data/browse?LinkText=WWJP27
- 地上気象実況報（SYNOP） https://www.wis-jma.go.jp/data/browse?LinkText=SMJP01
- 地上高層実況気象報（TEMP） https://www.wis-jma.go.jp/data/browse?LinkText=USJP01
ついでに、後二者は、なにやら膨大な数字の羅列ですが、上記制約のある電報に観測データをエンコードする規則が気象通報式と呼ばれます。それはまたそのうちご説明できるといいなと思います。
いずれにしても、各電報の先頭行は SMJP01 RJTD 010000 みたいな感じのパターンになっています。これがヘッダ（GTSマニュアル上の正式名称 Abbreviated Heading Line）です。電文が中継されていく中で、各中継局はヘッダのパターンマッチングをもって転送先を決めるということをしているわけです。いわば、IPパケットの宛先アドレスに相当するものであるわけです。
ヘッダの構造
規定は GTS マニュアル Part 2 §2.3.2 にあります。正式には次のようです。
␍␍␊ T₁T₂A₁A₂ii ␣ CCCC ␣ YYGGgg [␣ BBB]
CR-CR-LF 改行だったり、行の頭に改行コードを置くスタイルは異様ですが、まあおいといて、各記号の意味は次のようです。
| 記号 | 文字種 | 意味 |
|---|---|---|
| T₁ |
A-Z
|
データ種類・大分類。別添II-5 Table A参照。 |
| T₂ |
A-Z
|
データ種類・小分類。別添II-5 Table B1-B7（T₁ の値により異なる）参照。 |
| A₁A₂ |
AA-ZZ
|
伝統的な文字形式電文（T1 = A, B, C, E, F, M, N, R, S, U, V, W）ではデータ所在地国名を別添II-5 Table C1又は海上にあっては海域を別添II-5 Table C2で与える。GRIBなど格子データ（T1 = D, G, H, O, P, Q, T）では A₁ で別添II-5 Table C3により大略の位置を、A₂ で別添II-5 Table C4またはTable C5により予報時間を与える。BUFR（T1 = I, J）については A₁ でTable C6によりデータ種類の細分を、A₂ が大略の位置を与える。 |
| ii |
01-99
|
伝統的な文字形式電文では発信国が随意に附番する。ただし観測報についてはデータポリシーで区別があり、第12回総会決議40によるアディショナルデータは 20-99 を用いることとなっているのだが実際には番号枯渇により守れないことも多い。GRIBなど格子データ（T1 = D, G, H, P, Q, T）では別添II-5 Table D2によって高度（海中（T1 = O）にあってはTable D1で深さ）を与える。 |
| CCCC | 英字4字 |
発信センターを表わします。RJTD が東京（日本気象庁）です。日本を含め多くの国で ICAO Location Identifier と整合するようにつけられていたらしいのですが、どういう経緯かはわかりませんが必ずしも一致するわけではありません。WMO Publication No.9 Volume C1 Annex に定義あり。 |
| YYGGgg | 日時分 | 基本的には発信時刻ではなく、電文のデータ内容に基づく日時分です。ただし船舶気象報などは発信時刻です。 |
| BBB | 訂正・遅延などをあらわします。書式はGTSマニュアルをみてください。 |
WMOファイル名
ヘッダは名前空間が狭小で、記号番号が枯渇して運用に苦慮するようになってきました。そこでファイル名により事実上無限の名前空間を得ようとしたのですが、長くなるので場所を改めましょう。
とりあえず、ファイル名規則が GTS マニュアル Appendix II-15 にあり、日本の気象業務支援センターから配信されるファイル名の大半が Z__ で（ごく一部が W_ で）始まるのはこの規則によるのです。