\documentclass{article}

\topmargin -20mm
\topskip   0mm
\oddsidemargin -5mm
\textwidth     165mm
\textheight    250mm

\parindent 0mm
\parskip 1em

\begin{document}

\begin{center}
{\Large
netCDF データの規約(属性)についての調査\\[1cm]
}
{\large
平成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}

\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)}

メイルの一覧がある。未調査。

\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" を削除し、
		"evel","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) 非グレゴリオ暦について。

	\end{description}
\item{\tt long\_name}

	\begin{description}
   	\item[ドキュメント] 

	長い記述的な名前. これは, 例えば, プロットのラベルづけに使うこ
	とができる. もし, 変数に属性 {\tt long\_name} が割り当てられてい
	なければ, 変数名がデフォルトとして使われる.

   	\item[COARDS] 
	ドキュメントと同様. 

   	\item[GDT] 
	この属性はオプション。

	\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 とは異
	なる。} \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} を区別する特別の解釈を与
	えている。} 
	\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] 
	とくになし

	\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} は、ファイル内のデータ変
	数を区別するために用いるべきではない。
	\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} を付加するこ
	とを推奨する。

	\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{属性一覧表}

\small
\begin{tabular}{lcp{2zw}cllp{5zw}p{22zw}}\hline
属性   & doc & coa-rds & gdt & 種
    & 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$ & 
 S  & D & 9, 16, 18   & Identifies spatiotemporal dimensions \\ \hline
{\tt bounds}   &   &   & ○ & 
 N  & C & 20, 22, 28 & Identifies a bounday variable \\ \hline
{\tt calendar}   &   &   & ○ & 
 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}   &   &   & ○ & 
 S  & CD & 18   & Synonym for associate \\ \hline
{\tt expand}   &   &   & ○ & 
 S  & C   & 22, 28   & Coordinates before contraction \\ \hline
{\tt \_FillValue}   & ○ & △ & △$^4$ & 
 N  & D  & 29   & Indicator of invalid data \\ \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 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 positive}   &   & △ & △$^3$ 
 & S  & C  & 16   & Direction of positive for a vertical axis 
\\ \hline
{\tt production}   &   &   & ○ & 
 S  & GD  & 5, 12 & How the data was produced \\ \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 subgrid}   &   &   & ○ & 
 S  & D  & 21, 22, 28   & Records how the data values represent subgrid variation \\ \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}   & △ & △ & △$^2$  & 
 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
{\tt missing\_value}   & ○ & ○ & ○ & 
 N & D & 30 & a value for data that are unknown or missing\\ \hline
{\tt signedness}  & ○ &   &  & 
 ? & D? & & byte 値の符号の扱いを指示。事実上不要\\ \hline
{\tt C\_format} & ○ &   &  & 
S & CD & &  Format for a variable\\ \hline
{\tt title} & ○ &   &  & 
S & G & & データセットの中身を簡単に記述\\ \hline
\end{tabular}

S は string、N は数値。G はグローバル、C は座標変数(多次元座標変数を含
む)関連、D はデータ変数関連。

○は説明があるもの。△は説明があるが他の規約と相異点があるもの。

$^1$ この結果、軸の格納の順番が COARDS よりも柔軟になる。\\
$^2$ 基本的に udunits に従うが、いろいろと例外があるので注意。\\
$^3$ COARDS と GDT とではこの属性を利用するルールが異なる. これと関連して 
{\tt units} の指定方法も異なる。\\
$^4$ COARDS では、データが属性 {\tt scalar\_factor} と属性 {\tt add\_offset} 
を使ってパックされる際に、{\tt missing\_value} も {\tt \_FillValue} も同様にパック
される。しかし、GDT では {\tt \_FillValue} の値はパックされないので、アンパッ
クする再にはあらかじめ {\tt \_FillValue} の存在を確認しておくこと。
{\tt missing\_value} はパックされるので、一緒にアンパックする。

\end{document}
