\documentclass{article} \topmargin -20mm \topskip 0mm \oddsidemargin -5mm \textwidth 165mm \textheight 250mm \parindent 0mm \parskip 1em \begin{document} \begin{center} {\Large netCDF データの規約(属性)についての調査\\[1cm] } {\large 平成12年1月17日(第2版)\\ % NCAR-CSM に関する調査を追加 {\small 履歴 平成11年10月23日(第1版)}\\[1cm] 赤堀浩司\\ akahori@cse.nagoya-u.ac.jp\\[1cm] } \end{center} \tableofcontents \newpage \section{はじめに} \subsection{情報源} 調査にあたっては、netCDF のホームページ http://www.unidata.ucar.edu/packages/netcdf/ 以下の情報を利用した。 基本となるものは、netCDF を提供する Unidata が定めた次の規約 (ドキュメントと呼ぶ)である。 \begin{itemize} \item NetCDF-3 User's Guide for Fortran, Russ 他著, 1997, http://www.unidata.ucar.edu/packages/netcdf/guidef/, の 8. Attribute Convention の冒頭および 8.1 Attribute Conventions. (NetCDF-3 User's Guide for C も調査したが、属性に関しては両者はほぼ同 じである). \vspace{1em} このドキュメントの ver.2.4 の石岡圭一氏による翻訳 「netCDF ユーザーズガイド(version 2.4), (FORTRAN 対応部分の日本語訳)」 http://www.gfd-dennou.org/arch/netcdf/netcdf-jp/SIGEN.htm. もバージョンの違いに注意して参照・転載した. \end{itemize} NetCDF では、利用者グループが適当な手続きに従って新たな規約を定める ことができる。その情報は、上述のホームページの「NetCDF conventions」 の項目以下から得ることができる。 \begin{itemize} \item COARDS Convention, (Cooperative Ocean/Atmosphere Research Data Service が提供, 1995, \\ http://ferret.wrc.noaa.gov/noaa\_coop/coop\_cdf\_profile.html) \item GDT Convention, (Gregory, Drach, Tett による規約, 1999年3月の Ver.1.3 が最新, \\ http://www-pcmdi.llnl.gov/drach/GDT\_convention.html) \item ICSPAT Conventions \item NCAR-RAF Conventions \item NUWG Conventions \item PMEL-EPIC Conventions \item Proposals for coordinate conventions and coordinate conventions postings (ongoing discussion) \end{itemize} 上の場所からはたどれない\footnote{Boville センセは、NetCDF のグループ とは同じところにいるわけで、わざわざそんなところにリンクを張ることも ないのだ(赤堀の意訳)とおっしゃってた。}が、次の規約は無視できない。http://www.cgd.ucar.edu/cms/eaton/netcdf/NCAR-CSM.html \begin{itemize} \item NCAR-CSM NetCDF Conventions \end{itemize} \section{情報源の概略} \subsection{ドキュメント} 以下の「属性(attribute)」について説明している。 \begin{verbatim} units long_name valid_min valid_max valid_range scale_factor add_offset _FillValue missing_value signedness C_format FORTRAN_format title history Conventions \end{verbatim} \subsection{COARDS の規約の項目} 以下の項目について説明している。必ずしも「属性」ではないことに注意。 次節の GDT はこの規約を意識している。 \begin{verbatim} File Name: Coordinate Variables: Global attributes: Data Variable attributes: long_name scale_factor add_offset _FillValue missing_value Units attribute: Other attribute: Variable names: Rectilinear coordinate systems, only: Number of dimensions: Coordinate variable names: Order of dimensions: Data type: Coordinate value ordering: Coordinate Variable Attributes: Time or date dimension: Climatological time: Vertical (height or depth) dimension: Latitude dimension: Longitude diminsion: \end{verbatim} \subsection{GDT の規約の項目} 以下の項目について説明している。「属性」ではないことに注意。 属性の説明は、各項目の中で適宜行なわれており、また、 Appendix A に一覧表がある。文章中では COARDS データと相反する 規約について注意が書いてある。量は膨大。 \begin{verbatim} 1 Purposes 2 Filename 3 Data types 4 Attributes 5 Global attributes 6 Variable names 7 Data variables 8 Coordinate variables 9 Axes and dimensionality of a data variable 10 Coordinate systems 11 Units 12 Physical quantity of a variable 13 Topology of an axis 14 Longitude dimension 15 Latitude dimension 16 Vertical (height or depth) dimension 17 Component variables 18 Associated variables 19 Bundles 20 Boundary variables 21 Representation of subgrid variation 22 Contracted dimensions 23 Time variables and intervals 24 Relative time 25 Absolute time 26 Gregorian calendar 27 Non-Gregorian calendars 28 Multiple time axes and climatological time 29 Invalid values in a data variable 30 Missing values in a data variable 31 Compression by gathering 32 Compression using a scale and offset A Attributes B Methods of representing subgrid variation C Modifications to udunits.dat D Long names for quantities \end{verbatim} \subsection{ICSPAT 規約} Imperial College Space and Atmospheric Physics Group (ICSPAT) の規約。 この規約は 1994年 の Q 時系列解析で採用されたとあるが、規約の具体的な 内容は載っていない。 \subsection{NCAR-RAF 規約} National Center for Atmospheric Research の Research Aviation Facility の規約。1994 年。飛行機の時系列データに特化した規約を定めている。 サンプルデータあり。 \begin{verbatim} Dimensions: Time: Global attributes: Variable attributes: \end{verbatim} \subsection{NUWG 規約} 1992 年に作られた NetCDF Users Working Group (NUWG) の規約。 サンプルデータあり。 ミーティングをしていろいろなことを議論しているが、 Web ページで見る限りでは 1996 年以降は活動を停止している。 現在のところ、この規約については調査していない。 \begin{verbatim} General Conventions approved by NUWG (少ない) Conventions for Surface Observations (少ない) Conventions for Upper Air Observations (少ない) Conventions for Georeferenced Gridded Data (多い) Conventions for Satellite Data (ちょっと多い) \end{verbatim} \subsection{PMEL-EPIC 規約} NOAA の Pacific Marine Environmental Laboratory (PMEL) が、海洋データに 対して EPIC ソフトウエアパッケージを使うために作った規約。サンプルプロ グラム・データあり。未調査。 \begin{verbatim} General Conventions Axes Longitude Axis Latitude Axis Depth Axis Time Axis Variables Attributes Oceanographic Data Types: Conventions for Profile Type Data , e.g., CTD, XBT, Bottle data Conventions for Time Series Type Data , e.g., Buoy data Conventions for Track-line data, e.g., Shipboard ADCP Data (preliminary) \end{verbatim} \subsection{Proposals for coordinate conventions and coordinate conventions postings (ongoing discussion)} メイルの一覧がある。未調査。 \subsection{NCAR-CSM の規約} NCAR Climate Systems Model の出力データに用いられている規約。 COARDS の規約を拡張している。次の項目からなる。やや長い。 \begin{verbatim} 1. Overview 1.1 Convention Purpose and Philosophy 1.2 Summary 1.3 Relationship to the COARDS Convention 2. Conventions for Required Attributes 2.1 long_name Attribute 2.2 units Attribute 2.3 Coordinates 2.3.1 Time 2.3.2 Dimensional Vertical Coordinates 2.3.3 Dimensionless Vertical Coordinates 2.3.4 Latitude 2.3.5 Longitude 2.3.6 Non-Rectilinear Coordinates 2.4 Global Attributes 3. Conventions for Optional Attributes 3.1 Calendar / Orbital Parameters 3.2 Representing Values on Intervals 3.3 Non-Ordinal Coordinates 3.4 Projection Coordinates 3.5 Flux Direction 4. Resources \end{verbatim} \section{ドキュメントに記載された属性} ここでは、ドキュメントの 8.1 節を掲載し、そこに COARDS および GDT が定める規約の該当部分との比較調査の結果を示す。\\[1em] アンダースコア(`{\tt \_}')から始まる名前はnetCDFライブラリの使用のため に予約されている. netCDFファイルを加工する一般の多くのアプリケーションは, 標準的な属性の 慣習を仮定しており, そうしないだけの正当な理由が無い限りは, これら のとりめに従うことを強く勧める. 以下に, 推奨される標準的な属性(便利であることがすでに示されている)の名 前および意味のリストを示す. これらのうち, 数値データが仮定され, 文字データとしては使われないものも ある(例えば, {\tt units}, {\tt valid\_range}, {\tt scale\_factor})こと に注意が必要である. \begin{itemize} \item{\tt units} \begin{description} \item[ドキュメント] 変数データに対して使われている単位を指定する文字列. Unidata は, 自由に取得可能なルーチンのライブラリを提供しており, それ によって文字列と単位記述のバイナリ形式との間の変換を行うこと ができ,さらにそのバイナリ形式においては, いろいろと便利な操作 を実行できる. このライブラリはいくつかのnetCDFアプリケーショ ンにおいて使われている. 推奨される単位構文を使えば, 整合単位 で表現されたデータを, 算術演算できる一般的な単位に自動的に変 換できる. より多くの情報については, Appendix A [単位]を参照. \item[COARDS] 基本的にドキュメントに同じく udunits に従うことを推奨する. その複数形も使える. ただし, その規定から "degrees" を削除し、 "level","layer","sigma\_level" を追加する。 経度を表すときは, "degrees\_east","degree\_east","degrees\_E", "degree\_E" を使うことを推奨する. 経度は "degrees\_north", "degree\_north","degrees\_N","degree\_N" を使うことを推奨する. \item[GDT] 基本的にドキュメントに同じく udunits に従うことを推奨する. ドキュメントとの違いは、 Appendix C で示しており、今のバージョンでは、 degrees は認めない. year と month は認めない. calendar\_month と calender\_year は, お互い あるいは他の時間単位との変換ができない. ただし, カレンダー年と, 12 カレンダー月の倍数との間では変換可能. \vspace{1em} (11) この規約のユーザは、ユーザ自身の単位を定義すべきではない。 これは、ユーザのファイルを配布しにくくするからである。 Unidata に新しい単位の要求を要望すべきである。 \vspace{1em} (12) 変数の物理量に対する単位説明。 属性 {\tt units} においては大・小文字の区別は重要。 この属性は、量が無次元(純粋な数)でないならば必須である。 \vspace{1em} (14) 経度を表わす座標変数は属性 {\tt units} を含まなければならない。 デフォルトはない。 \vspace{1em} (15) 緯度を表わす座標変数は属性 {\tt units} を含まなければならない。 デフォルトはない。 \vspace{1em} (16) COARDS と異なり、鉛直座標は属性 {\tt units} を含む必要はない。 そのため、正の方向の判断が COARDS と異なることに注意。 \vspace{1em} また、時間に関係した次の項目で単位に関する記述がある: (23) 時 間変数と間隔について、(24) 相対時間について、(25) 絶対時間について、 (26) グレゴリオ暦について、(27) 非グレゴリオ暦について。 \item[NCAR-CSM] 全ての空間・時間座標変数には必須。これにより各変数の次元に どの座標軸が対応するかわかる。 udunits に従う。ただし degree(s) は認めない。 {\bf COARDS と異ないり、level, layer を認めない。} {\bf ドキュメントと等と異なり、属性 define\_ を利用して新しく udunits にない単位 ("hybrid\_sigma\_pressure"など)を定義することができる。} \end{description} \item{\tt long\_name} \begin{description} \item[ドキュメント] 長い記述的な名前. これは, 例えば, プロットのラベルづけに使うこ とができる. もし, 変数に属性 {\tt long\_name} が割り当てられてい なければ, 変数名がデフォルトとして使われる. \item[COARDS] ドキュメントと同様. \item[GDT] この属性はオプション。 \item[NCAR-CSM] この属性は必須。 \end{description} \item{\tt valid\_min} \begin{description} \item[ドキュメント] この変数に対する有効な値の最小値を示すスカラー. \item[COARDS] 記載なし \item[GDT] 基本的にドキュメントに同じ。 ただし、GDT が定める属性に関連して細かい約束事がある (例えば boundary 変数など。) \end{description} \item{\tt valid\_max} \begin{description} \item[ドキュメント] この変数に対する有効な値の最大値を示すスカラー. \item[COARDS] 記載なし \item[GDT] 上の {\tt valid\_min} の項目を参照のこと \end{description} \item{\tt valid\_range} \begin{description} \item[ドキュメント] この変数に対する有効な値の最小値および最大値を示す2つの数値の ベクトルであり, 属性{\tt valid\_min}および属性{\tt valid\_max} の 両方の値を指定するのに等しい. これらのどれもが有効範囲 を定義する. もし, {\tt valid\_min}または{\tt valid\_max}のど ちらかが定義されている場合には{\tt valid\_range}を定義しては ならない. \vspace{1em} 一般的なアプリケーションは, 有効範囲を外れた値を欠損とし て扱う. {\tt valid\_range}, {\tt valid\_min}, および{\tt valid\_max}のそれぞれの型は, その変数の型に合っていなければな らない(ただし, {\tt byte}型データを除く. この場合は, これらの 属性の型は, 意図する範囲を指定するために, 符号つきの integral 型であってもよい). \vspace{1em} {\tt valid\_min}, {\tt valid\_max}, および{\tt valid\_range}の どれも定義されていない場合には, 一般的なアプリケーションは, 有 効範囲を以下のように定義する. データ型がバイト型で, {\tt \_FillValue}が陽に定義されていない場合は, 有効範囲はすべての可 能な値を含む. 一方, 有効範囲は, {\tt \_FillValue}を以下のよう に除外する. もし, {\tt \_FillValue}が正ならば, それが有効な最 大値を定義し, そうでなければ, それは有効な最小値を定義する. 整 数型については, {\tt \_FillValue}とこの有効な最大または最小値 との間には1だけ違いがある. 浮動小数点型については, この違いは 丸め誤差を許すために, 表現可能な最小値(最も下位のビットが1)の2 倍の値である. \item[COARDS] 記載なし \item[GDT] 座標変数には有効範囲外の値は許されない。しかし、有効範囲を 示す属性を、境界のないセルを示すために境界変数内で用いることがで きる。 \vspace{1em} {\tt valid\_min} か {\tt valid\_max} のどちらかを定義したら、 {\tt valid\_range} を定義すべきではない。 \vspace{1em} byte 型の扱いは推奨しないので、この型に対する特別の扱いは定義 していない。 \end{description} \item{\tt scale\_factor} \begin{description} \item[ドキュメント] ある変数についてこの属性が与えられている場合, データは, それに アクセスするアプリケーションによって読み込まれる際にこのファク ター倍される. \item[COARDS] ドキュメントと同様. \item[GDT] ドキュメントと同様. \end{description} \item{\tt add\_offset} \begin{description} \item[ドキュメント] ある変数についてこの属性が与えられている場合, データは, それに アクセスするアプリケーションによって読み込まれた後にこの数が加 えられる. {\tt scale\_factor}および{\tt add\_offset}の両方の属 性が与えられている場合には, データはまずスケールされ, その後に オフセットが加えられる. 属性{\tt scale\_factor}および属性{\tt add\_offset}を同時に使うことによって, 簡単なデータ圧縮を行 うことができる;有効桁数の小さい浮動小数点データを小さな整数と してnetCDFファイルに格納することによって. スケールされたデータ を書く際には, アプリケーションは, まずオフセットを引いて, その 後でスケールファクターで割ればよい. \vspace{1em} {\tt scale\_factor}および{\tt add\_offset}を圧縮のために使う際 には,関係する変数(圧縮されたデータを格納している)は, 普通, byte型またはshort型である; 一方, 解凍されたデータはfloatまたは double型になるようにしたい. というわけで, 属性{\tt scale\_factor} および属性{\tt add\_offset}は両方とも, 解凍されたデータの持つ べき型(例えば, floatまたはdouble型)でなければならない. \item[COARDS] 基本的にドキュメントと同じ. ただし, NOAA cooperative standard は 以下のようにより厳しいものとなっている。 \vspace{1em} 属性{\tt scale\_factor} と属性{\tt add\_offset} が関連した変数と同じ データタイプの場合には, 特に制限は設けない。パックされていない データは, パックされたデータと同じデータタイプと仮定される. \vspace{1em} 属性{\tt scale\_factor} と属性 {\tt add\_offset} が(パックされ たデータを含む)関連した変数と異なるデータタイプの場合には, ファイル 内の関連した変数は単に byte, short, または long のタイプかもし れない。属性 {\tt scale\_factor} と属性 {\tt add\_offset} (これらはデー タタイプが一致しないといけない)は float または double でなけれ ばならない。この属性のデータタイプは、アンパックされたデータの意図さ れたタイプに一致すべきである. (long を float にアンパックする ことは, 潜在的な精度の消失があるので薦められない. ) \item[GDT] 座標変数も圧縮してよい. \end{description} \item{\tt \_FillValue} \begin{description} \item[ドキュメント] 属性{\tt \_FillValue}は, 変数に割り当てられているディスクスペー スを前もって埋めるために使われるフィル値を指定する. この ような前もって埋める動作は, {\tt NCSFIL}を使ってノーフィ ルモードが設定されていない場合になされる. 詳細については, [書き込みのためのフィルモードの設定: NCSFIL]の節を参照. フィル値は, まだ書 かれていない値を読むと返される. {\tt \_FillValue}が定義される 場合, それはスカラーで, 変数と同じ型でなければならない. {\tt \_FillValue}は通常, 有効範囲の外側にあり, それゆえ, 一般のアプ リケーションではでは欠損として扱われる. しかし, {\tt \_FillValue}を有効範囲内にして, 他の有効な値のように扱えるよう にするのは正当なことである. 変数の型に対するデフォルトの フィル値が適当であれば, 独自の{\tt \_FillValue}を定義する必要 はない. しかし, byteデータ型に対しては, デフォルトのフィル値 を使うことは勧められない. この属性の値を変えた場合, その変更さ れた値は引き続く書き込みにのみ適用されることに注意されたい; す なわち, それまでに書かれたデータは変更されない. より多くの情報 については, [フィル値]の節を参照. \item[COARDS] データ変数が scale\_value 属性によってパックされている場合には {\tt \_FillValue} も同様にパックされる。 \item[GDT] {\bf データ変数を属性 {\tt scale\_factor} と属性 {\tt add\_offset} を使ってパックする際、属性{\tt \_FillValue} の値 はパックされない。アンパックの際には、実行前に {\tt \_FillValue} の存在をチェックすること。この扱いはCOARDS とは異 なる。} \item[NCAR-CSM] 次のこと以外には説明がない。 multidimensional な軸において、使われない格子点を示すために \_FillValue または missing\_value が用いられることがある。 (例: 緯度によって経度座標の数が異なる``reduced grid'') \end{description} \item{\tt missing\_value} \begin{description} \item[ドキュメント] この属性は, ライブラリまたは慣習に従った一般的なアプリケーショ ンで特別に扱われるわけではないが, 記録として便利なこともあり, また特定のアプリケーションで使われることもありうる. 属性 {\tt missing\_value}は, 欠損データを示す値を含むスカラーまたは ベクトルでありうる. これらの値はすべて, 一般的なアプリケーショ ンが欠損として扱えるように, 有効範囲の外側にあるべきであ る. より多くの情報については, [フィル値]の節を 参照. \item[COARDS] 2 種類の欠損値を区別する必要があるときは、属性{\tt \_FillValue} と属性 {\tt missing\_value} の存在が役立つ。属性 {\tt missing\_value} のデータタイプは、それが属すデー タ変数のデータタイプと一致する。 データ変数が scale\_value 属性によってパックされている場合には {\tt missing\_value} フラグも同様にパックされる。 NOAA の規約では、{\tt missing\_value} と {\tt \_FillValue} を区別して特別に解釈することは推奨しない。 \item[GDT] データ変数にだけ適用できる。座標変数に使っては駄目。 属性{\tt \_FillValue} とは違い、netCDF API で特別な方法で使われない。デー タ変数が属性 {\tt scale\_factor} と属性 {\tt add\_offset} を使っ てパックされる際は、属性 {\tt missing\_value} もパックされる。 {\bf この規定は COARDS と異なっており、{\tt missing\_value} と {\tt \_FillValue} を区別する特別の解釈を与 えている。} \item[NCAR-CSM] 次のこと以外には説明がない。 multidimensional な軸において、使われない格子点を示すために \_FillValue または missing\_value が用いられることがある。 (例: 緯度によって経度座標の数が異なる``reduced grid'') \end{description} \item{\tt signedness} \begin{description} \item[ドキュメント] 価値のなくなった属性である; もともとは, バイト値が符号つきまた は符号なしのどちらで扱われるべきかを指定するように作られたもの である. 属性{\tt valid\_min}および属性{\tt valid\_max}をこの目的 のために使うことができる. 例えば, バイト変数を非負の値として格 納したい場合には, {\tt valid\_min = 0}および{\tt valid\_max = 255}を使うことができる. この属性は, netCDFライブラリでは無視さ れる. \item[COARDS] とくになし \item[GDT] とくになし \end{description} \item{\tt C\_format} \begin{description} \item[ドキュメント] この変数の値をプリントするCアプリケーションにおいて使われるフォー マットを与える文字列である. 例えば, 変数が有効数字3桁の精度し かないことが分かっているなら, 属性{\tt C\_format}を{\tt "\%.3g"}と定義するのが適当である. {\tt ncdump}ユーティリティプ ログラムは, この属性を, それが定義されている変数に対して使 う. このフォーマットは, スケーリングを行う属性{\tt scale\_factor} および属性{\tt add\_offset}のあるなしにかかわらず, スケールさ れた(内部の)型および値に対して適用される. \item[COARDS] とくになし \item[GDT] とくになし \end{description} \item{\tt FORTRAN\_format} \begin{description} \item[ドキュメント] この変数の値をプリントするFORTRANアプリケーションにおいて使わ れるフォーマットを与える文字列である. 例えば, 変数が有効数字3 桁の精度しかないことが分かっているなら, 属性{\tt FORTRAN\_format} を{\tt "(G10.3)"}と定義するのが適当である. \item[COARDS] とくになし \item[GDT] この属性は、変数および座標軸に対して用いることができる。 \end{description} \item{\tt title} \begin{description} \item[ドキュメント] グローバル属性で, そのデータセットの中身を簡単に記述する文字列. \item[COARDS] とくになし \item[GDT] とくになし \item[NCAR-CSM] 是非とも書きましょう。 \end{description} \item{\tt history} \begin{description} \item[ドキュメント] 履歴の検査のためのグローバル属性. これはそのファイルを修正した プログラムの各呼び出しに対する行からなる文字配列である. たちの よい一般的なnetCDFアプリケーションは, 日付, 時刻, ユーザ名, プ ログラム名, およびコマンド引数, を含む行を追加する. \item[COARDS] 必須ではないが、netCDF ファイル内に含まれるデータの履歴を記録 するために推奨される。 \item[GDT] グローバル属性 {\tt history} は、全てのデータへ適用されることが仮定 されている。個々のデータ変数はそれ自体の属性 {\tt history} を持 ち追加情報を提供する。 これらの属性は、グローバル属性よりも優先権を持つ。 \vspace{1em} 属性{\tt quantity} と属性 {\tt subgrid} に正規の形式または (\ \ ) 内におさめ られないようなものを属性 history に記録する。 なお、データ変数は、属性{\tt institution} や属性 {\tt production} も持っており、 これらはデータが最初にどのように得られたかを示す。 属性{\tt history}, 属性{\tt institution}, 属性{\tt production} は、ファイル内のデータ変 数を区別するために用いるべきではない。 \item[NCAR-CSM] 是非とも書きましょう。 \end{description} \item{\tt Conventions} \begin{description} \item[ドキュメント] ある変数についてこの属性が与えられている場合, `{\tt Conventions}'は, グローバル属性で, そのファイルが従っている慣 習の名前を表す文字配列である; それは, 分野に特化した慣習の集合 を記述した文書を貯蔵しているディレクトリからの, 相対ディレクト リ名として解釈できる文字列の形式になっている. これによって, 慣習の階層構造が可能となり, 場所を与えて, 慣習の記述および例を, それを定義している機関およびグループに維持してもらうことができ る. 慣習のディレクトリ名は, 現在, ホストマシン{\tt ftp.unidata.ucar.edu}の{\tt put/netcdf/Conventions/}ディレクト リから相対的に解釈される. 代わりに, 慣習を記述する文章が維持 されているWWWサイトを指定するために, 完全なURL指定子を使っても よい. \vspace{1em} 例えば, NUWGという名前のグループにおいて, 次元名, 変数名, 必要 な属性, およびある分野に特化したデータ構造のためのnetCDF表現, に対する一まとまりの慣習についての合意ができているのなら, その 合意されたとりきめを記述する文章を, 慣習のディレクトリのサブディ レクトリ{\tt NUWG/}以下のファイルに保管しておくことができる. これらの慣習に従ったファイルは, {\tt "NUWG"}という値を持つグロー バル属性{\tt Conventions}を含むことになる. \vspace{1em} 後になって, もしそのグループが, NUWGデータの特定の部分集合, 例 えば, 時系列データ, に対する追加の慣習について合意したなら, そ の追加の慣習の記述はサブディレクトリ{\tt NUWG/TIME\_series/}に 保管されることになる; また, これらの追加の慣習に従ったファイル は, {\tt "NUWG/Time\_series"}という値を持つグロー バル属性{\tt Conventions}を使って, このファイルがNUWGの慣習および追加的 なNUWGの時系列の慣習, に従っていることを示すことになる. \item[COARDS] とくに目新しい点はない。 \item[GDT] ドキュメントと同様。 ただし、ファイルを生成したアプリケーションによって用いられた規約の付録 のバージョン番号を記録するために、float の属性 {\tt appendices} を付加するこ とを推奨する。 \item[NCAR-CSM] ドキュメントと同様。 \end{description} \end{itemize} \section{COARDS を吟味} ここでは、COARDS が独自に定める規約に注目した調査結果を示す。 \\[1em] \begin{description} \item[ファイル名] NetCDF ファイルには拡張子 ".nc" をつけるべき. \item[座標変数] 次元名が変数名と一致するような 1 次元 netCDF 変数は「座標変数」 と認識される. \item[グローバル属性] とくに目新しい点はない。 \item[データ変数属性] \mbox{} \begin{description} \item[long\_name] とくに目新しい点はない。 \item[scale\_factor] とくに目新しい点はない。 \item[add\_offset] NOAA cooperative standard は、この属性を次のように厳密に定めて いる。\vspace{1em} 属性{\tt scale\_factor} と属性{\tt add\_offset} が関連した変数と同じ データタイプの場合には, 特に制限は設けない。パックされていない データは, パックされたデータと同じデータタイプと仮定される. \vspace{1em} 属性{\tt scale\_factor} と属性 {\tt add\_offset} が(パックされ たデータを含む)関連した変数と異なるデータタイプの場合には, ファイル 内の関連した変数は単に byte, short, または long のタイプかもし れない。属性 {\tt scale\_factor} と属性 {\tt add\_offset} (これらはデー タタイプが一致しないといけない)は float または double でなけれ ばならない。この属性のデータタイプは、アンパックされたデータの意図さ れたタイプに一致すべきである. (long を float にアンパックする ことは, 潜在的な精度の消失があるので薦められない. ) \item[\_FillValue] とくに目新しい点はない。 \item[missing\_value] 2 種類の欠損値を区別する必要があるときは、(属性{\tt \_FillValue} と属性 {\tt missing\_value} の存在は)役に立つ。属 性{\tt missing\_value} の netCDF データタイプは、それが記述す るデータ変数の netCDF データタイプと一致する。したがって、デー タ変数が scale\_value 属性によってパックされている場合には{\tt missing\_value} フラグも同様にパックされる。これは属性 {\tt \_FillValue} に対しても同様である。NOAA の規約では、{\tt missing\_value} と {\tt \_FillValue} を区別して特別に解釈する ことは推奨しない。 \end{description} \item[単位属性] とくに目新しい点はない。 \item[他の属性] ファイルは、この規約にない他の属性をもつことがある。それらはこの規約を 破るようなことを表現しない。アプリケーションプログラムは、認識しない属 性を無視すること。 \item[変数名] 変数名は文字で始まり, 文字,数字,{\tt \_} で構成される. 変数名は大・小 文字を区別しないことが推奨される. 変数が重複しないように、同じファイル 内で大・小文字を区別しない同じ名前を用いるべきでない. \item[rectlinear な座標系に限る] netCDF 変数内の点の空間/時間位置は, 座標軸から関連する値によって構成さ れた単純に並んだ要素で表されるべきである。それで、例えば, 座標位置が他 の非座標変数あるいは方程式から推測されねばならない曲線座標系はこの netCDF プロファイルでは標準化されていない。 \item[次元の数] 全ての netCDF 変数は 1, 2, 3, 4 次元空間のいづれかで定義されだろう。 \vspace{1em} ひとつの点が意味をなすところでは、位置は座標変数としてコード化され る. 例えば、鉛直プロファイルにおける緯度と経度を、このひとつの点の緯度 座標変数および経度座標変数として用いるのは自然なことである。4 次元以上 の netCDF ファイルを作る必要がある場合, 追加される次元は CDL において 表現されるように空間次元と時間次元の左に加えられることが推奨される. 例 えば 5 個目のパラメータ値座標の表現では次の形式が推奨される。 \begin{verbatim} float my_variable(param_value, time, hight, lat, lon); \end{verbatim} \item[座標変数名] 座標変数名は他の netCDF 変数と同様にして名付ける. \item[次元の順序] いくつかの或いは全ての変数の次元が "date or time" (T), "height or depth" (Z),"latitude" (Y), あるいは"longitude" (X) の解釈をもつ場合に は、これらの次元は相対的に T, Z, Y, X の順で定義されなければならない。 \item[データタイプ] 座標および非座標変数のデータタイプは限定されていない(byte, short, long, float, double の全てが認められている). 機能的に "byte" と同一で ある "char" は標準のデータタイプでは禁じられていないが, netCDF は新し いバージョンでその動作を変更する予定であるため, 推奨しない. \item[座標変数の順序] 座標変数の座標値は単調増加または単調減少でなければならない。 しかし、座標値は等間隔である必要はない。座標変数においては 欠損値は許されない。 \item[座標変数の属性] 座標変数が longitude, latitude, depth, elevation, date, time の値を含 む場合には、単位属性を必ずつけなければならない。座標変数の方向の決定に 使うためである. 属性{\tt long\_name} はオプションであるが, 指定した場 合 netCDF ファイルの透過性および自己記述性が高まる. 属性{\tt \_FillValue} と属性 {\tt missing\_value} を座標変数に用いることはでき ない。 \item[Time あるいは date 次元] 時間を表す座標変数は常に陽に属性 {\tt units} を含まなくてはならな い. デフォルト値はない. 時間座標変数であることは {\tt units} によって のみ確認される. 属性{\tt units} は, ユニデータの udunits パッケージバー ジョン 1.7.1. で推奨されるフォーマットの文字タイプである.\vspace{1em} 時間に関して許容される {\tt units} の一覧が udunits.dat ファイルにある. もっとも広く用いられている string (およびその短縮形)には, day(d), hour(hr,h), minute(min),second(sec,s),year(yr) が含まれている. 複数形 も許されている. date string には date のみ; date と time; date と time と time-zone が含まれている. "year" は時間の単位として使わないことが推 奨される. year は長さが変化するので曖昧さがある. Udunits は year を正 確に 365 日と定義している. \vspace{1em} 時間座標変数の認証はその単位によってのみ行なわれる. udunits のルーチン utScan と utIsTime によってこの認証を行なうことができる. \item[気候的な時間] 気候的時間 ( 12 months, 4 seasons など、特定の年とは無関係なもの) を表 す座標変数は、year 0000 で始めること。それ以外は普通の時間軸と同様。 \item[鉛直次元] 高さや深さを表す座標変数は常に陽に属性 {\tt units} を含まなくてはなら ない. デフォルトの属性は用意されていない. 属性 {\tt units} は character タイプである. \vspace{1em} 鉛直座標として認められる変数は次のもの、およびその複数形。 \begin{itemize} \item (udunits.dat の一覧にあるように) pressure の {\tt units}。 最もよく用いられる単位は bar, millibar, decibar, atmosphere (atm)。 \item (udunits.dat の一覧にあるように) length の {\tt units}。 最もよく用いられる単位は meter(metre,m), centimeter(cm), decimeter(dm), feet(ft)。 \item 無次元の {\tt units} である "level" "layer" あるいは "sigma\_level" \item 他の udunits.dat の一覧にある単位。 ある状況下では, 密度あるいは温度の {\tt units} のような鉛直位置が参照される。 \end{itemize} 上向きか下向きかの方向性は, 全ての場合に {\tt units} から推定され る. これはデータを表示するアプリケーションで役立つ. この理由でこの規約 では新しい属性 {\tt positive}を定義する。鉛直軸の {\tt units} が有効な 気圧の単位でない場合には属性 {\tt positive} を含めること求められる (udunits ルーチン utScan を使ってこれが決定される)。それ以外の場合には この属性はオプションである。属性 {\tt positive} は "up" あるいは "down" (大文字小文字の区別はない) の値をもつ. \vspace{1em} 鉛直座標変数は次によって認証される. \begin{itemize} \item 気圧の単位 \item "up" あるいは "down" (大文字小文字を区別しない)の値をもつ属性 {\tt positive} の存在 \end{itemize} \item[Latitude 次元] latitudes を表現する座標変数は常に陽に属性 {\tt units} を含まなければ ならない. 属性 {\tt units} のデフォルト値は用意されていない. 属性 {\tt units} は, ユニデータ udunits パッケージで推奨されるフォーマットの character タイプである. \vspace{1em} latitude の推奨される単位は "degrees\_north" である. "degree\_north" "degree\_N" "degrees\_N" も許されている. \vspace{1em} latitude 座標変数の確認は {\tt units} のみによって行なわれる. これは, udunits ルーチン utScan によって行なうことができる. \item[Longitude 次元] longitude を表現する座標変数は常に陽に属性 {\tt units} を含まなければ ならない. 属性{\tt units} のデフォルト値は用意されていない. 属性{\tt units} は, ユニデータ udunits パッケージで推奨されるフォーマットの character タイプである. \vspace{1em} longitude の推奨される単位は "degrees\_east" (東向きが正)であ る. "degree\_east" "degree\_E" "degrees\_E" も許されてい る. "degrees\_west" (西向きが正)は degrees\_east からの反転を意味して おり, 推奨しない. \vspace{1em} longitude は 360 を基本単位として表現される. それで, 例えば $-180$, 180, 540 は全て日付変更線を表す表現として有効である. また 0 と 360 も prime meridian の表現として有効である. しかし, netCDF ファイル内に格納 される longitude の数値は単調でなければならない. \vspace{1em} longitude 座標変数の確認は {\tt units} のみによって行なわれる. これは, udunits ルーチン utScan によって行なうことができる. \end{description} \section{GDT を吟味} ここでは、GDT が独自に定める規約および、COARDS との違いに注目した調査 結果を示す。 \\[1em] \begin{description} \item[目的] この規格は気候データの使用を想定しており, 特に GCM で生成されたデータ を念頭において作られた. 我々は規格が実際にカバーできる範囲には限界があ ると認識しており, 気候メタデータのデサインにおいて共通してよく直面する と我々が考えるところの問題に限定している. これは特化した netCDF 規格で はあるが, その考えの多くは広く適用できると思われる. 我々の主目的は気候 データに対して必要な明瞭, 適当, かつ柔軟なメタデータの定義を提案するこ とである. メタデータオブジェクトは netCDF 以外のファイルフォーマットに 格納できる. 異なったフォーマットのファイル間でメタデータの相互変換は, そのフォーマットが似た考えに基づいているならば容易に行なえ る. \vspace{1em} この規格は主に COARDS (ftp://ftp.unidata.ucar.edu/pub/netcdf/Conventions/COARDS)によって提供 された慣習に追加したものである. 加えて, 特に断わらない限り, 全ての Unidata の推奨がここではサポートされている. 規格間での違いがある部分は コメントで示している. \vspace{1em} この規格は, Unidata の提供する udunits 規格も参照している. \item[ファイル名] COARDS と同様。 \item[データの型] char と byte は機能的に同一であり、{\bf COARDS では char ではな く byte を薦めているが、GDT では byte の sinedness が曖昧との理由で char を薦めている。} NetCDF は character string 型をサポートしないので、これを char 配列と して表現しなければならない。GDT では, これらを string 型と呼ぶ. \item[属性] この規格が様々な定められた値をとる string の属性を定義する時は, 可能性 のある値は小文字で与えられる. しかし, アプリケーションプログラムはこれ らの属性の大文字・小文字を区別すべきではない. この規格では, いくつかの string の属性を「空白で分離されたリスト」を含むように定義している. そ のリストでは連続する単語は, ひとつ以上の隣接するスペースによって分離さ れる. リストの冒頭あるいは最後には複数のスペースがあってもよい. \item[グローバル属性] float の属性 {\tt appendices} を用いて GDT の付録のバージョン 番号を記録することが推奨される。 string の属性 {\tt quantity\_table} は ``quantity table(12章)''の URL の記録に用いられる(12節)。この属性が null の string の場合には 属性{\tt appendices} が示すバージョンの Appendix D の利用を仮定する。 string の属性 {\tt comment} は、ファイルに関する任意の特別な情報(例え ばGCMの積分名)を記録するのに用いられる。 ユニデータ規格の属性 {\tt history} は、必須ではないがnetCDF ファイル内 に含まれるデータの進化を記録するために推奨される。 string の属性 {\tt institution} と {\tt production} が推奨される. 属性 {\tt institution} はデータの作成者あるいは提供者を特定する. 属性 {\tt production} はどのようにデータが生成されたか(例えばモデルのバージョン 番号や観測手段など)を示す。 属性 calender (23節)はグローバル属性として記録されることがあり、グロー バルな属性 {\tt calendar} は全ての時間軸に対するデフォルトとして解釈さ れる. \item[変数名] COARDS と同じ \item[データ変数] 物理変数を含むような netCDF 変数をデータ変数(あるいは primary 変数)と 呼ぶ。データ変数の命名規則は特に定めない。 \item[座標変数] ひとつ以上のデータ変数と関連した一次元データ変数を座標変数と呼ぶ。次元 名がそれ自身の名前と一致する座標変数名は主要(main)座標変数と GDT では 呼ぶ。 \item[データ変数の軸と次元] {\bf (4 次元以内を強く推奨する COARDS とは異なり)データ変数は 0 次元を含む任意の数の次元をもつことができる。}空間あるいは時間以外の軸 が含まれてもよい。ひとつの特定の量に 2 つ以上の軸を用意することもでき る(28節)。 \vspace{1em} 格納順は COARDS と同様に TZYX とすべきである(Fortran では X が配列の最 初にくる)。空間時間以外の次元が TZYX の左にくることも COARDS と同じ。 \vspace{1em} {\bf もし最後の 4 次元が(COARDS 規定とは違って)TZYX 以外の順番を とる場合には、データ変数に属性 {\tt axis} を付けること。}それ以外の場 合にはこの属性はオプションだが推奨される。この属性はデータ変数の次元と 等しいサイズの文字配列で、各次元に対して 1 つの要素をもち、その次元の 解釈を与える。許される文字は T, Z, Y, X である。 \vspace{1em} 軸が座標変数をもたない場合には、座標変数は 0 から始まる軸に沿ったイン デックスに等しいと仮定される。 \vspace{1em} (全てのデータ変数がある等圧面で定義されているというような場合に、その 情報を含める方法として推奨するのは、)要素 1 の(気圧)座標変数をもつ singleton 次元を使うこと。 \item[座標系] 属性{\tt axis} が X と Y 軸を指し、かつ、これらがそれぞれ経度と緯度で ある場合には、これらの軸は地球表面に投影された経度-緯度グリッドを構成 し、XY-boxes はこの仮定に基づいて計算される。 \vspace{1em} 地理的な球座標ではなく、ある軸に基づく球座標系を "rotated grid" と呼ぶ。 "rotated grid" を記述するためには、float の属性 {\tt north\_pole} がデー タ変数につけられ、回転した北極に対する(経度、緯度)座標を特定する。 \vspace{1em} {\bf あるシステムでは、地球表面を被う軸は rectlinear グリッドで はないが、それでも構わない。でも、その場合の規定は決まっていない。 (COARDS は非 rectlinear 系を認めていない。)} \item[単位] Appendix. C に udunits との違いが書いてある。degrees は認めない。year と month は認めない。calendar\_month と calender\_year は, お互いある いは他の時間単位との変換ができない。 ただし、カレンダー年と、12 カレン ダー月の倍数との間では変換可能。{\bf COARDS とはいくつかの点で 違いがあるので注意。} \item[変数の物理量] データと座標変数の物理量を特定するための 3 つの string の属性は {\tt units}, {\tt long\_name}, {\tt quantity} である。 \vspace{1em} 属性 {\tt units} は、量が無次元でない場合には必須である。無次元の場合 には{\tt units} は純粋な数字で与えることができる。大・小文字の違いは重 要である。 \vspace{1em} 属性 {\tt long\_name} はオプションである。 \vspace{1em} 属性 {\tt quantity} は、定義されたリスト(``quantity table'')から選ばれ た記述およびオプション的に (\ \ ) 内に記述された情報によって、その量を 明らかにする。リストを定義するのは、出所の異なるデータに対し、どの量が 対比できるのかの判断を可能にするため。大・小文字の区別はない。 \vspace{1em} ``quantity talbe'' を選択する方法は 2 つある。ひとつは、グローバルな属 性 {\tt quantity\_table} を null の string に設定し、この規約の Appendix D のリストを使う方法。もうひとつは同様のリストを web 上に作り、 グローバル属性 {\tt quantity\_table} に URL を記録する方法。 \vspace{1em} 属性 {\tt subgrid}(21節)は {\tt quantity} を改良とみなされる。つまり、 データ変数のみに適用され、座標変数には適用されない。この 2 つの属性は、 共に量の物理次元を定義し、それと矛盾しない $units$ をもつ。 \vspace{1em} データ変数は属性 {\tt history} をもち、{\tt quantity} と {\tt subgrid} に格納できないような、量の導出についての情報を提供する。 \vspace{1em} データ変数は属性 {\tt institution} や属性 {\tt production} をもつこと もできる。 \vspace{1em} 属性 {\tt history}, 属性instutuion, 属性{\tt production} は、ファイル 内のデータ変数を区別するために用いるべきではない。 \vspace{1em} 変数に対するオプションの属性 {\tt modulo} は、量の有効性や物理的重要性 を変えることなく加わえたり引いたりできる数を記録する(例えば経度の場合 は 360 )。 \vspace{1em} Unidata 標準の属性 {\tt FORTRAN\_format} は、座標とデータ変数の両方に 用いられる。 \vspace{1em} 他のモデル依存した属性が、変数の量を定義するために含まれるかもしれない。 \item[軸の形態] 周期的な軸は属性 {\tt topology}="circular" とする。 \vspace{1em} 周期的な軸の main 座標変数は属性 {\tt modulo} を指定する。 \item[longitude 次元] 基本的に COARDS と同じ。ただし、module=360 とすること。 {\bf COARDS では属性 {\tt modulo} は定義されていないが modulo=360 が常に仮定されている。地球全体にわたる軸には COARDS にはない属性 {\tt topology}=''circular'' をつけるべき。} \item[latitude 次元] 基本的に COARDS と同じ。 \item[鉛直(height , depth )の次元] {\bf 鉛直の軸には属性 {\tt long\_name} と属性 {\tt positive} ( "up" または "down" を指定 )を両方与えること。これは、 軸の単位によって正方向を決定する COARDS 規定とは異なっている。} \vspace{1em} \item[Component 変数] 連続的な物理変数が、各点における値を特定するために 2 つ以上の数を必要 とすることがあり(例えば鉛直 $\eta$ 座標の場合には $\sigma$ と $p$ )、 これらは components と呼ばれる。components の値は変数内に記録され component 変数と呼ばれる。components が属す変数を components の "head" 変数と呼ぶ。component 変数の名前は head 変数の string の属性 {\tt component} 内に空白で区切ったリストとして記録される。component 変数の 次元は head 変数の次元と一致しなければならない。 \vspace{1em} 座標変数が components を持つ場合には、components を組み合わせて軸上に 点を並べるその方法を記した main 座標変数が提供されなければならない。他 の場合と同様に、この main 座標変数は単調でなければならないが、 components は単調である必要はない。components を使った main 座標の定義 は属性 {\tt component} の ( ) 内で与えられる。この情報は標準化されてお らず、そして一般のアプリケーションがこれを使うことは予期されていない。 \item[Associated 変数] データ変数のひとつ以上の軸が、座標値の 2 つ以上の組を持つ場合、これら の組は変数内に記録され、associated 変数と呼ばれ、これら自体が {\tt units}, {\tt long\_name}, およびその他の適当な属性をもつ。associated 変数の名前は、データ変数あるいは main 座標変数のどちらかの string の属 性 {\tt associate} 内に空白で区切られたリストとして記録される。データ 変数との association の場合には、この属性はデータ変数に対してのみ適用 される。しかし、main 座標変数との association の場合には、この属性はそ の main 座標変数を使用する任意のデータ変数に対して適用される。main 座 標変数との association は、このようにして一層便利であるが、柔軟性に欠 ける。データ変数との association は、複数の軸が含まれており、かつ、 main 座標変数がない場合のみのオプションである。 \vspace{1em} 属性 {\tt associate} は二者択一的かつ等価的に {\tt coordinates} と名付けられるかも しれない。 \vspace{1em} 変数は 2 つ以上のデータ変数あるいは座標変数と関連しているかもしれない。 もし associated 変数自体が属性 {\tt associate} をもつならば、この属性 によって名付けられた変数もまた associated と見なされる。 \vspace{1em} associated 変数は、それと associated しているデータ変数の全次元をもた なくてはならない。つまり、associated 変数はこれらの軸に対するインデッ クスの関数とみなすことができる。associated 変数の値は単調である必要は ない。 \vspace{1em} 一般のアプリケーションは associated 変数のなんらかの利用を要求されない。 associated 変数はデータ変数の属性 {\tt axis} において指示されない。し かし、ファイルの読み易さを向上させるため、データ変数の属性 {\tt associate} によって命名された変数が属性{\tt axis} における T Z Y また は X によって示されると解釈される時は、それ以外の変数の後にこの順番で リストすることが推奨される。 \vspace{1em} 一次元 associated 座標の特別なテクニカルな応用は、ひとつのultimited 次 元に対する netCDF の限界に対処することである。いくつかのデータ変数が長 さ或いは物理的重要性が異なる unlimited 軸を持つ場合、それらは全て名目 的な unlimited 次元を共有することができ、そして、各々は軸の意味を特定 する associated 変数をもつ。 \item[Bundles] 同じ物理量を含むいくつかのデータ配列が 1 つ以上の同じ軸を持ち、しかし 他の singleton 座標変数の値によって区別される場合に、属性{\tt associate} を使うことでそれらを同じデータ変数内に格納することができる。 \item[境界変数] ある次元に沿って、値が点あるいは、連続または不連続なセルと関連している とする。点の座標値の境界値および、セルの座標値の境界値を定義しなければ ならない。この境界値は string の属性 {\tt bounds} によって記録される。 その際に推奨される名前は、''{\tt bounds\_}座標の次元'' である。{\tt valid\_min} が小さい境界値と等しい場合、その区間は小さい境界値を持たな い。{\tt valid\_max} が大きい境界値と等しい場合、その区間は大きい境界 値を持たない。 \item[subgrid 変数の表現] データ変数の属性 {\tt subgrid} を用い、ある軸に沿って各データの値がど の程度格子以下の変動を反映しているか示すことができる。これは string の 属性であり、空白で区切られた単語のリストからなる。リスト内の "name:method" は "name" が与えられた次元の軸に沿っての格子点以下の変動 が特定された "method" によって表現されることを示す。method は Appendix B に示された項目の中のひとつであり、mean, maximum, minimum, mid-range, standard deviation, variance, mode, median, cell, point を含んでいる。 大・小文字や句読点は重要ではない。 \vspace{1em} 2 つ以上の subgrid method が指示される場合には、それが適用される順に左 から並べる。 \item[縮約次元] 縮約軸とは、大きな dimension (要素の数)をもつ軸の値をまとめて最初より も少ないグループにすることで作られた軸である。もっともありふれた場合に は、dimension は完全に singleton 次元に圧縮され、全てのデータ点は完全 に圧縮された軸を共有する。 \vspace{1em} 縮約される前の軸情報を記録するオプション属性として、{\tt old\_interval} (縮約されていない 2 つの近接する座標間の典型的な距離) と {\tt old\_spacing}("uniform" の場合は {\tt old\_interval} が等間隔, "variable" の場合は不等間隔だが近接している, "disjoint" の場合はギャッ プがある)がある。縮約される前の軸の座標値がその変数内で陽に記録される ことがある。その場合には、縮約される前の main 座標変数は縮約された main 座標変数の属性 {\tt expand} によって命名されるべきである。 \item[時間変数と間隔] 時間変数(以下時間と呼ぶ)は日時をあらわす変数。時間間隔は 2 つの時間の 差。時間は 6 つの要素 ( year, month, day, hour, minutes, second ) で記 述することができる。これらの要素を変換してただひとつの数として表すこと をエンコードといい、その逆をデコードという。これらはカレンダーに強く依 存する。 \vspace{1em} 属性{\tt calendar} は、使用するカレンダーを指定する。もし時間座標変数 が属性{\tt calendar} をもたないなら、(もしあれば)グローバル属性 {\tt calendar} が適用される。 \vspace{1em} 規約では、6つの要素で表現される時間をひとつの数にエンコードする 2 つの 方法が許されており、これらは {\tt units} で区別される。ひとつは相対時 間へのエンコード、もうひとつは絶対時間へのエンコードである(24,25 節)。 \vspace{1em} 時間変数は属性 {\tt time\_format} をもつことがあり、日時をプリントする フォーマットをUNIX の date コマンドのコンベンションによって特定する。 \vspace{1em} 時間座標変数は、常に陽に属性 {\tt units} を含まなければならない。 デフォルトの値はない。 \item[相対時間] 特定の標準時間から経過した時間。 {\tt units} は "時間単位 since 標準時間" のようになる。 デコードするためにはカレンダーが必要。 \vspace{1em} udunits.dat ファイルは秒、分、時間、日を時間の単位として定義している。 月と年はこの規格の Appendix C では認めていない。これは、それらが うまく定義されていないため。udunits の単位 common\_year (正確に 365 日)は 使ってもよいが、推奨はしない。 \item[絶対時間] 属性{\tt units} は "時間単位 as 時間string " となる。 可能な単位と推奨されるデータタイプおよび意味はつぎのとおり: \begin{verbatim} Format Data type Interpretation second as %S.%f float Diurnal phase minute as %M.%f float Diurnal phase hour as %H.%f float Diurnal phase day as %Y%m%d.%f double Time day as %Y%m%d int Year and seasonal phase day as %m%d.%f double Seasonal phase and diurnal phase day as %m%d int Seasonal phase day as .%f float Diurnal phase calendar_month as %Y%m.%f double Year and seasonal phase calendar_month as %m.%f float Seasonal phase calendar_year as %Y.%f double Year and seasonal phase calendar_year as %Y int Year calendar_year as .%f float Seasonal phase \end{verbatim} calendar\_year と calendar\_month はこの規約の Appendix C で 定義された時間の単位。 \vspace{1em} 時間string コードは UNIX の date と printf コマンドに従っている。 \begin{verbatim} Format letter Interpretation %Y Year (including century) %m Two-digit month (01=January) %d Two-digit day within month %H Hours since midnight %M Minutes since midnight %S Seconds since midnight %f Floating-point fraction of the specified time-unit . Position of decimal point \end{verbatim} \item[グレゴリオ暦] 絶対時間を扱えないアプリケーションとの適合性が本質でない ならば、グレゴリオ時間を、データタイプ はdoubleで、{\tt units} は "day as \%Y\%m\%d.\%f" で与えることを推奨する。それが本質である場合には、 相対時間とする。推奨する単位は days、データタイプは double。 \vspace{1em} 時間変数に適用する属性 {\tt calendar} がない場合には、値は通常のグレゴ リオ暦であると仮定される。これは {\tt calendar} に standard または gregorian を設定することで陽に指定できる。 \item[非グレゴリオ暦] 他のカレンダータイプの場合には、 データタイプは double で、 {\tt units} は "day as \%Y\%m\%d.\%f" とす ることを推奨する。 相対時間は認められており、推奨される {\tt units} は days since 1-1-1 (1年1月 1日の真夜中)であり、データタイプは double である。Unidata の udunits パッケージは 標準カレンダーだけを処理できるので、他のカレンダーに対して 相対時間を処理するための拡張が必要となる。 \vspace{1em} グレゴリオ暦以外で、この規約が認識するカレンダーは julian (ユリウス暦)、 noleap (各月が 30 日で一年が 360 日)である。それ以外のカレンダーを使う ときは、属性{\tt calendar} に適当に記述すべきであるが、一般のアプリケー ションがこれを処理することは予期されていない。 \item[多重時間軸と気候的時間] もし、collapsed 軸と結びついた uncollapsed な軸があれば、 それは "climatological time" 軸である。 \vspace{1em} {\bf CAORDS とは異なり、気候的時間を year 0 から始める必要はない。} \item[データ変数における無効値] 基本的にドキュメントの {\tt valid\_min}, {\tt valid\_max}, {\tt valid\_range} と同じ \item[データ変数における欠損値] ドキュメントの missgin\_value の項目を見よ。 \item[gathering による圧縮] データ配列から常に欠損となる点を消去したいことがある。そのような圧縮は 隣りあったひとつ以上の軸にわたって操作でき、記憶されるべき点のリストを 参照することで達成できる。このリストは単に圧縮される軸をもつマスク配列 を考慮し、ならべ替えなしにこの配列を一次元上にマッピングすることで、作 成される。リストは、要求された点のこの一次元マスクにおけるインデックス の集合である。圧縮された行列では、圧縮されるべき軸は全て、次元が要求さ れた点の数であるただひとつの軸に取り換えられる。要求された点は、この軸 に沿って、圧縮されていない配列で表れた順番で、要求されていない点を飛ば して現れる。圧縮および戻す操作はこのリストにわたってループの操作をする ことで実行される。 \vspace{1em} このリストは、データ配列の圧縮された軸に対する座標変数として記憶される。 こうして、リスト変数とその次元は同じ名前をもつ。このリスト変数は string の属性 {\tt compress} をもち、圧縮されていない配列のファイル内での宣言の 順番で、圧縮によって影響される次元の空白で区切られたリストを含む。 この属性の存在によって、リスト変数がそのようなものだと確認される。 リスト、オリジナルの次元と座標変数(component, associated, boundary 変数を含む)、および、圧縮されない変数の全ての属性をもつ圧縮されたデータ変数が、netCDF ファイルアーカイブに書かれる。圧縮されていない変数は、そのオリジナル変数名が知られていない場合を除いて、この情報を使って正確にもとどおりに構成されることになる。 \item[scale と offset を用いた圧縮] COARDS の {\tt add\_offset} の内容と基本的に同じ。また、ドキュメントの {\tt add\_offset} を見よ。{\bf ただし、{\tt missing\_value} と {\tt \_FillValue} の扱いに関連 してCOARDS と若干の違いがある(ドキュメントの {\tt missing\_value} の項目を見 よ)。} \end{description} \section{NCAR-CSM を吟味} ここでは、NCAR-CSM とそれの準拠する COARDS との違いに注目した調査結果 を示す。 \\[1em] \begin{description} \item[概要: 目的と哲学] 規約を定める目的は、 自己記述的(ファイル内の各変数は、単位の情報を含めそれが何であるか、 各値が空間的にどう配置するかという関連情報をもつ) なデータを作成させることにある。 また、データソースや操作の履歴といった高度な情報を変数に付すことも 要求する。 この規約を用いることで、データの図示やサブセットに対する操作が 容易になる。また場が時空間どのように配置されているかを直に正しく 理解できるデータ提供が可能になる。それにより、お絵描きもすぐできてしま う。我々が課す規定の主なものは、座標変数と一般変数に対する属性をいくつ か使うこと。変数の次元の順番は限定しない。 \item[概要: まとめ] \mbox{} \\ {\tt long\_name} 全変数に必要。\\ {\tt coordinate} 不規則な格子データを扱えるようにこの属性を定義する。\\ {\tt units} 全変数に必要、可能なときは UNIDATA に従う。例外は degree(s) が許されないこと。 また、ある状況下では UNIDATA 以外のものも用いられる。\\ {\tt title} グローバル、必要\\ {\tt source} グローバル、必要\\ {\tt history} グローバル、必要\\ {\tt Conventions} グローバル、必要\\ 時間平均などのデータを表すためのコンベンションを導入\\ \item[\underline{COARDS との関係}]\mbox{} \\ \begin{enumerate} \item COARDS とは異なり変数の次元の順番を限定しない。 \item COARDS とは異なり level と layer を認めない。 属性 {\tt units} を座標系を特定するための材料として使う。 sigma\_level は特定のタイプの無次元座標を記述するが、 CSM の大気コンポーネントで用いられているものを記述しない。 \item COARDS と同じく \_ を含む名前を使わない方が良いと考えるが、COARDS と は違って大文字小文字を区別する使い方を許す。 \end{enumerate} \item[守るべき規定: long\_name 属性] \item[守るべき規定: units 属性] 座標変数の場合は必須。 座標変数以外の場合は、次元つきの量を表す場合に必須。 記述は udunits に従うが degree(s) は許されない。 udunits は無次元量(\%,ppb,fractionなど)の表示を定めていないが、 無次元量にも属性 {\tt units} を使うことを推奨する。 ただし以下で定義する鉛直座標を示す場合を除いてその方法は定めない。 なお ``level'', ``layer'' は曖昧なので使っちゃだめ。 \item [守るべき規定: 座標] NetCDF のユーザーズカイドでは座標変数は 1D 配列であると定められ、 rectilinear 格子の座標を記述するのに用いられる。 Non-rectilinear 格子では、座標情報は多次元配列を用いて表現され、 座標変数の想定外にある。この状況を扱うため属性 {\tt coordinates} を導入する。 {\tt coordinates} は 1D の場合にも多次元の場合にも用いられる。 属性 {\tt \_FillValue} あるいは属性 {\tt missing\_value} によって、多次元座標の使用しない格子(例えば reduced grid のように)を指 示することがある。 全ての空間、時間座標に属性 {\tt units} が必要。この結果、次元の順番に対する 制限はいらなくなる。 \item [守るべき規定: 座標: 時間] 時間軸の属性 {\tt units} は udunits に従うこと。 udunits は year を正確に 365.242198781 日と定めており、365 日のものは common\_year、366日のものは leap\_year、365.25 日は Julian\_year、 365.2425 日のものは Gregorian\_year と定めているので注意。 udunits のカレンダー計算は1582-10-15を境として Gregorian/Julian カレン ダーをチャンポンで使うので、他のカレンダーを使う時間座標は udunits ラ イブラリを使って計算できない。そこで属性 {\tt calendar} を定める。 気候時間 ( 特定の年に依存しないもの ) は year 0000 で始まること。 属性{\tt orbital\_parameters} もある。 属性{\tt define\_calendar} もある。 \item [守るべき規定: 座標: 有次元鉛直座標] もし、属性 {\tt units} が有効な気圧の単位(この場合はデフォルトが 用意されているらしい)でないならば、方向は COARDS と同様属性 {\tt positive} を使って表わす。値は up か down (大文字小文字によらない)。 \item [守るべき規定: 座標: 無次元鉛直座標] 無次元の鉛直座標に対しては、対応した次元つきの座標の計算を容易にするた めに考案したコンベンションを導入する。 無次元量から次元つきの座標に変換するための規則は 単位と同じ名前を {\tt define\_} のあとにもつグローバル属性として記述すること を推奨する。 \item [守るべき規定: 座標: 緯度] 推奨する単位は degrees\_north。また degree\_north, degree\_N, degrees\_N でも良い。 \item [守るべき規定: 座標: 経度] 推奨する単位は degrees\_east。また degree\_east, degree\_E, degrees\_E でも良い。degrees\_west は推奨しない。 緯度を一周を 360 で表すと、例えば, -180, 180, 540 は日付変更線の表現と しては全て有効。しかし、ファイル内の経度の値は non-modulo の意味で単調 であること。 \item [守るべき規定: 座標: Non-Rectilinear 座標] 座標を記述するために多次元変数が必要となる場合は これらの変数は属性 {\tt coordinates} の使用によって座標として認識される。 属性の値は座標システムを記述する変数の名前を含む文字である。 少なくとも場の変数に対する次元と同じだけの座標がなくてはならない。 空間における軌跡に沿って定義される場を記述する場合にはもっとあるかも。 \item [守るべき規定: グローバル属性] 読みやすくするため改行マークを入れることを 推奨する。{\tt title}、{\tt source}、{\tt history}、{\tt Conventions} を書く。 \item [オプションの規定: calendar] 属性{\tt units} が time units since base date, base time と なっているときはいつでも、属性 {\tt calendar} を時間座標 (あるいはグローバル属性)として与えることを推奨する。 この属性は gregorian ( 今のカレンダー；デフォルト )、noleap (今のカレンダーだが毎年 365 日)、julian (Julian)、n kyr B.P. ( n 千年前のカレンダー )。 詳細な定義はグローバル属性 {\tt define\_calendar} で与える。 \item [オプションの規定: orbital\_parameters] 古気候の研究で、今とは異なる公転軌道を考える場合には、 時間座標(あるいはグローバル)の属性 {\tt orbital\_parameter} で eccentricity, obliquity, perihelion のデータを含む変数の名前のリスト を与える。 \item [オプションの規定: 区間に対する値の表現] 格子点データが、場の点の値でなく、適当な間隔をもつ時空間平均や最大値な どといったものを表すため、属性 {\tt coord\_op} (coord は座標の名前で、lat\_op や time\_op のように使う)を定め。その軸に対する操作を次の文字列であらわす。 \begin{verbatim} "point" - 格子点値(デフォルト) "minimum" - ある区間における最小値 "maximum" - ある区間における最大値 "sum" - ある区間にわたる値の合計 "average" - ある区間にわたる値の平均 "rms" - ある区間にわたる値の RMS "range" - ある区間にわたる最大値と最小値の差 \end{verbatim} この属性は、個々の変数に対して、あるいはグローバルに用いられる。 両方ある場合は、個々の変数に対する指定が優先される。 区間を表現するために、属性 {\tt bounds} 定義し適当な座標に対して指定する。 {\tt bounds} の値は、区間の境界をもつ変数の名前である。 格子が座標変数によって定義されかつ間隔の切れ目がない場合、 対応する座標変数よりも 1 大きなサイズをもつ変数である。 座標変数 x と区分境界 x\_bound をもつ変数は、値 x(i) は 境界 x\_bound(i) と x\_bound(i+1) との間に含まれる、という関係にある。 間隔に切れ目がある、あるいは一部重複しているようなもっと一般の場合(し かし 1Dとする)には、変数は 2D であり(Cの notation では)第2次元目は対応 した座標変数と同じ大きさをもつ。 値 x(i)は、間隔 x\_bound(0,i) と x\_bound(1,i) との間に含まれる。 \item [オプションの規定: 普通じゃない座標] (どうもよくわからん by 赤堀)。 対応した次元と関連した値に \_label をつけた次元の名前をもつ文字 列値を使って何かする。 \item [オプションの規定: 投影座標] 地図投影に関連して属性 {\tt proj\_coordinates} を定義。グローバルにまたは 各変数に対して定義。 投影には http://kai.er.usgs.gov/ftp/mapgenproj.html のソフトがおすすめ。 投影方法を定義するため属性 {\tt proj\_parameter} を定義。 \item [オプションの規定: フラックスの方向] 全てのフラックス量を、その変数の属性 {\tt flux\_direction} を用いて陽に指定す ることを推奨する。値は up, down, north, south, east, west。 \end{description} \section{属性一覧表} \small \hspace*{-5mm} \begin{tabular}{lcp{2zw}cp{2zw}llp{5zw}p{23zw}}\hline 属性 & doc & coa-rds & gdt & ncar-csm & 種 & Use & GDTの節 & Description \\ \hline \hline {\tt add\_offset} & ○ & ○ & ○ & & N & CD & 29, 32 & Additive offset for packing data \\ \hline {\tt appendices} & & & ○ & & S & G & 5 & Version number of these appendices \\ \hline {\tt associate} & & & ○ & & S & CD & 18, 19 & Identifies variables containing alternative sets of coordinates \\ \hline {\tt axis} & & & ○$^1$ & $^{1'}$ & S & D & 9, 16, 18 & Identifies spatiotemporal dimensions \\ \hline {\tt bounds} & & & △ & △$^2$ & N & C & 20, 22, 28 & Identifies a bounday variable \\ \hline {\tt calendar} & & & △ & △$^3$ & S & GD & 5, 23, 26, 27 & Calendar used for encoding time axes \\ \hline {\tt comment} & & & ○ & & S & G & 5 & Additional information about the file \\ \hline {\tt component} & & & ○ & & S & CD & 17, 20 & Identifies variables containing components of a variable \\ \hline {\tt compress} & & & ○ & & S & D & 31 & Records dimensions which have been compressed by gathering \\ \hline {\tt Conventions} & ○ & ○ & ○ & ○ & S & G & 5 & Identifies the netCDF standard \\ \hline {\tt coordinates} & & & ○ & ○$^4$ & S & CD & 18 & Synonym for associate\\ \hline {\tt coord\_op} & & & & ○ & S & C & & point(デフォルト), average, maximum 等。coord は軸の名\\ \hline {\tt define\_単位名} & & & & ○ & S & G & & udunits にない座標を定義 (例 hybrid\_sigma\_pressure ) \\ \hline {\tt define\_calendar} & & & & ○ & S & G & & 新たなカレンダーを定義\\ \hline {\tt define\_projection} & & & & ○ & S & G & & 非標準の地図投影の方法を定義(した場所)\\ \hline {\tt expand} & & & ○ & & S & C & 22, 28 & Coordinates before contraction \\ \hline {\tt \_FillValue} & ○ & △ & △$^5$ & △$^6$ & N & D & 29 & Indicator of invalid data \\ \hline {\tt flux\_direction} & & & & ○ & S & D & & フラックスの正方向(up,north,eastなど)\\ \hline {\tt C\_format} & ○ & & & & S & CD & & Format for a variable\\ \hline {\tt FORTRAN\_format} & ○ & & ○ & & S & CD & 12 & Format for a variable \\ \hline {\tt history} & ○ & ○ & ○ & ○ & S & GD & 5, 12 & Evolution of the data in the file \\ \hline {\tt institution} & & & ○ & & S & GD & 5, 12 & Who made or supplied the data \\ \hline {\tt long\_name} & ○ & ○ & ○ & ○ & S & CD & 12 & Long description of a physical quantity \\ \hline {\tt missing\_value} & ○ & ○ & ○ & △$^6$ & N & D & 30 & a value for data that are unknown or missing\\ \hline {\tt modulo} & & & ○ & & N & CD & 12, 14, 25 & Arithmetic modulo of a variable \\ \hline {\tt north\_pole} & & & ○ & & N & D & 10 & Long.,lat. of rotated North Pole \\ \hline {\tt old\_interval} & & & ○ & & N & C & 22, 28 & The typical separation between points on an axis before contraction \\ \hline {\tt old\_spacing} & & & ○ & & S & C & 22, 28 & Indicates the spacing of points along an axis before contraction \\ \hline {\tt orbital\_parameter} & & & & ○ & S & G & & 軌道に関する情報\\ \hline {\tt positive} & & △ & △$^7$ & △ & S & C & 16 & Direction of positive for a vertical axis \\ \hline {\tt production} & & & ○ & & S & GD & 5, 12 & How the data was produced \\ \hline {\tt proj\_coordinate} & & & & ○ & S & GD & & デカルト座標で横軸、縦軸をあらわす座標\\ \hline {\tt proj\_parameters} & & & & ○ & S & G & & ``proj'' パッケージに地図投影を教える\\ \hline {\tt quantity} & & & ○ & & S & CD & 12 & Standardised description of a physical quantity \\ \hline {\tt quantity\_table} & & & ○ & & S & G & 5, 12 & URL of the quantity table \\ \hline {\tt scale\_factor} & ○ & ○ & ○ & & N & CD & 29, 32 & Multiplicative factor for packing data \\ \hline {\tt signedness} & ○ & & & & ? & D? & & byte 値の符号の扱いを指示。事実上不要\\ \hline {\tt source} & & & & ○ & S & G & & データソース。モデル等の情報。\\ \hline {\tt subgrid} & & & ○ & & S & D & 21, 22, 28 & Records how the data values represent subgrid variation \\ \hline {\tt title} & ○ & & & ○ & S & G & & データセットの中身を簡単に記述\\ \hline {\tt topology} & & & ○ & & S & C & 13, 14, 25 & Topology of an axis (circular or not) \\ \hline {\tt time\_format} & & & ○ & & S & CD & 23 & Format for printing a time and date \\ \hline {\tt units} & △ & △ & △$^8$ & △$^9$ & S & CD & 12, 14, 15, 23 - 27 & Units of a physical quantity \\ \hline {\tt valid\_max} & ○ & & ○ & & N & CD & 20, 29 & Largest valid value of a variable \\ \hline {\tt valid\_min} & ○ & & ○ & & N & CD & 20, 29 & Smallest valid value of a variable \\ \hline {\tt valid\_range} & ○ & & ○ & & N & CD & 29 & Smallest and largest valid values of a variable \\ \hline \end{tabular} S は string、N は数値。G はグローバル、C は座標変数(多次元座標変数を含 む)関連、D はデータ変数関連。 ○は説明があるもの。△は説明があるが他の規約と相異点があるもの。 $^1$ この結果、軸の格納の順番が COARDS よりも柔軟になる。\\ $^{1'}$ units を利用することで COARDS の軸の格納順に対する制限が不要にな る\\ $^2$ NCAR-CSM では区間に切れ目のない場合の方法も定義している。\\ $^3$ ncar-csm では GDT にない値 n kyr B.P. (nは数字)をサポートするが standard はサポートしない。\\ $^4$ NCAR-CSM と GDT は多分同じ。GDT では coordinate と同義語の associate という属性を定義してる。\\ $^5$ COARDS では、データが属性 {\tt scalar\_factor} と属性 {\tt add\_offset} を使ってパックされる際に、{\tt missing\_value} も {\tt \_FillValue} も同様にパック される。しかし、GDT では {\tt \_FillValue} の値はパックされないので、アンパッ クする再にはあらかじめ {\tt \_FillValue} の存在を確認しておくこと。 {\tt missing\_value} はパックされるので、一緒にアンパックする。\\ $^6$ NCAR-CSM では、multidimensional 座標で未使用の格子点を表わすため に用いられることがある。\\ $^7$ NCAR-CSM と COARDS は同じ。GDT の利用ルールは異なる. \\ $^8$ 基本的に udunits に従うが、いろいろと例外があるので注意。\\ $^9$ NCAR-CSM は基本的に COARDS と同じだが level, layer は認めない。 また define\_ を用いて udunits 以外の単位を定義可能。 \end{document}