gtool4 規約 version 4.2
2001-12-30T00:52:32+09:00 豊田英司
NetCDF に関する文献では「netCDF dataset」「netCDF file」という用語は区別されずに用いられている。「データセット」という用語は汎用計算機で「ファイル」を指すのに用いられた。gtool4 プロジェクトでは「ファイル」という用語を使うオペレーティングシステムを利用することを想定しているので、親しみやすいと思われる「ファイル」を用いた。
NCAR-CSM 規約を重要視したのは、数値モデル NCAR CSM によって作られる数値データとの可搬性を考慮したためである。
ファイル名の末尾を固定するのは、ファイル名の末尾によって起動すべきアプリケーションを決めるソフトウェアが不便にならないようにするためである。
ファイル名を 8 文字に制限する推奨規約は、ISO 9660 level 1 (CD-ROM) ファイルシステムを考慮したものである。CD-ROM への可搬性を考慮しなければ、文字数に関する制限は事実上なくなり、ハイフンマイナスなどのありふれた文字を利用することもできるようになる。
NetCDF ユーザーズガイドによれば、変数名、次元名、属性名は以下の規則に従わねばならない。
ユーザーズガイドには書いていないが、dimensions, variables, data も予約語とすべきである。
NetCDF ファイルの構造体変数は、生成系・解釈系の内部で構造体またはクラスとして表現されるデータ構造と一対一対応する利用を想定している。
しかし、実装は自由であるから、解釈系は構造体変数を読み取った結果をひとつの構造体（またはクラスの実体）に格納しなければならないわけではない。
これにより、他の GDT 互換性を十分に考慮しておけば、 :Conventions
属性値を "GDT" と変更するだけで完全に GDT
規約に従うことが可能となる。
以下のような理由から、history 属性から意味のある情報を機械的に取り出すことはできない。
ＮetCDF で用いる外部表現の浮動小数点形式は 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) より小さく、単精度実数形式の指数部が繰り上がった直後だからである。
GDT の議論によれば、modulo 属性が必要なのは座標変数の単調増加性を維持するためである。たとえば「0 から 360 まで」の経度座標の切断点を動かして「180 から 360 すなわち 0 を経由して 180 まで」の座標に作り変える場合、周期性を利用してたとえば「-180 から 180」のように単調増加の値に変換しなければならない。このために周期を知る必要がある。
構造体変数の型を int とした意味はない。強いて言えば、C では型のない宣言は int となることに合わせた。
解釈系が構造体変数の型及び次元について仮定してはならないひとつの理由は、将来違った型になるかもしれないからである。もうひとつの理由は、従来型変数に
gt_structure_class
属性を付加して構造体変数に見せかける利用法を許容するためである。
構造体のリンクを行うためには変数名から短縮名称を生成せねばならない。単に変数 URL を列挙するようにしなかった理由は、netCDF ファイルの外の変数にメッセージを送る場合に変数URLをそのまま属性名の一部として用いることができないからである。
リンクされた変数URLの代わりに通し番号を属性名の一部とすれば、属性名として正当な名前を付けることができるが、リンクが削除された場合にはすべての属性名を付け直さなければならない。
そこで、通し番号ではなく任意の名前を用いることにすれば、削除時には他の変数へのリンクには何もしなくてよくなる。
短縮名称の例として変数名と異なる名前が挙げられているが、これは記述を明確化するためであり、規約に反しない限りで変数名と同じ名前を与えることを推奨する。
構造体種別の名称のうち、device, frame, figure, ... は DCL の同名の機能から命名された。可視化表現を DCL で行う場合は同名の機能を用いることが想定されているが、そうしなくてもよい。
透視座標系という名称は Fortran 90 版 DCL の用語を用いた。
単位を表記する文法は udunits のドキュメンテーションおよびソースコードから推測した文法を明文化したものである。NetCDF および既存規約は udunits によって単位が処理されることだけを規定している。乗算やべき乗の推奨される形は JIS X 0124 に合わせた。単位名は udunits に許容されるものを用いることが推奨されるので、推奨される単位表記は単位名を置き換えなければ JIS X 0124 には適合しない。