WMO全球通信システム（GTS）の電文ヘッダについて

# はじめに
リアルタイム気象情報を扱う上では、たびたびWMO（世界気象機関）全球通信システム（GTS）に由来する電文ヘッダというものが現れます。気象庁から気象業務支援センター経由で配信される電文の「データ種類コード」もその延長線上にあります。

# GTSとは
WMO（世界気象機関）が気象の観測および予報の結果を迅速に国際交換するために維持している通信網です。古くは無線テレタイプ放送が国際通信の基幹でしたが、1980年代からは有線通信の電報で実現されるようになりました。有線だと相手が固定化されるので、下図のように誰が誰と通信するかが決められて、世界各国で発信された電報が主要国間で中継されて世界中に届けられる、という store and forward メカニズム（ethernet の説明でも同じ用語が使われますが、無関係）となりました。その後2000年前後のTCP/IP化、2010年代のFTP PUT化を経ても基本的には「電報を送る」という概念を最新インフラでエミュレートして業務を組み立てていることは変わりません。

![GTS network around RTH Tokyo](https://www.jma.go.jp/jma/jma-eng/jma-center/rth/common/GTS_map_new.jpg)
（図：気象庁ホームページ 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 という形でとりまとめられています。

# 電報とは

そもそも電報ってなんですかという話になりますよね。[電気通信事業法](https://elaws.e-gov.go.jp/search/elawsSearch/elaws_search/lsg0500/detail?lawId=359AC0000000086)でいう電信と技術的には同じルーツをもつものです。実際、電気通信事業法でいうところの国際電信電話会社の承継人たるKDDIさんは引き続き[国際電報](https://www.kddi.com/phone/international/telegram/)をやっておられまして、[約款](https://media3.kddi.com/extlib/files/corporate/kddi/kokai/keiyaku_yakkan/pdf/denpo.pdf)をみると混雑時に優先するものとして気象電報が挙げられているあたりに往時の名残をとどめています。

技術にもどって、KDDIさんのサイトに[結婚祝電の例](https://media3.kddi.com/extlib/files/personal/kokusai/service/denpo/pdf/denpo_sample.pdf)が挙げられているんですが、形式面ではWMO気象電報との類似点が多くて興味深いです。

* 元来はプレーンテキストのメッセージを送るもの
    * 使える文字について後述します。のちにWMO気象電報はバイナリに拡張されていったけれど
* 先頭が `ZCZC`、末尾が `NNNN`
    * WMOもIA2電報（後述）はそうでした
    * なぜこの文字列かは知らないけれど、ナブテックス受信機（[例](https://www.furuno.com/jp/products/navtex/NX-700A#Screenshots)）のようにロール紙で電報がプリンタから出てくるなら、`NNNN` / `ZCZC` という目立つパターンを切り取り線に使えるでしょうね。
* 総じてルーティング情報とペイロードの概念が未分化
    * メッセージの先頭のほうにルーティング情報がある（UDPメッセージをIPヘッダから全部印字したみたいな状態）
    * 今日のTCP/IPプロトコルスタック上でファイル（任意のバイト列）を伝送するプロトコルに慣れた目でみると、どこからどこまでがペイロードかはっきりしない
    * そもそも伝送路で改行を勝手にいれてよいなど、バイト列ではなくテキストを送るものという建付け

文字コードの話。KDDIさんが国際電報で使えるとしている数字、英大文字と11記号の文字集合は、[ITU-T勧告S.1「International Telegraph Alphabet No.2」](https://www.itu.int/rec/T-REC-S.1-199303-I/en) と同じものです。今はITA2と略称するのでしょうが、CCITTがITUに改組する前は International Alphabet No.2 と言っていて、WMO GTSマニュアルでいう CCITT IA2とはそのことです。

WMO気象電報は後に使える文字が CCITT International Alphabet No.5 すなわち [ITU-T勧告T.50](https://www.itu.int/rec/T-REC-T.50-199209-I/en) （概ね US-ASCII と思えばいいです）に拡張され、またバイナリも送れるように拡張されていきます。バイナリが伝送できるようになってGRIB（[概要を以前にQiitaに書きました](https://qiita.com/e_toyoda/items/ce7497e1a633b16f1ff1)）のようなデータ形式が作れるようになったわけです。

いくつか生きた実例をお見せするといいでしょう。

* 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

ついでに、後二者は、なにやら膨大な数字の羅列ですが、上記制約のある電報に観測データをエンコードする規則が[気象通報式](https://www.jma.go.jp/jma/kishou/books/tsuhoshiki/tsuhoshiki.html)と呼ばれます。それはまたそのうちご説明できるといいなと思います。

いずれにしても、各電報の先頭行は `SMJP01 RJTD 010000` みたいな感じのパターンになっています。これがヘッダ（GTSマニュアル上の正式名称 Abbreviated Heading Line）です。電文が中継されていく中で、各中継局はヘッダのパターンマッチングをもって転送先を決めるということをしているわけです。いわば、IPパケットの宛先アドレスに相当するものであるわけです。

# ヘッダの構造

規定は GTS マニュアル Part 2 §2.3.2 にあります。正式には次のようです。

&#x240d;&#x240d;&#x240a; *T&#8321;T&#8322;A&#8321;A&#8322;ii* &#x2423; *CCCC* &#x2423; *YYGGgg* [&#x2423; *BBB*]  

CR-CR-LF 改行だったり、行の頭に改行コードを置くスタイルは異様ですが、まあおいといて、各記号の意味は次のようです。

|記号|文字種|意味|
|:---|:---|:---|
|*T&#8321;*|`A`-`Z`|**データ種類**・大分類。[別添II-5 Table A](https://www.weather.gov/tg/tablea)参照。|
|*T&#8322;*|`A`-`Z`|データ種類・小分類。別添II-5 Table B1-B7（*T&#8321;* の値により異なる）参照。|
|A&#8321;A&#8322;|`AA`-`ZZ`|伝統的な文字形式電文（T1 = A, B, C, E, F, M, N, R, S, U, V, W）では**データ所在地国名**を[別添II-5 Table C1](https://www.weather.gov/tg/tablec1)又は海上にあっては**海域**を[別添II-5 Table C2](https://www.weather.gov/tg/tablec2)で与える。GRIBなど格子データ（T1 = D, G, H, O, P, Q, T）では *A&#8321;* で[別添II-5 Table C3](https://www.weather.gov/tg/tablec3)により**大略の位置**を、*A&#8322;* で[別添II-5 Table C4](https://www.weather.gov/tg/tablec4)または[Table C5](https://www.weather.gov/tg/tablec5)により**予報時間**を与える。BUFR（T1 = I, J）については *A&#8321;* で[Table C6](https://www.weather.gov/tg/tablec6)によりデータ種類の細分を、*A&#8322;* が大略の位置を与える。|
|*ii*|`01`-`99`|伝統的な文字形式電文では発信国が随意に附番する。ただし観測報についてはデータポリシーで区別があり、第12回総会決議40によるアディショナルデータは `20`-`99` を用いることとなっているのだが実際には番号枯渇により守れないことも多い。GRIBなど格子データ（T1 = D, G, H, P, Q, T）では[別添II-5 Table D2](https://www.weather.gov/tg/tabled2)によって高度（海中（T1 = O）にあっては[Table D1](https://www.weather.gov/tg/tabled1)で深さ）を与える。|
|*CCCC*|英字4字|*発信センター*を表わします。`RJTD` が東京（日本気象庁）です。日本を含め多くの国で ICAO Location Identifier と整合するようにつけられていたらしいのですが、どういう経緯かはわかりませんが必ずしも一致するわけではありません。[WMO Publication No.9 Volume C1 Annex](https://www.wmo.int/pages/prog/www/ois/Operational_Information/VolumeC1/CCCC_en.pdf) に定義あり。|
|*YYGGgg*|日時分|基本的には発信時刻ではなく、電文のデータ内容に基づく日時分です。ただし船舶気象報などは発信時刻です。|
|*BBB*||訂正・遅延などをあらわします。書式はGTSマニュアルをみてください。|

# WMOファイル名

ヘッダは名前空間が狭小で、記号番号が枯渇して運用に苦慮するようになってきました。そこでファイル名により事実上無限の名前空間を得ようとしたのですが、長くなるので場所を改めましょう。

とりあえず、ファイル名規則が GTS マニュアル Attachment II-15 にあり、日本の気象業務支援センターから配信されるファイル名の大半が `Z__` で（ごく一部が `W_` で）始まるのはこの規則によるのです。