8. (参考) 規定の注釈

2005-08-22T10:16:07+09:00 地球流体電脳倶楽部 davis プロジェクト

用語: netCDF ファイル

NetCDF に関する文献では「netCDF dataset」「netCDF file」という用語は区別されずに用いられている。「データセット」という用語は汎用計算機で「ファイル」を指すのに用いられた。 gtool4 プロジェクトでは「ファイル」という用語を使うオペレーティングシステムを利用することを想定しているので、親しみやすいと思われる「ファイル」を用いた。

サポートする既存の規約

NCAR-CSM 規約を重要視したのは、数値モデル NCAR CSM によって作られる数値データとの可搬性を考慮したためである。

ファイル名

ファイル名の末尾を固定するのは、ファイル名の末尾によって起動すべきアプリケーションを決めるソフトウェアが不便にならないようにするためである。

ファイル名を 8 文字に制限する推奨規約は、ISO 9660 level 1 (CD-ROM) ファイルシステムを考慮したものである。 CD-ROM への可搬性を考慮しなければ、文字数に関する制限は事実上なくなり、ハイフンマイナスなどのありふれた文字を利用することもできるようになる。

変数名

NetCDF ユーザーズガイドによれば、変数名、次元名、属性名は以下の規則に従わねばならない。

英字、数字、下線、またはハイフンマイナスで構成されなければならない。
名前の最初の文字は英字でなければならない。
予約語を使ってはならない。予約語とは、char, byte, short, int, long, float, real, double のいずれかである。予約語の任意の小文字を大文字に置き換えたものも予約語である。
最初の文字が下線となっている名前は netCDF ライブラリの内部的使用のために予約されている。

ユーザーズガイドには書いていないが、dimensions, variables, data も予約語とすべきである。

構造体変数

NetCDF ファイルの構造体変数は、生成系・解釈系の内部で構造体またはクラスとして表現されるデータ構造と一対一対応する利用を想定している。

しかし、実装は自由であるから、解釈系は構造体変数を読み取った結果をひとつの構造体（またはクラスの実体）に格納しなければならないわけではない。

appendices 属性

これにより、他の GDT 互換性を十分に考慮しておけば、 :Conventions 属性値を "GDT" と変更するだけで完全に GDT 規約に従うことが可能となる。

履歴情報の信頼性

以下のような理由から、history 属性から意味のある情報を機械的に取り出すことはできない。

記入される情報が既存の規約では標準化されておらず、属性値を解析することは不可能
編集履歴が netCDF の規定どおりに追加されずに、 history 属性の先頭に挿入される実装が存在する
複数のデータファイルから情報が生産される場合、そのひとつの履歴だけが保存される

非数以外の欠損値表現法の必要性

NetCDF で用いる外部表現の浮動小数点形式は IEEE 754 規格である。 IEEE 754 規格には非数 (Not a Number, NaN) があり、非数と通常の実数の演算結果は欠損値の条件を満たす。従って、内部表現も IEEE が使えることが確実であれば、欠損値としては非数を用いることができる。そうすればプログラムは欠損値処理を明示的に書く必要がない。

しかしながら、実際には伝統的なプログラミング言語 (たとえば C, Fortran 90 など) はともに IEEE 754 規格が使えることも非数が使えることも保証していない。また、netCDF の想定しているプラットフォームでも内部的に IEEE 754 規格の数値演算が行える保証はない。

IEEE 754 以前から習慣として、「無効な数値」の範囲 (または単独の欠損値) を定義しておいて、その範囲の数値を欠損値とみなす処理が行われてきた。 IEEE 754 規格の使えない環境が無視できるようになった現在も、 gtool4 規約の対象とする領域にとってこの習慣は無視できないものである。

以上のような理由から、著者にとって非常に残念なことではあるが、 gtool4 規約においても欠損値範囲の取り扱いはなされなければならないものとする。

欠損値範囲の推奨値

6.0e36 を推奨するのは、 netCDF のデフォルトの _FillValue (NF_FILL_REAL) より小さく、単精度実数形式の指数部が繰り上がった直後だからである。

周期的座標と modulo 属性の必要性

GDT の議論によれば、 modulo 属性が必要なのは座標変数の単調増加性を維持するためである。たとえば「0 から 360 まで」の経度座標の切断点を動かして「180 から 360 すなわち 0 を経由して 180 まで」の座標に作り変える場合、周期性を利用してたとえば「-180 から 180」のように単調増加の値に変換しなければならない。このために周期を知る必要がある。

構造体変数の型と次元

構造体変数の型を int とした意味はない。強いて言えば、C では型のない宣言は int となることに合わせた。

解釈系が構造体変数の型及び次元について仮定してはならないひとつの理由は、将来違った型になるかもしれないからである。もうひとつの理由は、従来型変数に gt_structure_class 属性を付加して構造体変数に見せかける利用法を許容するためである。

構造体リンクの短縮名称

構造体のリンクを行うためには変数名から短縮名称を生成せねばならない。単に変数 URL を列挙するようにしなかった理由は、 netCDF ファイルの外の変数にメッセージを送る場合に変数URLをそのまま属性名の一部として用いることができないからである。

リンクされた変数URLの代わりに通し番号を属性名の一部とすれば、属性名として正当な名前を付けることができるが、リンクが削除された場合にはすべての属性名を付け直さなければならない。

そこで、通し番号ではなく任意の名前を用いることにすれば、削除時には他の変数へのリンクには何もしなくてよくなる。

短縮名称の例として変数名と異なる名前が挙げられているが、これは記述を明確化するためであり、規約に反しない限りで変数名と同じ名前を与えることを推奨する。