地上気象・水文データのローカル標準フォーマット案

MAHASRIで収集している地上気象・水文データを整理する際に、標準と呼ぶのは不適切かもしれないのですが、作業用にフォーマットを統一する必要があります。その具体的な形についての提案を、文書化してみました。他の関係者のかたと相談しながら、内容も、表現も、改良していきたいと思います。したがって、このページはたぶんたびたび書きかえます。(Masudako 00:44, 14 October 2009 (UTC))

序論

必要性

• 気象データの記録形式は国あるいは機関ごとにまちまちである。通信のための標準形式はあるが、それは保存・利用に便利なものではない。
• 複数の国・機関のデータをいっしょにして公開する際には、わかりやすい形式に統一したい。
• 格子データ作成などの作業には、形式を統一した入力を使いたい。このため、公開できないデータもなるべく共通形式にしておきたい。

ここでの対象

• 地上気象・水文観測値。同一地点で一定時間間隔で継続観測されているもの。原則として数値で表現できるもの。
  • 空間次元をもたないものに限る。
    • ゾンデ観測など多数の高さでの値をもつものは、これとは別に考える。
    • 複数だが少数の決まった高さ(深さ)で測定されている場合は、高さごとに別々の気象要素として扱う。
  • 「気象要素」という用語を水文データ(河川の水位、流量など)についても便宜上使う。

過去の経験

• GAME-T http://hydro.iis.u-tokyo.ac.jp/GAME-T/GAIN-T/
• GAME Phase 2 CD-ROM http://game.suiri.tsukuba.ac.jp/cdroms/CD-ROM.html#datacd h【[2015-10-15変更] http://www.suiri.tsukuba.ac.jp/~game/cdroms/CD-ROM.html】
• 日(および3時間)降水量: テキストファイル。1地点1年を1ファイルとする。1時刻(1日または3時間)を1行とし、各行には日付(3時間値の場合は時刻も)と観測値がタブ区切りでならんでいる。各ファイル末に「#」で始まる行があり、年の有効観測件数、合計値などの情報がある。無降水は「0」、微量降水は「+0.0」、欠損は「-9999」が観測値のところにはいる。
• その他の地上気象データ: テキストファイル、1地点1年を1ファイルとする、1時刻を1行とするという基本は上と同様。同一日時の観測値は横にならぶ。それ以外は、提供機関ごとに気象要素の組み合わせが違うなどの理由で、統一されていない。最初の行に各列の気象要素名が示されている。

観測値データファイル

大まかな構造

ファイル形式

• テキストファイルとする。
  • ASCIIの印字可能文字、空白、改行コードだけで構成する。タブは使わない。
  • 改行コードはLFのみを原則とするが、CR+LFを許容する(変換可能にしておく)。
  • ASCIIで表現できない情報は入れない(必要ならば別のドキュメントファイルに書く)。

ファイルの分割

• 1地点、1年、1気象要素を1ファイルとする。
  • 採用しなかった別案: 同じ時刻の気象要素を横にならべる。最初の行をヘッダ行とし、各列の気象要素略称をならべる。(GAME-2の降水量以外の地上気象データと同様)。

ファイル名

• 気象要素略称_時間間隔略称_年_地点ID[_補足情報].txt
  • GAME-Tデータでは補足情報のところに単位を入れていた。ここでもそうする可能性はあるが必須とはしない。
• 地点IDは、初めの部分に国・機関名を含み、同じ国・機関内で(原則として)文字数を統一する。
• 時間間隔略称は、d(日), 6h, 3h, h(時)。月はmo、30分は30mとするか?
• 気象要素略称の標準化は要検討。

ファイル内の構造

• まず観測値の表。
• そのあとに、特定文字で始まる行で、簡単なメタデータ情報。

観測値の表の部分

形式

• 固定長フィールド、かつ、空白区切りとする。
  • ←人が目で見て確認するため、数値の桁が縦にそろっているとよい。
  • ←Fortranで、固定幅書式でも、並びによる入力(書式のところに*)でも読めるとよい。
  • ←表計算へのとりこみもほぼ自動でできるようにしたい。
  • ←再加工しないで、gnuplot, GMT, Rなどで読めるとよい。
• 表として見たとき、行と列の数がそろった長方形の表にする。
  • フラグ列が一部の行だけに例外的につけ加わってもよいとするか、「問題ない」というフラグ値で埋めてフィールド数をそろえるか、要検討。
  • ある時刻の観測値の情報が原資料にない(欠損フラグもない)とき、その時刻の行を作って欠損フラグで埋めておくべきか、行が欠けたままにしておいてよいか、要検討。

日時のフィールド

• 複数の整数値フィールドを使って日時を表現し、さらにファイル内通しの時間座標値のフィールドをもつ。
• 採用しなかった別案: 「日付型」の単一のフィールドとする。
• 日値データでは、年、月、日、通しの日付の4フィールド。通しの日付は1月1日を1とする。2月29日も数える。年末は365または366となる。
• 1時間以上1日未満の時間間隔のデータでは、年、月、日、時、時間座標値の5フィールド。時間座標値は1月1日0時を0として日単位の数値。
  • Time zoneの扱いは要検討。現在の案は次のとおり。年・月・日・時のほうでは原資料提供機関の標準に従う。時間座標値のほうはUTCとする。
  • 時間座標値の小数桁数。要検討。現在の増田の処理では4桁 (1分以上の間隔の時刻を復元可能にしたつもり)。桁数とまるめかたを統一するか、不統一でもよいとするか? 3時間の倍数は3桁で厳密に表現できるが、1時間は無限小数になる。
  • 日時の整数値の上位の0は空白とするのを原則とするが、0も許容する。
• 観測された数量と時間座標値との関係は、観測値が瞬間値、積算値、時間平均値のいずれかによっても違うし、積算値や平均値の場合は区間をどの時刻で代表させるかによって違うが、その区別はここには書かれない。ドキュメントには書くことが望ましい。

観測値とフラグのフィールド

• 同じ時刻に観測値とフラグの両方の情報が必要なことがあれば、その機関のその気象要素のデータには観測値とフラグの両方のフィールドを用意する。
• 観測値とフラグのどちらかだけが有効な場合は、同じフィールドを観測値とフラグに兼用する。
  • この場合、フラグは数字以外のASCII文字を使い、数値と明確に区別されるようにする。(要検討。こうすると、数値を期待して読むプログラムでエラーを起こす。他方、数値で表現すると、気づかずに数値として処理してしまうおそれがある。たとえフラグを別フィールドにしたとしても、有効な数値がないところを何で埋めるかは問題。)
    • (農業課題との連携では、フラグを文字で表現したものと数値で置きかえたものの両方を作る約束になっている。)
• データ欠損は「M」とする。
  • 同じ欠損でも、原資料に欠損フラグがある場合、原資料に記録がない場合、フォーマット変換の想定外の値だった場合、解析者が欠損と判断した場合、解析者がまちがった値と判断した場合などがある。今のところ欠損は理由を区別せずいずれも「M」としている。履歴情報としては欠損とした理由を記録しておくのが望ましいが、フラグにもその区別を含めるべきか?
    • 変換の想定外の場合の例。あるデータセットの風向は原則として1個の値だが、ときどき2個の数値がはいっている。出力書式を1個の場合に合わせて作ってしまったので、2個の場合は例外処理が必要となった。
• 降水量で、無降水と微量降水の区別がある場合は、無降水を「0」、微量降水を「T」とする。
  • 降水量の値に小数の桁がある場合も無降水は小数部のない「0」としたい。無降水と微量降水の区別がなくて値が0のとき「0.0」を使う。(整数値だけの場合にはどちらも「0」になってしまうが。)

単位換算と小数桁数

• 気象要素ごとに、なるべく単位を統一する。ただし、換算が不確かな場合はまず原資料のままの単位でフォーマット統一だけする。
• 単位換算をしない場合、小数桁数は、原資料に従う。ただし原資料で統一されていなかった場合は適宜判断する(統一することも不統一のま残すこともありうる)。小数の桁数あるいは小数点の桁位置がそろっているのが望ましいとするが、そろっていることを保証しない。
• 換算が10進法の桁移動だけの場合は、情報落ちや有効数字の変化がないので、積極的に統一してよい。
• その他の換算では、復元可能にするために、実質的有効桁数よりも1桁程度多めにとる。もし厳密な数値になる場合はさらに余分にとることもある(たとえば雲量を全天=8から全天=1に換算する際には0.125を表現できるように小数3桁とる)。

簡単なメタデータ情報

ファイルの数値が何であるか、またその出典が何であるかを識別できる情報をファイル内に入れておく。(メタデータ情報のすべてを入れるのではなく、識別に有効な情報を書く。)

(これまでわたしは、日時と観測値だけの表の形のファイルを使ってきた。Unix関係のAwk, sort, uniqなどで加工する便宜を優先させたためである。しかし、これでは内容の意味がわからなくなることがよくある。気象要素と地点はファイル名でわかるとしても、同じ地点の同じ気象要素のデータが複数届いたり，データ加工をやりなおしたりした場合に生じるバージョンの違いが区別できない。)

形式

• メタデータ情報の行は、最初の空白でない文字を「#」とする。(シェルやAwkのコメント行、GAME-Tの前例に合わせた。)
• メタデータ情報の行は、原則として、数値データの表のあとに入れる。
• この部分も文字コードはASCIIに限る。地名、人名などにASCIIに含まれない文字がある場合もASCIIによる代用表記をする。

項目(案)

• 地点ID、地点名(optional)
• 気象要素略称、気象要素名(optional)、数量の単位
• 単位換算をした場合は、原資料での単位、原資料での小数桁数、換算式(optional)
• 原資料提供機関名(optional)
• 原資料のファイル(群)名
• フォーマット変換作業の日付、作業者識別情報、作業内容の説明(optional)、作業プログラムとそのバージョン(optional)
• 年の有効件数(optional)、集計値(optional)

フォーマット(案)

• #(空白)項目名:(空白)値
  • 項目名中にはコロンと空白を入れない(コロンはコンマなど、空白はアンダースコアに変える)。値には空白を含んでよい。

地点一覧ファイル

• 原資料には地点の位置情報が含まれているが、その資料は次のようにさまざまである。
  • 緯度経度の単位が度、度/分、度/分/秒とまちまち。
  • 標高情報があったりなかったりする。WMO気象観測地点表の場合は気圧計の高さと地面の高さがある。
  • 地点IDが複数の方式でつけられていることがある。
  • 地方名、管理区分などの情報が含まれていることが多い。
  • 地点の履歴情報も含まれることがある。
  • ファイル形式が、テキストファイル、Excel、Wordなどまちまち。
• GAME-Tでは次のように編集された地点一覧ファイルが作られた。
  • テキストファイル。1地点1行。タブ区切り。
  • フィールドは、左から、地点ID、地点名、緯度、経度。

これまでの増田の作業では、地点一覧ファイルの形式はテキストファイル・1地点1行までは統一したものの、それ以上統一せず、緯度経度の単位などは原資料に従ってきた。プログラムのほうを変えて対応する必要があった。

今後は次の2つを作るようにしたい。

定型処理用の、形式を統一した地点一覧ファイル

• テキストファイル。1地点1行。文字コードはASCIIの印字可能文字、空白、改行だけ。
• 固定長フィールド兼空白区切り。地点名の文字列中の空白はアンダースコアに変えておく。
  • 採用しなかった別案: タブ区切りで空白を許す。(GAME-Tと同様)
• フィールドは、左から、地点ID、地点名、緯度、経度、標高(optional)。
  • 地点名はあらかじめ決めておいた文字数(30字くらい)以内におさめる形にする。
  • 緯度経度は度単位の単独の数値(北緯、東経が正)。小数桁数はファイル内で統一するがファイル間では統一しない。
  • 標高を入れるかどうかはファイル内で統一。単位はメートル。
  • 緯度、経度、標高の情報欠損は欠損のフラグで埋める(「M」としたい。)

各国個別対応処理用の、原情報を尊重した地点一覧ファイル

• テキストファイル。1地点1行の表と、「#」で始まるコメント行からなる。
• 原則として固定長フィールド兼空白区切り。
  • フィールド構成は任意。コメント行でじゅうぶんな説明をつける。
• 緯度経度の度、分、秒の部分はそれぞれ別のフィールドにする。
• 表におさまらない情報はコメント行として含める。

その他のメタデータ情報を書いたドキュメント類

(この部分、充分な考察ができていない。)

• 概略ドキュメント
• データポリシードキュメント
• 原データに付属していた有用な情報(観測地点の履歴など)
• 変換履歴、変換前後のファイルの対応 (たぶん公開データにはつけないが、保存は必要)
• 加工者の判断による特別な処置の記述

[個人Wikiにあった文書の一覧へ] [増田のホームページへ]