気候データ、バージョン1.3のためのGDT netCDF規定

Jonathan Gregory1、Bob Drach2、及び、Simon Tett1
( 1 ) Hadleyセンタ、UK気象庁; ( 2 ) PCMDI、LLNL

1999年3月14日

1目的

この標準は、netCDF Application Programmer Interface ( API ) と共に作成されたファイルの交換、及び、シェアリングを促進するために、採用された一組の規定を定義する。その標準は、netCDFのバージョン2.4に基づいている。Documentation of the netCDF API may be found in the ``NetCDF Users' Guide'', Version 2.4, February 1996, available from http://www.unidata.ucar.edu/packages/netcdf/ or via anonymous ftp at ftp.unidata.ucar.edu . その標準は、著者の名前にちなんで「GDT」と命名される。

この標準は、気候データによる使用のためのものであり、そして、GCMsによって心において特に生成されたデータによって設計された。我々は、標準が実質的にはカバーし得るものの限界があるということを認識する; 我々は、我々が気候metadataの設計との一般の、そして頻繁な関係であると考える問題に自分達を制限する。これが明確にnetCDF標準であるが、我々は、大部分のアイデアが更に広いアプリケーションであると考える。我々のメイン目的は、気候データのために必要とされるmetadataの明瞭で、十分で、柔軟な定義を提案することである。 metadataオブジェクトは、netCDF以外のファイルフォーマットに含まれるであろう。それらが同様のアイデアに基づいているならば、異なるフォーマットのファイルの間のmetadataのインター‐変換は、促進されるであろう。

この標準は、COARDS ( ftp://ftp.unidata.ucar.edu/pub/netcdf/Conventions/COARDS ) によって後援された規定にたいてい追加である。更に、それと逆の趣旨で注目に値されない限り、全てのUnidata推薦は、ここでサポートされる。コメントは、標準の間の差異がある場所を示す。提出された強調されたタイプ、及び、CDL例において与えられたコメントタイプライタタイプを傾けた標準の一部ではない。例が典型的に検討中にポイントに関連した詳細のみ示し、従って完全な標準の提供に関して不完全であるかもしれないことに注目しなさい。

データの首尾よい伝送は、ファイルのレシーバが正しくそれを翻訳するであろうソフトウェアを持つことによって変わる。この理由のために、属性の使用においてできる限り保守的で、そして、技術をコード化している戦略は、データの可搬性を最もよく促進するであろう。

同じくこの標準は、Unidataによってサポートされたudunits標準を参照する。 udunitsパッケージは、ftp.unidata.ucar.eduのanonymous ftpによって利用可能である。いかにそのパッケージがこの規定によって使われるかの詳細が物理的量のためにユニットを定義するために、セクション 11を見る。

カール・テイラー、John Sheldon、Jan Polcher、ブライアントMcAvaney、ハーヴェイDavies、John Caron、Steve Hankin、及び、netCDFニュースグループへの寄与者からの有益なコメント、及び、提案は、この標準の発展に影響した。我々は、NCAR CSM netCDFをスタンダード状態にして更に大きい互換性を得るために、いくらかの変更を行った。

このドキュメントは、いくらかの数学的記号の時折の使用、たとえば「s」 ( 小文字シグマとして現れるべきである ) を行う。Xの下で、これは、あなたが下記をあなたのX資源に加えることを要求するかもしれない:
Netscape*documentFonts.charset*adobe-fontspecificiso-8859-1

2ファイル名

3データタイプ

netCDFデータタイプ木炭、短い ( 長く ) フロート、及び、ダブルは、全て受け入れられる。全ての数値タイプは、署名される。その署名された状態がnetCDFにおいて曖昧であるので、バイトデータタイプ ( 機能的に木炭と同じである ) は、推薦されない。 COARDS規定、非難する、木炭よりむしろ、バイト。

NetCDFは、キャラクタストリングタイプを支えない。従って、これらは、木炭アレイとして表明されなければならない。この標準において、我々は、それらをタイプ「ストリング」と言う。ストリングアレイは、二次元のキャラクタ与件変数として実行されなければならない。固定長ストリングのベクトル、netCDFファイルにおける次元として示されたそのCDL宣言 ( Fortranに関する主要な次元 ) の第2の次元として役立って。

4属性

この標準は、多くの属性 ( ある委任者、他のもの、任意の ) を示す。しかし、ファイルは、非標準的属性を同じく含むかもしれない。そのような属性は、この標準の侵害を表さない。アプリケーションプログラムは、それらが認識しない属性を無視するべきである、〜もしくは、それらの目的のために無関係である。従来の属性の名前は、使われるべきである、どこに〜ても、適用できる。非標準的名前は、できる限り有意義であるべきである。属性を導入する前に、考慮は、その情報が変数として更によく表明されるであろうかどうかに与えられるべきである。概して、提案された属性がそれを示すのに付属のデータを必要とする、マルチ‐寸法がある、その値をインデックスするのに定義されたnetCDF次元のうちのどれでも必要とする、または、記憶装置のかなりの量を必要とするならば、変数は、その代りに使われるべきである。この標準がストリング属性を定義するとき、作る、様々な規定された値をとる、可能な値、である、小文字において与える。しかしながら、アプリケーションプログラムは、これらの属性においてケースに対して敏感であるべきでない。いくらかのストリング属性は、この標準によって「ブランクに分離されたリスト」を含むために定義される。そのようなリストにおける連続したワードは、1以上の隣接のスペースによって分離される。そのリストは、始まり、そして、あらゆる数のスペースで終わるかもしれない。 この標準によって示された属性のリストのためにAppendix Aを見なさい。

5グローバルな属性

ストリングGDT 1.3を含んで、Unidata‐標準属性のConventionsがこの標準に参照を付けるように勧められる。この標準は、ディレクトリftp://ftp.unidata.ucar.edu/pub/netcdf/Conventionsにおいて名前「GDT」の下でUnidataと共に登録されており、そして、http://www-pcmdi.llnl.gov/drach/GDT_convention.htmlから利用可能である、そして、 http://www.met-office.gov.uk/sec5/CR_div/GDT_convention.html .

フロート属性のアペンディクス、ファイルを生成したアプリケーションによって使われるこの標準に、アペンディクスのバージョン数を記録するように勧められる ( セクション12を見なさい ) 。 この情報は、おそらく記録されるであろう、で、規定それのために個別の属性を持つ以外の属性は、アプリケーションがストリングを文法的に説明しなければならなくないで情報を抽出することを可能にするであろう。 ストリング属性のquantity_tableは、量テーブルのURLを記録するために使われるべきである ( セクション12を見なさい ) 。この属性が無効のストリングであるならば、アペンディクスによって指定されたバージョンでAppendix Dが使われたということが推測される。

ストリング属性のコメントは、ファイルに関するあらゆる余分の情報を記録するために使われるかもしれない。必要とされるように、ファイルを示すための追加の属性は、含まれるかもしれない。 例えば、アウトプットされたGCMは、統合とモデルを指定するために、属性を含むであろう。

それが強制的ではないが、Unidata‐標準属性のヒストリは、netCDFファイルの中に含まれるデータの発展を記録するために、推薦される。netCDFデータを処理するアプリケーションは、それらの情報を歴史属性に付加し得る。グローバルな歴史属性は、全ての与件変数に適用されるために、呈される; 個々の与件変数は、追加の情報を供給するそれら自身の歴史属性を持っているかもしれない ( セクション12を見なさい ) 。

ストリング属性の制度、及び、生産の使用は、推薦される。属性の機関は、誰がデータを作ったか、もしくは供給したかを指定する。 我々は、「センタ」、または、「センタ」よりもこの名前の方を好む。なぜなら、2つの可能なスペルが混乱を引き起こすであろうからだ。属性の生産は、いかにデータが作られたかを示す。有益であろうのと同じくらいすなわち、それがモデルに発生させられたならば、生産は、モデル、及び、そのバージョンを指定するべきである。それが観察によるならば、生産は、それの特性を示すべきである<例>。ßurface観測〜もしくは、「ラジオゾンデ」。 グローバルな、制度、そして、生産属性は、それら自身のそのような属性を持たない全ての与件変数に適用されるために、とられる ( セクション12を見なさい ) 。

カレンダー属性 ( セクション 23を見る ) は、グローバルな属性として記録されるかもしれない。グローバルなカレンダー属性は、全ての時間軸のためのデフォルトと解釈される。

6変数名

変数名前は、レターで始まり、そして、レター、数字から成るべきである、そして、下線を引く。ケースは、netCDF名において有意である。しかし、名前が全くケースによって区別されるべきであるとは限らないということが勧められている、すなわち、ケースが無視されるならば、no、2つの名前は、同じであるべきである。同じくこれが更に効果的に自己‐述べるファイルを与えるので、可能であるならば、変数名が明らかに有意義であるべきであるということが勧められている。しかしながら、この規定における何も、変数の件を特別な名前の使用に頼らない。

7与件変数

物理的データを含むnetCDF変数は、Unidataによって同じく「一次変数」と言われる「与件変数」と言われる。変数 ( 上記、セクション 6 ) のための一般的なネーミング規則は別として、与件変数の名前は、これらの規定、によって標準化されない。ファイルが概して同じ物理的量の多重与件変数を含むかもしれないので ) 。

8の対等の変数

1以上の与件変数の次元と関連していた一次元のnetCDF変数は、「対等の変数」と呼ばれる。それを他のタイプの対等の変数 ( セクション 17、 18、 19、及び、 20 ) と区別することが必要であるとき、次元名がそれ自身の名前と同じである対等の変数は、この標準に「メインの対等の変数」と言われる。変数 ( 上記、セクション 6 ) のための一般的なネーミング規則は別として、対等の変数の名前は、これらの規定、によって標準化されない。ファイルが概して同じオリエンテーションの多重の対等の変数を含むかもしれないので ) 。メインの対等の変数における値は、絶対にモノ‐強壮にしなければならない ( 全ての値が異なり、そして、増加している、もしくは減少している ) 。なぜなら、ソフトウェアによってこの仮定が頻繁に行われるからだ。

与件変数の 9軸、及び、寸法があること

与件変数は、ゼロを含む次元の数、及び、次元が異なる状態に全てしなければならないどれでも持っているかもしれない、名前。 COARDSは、数を4に制限することを強く勧める。しかし、我々は、更に大きい柔軟性を許すことを望む。変数の次元は、それが含む量の軸を定義する。スペース、及び、時間のそれら以外の次元は、含まれるかもしれない。 いくらかの例は、このドキュメントにおいて発見され得る。ベクトル、または、張筋量のコンポーネントは、コンポーネント上で次元を変数に与えることによる1つの与件変数に含まれるであろう。利点がメモリにおいてそのような変数を処理するために存在する、と同時に、我々は、この複雑さをnetCDF記述に導入する際強い利点を見ず、そして、それを推薦しない。 ある情況の下で、1つは、特別な量で1を超える次元を必要とするかもしれない ( セクション28が多重時間軸に関係しているのを見なさい ) 。 たとえば、二次元の確率密度分布を含む与件変数は、2つの異なる垂直のレベルで温度に相互関係を持たせるであろう、そして、熱は、従って双方の軸上で出るであろう。

If any or all of the dimensions of a data variable have the interpretations of ``date or time'' ( T ), ``height or depth'' ( Z ), ``latitude'' ( Y ), or ``longitude'' ( X ) then those dimensions should appear in the relative order T , then Z , then Y , then X in the CDL definition corresponding to the file. Fortran、この方法に関してXアレイの最初の次元である。非時空の次元は、時空の次元の左側に置かれるべきである、すなわち、Fortranに関して次元を引きずるとして。

この規定の理由は、これらの種類の軸が特別なアプリケーションに特別な意味を持っているかもしれないことである。例えば、アプリケーションは、経度‐緯度マップをたくらむことを望む、または、timeseriesを垂直に統合するであろう、もしくは抽出するであろう。 COARDS標準において、次元のオーダによって与えられた指示、及び、対等の変数の属性における情報は、必要とされた軸を確認するために共に使われなければならない。 COARDSを持つ互換性のために、次のとおりに、我々は、全てのこれらの規定を支える。しかし、同じく我々は、識別を簡単で、曖昧でない状態にするために、新しい属性を導入する。

最後の4つの次元が解釈TZYX ( 最大4つの次元があるならば、左から省略して、CDLにおいて命令する ) を持っていないならば、軸属性は、与件変数にあると考えられるべきである。他のケースにおいて、それは、任意である。しかし、推薦される。その次元の解釈を示して、各次元 ( CDLにおいて命令する ) のために1つのエレメントを持って、この属性は、木炭一連の与件変数の寸法があることに等しいサイズである。可能にされたキャラクタは、上で与えられた意味を持つT Z Y、及び、Xである、そして、-、これらの意味のうちのいずれも持たない次元のためのplaceholderとして。それぞれ可能にされたレターは、アレイにおける一度もよりもう現れないかもしれない。与件変数がある解釈、軸属性を行われるであろう1を超える次元を持っているかどうかは、従って明解になるであろう、選択されるべきである。多重時間軸 ( セクション 28 ) ( わずか1つが崩壊しない ) があるならば、それに注目する、この1つのclimatologicalな時間軸は、通常示されたT -axisであろう。 かどうか、軸属性は、含まれる。それらの次元は、あらゆるオーダに入れられるかもしれない。しかし、この属性を使うことができないアプリケーションが正しくデータを処理しないかもしれないので、これは、可能であれば回避されるべきである。

普通の時間‐平均longitude-latitude-height変数のための軸:

次元:
lat=18 ;
lon=36 ;
pressure=15 ;
con_time=1 ;
変数:
xwind ( con_time、圧力、lat、lon ) を呈示しなさい;// T Z Y X xwind:axis="TZYXを命令しなさい;
lon ( lon ) を呈示しなさい;
lat ( lat ) を呈示しなさい;
pressure ( pressure ) を呈示しなさい;
con_time ( con_time ) を呈示しなさい;

セクション 14、 15、 16、経度の詳細のための 23、緯度、垂直の、そして、時間軸を見る。

与件変数以内のポイントの座標は、対等の変数 ( セクション 8 ) から値を結び付けることによって形成されたシンプルな整然としたテゥープルである。特別な軸に対等の変数がないならば、対等の値は、軸に沿ったそれらのインデックス、0からのナンバリングに等しいとみなされる。

統一を含んで、次元は、あらゆるサイズであるかもしれない。いくらかの物理的量の1つの値が与件変数における全ての値に適用されるとき、この情報を変数に付加する推薦された方法は、1‐エレメントの対等の変数を持つ個体次元 ( サイズ統一の次元 ) の使用によるものである。 この方法の利点は、対等の変数 ( 量、コンポーネント、境界等 ) の全ての属性が評価されたシングル量を示すために使われ得ることである。同じく個体次元は、収縮に起因する ( セクション 22で示されて ) 。

温度の経度‐緯度フィールド圧力上で、平らになりなさい:従って、これは、レベルを記録するために個体圧力次元を使うであろう:

次元:
lon=96 ;
lat=72 ;
pressure=1 ;//評価されたシングル対等の変数変数:
temperature ( pressure、lat、lon ) を呈示しなさい;//は、Z Y X temperature:axis="ZYXを順番に切る;
pressure ( pressure ) を呈示しなさい;
圧力:long_name="pressure ;
圧力:units="kPa ;
データ:
pressure=50.0 ;// 50 kPa = 500 mbarの圧力レベル
ユニットそして、long_name属性は、セクション 12で示される。

表面の空気温度:表面の気象学の測定は、ある定義された高さ<例>、1.5メートル ( このように示され得る ) で行われる:

変数:
temperature ( height、lat、lon ) を呈示しなさい;
温度:axis="ZYX ;
温度:long_name="atmospheric温度;
temperature:units="K ;
height ( height ) を呈示しなさい;
高さ:表面の上のlong_name="height ;
高さ:units="m ;
データ:
height=1.5 ;

測定の表面が量、<例>、スクリーンの高さのために含まれるならば、明白な高さは、与えられるべきでない。

10座標系

軸属性がXを示すならば、-そしてY -axes、及び、これらは、各々経度、及び、緯度の程度にあり、これらの軸は、地球の表面にマップされた経度‐緯度グリッドを構成し、そして、XY -boxesのエリアは、この仮定に基づいて計算されるかもしれない。

地球の表面 ( 直線である、しかし、正常な地理的軸以外の極地の軸に基づく ) のための座標系は、「回転したグリッド」と言われる。回転したグリッドを描くために、2‐エレメントフロート属性のnorth_poleは、与件変数に付加される。回転した北ポールの ( 経度、緯度 ) 座標を指定して。その属性がなく、関連したならば、値 ( 0.、90 ) 、すなわち、地理的な北ポールを持つことが推測される。

いくらかのシステムにおいて、地球の表面をカバーする軸は、直線のグリッドを定義しない。我々は、非直線のシステムを除外することを必ずしも望むとは限らない。当座は、この標準は、これらのシステムのために定義されず、そして、我々は、適切な定義に関する潜在的なユーザーからコメントを求める。 COARDS標準は、非直線のシステムを除外する。適切な2以上の軸を交換することによって、無器用にではあるが、原則としては、あらゆる座標系は、扱われ得る、によって、1つの軸によって、どちらがポイントにインデックスを付けるか、そして、指定するための関連する対等の変数を提供する、調和する、逐一 ( セクション 18を見なさい ) 。

11ユニット

udunitsパッケージは、ファイルudunits.dat ( ユニット名の収集をリストする ) を含む。このファイル、及び、それらの複数形の最も最近のバージョンにおいて与えられた名前は、この標準のための受け入れられるユニット名と見なされるであろう ( この標準へのAppendix Cにリストされるであろう2、3の修正に関して ) 。 COARDSは、標準の中でいくらかの修正をリストする。しかし、我々は、将来の修正を許すための方法が容易に作られる場所を入れる方を好むであろう。この標準のユーザーは、それら自身のユニットを定義するべきでない。なぜなら、これがそれらのファイルをあまり携帯用の状態にしないであろうからだ; 新しいユニットのリクエストは、Unidataに向けられるべきである。

同じくudunitsパッケージは、倍率、及び、オフセットによってユニットの一次変換の方法を定義する。そのようなフォームにおいてユニットを表すことが自然であるとき、この会議は、認められる<例>、1000 kg m^{を超過した}kg m -3における海水の密度 ( udunitsに指定され得る、〜同じくらい ) 「kg m-3 @ 1000」。 COARDSは、この機能の使用を可能にしない。 この機能は、データ圧縮の方法 ( これに代るものが提供される ( セクション 32を見なさい ) ) として使われるべきでない。

12の物理的量の変数

これらの規定は、物理的量のデータ、及び、対等の変数を指定するために3つのストリング属性を標準化する。

時間、の拡張に関して、ユニット属性は、Unidata udunitsパッケージ ( セクション 11を見る ) における推薦と同様にフォーマットされる。セクション 25を見なさい ) 。ケースは、ユニットにおいて有意である。この属性は、強制的である。その量が次元がない ( 純粋な数 ) ない限りは。 ( それらのユニットが純粋な数としてどちらのケースを与えられるであろうかにおいて。 ) 2、3の定義された次元がないユニットがある、のような、パーセントしかし、海‐氷集中、雲小数、確率等のように量のために多種多様な次元がないユニットの必要性がない; この記述的情報、である、long_nameよりむしろ、ユニット。 Aは、ファクタを一定の基準で決める、かつ、または、オフセットは、tenthsにおける指定された量<例>、海‐氷集中が与えられるかもしれないことであるかもしれない、〜同じくらい、units="0.1f。段階的に進むことなしの量、または、オフセットが持つかもしれないdimensionlessunits="1.0f〜もしくは、units=ünity。

long_nameは、ユニットを指定するべきでない記述的な名前を含む標準のUnidata属性である。この属性は、任意である。

量属性は、定義されたリストから選択された記述で量を確認する、随意に、括弧に納められている追加の情報によって、 ( ) 十分だならば、詳細は、標準化された記述によって伝えられることができない。リストを定義する目的は、異なるソースからのデータのユーザーがどちらの量が匹敵するかを決定することを可能にすることである。ケースは、量で有意ではない。

我々は、可能な量のリストを「量テーブル」と言う。量テーブルは、各量のために量、及び、許すことができるユニットを定義する。あらゆる法律上の、そして物理的に同等のユニットは、受け入れられるユニット属性であろう。量テーブルの選択のために2つのオプションがある。 1つのオプションは、この標準のAppendix D ( ウェブ上で利用可能にされるであろう ) を使うことである。この場合、グローバルなquantity_table属性は、無効のストリングに設定されるべきである。アプリケーションがファイルを生成したアプリケーションに利用可能であった量の完全なセットを推論することを可能にして、Appendix Dにおける各量がそれが提出されたアペンディクスのバージョン付きで分類されるであろう。もう一方のオプションは、全ての可能な量名のリストを生産することであり、受け入れられるユニット、及び、Appendix D. Thisにおける同等の量の名前がリストする各々のために与えることがウェブ上で利用可能にされるべきであり、そして、そのURLは、グローバルなquantity_table属性に記録した。

標準化された量の使用は、任意である。グローバルなquantity_table属性の存在は、このオプションが進められつつあると意味する。好まれた ( 同じlong_name、及び、量属性を持つことを回避するために ) ならば、量名前は、随意にlong_name属性において記録されるかもしれない。量を利用することを望むアプリケーションが量属性がないということが分かるそれがlong_name属性から量を獲得するべきであるならば、従って。 このドキュメントの残りにおいて、量属性は、例に現れない、しかし、long_name属性は、役立つであろう、供給に、量情報。

量属性:

tempt ( pressure、lat、lon ) を呈示しなさい;
以下を誘惑しなさい。long_name="potential温度;
tempt:quantity="atmosphericの潜在的な温度 ( timestepの後で ) ; tempt:units="K ;
「潜在的な温度」プロットのタイトルとして使われるであろう記述である。 ätmosphericな潜在的な温度標準の量である、そして、äfterにtimestep一般的アプリケーションが無視し得る追加の情報である。

2つの物理的量が異なるか、もしくは、同じであるかどうかは、しばしば明確な応答による質問ではない。それらが同じであるならば、確かにそれらは、同じユニットを持っていなければならない、しかし、同じユニットに関する様々な量は、区別されなければならないかもしれない、<例>。大気の潜在的な温度そして、土温度。実際上、適用できる最も明確な記述は、用いられるべきである。我々が全ての可能性を予測し得るとは限らないので、我々は、この標準のユーザーによってリクエストに答えて進行中のベースのAppendix Dを拡張するつもりであり、そして、新しい量が必要とされるか否かに拘らず、それがはっきりしないとき、我々は、制限よりむしろ拡張の側で誤るであろう。

サブ‐グリッド属性 ( セクション 21を見る ) は、量の変更子と見なされ得る; それは、対等の変数ではなく与件変数にのみ適用される。 量、及び、サブ‐グリッド属性は、量 ( Appendix B、及び、量テーブルにおいて与えられたインフォメーションを経て ) の物理的次元を共に定義し、そして、それらのユニットは、これと一致していなければならない。 long_nameは、サブ‐グリッド属性によって標準化される情報を繰り返すであろう。 場合のために、long_nameそうであろう「最高気温」。 サブ‐グリッド属性、定義する、ちょうど温度がどのようなセンスであるかにおいて、最大限にされる。

標準化されたフォームとしての、もしくは、括弧におけるどちらでも量、及び、サブ‐グリッド属性に入れるために可能ではない量の派生に関する情報を供給して、与件変数は、歴史属性を持っているかもしれない。 この属性は、最後の手段として使われるべきである。同じくグローバルな歴史属性 ( 存在するならば ) は、全ての与件変数 ( セクション 5 ) に適用される。いかにデータが元来獲得されたか ( セクション 5を見なさい ) を示して、与件変数は、制度、及び、生産属性を同じく持っているかもしれない。これらの属性は、一致するグローバルな属性より優先である。属性のヒストリ、制度、及び、生産は、ファイルにおける与件変数を区別するために、頼られてはいけない、そして、一般的アプリケーションは、それらを無視するかもしれない。

任意の量情報: これらの任意の属性は、このようにgridd‐された観察の沈澱気候学を示すために使われるであろう。

precipitation ( lat、lon ) を呈示しなさい;
沈澱:Thiessen多角形増量を使うhistory="gridded ;
precipitation:institution="Climaticユニット、東Anglia、UK大学を研究しなさい;
沈澱:沈澱のlong_name="rate ;
沈澱:production="surface観測を配置しなさい;
precipitation:units="mm 1日‐1 ;

与件変数が他の制度からのデータ、または、生産の方法を持つファイルにあったならば、これは、適切であろう。

変数 ( 存在するならば ) の任意のmodulo属性は、量の妥当性、または、物理的意味を変更せずに加えられ得る、もしくは減じられ得る数を伝える。それは、変数と同じユニットにおいて与えられるべきである。 aに関してこれは、経度座標軸 ( セクション 14 ) にとって有益である最もそうであるmodulo360の、そして、季節的な、もしくは、昼間のフェーズ ( セクション 25、及び、 28 ) のclimatologicalな軸。

我々は、Unidata‐標準FORTRAN_format属性が対等のそしてまたデータ変数にとって有益であるかもしれないことに注目する。

更に、他のモデル‐依存の属性、変数の量を定義するために、含まれる。 Hadley Centreモデルは、各与件変数整数を示すであろう隠匿物そして、サブ‐モデルGCMの診断の出力量を確認するコードである属性 ( 例えば ) 。

それらにはある規定された価値のみ要し得ることを意味して、変数は、連続的であるよりむしろ別個である量を含むかもしれない。 これは、与件変数より対等の変数に適切である。例えば、Fourier、もしくは、球形の和声の分析の結果を含む与件変数は、和声の数のために次元を持っているであろう。セクション 25は、別個であるいつか変数を示す。

軸の 13トポロジー

「円トポロジー」を持つ軸は、初めまで最後のポイントを動かす軸に沿ってポイントもの場所全てを何度も変えることによって合法的に変えられ得るものである。円トポロジーを持つ軸のメインの対等の変数は、属性のtopology="circularの存在によって区別される。 全球を囲む経度軸は、例である。値線形、または、この属性の欠如は、「線のトポロジー」によって軸を示す。そのトポロジーは、メインの対等の変数によってのみ示される。しかし、それが軸の特質であるので、それは、あらゆるコンポーネント、関連する、もしくは、境界の対等の変数もに申し込む。

円軸が回転するとき、メインの対等の値は、モノ‐強壮にする状態を維持するために、変更されなければならない。従って、円軸のメインの対等の変数は、modulo ( セクション 12 ) を必要とする。

それに注目する、トポロジーそして、modulo属性は、異なる情報を伝える。例えば、グリニッジ子午線、及び、日付変更線 ( <例>、0E、25E、120E、130E、180E ) の間の東半球における値に制限された経度の対等の変数は、円トポロジーを持っていない。( これは、世界の限られたエリアのモデルから来たであろう。 ) フィールドの等高線地図をそのような経度軸で作っているとき、1つ、手を加える、東半球の中で近づくどこででも、輪郭、しかし、それは、合法的ではない、に、手を加える、西の半球上で、そして、近づく、世界 ( 全く欠けている ) の残り。円トポロジーの含意は、1つがマップの左手サイドに全くあらゆる経度を置くであろうことであろう。しかしながら、この対等の変数は、modulo ( セクション 14において必要とされる360の ) を持っており、そして、ポイントは、moduloの下で同等であるあらゆる方法で分類され得る、に、ファイルにおいて調和する。対等の値0,25,120,130,180は、-360、-335、-240、-230、-180までこのように同等である。

14経度次元

経度を表す対等の変数は、ユニット属性を常に明白に含まなければならない;デフォルト値がない。 ユニット属性は、Unidata udunitsパッケージにおける推薦と同様にフォーマットされたストリングであろう。経度の推薦されたユニットは、degrees_east ( 東の正 ) である。同じく受け入れられる、degree_east、degree_E、及び、degrees_Eである。ユニットdegrees_west ( 西に向かう正 ) は、推薦されない。なぜなら、それがdegrees_eastから負の転換比を意味するからだ。

それらが翻訳されたmodulo 360であるかもしれないことを示して、経度軸は、属性のmodulo=360を持っているべきである。 このように ( 例えば ) 、-180、180、及び、540は、インターナショナルDatelineの全ての正当な表現であり、そして、0、及び、360は、Prime Meridianの双方の正当な表現である。 COARDSは、経度がこのように常に扱われるかもしれないと推測する。ので、我々、持つ、導入される、modulo属性、我々は、それがこれを示すと明示されるべきであることを必要とする。 グローバルな経度軸は、属性のtopology="circularを持っているべきである。 それに注目する、存在、の、modulo属性は、その軸が円トポロジー ( セクション 13 ) を必ず持っていることを意味しない; 球の一部のみ覆う経度軸は、そのポイントを回転する状態にし得ない。 netCDFファイルに格納される数値経度値のシーケンスは、経度のメインの対等の変数のための非‐moduloセンスにおいてモノ‐強壮にしなければならない。

グローバルな経度軸:

lon ( lon ) を呈示しなさい;
lon :long_name="longitude ;
lon :modulo=360.0f ;
lon :topology="circular ;
lon:units="degrees_east ;

量テーブルが使用中であるならば、それに注目しなさい、「経度」標準のリストにおける量の名前である、そして、その代りに示されるであろう、で、量属性。

15緯度次元

緯度を表す対等の変数は、ユニット属性を常に明白に含まなければならない;デフォルト値がない。 ユニット属性は、Unidata udunitsパッケージにおける推薦と同様にフォーマットされたストリングであろう。緯度の推薦されたユニットは、degrees_northである。同じく受け入れられる、degree_north、degree_N、及び、degrees_Nである。

緯度軸:

lat ( lat ) を呈示しなさい;
lat :long_name="latitude ;
lat:units="degrees_north ;

量テーブルが使用中であるならば、それに注目しなさい、「緯度」標準のリストにおける量の名前である、そして、その代りに示されるであろう、で、量属性。

16の垂直の ( 高さ、または、深さ ) 次元

2つの水平の次元が通常経度、及び、緯度 ( その方向が相当に定義される ) であるのに反して、1つがあるならば、様々な量は、縦軸のために使われるかもしれない。許された値のうちの1つに関して、縦軸と見なされるための軸は、long_name属性 ( セクション 12 ) 及び正の属性を持っていなければならない、アップして、以下、方向感覚を示すために、の、これ以来情報がデータを表示するアプリケーションにとって有益であるかもしれないと確信した。

垂直の圧力軸:

次元:
pressure=15 ;
変数:
pressure ( pressure ) を呈示しなさい;
圧力:long_name="pressure ;
圧力:positive="down ;
圧力:units="hPa ;
データ:
pressure=850、700、500、300、200、150、100、50、30、20、10 ;

この軸がそのユニットで識別され得るように、COARDS標準は、定義されたリストの中から選択されるのに縦軸のユニットを必要とする。それは、特別な地位を圧力のユニットに与える、のために、方向、の、正の、定義される、そして、作る、正の他のユニットに関する縦軸のための属性委任者。

我々は、いくつかの理由のために異なるアプローチを採用した。第一に、あらゆる次元がない量1で次元がないユニットを定義する縦軸方法のためにユニットを必要とすることは、対等の変数のために使用することを望むであろう。これは、与件変数の処置と一致しない; その標準は、次元がないユニットが与件変数における次元がない物理的量のために発明されることを必要としない。第二に、与件変数の垂直の次元は、確認され得る、から、軸属性、〜もしくは、そのような次元が更なるヘルプなしでそれを発見すると予測するあらゆるアプリケーションを許す次元 ( セクション 9を見る ) のオーダ。第三に、量属性 ( 使用中であるならば ) は、ユニットより有益である。

我々は、完全に正の方向が実際にデータ構造の一部として記録されるべきであることを確信しているとは限らない。それは、たいていデータを表示するための問題であり、そして、ある程度パーソナル好みに関わる問題である。そのような特別な処置が縦軸に与えられるならば、理由は、それが他の軸のために同じく記録したことである? 例えば、緯度がプロットの水平軸に関して示されるとき、北は、左、または、右にあるか? これは、同じ種類の質問である。しかし、それは、更にと同様に我々に対しストライキを行う、熟慮するためのグラフィックスアプリケーションに関わる問題。それでもなお、我々、持つ、必要とされる、正のCOARDSを持つ互換性のための属性。

例えば、oceanographicなnetCDFファイルが表面の深さをコード化するならば、1000、そして、軸と同じくらい0、及び、1000メートルの深さは、次のとおりに属性を使うであろう:units="m表面の下方のlong_name="depthpositive="down。〜ならば ( 一方 ) 1000メートルの深さ、-1000として表明された、我々、持つ表面の上のlong_name="heightpositive=üp。

17コンポーネント変数

連続的な物理的変数は、各ポイントでそれを指定するのに1を超える数を必要とするかもしれない。我々は、これらを「コンポーネント」と言う。コンポーネントの値は、変数に記録される、「コンポーネント変数」と言われる。それらのコンポーネントが属する変数は、コンポーネントの「ヘッド」変数と呼ばれる。コンポーネント変数の名前は、ヘッド変数のコンポーネントストリング属性におけるブランクに分離されたリストとして記録される。コンポーネント変数の次元は、そのヘッド変数のそれらと同じでなければならない。 OGDTは、コンポーネントを対等の変数に制限した。しかし、対等の変数として使われるあらゆる量が与件変数として同じく必要とされるので、その概念は、ここで一般化された。

対等の変数がコンポーネントを持っているとき、この標準は、メインの対等の変数がそれでもなお供給されるべきであることを必要とする、軸上でポイントを命令するために使われ得るコンポーネントの結合を表す。いつものように、このメインの対等の変数は、モノ‐強壮にしなければならない。しかし、それらのコンポーネントは、モノ‐強壮にする必要がない。 コンポーネント属性における括弧においてそのコンポーネントに関するメイン座標の定義が行われるかもしれない。この情報は、標準化されず、そして、一般的アプリケーションは、それを利用すると予測されることができない。

ハイブリッドの垂直の座標: A vertical coordinate h ｺ p/p0 + s is used in some atmospheric GCMs. 大気のモデルレベルは、ペア ( そこで、pは、圧力である ) に関して ( p、s ) 指定され、p0は、定数であり、そして、sは、表面の圧力、の小数である。変数である ) 。 h値は、比類なく分解されることができない2つの一次結合である、バックする、に ( p、s ) 。我々は、このようにこの対等の変数を記録するであろう:

eta ( eta ) を呈示しなさい;//メインの対等の変数eta:component="pressureシグマ ( eta=pressure/p0+sigma ; p0=100 kPa ) フロートpressure ( eta ) ;フロートsigma ( eta ) ;
一般的アプリケーションは、コンポーネント、そして、メイン座標を独立した情報のように扱うであろう。それらを関係づけるのに必要とされる余分の知識は、それを必要としたあらゆる特定のアプリケーションにあるであろう。ハイブリッドの垂直の座標は、コンポーネント変数の唯一の明白なアプリケーションである。しかし、それらが起こるならば、その規定は、他の同様の目的のために使われるであろう。

18の関連する変数

与件変数の軸、または、結合における2以上の軸は、対等の値の代替セットを持っているかもしれない。これらの代替セットは、変数に記録される、参照する、に、「関連する」変数として、それら自身のユニット、long_name、及び、他の適切な属性を持つ、に、それらを示す。関連する変数の名前は、与件変数或いは関係のある軸のメインの対等の変数の提携者ストリング属性におけるブランクに分離されたリストとして記録される。その結合が与件変数を持っているならば、それは、その与件変数のみ申し込む、しかし、それがメインの対等の変数を持っているならば、それは、そのメインの対等の変数を使うあらゆる与件変数を申し込む。メインの対等の変数との連合は、このように更に便利であるかもしれない。しかし、あまり柔軟ではない。いくらかの軸が包含されるとき、そして、メインの対等の変数がないとき、与件変数との連合は、唯一のオプションである。 それらの例は、これらのポイントを例証する。

提携者属性は、代りに、そして、同等にコーディネートと命名されるかもしれない。 この可能性は、CSMをスタンダード状態にして互換性のために含まれる。しかしながら、現在の標準において、それは、「coordinate variable ( section 8 ) 」の正常な定義との可能な混同のために非難される、そして、関連する変数の使用が通常のセンスにおける単に対等の変数より広いということ。

変数は、1を超える与件変数、または、対等の変数と関連しているかもしれない。関連する変数そのものが提携者属性を持っているならば、この属性によって指定された変数は、関連していると同じく見なされる。

関連する変数は、それが結合しているあらゆる与件変数の全ての次元である次元を持っていなければならない; 関連する変数は、これらの軸に沿ったインデックスのファンクションと見なされ得る。関連する変数の値がモノ‐強壮にする必要はない。

一般的アプリケーションは、関連する変数のあらゆる使用を行うのに必要とされない。関連する変数は、与件変数 ( セクション 9 ) の軸属性において示されない。しかしながら、その他現れることに関して、CDLファイルの可読性を全く改良するために、与件変数の提携者属性によって指定された変数が軸属性におけるT Z Y、または、Xによって表示されるであろう解釈を持っているとき、それらがそのオーダにリストされるということが勧められている、前の。

縦軸:1つの軸のための値の代替セットを与えて、多くの関連する変数は、一次元であろう。 1つの例は、1つが物理的座標と、順序のモデルレベル番号の両方を格納することを望む縦軸である:

次元:
lat=90 ;
sigma=19 ;
変数:
xwind ( sigma、lat ) を呈示しなさい;// 2D与件変数xwind:axis="ZY ;
lat ( lat ) を呈示しなさい;
lat :long_name="latitude ;
lat:units="degrees_north ;
sigma ( sigma ) を呈示しなさい;//の物理的高さ座標
シグマ:associate="model_level ;
シグマ:long_name="sigma ;
sigma:positive="down ;
int model_level ( sigma ) ;各高さの//モデルレベル番号
model_level :long_name="modelレベル番号;
model_level:positive="up ;

結合として、の、model_levelである、に関して、シグマaを持つあらゆる与件変数シグマ-axis結合を持つであろう、に関して、model_level以下。それは、プロパティではない、の、xwind特に。

軌道:一次元の軌道に沿った量の値。そのようなケースにおいて、我々は、緯度を与える旅行、及び、関連する対等の変数の時間、及び、各ポイントの経度を含む対等の変数を持っているであろう:

次元:
day=10 ;軌道に沿った// 10の見本の時代、変数:
hice ( day ) を呈示しなさい;その浮氷塊が漂うので、測られた//海‐氷厚さ
hice :associate="lat lon ;
hice :axis="T ;
hice:units="m ;
day ( day ) を呈示しなさい;旅行の初め以来の//時間
日:long_name="time ;
day:units="day ;
lon ( day ) を呈示しなさい;各時間の//経度
lon :long_name="longitude ;
lon:units="degrees_east ;
lat ( day ) を呈示しなさい;各時間の//緯度
lat :long_name="latitude ;
lat:units="degrees_north ;

メインの対等の変数 ( 日) は、モノ‐強壮にしなければならない。しかし、結合したものは、調和する、である、ない、必ず。このものといくぶん類似した重要なアプリケーションは、セクション 19で示される。それに注目するlatそして、lon示されることができない、〜同じくらい、Xそして、Y調和する、軸属性 ( セクション 9 ) 。それらが緯度、及び、経度の解釈を持っているとしても、それらがそのような軸を捜すであろうアプリケーションによって通常予期されたセンスにおいて独立した次元ではないので、これは、妥当である。

それ以来ずっとlonそして、lat与件変数と関連しているhiceaを持つ他の変数日-axisは、これらの結合を共有しないであろう。それらが必要とされるならば、それらは、それらの与件変数に関しても示されなければならないであろう。このアプローチは、可能性にそれを許す、同じである、日変数は、関連する対等の変数の様々な異なるセットと共同して発生するであろう。例えば、同じものに関して、1を超える軌道があるであろう日ほんの異なる経度‐緯度ポジションを統合する。

変えられた座標:1を超える次元の関連する変数は、代替座標系を示すために使われ得る。例えば、大気の湿度の垂直のプロファイルは、規則的な経度‐緯度グリッド上で利用可能であろう。しかし、我々は、各ポイントの国家のグリッド座標を与えることを同じく望むであろう。国家のグリッドx‐、及び、y‐座標は、緯度と、経度の両方の各ファンクションである; x‐座標は、緯度に特に経度、も、y‐とも一致しない。適切な表現、である、従って:

次元:
lon=10 ;
lat=20 ;
pressure=15 ;
変数:
humidity ( pressure、lat、lon ) を呈示しなさい;
humidity:associate="y x ;
pressure ( pressure ) を呈示しなさい;
圧力:long_name="pressure ;
圧力:positive="down ;
pressure:units="kPa ;
lon ( lon ) を呈示しなさい;// 1Dメインの対等の変数
lon :long_name="longitude ;
lon :modulo=360.0f ;
lon:units="degrees_east ;
lat ( lat ) を呈示しなさい;
lat :long_name="latitude ;
lat:units="degrees_north ;
x ( lat、lon ) を呈示しなさい;// 2Dは、対等の変数x:long_name="UKの国家のグリッド東進を結び付けた;
y ( lat、lon ) を呈示しなさい;
y:long_name="UKの国家のグリッド北進;

これは、それを我々に告げるhumidity[*][10][5]緯度を持つポイントの湿度の垂直のプロファイルであるlat[10]そして、経度lon[5]国家のグリッドx‐座標にあるx[10][5]そして、y‐調和するy[10][5]。関連する変数がマルチ‐寸法があるので、それらは、行う、ない、一致する、一対一の、従って、軸に関して、その結合は、メインの対等の変数よりむしろ与件変数を持っていなければならない。

メインの対等の変数なし: 関連の状況は、2Dグリッドがいつあるかがよろめいたことである、もしくは、軸のために一次元の対等の変数を示すことが可能ではない、及び、容易ではないように、幾何学的にある方法 ( 〜こと以外は〜セクション 10を回転‐見る ) で変えられる。この場合、メインの対等の変数がないであろう、そして、明瞭なインデックスのデフォルトは、適用されるであろう。物理的座標は、2D gridpointインデックスのファンクションであり、そして、ちょうど、上であるようである、与件変数の関連する変数において与えられるであろう:

次元:
x=90 ;
y=45 ;
変数:
orog ( y、x ) を呈示しなさい;水平のグリッド上の// 2D変数
orog :associate="lat lon ;
orog :axis= --以下。
orog :海面の上の表面のlong_name="height ;
orog:units="m ;
lon ( y、x ) を呈示しなさい;// 2Dは、同じグリッド上で変数を統合する
lon :long_name="longitude ;
lon :modulo=360.0f ;
lon:units="degrees_east ;
lat ( y、x ) を呈示しなさい;
lat :long_name="latitude ;
lat:units="degrees_north ;

latそして、lon変数は、示されない、〜同じくらい、Xそして、Y調和する、軸変数 ( セクション 9 ) 。緯度、及び、経度座標を参照したアプリケーションは、一般にそれらが二次元であると予測しないであろう。それがこの状況を処理し得るならば、それは、これらの軸を確認するべきである、それらの、long_nameそして、ユニット。

関連していた3次元は、調和する: 双方共上の場合のために、1つが代替3次元座標系によってフィールドを描写することを望んだならば、これらは、使われるであろう、規則的なデカルトのグリッド、そして、で、円筒の、もしくは、球形の、調和する。代替座標の値は、デカルトのグリッド上で与えられるであろう。場合のための球形の場合に

temperature ( z、y、x ) を呈示しなさい;デカルトのグリッドtemperature:associate="radiusシータファイに関する// 3次元変数;
radius ( z、y、x ) を呈示しなさい;
theta ( z、y、x ) を呈示しなさい;
phi ( z、y、x ) を呈示しなさい;

一次元の関連する座標の特別な技術的なアプリケーションは、netCDFの制限を1つの無制限の次元に扱うことである。いくらかの与件変数が異なる長さ、または、物理的意味の無制限の軸を持っているならば、それらは、名目上の無制限の次元を全て分配し得て、そして、軸の意味を指定する変数をそれぞれ結び付けた。

1を超える無制限の軸: 無制限の軸測定によって与件変数を含むファイルが経過した、と考える、異なるサンプリング周波数を持つ時間、従って、異なる長さのうちで。

次元:
time_counter=UNLIMITED ;
変数:
sw ( time_counter ) を呈示しなさい;3時間毎に見本をとられた//
sw :associate="time_3h ;
sw :axis="T ;
短波の放射するフラックス密度; sw:units="W m-2 ;フロートlatent ( time_counter ) のsw:long_name="verticalコンポーネント; 30分毎に見本をとられた//
潜在的:associate="time_30min ;
潜在的:axis="T ;
潜在的:long_name="latentフラックス密度を熱くしなさい;
latent:units="W m-2 ;
time_3h ( time_counter ) を呈示しなさい;
time_3h :long_name="elapsed時間;
time_3h:units="h ;
time_30min ( time_counter ) を呈示しなさい;
time_30min :long_name="elapsed時間;
time_30min:units="min ;

19バンドル

同じ物理的量を含むいくらかのデータアレイが1以上の同じ軸を持っている、しかし、他の個体の対等の変数の値によって区別されるならば、それらを同じ与件変数に格納することは、便利であるかもしれない。個別のアレイの一般の軸は、結合された変数の軸になる。 1以上の追加の軸は、導入される、個別のアレイを「束ねる」ために。そのような軸は、連続的な物理的座標と一致しない。それは、暖かくくるまったアレイのインデックスとして簡単に行動する。

個別のアレイの個体値は、バンドル次元のための関連する対等の変数において記録される。それらは、連続的座標として翻訳されるべきでない。

Timeseries : Hadley Centre GCMは、個々のポイントで量の値のtimeseriesを生成し得る。典型的に、多くの異なるポイントからのtimeseriesは、生産される、同じサンプリング時代の同じ量のうちで。 2つの次元によって与件変数におけるこの情報を含むことは、自然である。 1つの次元は、サンプリング時を指定する4分の4拍子軸である。それは、見本をとられた全てのポイントのために同じである。もう一方の次元は、連続的な物理的座標ではない; それは、簡単に使われつつある、timeseries、2以上の次元のスペースに不規則にまき散らされるポイントを「束ねる」ために。このように:

次元:
points=15 ;//測定ロケーションtimes=20 ;時代変数の見本をとる// :
snowdepth ( times、ポイント ) を呈示しなさい;
snowdepth :associate="sitename lat lon ;
snowdepth:axis="T‐;
lon ( points ) を呈示しなさい;サイトの//経度
lon :long_name="longitude ;
lon :modulo=360.0f ;
lon:units="degrees_east ;
lat ( points ) を呈示しなさい;サイトの//緯度
lat :long_name="latitude ;
lat:units="degrees_north ;
sitename ( points、StringMaxLength ) を焦がしなさい;sitenamesの二重のtimes ( times ) の//ストリング配置;測定の//時代
時間に関するセクション 23が調和することを理解する。まさにこのフォームは、ステーションからの観察されたtimeseriesのために使われるであろう。バンドル軸 ( ポイント) は、単にインデックスである。 long_nameそして、ユニット結合したもののうちで、コーディネートは、それらの意味を確認する。

垂直のプロファイル: 同様のアプリケーションは、ポイントのセットで垂直のプロファイルのそれである; 例えば、大洋を通る分散した垂直の温度プロファイル、または、様々なラジオゾンデステーションからのデータ。

次元:
station=10 ;//測定ロケーションpressure=11 ;//圧力レベル変数:
humidity ( pressure、ステーション ) を呈示しなさい;
湿度:associate="lat lon ;
humidity:axis="Z‐;
int station ( station ) ;//ステーション番号は、lon ( station ) を浮かべる;ステーションフロートlat ( station ) の//経度;ステーションフロートpressure ( pressure ) の//緯度

いくらかの小包軌道: Lagrangian小包軌道 ( 例えば、大洋浮浪者 ) のセットを考察しなさい。様々なパラメータは、各軌道の初めからの固定した時代に評価される。それらの軌道は、それらの原産地で確認され、そして、そのポジションは、時間、及び、軌道一致のファンクションである。ポジション情報は、従ってマルチ‐寸法の関連する対等の変数に格納される。

次元:
parcel=15 ;軌道times=20の//数;
max_len_parcel_name=64 ;軌道名前変数の// max長さ:
temperature ( parcel、掛ける ) を呈示しなさい;
温度:associate="parcel_name lat lon ;
temperature:axis="-T ;
salinity ( parcel、掛ける ) を呈示しなさい;
塩分:associate="parcel_name lat lon ;
salinity:axis="-T ;
times ( times ) を呈示しなさい;
times:units="days ;
parcel_name ( parcel、max_len_parcel_name ) を焦がしなさい;
lon ( parcel、掛ける ) を呈示しなさい;
lat ( parcel、掛ける ) を呈示しなさい;

それらの結合は、この場合与件変数に関して作られなければならない、 ( なぜなら〜からだ ) parcel_nameメインの対等の変数、時間を持たないlonそして、latマルチ‐寸法がある。

このセクションは、いかに最もよく1つのtimeseries、または、1つの垂直のプロファイルを格納するかの質問を提起する。このセクションの計画に従って、それは、サイズ統一であるバンドル軸を持つ二次元の与件変数に含まれるであろう。緯度、または、経度のような関連する情報は、それから個体の対等の変数に格納されるであろう、同じ次元と関連していた全て。代りに、これらの値は、個別の個体次元 ( 次のセクション 9 ) として記録されるであろう。我々は、これのために推薦を持っていない。同様に、計画は、適切であろう; どちらがおそらく更に自然であるかは、いかにデータが連続的軸から抽出されたかによって変わる。

20境界変数

次元に沿って、それらの値は、ポイント ( 対等の値で ) 、もしくは、接触している、もしくは、非接触しているセルに関係するであろう。セルの境界は、ポイントの対等の値のように定義されるべきである。その規定は、サイズ2の右手次元 ( Fortran期間の主要な次元 ) によって追加の二次元の「境界変数」を定義することである。この次元がインデックス0 ( 0からのナンバリング、すなわち、C表記法において ) を持っている値は、更に小さいメインの対等の値、及び、大きいものが評価するインデックス1を持つそれらを境界に供給する、「更に小さい」、そして「更に大きい」、物理的方向ではなく単に数値比較を参照する。別々に上の、そして更に低い境界を供給することは、それらのセルが接触していないであろうという可能性を考慮する;それらは、他の事はもちろんオーバーラップするであろう。更に低い境界値が対等の変数 ( セクション 29 ) のためにvalid_minに等しいならば、セルは、更に低い境界を持っていない。上の境界値がvalid_maxに等しいならば、セルは、上の境界を持っていない。境界変数の名前は、ストリング属性に記録される、メインの対等の変数の限度。我々は、それを推薦する、それは、接頭辞bounds_を持つ対等の次元によって指定されるべきである。境界変数は、ユニット属性を持っているべきでない; そのユニットは、メインの対等の変数のそれらと同じである。

一次元の緯度のための境界は、変数を統合する:

lat ( lat ) を呈示しなさい;
lat:bounds="bounds_lat ;
bounds_lat ( lat、2 ) を呈示しなさい;

C表記法において、lat[0]最初のポイントの座標を与える、bounds_lat[0][0]その更に低い境界、bounds_lat[0][1]その上の境界。 Fortran表記法において、宣言、である、lat ( lat ) そして、bounds_lat ( 2、lat ) そして、適切なエレメント、である、lat ( 1 ) bounds_lat ( 1,1 ) bounds_lat ( 2,1 ) 。

波長、及び、積雪のファンクションとしてのアルベド: アルベドの固有値は、様々な波長バンド、同じくsnowdepth上の扶養家族に与えられる。

次元:
lambda=4 ;短波周波数バンドsnowdepth=10の//数;snowdepthカテゴリ変数の//数:
albedo ( lambda、snowdepth ) を呈示しなさい;//アルベドのためのユニットなし
アルベド:axis= -- ; albedo:long_name="surfaceアルベド;フロートlambda ( lambda ) ;
ラムダ:bounds="bounds_lambda ;
ラムダ:long_name="wavelength ;
lambda:units="nm ;
bounds_lambda ( lambda、2 ) を呈示しなさい;
snowdepth ( snowdepth ) を呈示しなさい;
snowdepth :bounds="bounds_snowdepth ;
snowdepth :偽りの雪のユニットエリアにつきlong_name="mass ;
snowdepth :units="kg m-2 ;
snowdepth:valid_max=1e9 ;
bounds_snowdepth ( snowdepth、2 ) を呈示しなさい;
データ:
lambda=250、385、570、795 ;
bounds_lambda=175,320、320,450、450,690、690,900 ;
snowdepth=0.05、0.15、0.35、0.75、1.25、1.75、...、450.0、1000.0 ;
bounds_snowdepth=0.0,0.1、0.1,0.2、0.2,0.5、0.5,1.0、1.0,1.5、1.5,2.0、...、400.0,500.0、500.0,1e9 ;

0 ( たとえば ) の最初のインデックスは、アルベド値を波長範囲175-320 nmに与える。最も深いsnowdepthクラスは、上の限度を持っていない;500を越えるあらゆる価値は、このクラスまで低下する。

いくらかにおいて、その境界が統合する前の例のようなケースは、相当に定義される。しかし、gridpoint座標は、随意である。そのような情況において、この標準は、境界の中間点を推薦する、gridpointとして使われる。 この選択の2つの利点は、以下である。第一に、gridpointと境界との比較は、そのポイントがどちらのセルに属するかを常に決定するであろう; 第二に、それは、おそらく区別のようなgridpointsを包含するプロッティング、及び、計算のための適切な選択であろう。しかしながら、前述の例の最後のsnowdepthセル ( 上方へ限界がない ) によって示されたように、中間点は、常に賢明な選択であるとは限らない。

沈澱量の確率密度分布:

次元:
ppn=10 ;
変数:
pdf ( ppn、lat、lon ) を呈示しなさい;
pdf :axis="-YX ;
水‐等価物沈澱; pdf:units="mm-1 ;フロートppn ( ppn ) の深さのpdf:long_name="probability密度;
ppn :units="mm ;
ppn :水‐等価物沈澱のlong_name="depth ;
ppn:bounds="bounds_ppn ;
bounds_ppn ( ppn、2 ) を呈示しなさい;
データ:
bounds_ppn=0.0,0.1、0.1,0.2、0.2,0.35、0.35,0.5、0.5,1.0、... ;

pdf[3][10][12]ロケーションに落下する0.35、及び、0.5ミリメートルの間の沈澱量の確率密度を与えるlat[10] lon[12]。

メインの対等の値が均等にスペースを開けられないならば、もしくは、次元が統一のサイズを持っているならば、境界変数は、推薦される。それらの座標が均等にスペースを開けられ、そして、境界が指定されないならば、一般的アプリケーションは、メイン座標がそれらのセルの中心にあると推測するかもしれない。境界変数は、メインの対等の変数のためなのと同様に、コンポーネント、及び、関連する対等の変数のために供給されるかもしれない。それらのエレメントは、一致するメイン境界変数と一致するように命令される。従って、それらは、必ずしもモノ‐強壮にするとは限らず、そして、サイズ2の次元のインデックス0、及び、1 ( 0からのナンバリング ) は、更に小さく、更に大きい値を必ずしも抑制するとは限らないであろう。

ハイブリッドの垂直の座標のための境界値: 大気のカラムは、垂直における3つのセルにここで分割される; 表面からs = 0.7以下まで。そこから20 kPaまで、そして、最終的に、ハイブリッドを使う空気のトップまで、垂直の、調和する、セクション 17における例に提出される。

次元:
eta=3 ;
変数:
float ( eta ) ;
エータ:long_name="pressure‐シグマハイブリッド;
エータ:component="pressureシグマ;
エータ:bounds="bounds_eta ;
eta:positive="down ;
bounds_eta ( eta、2 ) を呈示しなさい;
pressure ( eta ) を呈示しなさい;
圧力:units="kPa ;
圧力:long_name="pressure ;
pressure:bounds="bounds_pressure"
bounds_pressure ( eta、2 ) を呈示しなさい;
sigma ( eta ) を呈示しなさい;
シグマ:long_name="sigma ;
sigma:bounds="bounds_sigma ;
bounds_sigma ( eta、2 ) を呈示しなさい;
データ:
eta=0.75、0.45、0.05 ;
bounds_eta=0.7,1.0、0.3,0.7、0.0,0.3 ;
pressure=0.0、10.0、5.0 ;//は、モノ‐強壮にするbounds_pressure=0.0,0.0、20.0,0.0、0.0,20.0である必要がない;//ノートは、sigma=0.75、0.35のために0.0を注文する;
bounds_sigma=0.7,1.0、0.1,0.7、0.0,0.1 ;

bounds_pressure[1][0]越える、bounds_pressure[1][1]それらは、一致するように命令されるということ、に、bounds_eta。

境界変数は、関連するマルチ‐寸法の対等の変数 ( セクション 18 ) のために示されるかもしれない。メイン変数の各次元は、境界変数においてサイズ2の余分の次元を必要とする。これらの余分の次元は、対等の次元の、そして、対等の次元と同じオーダにおける右 ( Fortranタームに残される ) に置かれる。

二次元の緯度のための境界は、変数を統合する:

lat ( y、x ) を呈示しなさい;
lat:bounds="bounds_lat ;
bounds_lat ( y、x、2,2 ) を呈示しなさい;

そのようにbounds[4][5][0][0]gridboxの左下の ( 更に小さいx、及び、y ) コーナーの緯度を含む[ 4][5 ]bounds[4][5][0][1]右下のコーナー、bounds[4][5][1][0]左上、そして、bounds[4][5][1][1]右上。 Fortranにおいてボックスのインデックスは、そうであろう( 1,1,6,5 ) ( 2,1,6,5 ) ( 1,2,6,5 ) ( 2,2,6,5 ) 各々。

サブ‐グリッド変化の 21表現

与件変数が軸に沿って切れ目なく変化する物理的量を通常代表するので、実は、一般に隣接のgridpointsの間に量の変化があるであろう。このサブ‐グリッド変化にもかかわらず、与件変数は、各セルのためにわずか1つの値を与え得る。多くの目的のために、どのようにそれがサブ‐グリッド変化に関係しても、正確に定義するために「代表的な」値、及び、それが必要ではないように、これは、とられ得る。

どのように各データ価値が特別な軸に沿ってサブ‐グリッド変化を反映しても、周囲で明白であるために、与件変数のサブ‐グリッド属性を使いなさい。 この属性の最も重要なアプリケーションは、セクション 22で示された収縮した、もしくは、崩壊した軸に対するものである。これは、ブランクに分離されたワードのリストを含むストリング属性である。このリストにおいて、「名前:方法」は、「名前」が与えられる次元を持つ軸に沿ったサブ‐グリッド変化が指定された「方法」で表されることを示す。方法 ( いくらかのワードであるかもしれない ) は、Appendix Bで詳述された可能にされた値のうちの1つであるべきである、含む、意味する、最大の最小の範囲の中央、標準偏差、分散、モード、中央のセル、ポイント。ケース、及び、句読点は、方法において有意ではない。 Appendix Dのように、Appendix Bは、この標準のユーザーによってリクエストに関して拡張されるであろう。いくらかの方法は、与件変数のユニットの変更を意味し、そして、同じくこれは、Appendix Bによって指定される。 前述のリストにおいて、これは、真である、のために、分散。 方法ポイントが示すのは、データ値がちょうど対等の値で適用され、そして、役立つということである、ない、際、全ては、関係のある軸に沿った隣接のgridpointsの間で変化を表す。方法セルが示すのは、各値が関係のある軸、<例>、和に沿った全セルの特質と見なされるべきであるということである、〜もしくは、必須の。その方法は、様々な次元のために異なって指定され得る。 その方法が示された軸にのみ適用されることが記憶されていなければならない。経度‐緯度gridboxにおける沈澱値が方法を与えられるならば、最大これらの軸 ( たとえば ) のために、それは、それがこれらの空間のセルの中の最大であり、そして、それが時間通りに同じく最大であると意味しないことを意味する。

あらゆる仕様方法 ( 一般的アプリケーションがデータ値を代表と見なすかもしれない ) の欠如。 数値モデルによるgridpointsと算定された量のために、この種類のあいまいさは、避けることができない。モデルがgridpoints、アプリケーションの温度の経度‐緯度フィールドが近づいたものだったことを規定するならば、フィールドの輪郭を示すプロットは、一般に温度がポイントで適用されると推測し、そして、それらの間で値を計算するある補間計画を使うであろう。フィールドの平均を計算するアプリケーションは、おそらく温度がgridbox方法であるとしかしながら推測し、そして、そのエリアによってそれぞれ増量によってそれらを平均するであろう。これらのアプローチの双方共が、正当である。定義による定形動詞‐差異計画は、サブ‐グリッド変化に関する情報を全く持っていず、そして、双方の道で値をそれ自体扱うかもしれない; それらをポイントと見なして、それは、それらの間で勾配を計算する、または、方法としてそれらに関する保存プロパティを実施するであろう。値をextremaと見なすことは、異常であろう、しかしながら。これが明白に示されない限りは。

いつデータがポイント値であるかを除いて、gridpointsの座標が何であるべきであるかは、同じくはっきりしないかもしれない。 例えば、座標が何時にあるべきであるかは、時間平均値にアサインした? そのような情況において、セルの境界が相当に定義されるならば、この標準は、gridpointsが境界の間の中間点と定義されるべきであることを勧める ( セクション20を見なさい ) 。

timeseriesにおけるサブ‐グリッド時間変化: いくつかのステーション ( そこで、圧力は、そう ) からの圧力、温度、及び、沈澱の12‐毎時間のtimeseriesが瞬時に測定し、前の期間にわたる温度極端が最大の、そして最小の温度計によって記録され、そして、沈澱が雨量計に蓄積される、と考えなさい。 1998年4月19日の午前6時からの48時間の期間の間、データは、次のとおりに構造化される:

次元:
instanttime=5 ;12時間間隔periodtime=4の// 5の瞬間的な測定;// 4介在している12時間期間station=10 ;
変数:
pressure ( station、instanttime ) を呈示しなさい;
圧力:axis="-T ;
pressure:long_name="pressure
圧力:subgrid="instanttime :指し示しなさい;
pressure:units="kPa ;
maxtemp ( station、periodtime ) を呈示しなさい;
maxtemp :axis="-T ;
maxtemp:long_name="temperature"
maxtemp :subgrid="periodtime :最大;
maxtemp:units="K ;
ppn ( station、periodtime ) を呈示しなさい;
ppn :axis="-T ;
水‐等価物沈澱のppn:long_name="depth ;
ppn :subgrid="periodtime :セル;
ppn:units="mm ;
instanttime ( instanttime ) を2倍にしなさい;
instanttime :long_name="time ;
1998-19-4 6:0:0以来のinstanttime:units="h ;
periodtime ( periodtime ) を2倍にしなさい;
periodtime :bounds="bounds_periodtime ;
periodtime :long_name="time ;
1998-19-4 6:0:0以来のperiodtime:units="h ;
二重のbounds_periodtime ( periodtime,2 )
データ:
instanttime=0.、12.、24.、36.、48. ;
periodtime=6.、18.、30.、42. ;
bounds_periodtime=0.、12.、12.、24.、24.、36.、36.、48. ;

それは、適切ではない、ステーションのためにサブ‐グリッド方法を与える、軸、‖ ( これが連続的な物理的座標ではなくバンドル 軸 ( section 19 ) であるので ) 。瞬間的、そして、期間測定は、それらの異なる次元のために異なる時間軸双方共持っていなければならない、そして、なぜなら、それらが同時に起こらないからだ。圧力測定がその他 ( 正午、及び、夜半 ) の間で時々中間の状態にされたならば、時間軸は、共有されるであろう。その沈澱が量として行われるので、それは、定義による時間の間隔にわたる和である。それは、その代りにレートとして表されたであろうmm h-1そのサブ‐グリッド方法がどちらのケースであろうかにおける場合のために平均よりむしろ、セル。

厚さ ( geopotentialな差異 ) :「厚さ」は、雰囲気の2つの圧力表面の間のgeopotentialな高さにおける差異である。この量は、定義もの ( 垂直の次元におけるそのセルの全エクステントに関係する ) によるものである。

変数:
thickness ( pressure、lat、lon ) を呈示しなさい;
thickness:long_name="thickness"
厚さ:subgrid="pressure :セル;
thickness:units="m2 s-2 ;
pressure ( pressure ) を呈示しなさい;
圧力:bounds="bounds_pressure ;
圧力:long_name="pressure ;
pressure:units="hPa ;
bounds_pressure ( pressure、2 ) を呈示しなさい;

ここ、bounds_pressure[0][0]そして、bounds_pressure[0][1]厚さフィールドの上の、そして更に低い圧力限度であろうthickness[0][*][*]。

1を超えるサブ‐グリッド方法が示されるべきであるならば、それらは、それらが適用された命令においてアレンジされるべきである。最も左のオペレーションは、最初に適用されたために、推測される。 量が経度と、時間 ( 次元の両方の点で異なる、と仮定するlonそして、時間各gridboxの中の ) 。帯の最大の時間‐平均を表す値は、分類されるsubgrid="lon :最大の時間:平均すなわち、全ての経度上の時間の各瞬間に最も大きい値を求めなさい、その後、時間の間ずっとこれらの最大を平均しなさい; 時間‐平均の帯の最大の値は、分類されるsubgrid="time :lonを意味しなさい:最大。それらの方法が結果に影響を及ぼさずにあらゆる順番に適用されたであろうならば、それらは、入れられるかもしれない、どれでも、命令する、で、サブ‐グリッド属性。

データ値が軸の結合に関して変化を代表するならば、1つの方法は、関係がある全ての次元 ( それらのオーダが重要でない ) の名前によって接頭辞をつけられるべきである。個々にそれらを扱うとの本質的差異がありさえすれば、次元は、このように集められるべきである。 場合のために、経度‐緯度gridboxの中の地形学の高さのサブ‐グリッド標準偏差、持つ、subgrid="lat :lon :標準偏差。これは、同じではない、〜同じくらい、subgrid="lon :標準偏差lat :標準偏差どちらがgridboxの帯のエクステント、そして、これらの標準偏差の中で各緯線に沿った標準偏差を求めることを意味するであろうかは、過剰緯度を評価する。

いかにサブ‐グリッド方法が適用されたかを更に正確に示すために、余分の情報は、方法の識別後の括弧 ( ) に含まれるかもしれない。この情報は、標準化されず、そして、一般的アプリケーションによって無視されるかもしれない。 緯度 ( たとえば ) に関する平均は、エリア‐重荷を負っているかもしれない。これは、示されるであろう、〜同じくらい、lat :平均 ( エリア‐重荷を負った ) 。

サブ‐グリッド属性は、いかに価値が与件変数で次元を持たない座標上で変化を反映するかを示すために使われることができない。これは、その代りにlong_nameにおいて行われるべきである。しかしながら、特にこの目的のために個体次元を導入することは、一般に更に有益で、正確である。 例えば、我々は、量について述べるであろう、その、long_name単に一時的分散であるとして、しかし、それは、更に有益であろう、に、サブ‐グリッド方法としてそれを記録する、個体時間次元を変数に与えることによって、同じく中古であろう、に、範囲、の、時代、それ、カバー、及び、その分散がどちらであったかからのデータの時間‐間隔は、計算した。同じくセクション 22を見る。

22の収縮した次元

収縮した軸は、更に大きい次元によって軸の値を更に小さい数のグループに集めることによって形成されるものである。最も一般のケースにおいて、その次元は、完全に個体寸法 ( すなわち、統一、セクション 9のサイズ ) まで崩壊する。そこで、全てのデータポイントは、全体の崩壊した軸を共有する。崩壊した次元は、更に高い寸法があることの他の変数に示されつつある与件変数の関係を示す。収縮した軸に沿ったセルの境界は、収縮していない軸に沿ったセルのグループの外側の境界であろう、または、境界が与えられなかったならば、その外側は、調和する。収縮した軸のメインの対等の値は、グループによって測られた対等の範囲を代表する値であろう。崩壊した次元は、完全な範囲の崩壊されない軸を供給する1つの代表的なメインの対等の値、及び、境界の対等の値を持っている。境界が供給されなかったならば、これらの境界は、崩壊されない軸の極端な境界の対等の値、または、極端なメインの対等の値であろう。 崩壊した軸の非常に重要なアプリケーションは、climatologicalな時間を示すことである。これについて、セクション 28で論じられる。

収縮した軸を持つ与件変数のサブ‐グリッド属性 ( セクション 21 ) は、いかに次元を減少させるために収縮していない軸を持つ変数のデータ値が集められたかを示すために使われ得る。新しいサブ‐グリッド情報は、もしあれば最近契約された次元の名前を示す現存する属性に付加されるであろう。収縮していない次元がもはや与件変数の次元ではないので、サブ‐グリッド属性における収縮していない次元のあらゆる現存する参照は、収縮した次元を参照するために、修正されるべきである。

セクション 21で説明されたように、この属性は、データ値が平均、最大、最小等であることを示すであろう。許される、サブ‐グリッド「方法」は、Appendix B ( 必要性が起こるので、拡張されるであろう ) にリストされる。今のところ予測されたように、そのアイデアは、各収縮した一群のあらゆる外部の定数と無関係の値を代表する1つの値を与えるオペレーションに制限される。例えば、グループ、または、同等に第20の百分位数の点で値の20%を越える数は、グループを表す1つの数である。しかし、それを発見することの手続きは、aのように扱われないサブ‐グリッド方法、それを定義することが一定の0.2を必要とするので。その代りに、この新しい変数の関係、に、古い、変わることによって示されるべきである、その、long_nameそれを示すために、それは、百分位数の値であり、そして、値20、または、値0.2を持つ累積的な確率によって新しい個体パーセンテージ軸をそれに与えている。この種類の変化は、3つの空間の次元 ( 言う ) で、指定された表面にその値を抽出することによる2に、変数を減少させることに類似している。収縮、または、崩壊は、特別なケースである、ということ、概して、百分位数の軸は、統一のサイズを持っている必要がない; それは、古いもの ( 場合のためのある空間の寸法で ) を交換する新しいマルチ‐貴重な軸 ( 累積的確率において ) であろう。これは、圧力に高さの縦軸をregriddingすることのようである。全てを言った、これ、しかしながら、我々は、それに注目する、メジアン実際第50のpercentile-but ( それが1つの代表的値を選択するための一般の方法であるという理由で、我々がそれに与える ) のこのオペレーション‐抽出の指定された場合である。

個体軸は、必ずしも軸を崩壊させることの結果であるとは限らない。セクション 9において、我々は、特徴的な1つの物理的値を与件変数、たとえば高さに付加する方法、または、変数が供給される表面の圧力として個体軸を推薦する。かどうか、no、サブ‐グリッド方法が指定されるということを、そのアプリケーションは知る、1つの値がデータの特性を示すということさえなければ、で、どうにかして。情報全て、で、サブ‐グリッド属性は、完全に任意である。たとえば、時間‐平均量は、一般にそれが申し込む時代の範囲を示すための個体時間次元を持っているべきである。しかし、それは、示すための委任者ではない、サブ‐グリッドそれが平均である属性、時間。

収縮した軸の対等の変数に関して、任意のold_interval属性は、収縮していない軸の2つの隣接の座標の間で典型的スペーシングを指定する。そこで、「typical」は、相当に定義されない。 old_interval属性は、座標と同じユニットにおいて与えられるべきである。更なる情報である与えるで任意のold_spacing属性持つ値制服示すということ座標である均等にスペースを開ける付きでold_interval指定するそして細胞接触している〜もしくは変数〜ならばそれらである均等にスペースを開けるしかしまだ接触している〜もしくは解体する方法であるギャップの間にそれら収縮していない軸の座標は、個別の変数において明白に示されるかもしれない; 従ってメインの収縮していない対等の変数が属性によって指定されるべきであるならば、拡大する、メインの収縮した対等の変数のうちで。

経度‐緯度をエリア‐平均して、更に低い解像度のうちの1つに野手をつとめなさい:オリジナルの解像度は、1度であり、そして、そのフィールドは、10度ボックスに平均された。

次元:
con_lat=18 ;//は、次元con_lon=36を契約した;
lat=180 ;//オリジナルは、次元lon=360を契約しなかった;
変数:
sst ( con_lat、con_lon ) を呈示しなさい;
sst :axis="YX ;
sst:long_name="seaの表面の温度;
sst :subgrid="con_lat :con_lonを意味しなさい:以下を意味しなさい。
sst:units="degC ;
con_lat ( con_lat ) を呈示しなさい;//は、緯度軸を契約した
con_lat :bounds="bounds_con_lat ;
con_lat :expand="lat ;
con_lat :old_interval=1.0f ;緯度における//オリジナルの解像度
con_lat :long_name="latitude ;
con_lat:units="degree_north
bounds_con_lat ( con_lat、2 ) を呈示しなさい;
lat ( lat ) を呈示しなさい;//オリジナルは、緯度軸lat:bounds="bounds_latを契約しなかった;
bounds_lat ( lat、2 ) を呈示しなさい;
データ:
con_lat=-85、-75、-65、... ;
bounds_con_lat=-90.、-80.、-80.、-70.、-70.、-60.、...、80.、90. ;
lat=-89.5、-88.5、-87.5、... ;
bounds_lat=-90、-89、-89、-88、-88、-87、...、89,90 ;

エリア‐平均の代りに、収縮したフィールドは、その代りにSSTのサブ‐グリッドの空間の変化を表したであろう。そのような場合、subgrid="con_lat :con_lon :標準偏差。

時間外労働、及び、経度を意味しなさい:ここで、時間‐平均帯の‐平均湿度は、緯度、及び、高さのファンクションとして与えられる。その方法は、オリジナルのデータの完全な時間、及び、経度間隔の間ずっと形成された。従って、これらの次元は、崩壊する。

次元:
con_lon=1 ;//は、経度次元con_time=1を崩壊させた;//は、時間次元lon=72を崩壊させた;
sigma=6 ;
変数:
humidity ( con_time、シグマ、lat、con_lon ) を呈示しなさい;
湿度:axis="TZYX ;
humidity:long_name="specific湿度;
humidity:subgrid="con_time :con_lonを意味しなさい:以下を意味しなさい。
con_time ( con_time ) を2倍にしなさい;
con_time :bounds="bounds_con_time ;
con_time :old_interval=0.125 ;//、元来。%Y%m%d.%fとしての3 h con_time:units="daysの間隔で;
bounds_con_time ( con_time、2 ) を呈示しなさい;
con_lon ( con_lon ) を呈示しなさい;
con_lon :bounds="bounds_con_lon ;
con_lon :long_name="longitude ;
con_lon :modulo=360f ;
con_lon :topology="circular ;
con_lon:units="degree_east ;
bounds_con_lon ( con_lon、2 ) を呈示しなさい;
sigma ( sigma ) を呈示しなさい;
シグマ:bounds="bounds_sigma ;
sigma:long_name="sigma ;
bounds_sigma ( sigma、2 ) を呈示しなさい;
データ:
con_time=19960901.0 ;
bounds_con_time=19960301.0、19970301.0 ;
con_lon=180 ;
bounds_con_lon=0、360 ;
sigma=0.99、0.96、0.92、0.8、0.5、0.1 ;
bounds_sigma=0.98,1.00、0.94,0.98、0.86,0.94、0.65,0.86、0.30,0.65、0.05,0.30 ;

これは、1996年3月1日から1997年3月1日まで完全な範囲の経度上の平均である ( 時間に関するセクション25が調和するのを見なさい ) 。それが崩壊する前に、これがそのケースであったので、経度軸は、円トポロジーを示す;崩壊の後で、そのトポロジーは、本当に有意義ではない。その湿度が空気のも深さ以上続いて平均‐されたならば、サブ‐グリッド付けられるであろう、に関して、con_sigma :平均そして、con_sigma限度0.05、及び、1.00を持つであろう。

同じ軸が繰り返して契約されるならば、それらの方法は、全て与件変数のサブ‐グリッド属性において記録されるかもしれない。しかし、最も最近のold_intervalのみ、及び、old_spacingは、収縮した対等の変数に関して示されるであろう。しかし、収縮の前の軸がファイル ( 確認される、属性を拡張する ) において保持され、そして、それ自体収縮の結果であったならば、それは、前のold_interval、及び、old_spacingを記録し得る。

いくらかの方法の繰り返されたオペレーションは、1つのオペレーションに相当すると見なされ得る。 例えば、5度、及び、5 〜 45度からのその時にとって1度幅の経度セルを意味する、与える、1度から45度 ( 欠測値を持つ複雑から離れて ) までの1のステップにおける意味としての同じ結果。同様に、月への、その後、季節への日からの時間軸を意味する、そして、最終的に、に、年は、日から年まで意味の1つのオペレーションとして表明されるであろう。 そのような場合、サブ‐グリッド、old_interval、及び、old_spacing属性は、連続するオペレーションのために修正する必要がない。このアプローチを行うかどうかの選択は、アプリケーションに任せられる。

23時間変数、及び、間隔

「時間変数」は、日付、及び、時間 ( 我々がちょうど「時間」として今後参照するであろう ) を表すものである。「interval of time」は、2回の間の差異である。

netCDFファイルにおける6つのコンポーネント ( 年、月、日、時間、瞬間、瞬間 ) に関して時間を示すことは、可能であろう ( 様々なデータタイプの6つのコンポーネント変数を用いて ) 。しかしながら、それは、更に効率的である、そして、多くの目的のために、与える1つの数としての更に時であると表明するのに便利な、経過した、ある参照時以来の間隔 ( 含蓄がある或いは明白であるかもしれない ) 。我々は、時のコンポーネントからの変換を「エンコーディング」としての1つの数、及び、「デコーディング」としての逆に参照する。エンコーディング、及び、デコーディングは、複雑になる。なぜなら、年、及び、月が使用中の日付、及び、カレンダーによって決まる長さを持つユニットであるからだ。従って、特別な供給は、時間軸のために必要とされる。

「カレンダー」は、正当な日付 ( year-month-day結合 ) のセットを定義する。標準のカレンダーは、Gregorian ( udunitsのカレンダー ) である。しかし、気候モデルは、これを常に使うとは限らない。 例えば、Hadley Centre GCMのカレンダーにおいて、全ての月には、30日がある。経過した、2回の間の固定長 ( 日、時間、分、秒 ) のユニットにおける間隔、ない、必ず2冊の異なるカレンダーと同じである、‖ ( なぜなら、それらの間に正当な日付の異なる数があるかもしれないからだ ) 。 例えば、1996年2月1日、及び、1996年3月1日の間の間隔は、1ヶ月であり、そして、標準のカレンダーに関して29日と同等である。しかし、2月30日以来のHadley Centreモデルカレンダーにおける30日は、後半に正当な日付である。従って、時のエンコーディング、に、経過した、間隔は、カレンダーによって変わるであろう、そして、変わっているとき、カレンダーを知ることは、必要である。この標準は、標準のカレンダー ( 下記、セクション 26 ) の、そして、他のカレンダー ( セクション 27 ) の使用を可能にする。次のセクションで述べられたカレンダー属性は、使用中のカレンダーを示す。時間の対等の変数がカレンダー属性を持っていないならば、グローバルなカレンダー属性 ( セクション 5 ) ( 存在するならば ) は、それに適用される。

この標準は、時を数にコード化することのそれらのユニットによって区別された2つの異なる方法を可能にする。「相対的時間」、及び、「絶対的時間」と言われるこれらの方法は、次のセクション ( 24、及び、 25 ) で述べられる。相対的時間は、更に熟知の方法である。しかし、絶対的時間は、重要な利点を提供する。

Unix ( TM ) 日付コマンドの規定に基づいた日付、及び、時間をプリントするためにフォーマットを指定するために、時間変数は、属性のtime_formatを持っているかもしれない。

時間の対等の変数は、ユニット属性を常に明白に含まなければならない;デフォルト値がない。

24の相対的時間

相対的時としてコード化された時は、与える、経過した、指定された参照時以来の間隔; ユニット、「参照‐時間以来フォーム時間単位をとる、Unidata udunitsパッケージの推薦と同様に ( しかし時間単位に関係することの下方で見る ) 、<例>、ユニット、の、1992-10-8 15:15:42.5以来の秒3時間、15分、及び、42.5秒の1992年10月8日以来秒を午後示す、Universal Coordinated Timeにおいて ( 時間帯が同じく扱われ得る ) 。 相対的な時間軸上で値を解読するために、そのアプリケーションは、概してカレンダーを知る必要があるであろう; コード化された時間値は、この知識なしで無意味である。更に、同じユニットに関する2冊の異なるカレンダーにおいてコード化されたとき、ある日付は、異なる時間値に帰着するかもしれない。 場合のために、1996-2-1 15:00:00である、1995-12-1 0:0:0以来の62.625日標準のカレンダーにおいて、そして、1995-12-1 0:0:0以来の60.625日360日カレンダーにおいて。

ファイルudunits.datは、瞬間、瞬間、時間、及び、日を単位時間と定義する。月、及び、年のユニットは、この標準のAppendix Cによって却下される。なぜなら、それらが明確ではないからだ; udunitsが31556925.97 s ( 365日未満の674.03 s ) の「太陽年」としての1年、及び、1年のちょうど第12としての1ヶ月を定義するので、これらのユニットの使用は、おそらく予測される結果を与えないであろう。 例えば1995-4-1 0:0:0以来の1ヶ月udunitsによって扱われる、〜同じくらい、1995-4-1 0:0:0以来の30.4368日どちら、である、おおよそ、1995-5-1 10:29ない、1995-5-1 0:0:0。同じく、1995-4-1 0:0:0以来の1年である、周囲で、1996-3-31 5:49ない、1996-4-1 0:0:0。 udunitsユニットcommon_year ( ちょうど365日 ) は、可能にされる、ではなく、推薦される。

量の瞬間的な測定のための相対的な時間軸:1996年6月に正午測定は、第2‐5日に行われる。

次元:
time=4 ;
変数:
time ( time ) を2倍にしなさい;
時間:long_name="time ;
時間:1996-1-1 0:0:0以来のunits="days ;
データ:
time=1.5、2.5、3.5、4.5 ;

毎月の方法のための相対的な時間軸: 方法は、1990年の2月、3月、及び、4月のために計算される。

次元:
time=3 ;
変数:
time ( time ) を2倍にしなさい;
時間:bounds="bounds_time ;
時間:long_name="time ;
1990-1-1 0:0:0以来のtime:units="days ;
bounds_time ( time、2 ) を2倍にしなさい;
データ:
time=45.0、74.5、105.0 ;
bounds_time=31.0,59.0、59.0,90.0、90.0,120.0 ;

この例において、メイン時間座標は、単にそれらのそれぞれの月の中間点である代表的な値である。解読した、それら、である、1990-2-15 0:0:01990-3-16 12:0:0そして、1990-4-16 0:0:0。

25の絶対的時間

時間をコード化するこの方法は、固定長の1つのユニットよりむしろ時間の個別のコンポーネントを参照する。それは、2つの利点を提供する。第一に、コード化された時代は、有意義で、そして、それらの間で間隔を計算するためにこの知識がまだ必要とされるが、カレンダーの知識のない時間のコンポーネントに解読され得る。第二に、「部分的な」時代は、コード化され得る ( その年、または、「seasonal phase ( time of year , time within the seasonal cycle ) 」、または、「diurnal phase ( time of day , time within the diurnal cycle ) 」を省略する ) 。対照的に、相対的時代は、ただ「完全な」時代であり得る。それは、これらの3つ全てに関する情報を含む。

そのフォームは、絶対的時間のユニット属性に「時間‐ストリングとしての時間単位、推薦されたデータタイプを持つThe可能性を要し、そして、それらの意味は、次のとおりである:

従って、Unix ( TM ) 日付、そして、printfコマンドにならって、時間‐ストリングコードは、いかにその年、月、月の内の日、及び、日以内の時間が1つの数にコード化されるかを示す:

絶対的時間に、1998年4月5日の午後3時は、値19980405.625によってコード化される、そして、%Y%m%d.%fとしてのunits="day。完全な時をコード化するこの方法の利点は、それがカレンダーの知識なしで行われ得ることである、一方、かどうか、我々、相対的時間単位においてコード化される、の、1900-1-1以来の日その値は、標準のカレンダーにおける35888.625、及び、360日カレンダーにおける35374.625であろう。同じく我々は、カレンダーに関係なく値19980605.625が同じユニットと共にちょうど2カレンダー月後に時であり、そして、19970405.625が早期にちょうど1暦年であるということを知っている。他の時間ユニット‐日にこれらの間隔を計算する以外の、時間、etc.-weは、まだカレンダーを知る必要がある。

唯一の完全な形の絶対的時間は、「%Y%m%d.%fとしての日」である。それに特に注目する、%Y%m.%fとしてのフォームcalendar_month、及び、「%Y.%fとしてのcalendar_year」は、昼間のフェーズについて情報を意味しない部分的な時代である。 これは、非常に重要なポイントである。場合のために、%Y.%fとしての1998.25 calendar_year「わずか季節的サイクルに関しての1998年の間の方法の4分の1」の方法。この意味は、標準、及び、360日カレンダーにおいて同じである。この表現が情報を携帯しないので、それは、それを解読することを可能にされない、に、1998-4-2 3:0:0( すなわち、その年の初めからの91.25日 ) 標準のカレンダーにおいて、〜もしくは、1998-4-1 0:0:0360日カレンダーにおいて。同様に、%Y%m.%fとしての199804.3 calendar_month「季節的サイクルに関しての1998年4月の間の方法の30%」を意味する。下の例は、そのような部分的時代の使用を示す。

唯一の形の季節的な、そして昼間のフェーズから成る部分的な時間が「%m%d.%fとしての日」であることに同じく注目しなさい; 昼間のフェーズと結合した暦年、または、月の小数として季節的フェーズをコード化する方法がない。これ、必要とされる、そのアプリケーションは、2‐コンポーネント時間変数としてそれを組み立てるであろう。 この除外は、妥当なように思われる。なぜなら、季節的なそしてまた昼間のサイクルを解決するデータが既知のカレンダー ( たとえば、それが1年で幾らかの日を示すであろう ) に属しなければならない、従って、その季節的サイクルが月、及び、日によって分類され得るからだ。季節的な、そして昼間のサイクル ( 双方共が現れるならば ) が個別の軸上でどちらのケースであろうかにおいて、季節的サイクルの部分が平均されたとき、下の例において示された季節的なサイクルのカレンダー‐非依存の表現は、更に有益である。

.%fを時間‐ストリングに入れない部分的な時間のフォームは、離散変数である、よりむしろ、連続的な。これらのフォームのうちの1つにおける時間軸によってカバーされた日、または、年の時間の間隔は、軸の両端をカウントに入れることによって計算される、〜もしくは、同等に、1をエンドの差異に加えることによって。 場合のために、軸、に関して、%Yとしてのunits="calendar_year両端が含まれるので、それは、9ではなく1930年から1939年のカバー10年に達する。これは、季節的フェーズではなくその年のみ示す部分的な時である。持って、これを季節的フェーズを含む軸と対照する%Y.%fとしてのunits="calendar_yearそして、1930.0、及び、1939.0のポイントを終えなさい。 1930年の初めから1939年の初めまで、この軸は、9年を測り、そして、1939年そのものを含まない。下の例は、更にこのポイントを例証する。

量の瞬間的な測定のための絶対的時間軸: 1996年6月に正午測定は、第2‐5日に行われる。

次元:
time=4 ;
変数:
time ( time ) を2倍にしなさい;
時間:long_name="time ;
時間:%Y%m%d.%fとしてのunits="days ;
データ:
time=19960602.5、19960603.5、19960604.5、19960605.5 ;

日でコード化された毎月の方法のための絶対的時間軸:

次元:
time=3 ;
変数:
time ( time ) を2倍にしなさい;
時間:bounds="bounds_time ;
時間:long_name="time ;
%Y%m%d.%fとしてのtime:units="days ;
bounds_time ( time、2 ) を2倍にしなさい;
データ:
time=19900215.0、19900316.5、19900416.0 ;
bounds_time=19900201.0,19900301.0、19900301.0,19900401.0、19900401.0,19900501.0 ;

この例の相対的な時間バージョンと同様に、メイン時間座標は、それらのそれぞれの月の中間点である。それらがまっすぐにコード化されるが、それらの値は、カレンダーによって変わる。 1つが異なるカレンダーを使ったデータソースからこれらの月にわたる方法を比較していたならば、それは、不便であろう、そして、次の例と同様に回避されるであろう。

数ヶ月のうちでコード化された毎月の方法のための絶対的時間軸:

次元:
time=3 ;
変数:
time ( time ) を2倍にしなさい;
時間:bounds="bounds_time ;
時間:long_name="year、及び、季節的フェーズ;
%Y%m.%fとしてのtime:units="calendar_months ;
bounds_time ( time、2 ) を2倍にしなさい;
データ:
time=199002.5、199003.5、199004.5 ;
bounds_time=199002.0,199003.0、199003.0,199004.0、199004.0,199005.0 ;

この方法は、メイン座標がそれらの月の間ずっと中間であることを直接示す。

単にその年を定義する部分的な時: この種類の軸は、特別な種類のイベントの出来事の数を記録するために使われるであろう:

次元:
year=3 ;
変数:
int year ( year ) ;
年:long_name="year ;
%Yとしてのyear:units="calendar_year ;
int count ( year ) ;
データ:
year=1991,1992,1993,1994,1995
count=0,2,1,0,1 ;

上で論じられたように、この軸は、5年を測る。境界は、供給されない、 ( なぜなら〜からだ、各エレメント、の ) カウント単に1年まで申し込む。従って、〜そしてまた〜、上の、そして、下がる、年境界は、等しいであろう、に、それらの、年。

暦年に定義された年、及び、季節的フェーズ: 各カウントがそのそれぞれの年の連続的な期間全体に適用されたことを示すことが適切であったならば、対照的に、最後の例に、これは、このように行われるであろう:

変数:
year ( year ) を2倍にしなさい;
年:bounds="bounds_year ;
年:long_name="year、及び、季節的フェーズ;
%Y.%fとしてのyear:units="calendar_year ;
bounds_year ( year、2 ) を2倍にしなさい;
int count ( year ) ;
データ:
year=1991.5、1992.5、1993.5、1994.5、1995.5 ;
bounds_year=1991.0,1992.0、1992.0,1993.0、1993.0,1994.0、1994.0,1995.0、1995.0,1996.0 ;
count=0,2,1,0,1 ;

浮動少数点年の使用は、途中まで1年、及び、ポイントの初め、及び、ちょうど結末を表すために、都合よく我々を許す、貫いて。標準のカレンダー ( もちろん ) において、1992.0から1993.0までの間隔は、他の全ての年より相対的時間に更に長い。いくらかの目的がなければ、各間隔が暦年であることを記録することは、更に有益であろう。異なるカレンダーからデータを比較しているとき、これは、とりわけ役に立つであろう。

年のファンクションとしての季節的なフェーズ: その年の内の部分的な時として、ここで、我々は、最も高い毎日の最高気温、または、モンスーンの開始のような特別なイベントの年の内に日付を示す。

次元:
year=5 ;
変数:
int year ( year ) ;
年:long_name="year ;
%Yとしてのyear:units="calendar_year ;
int date ( year ) ;
日付:long_name="seasonalフェーズ;
日付:%m%dとしてのunits="day ;
データ:
year=2011、2013、2027、2028、2051 ;
date=629、627、626、703、710 ;

2028年7月3日に、そして、2051年7月10日に、関係のあるイベントは、2011年6月29日に2027年6月26日に発生した。明瞭に、日付変数は、完全な時としてコード化されたであろう、おそらく、相対的時間単位において、しかし、これは、冗長な年の情報を含んだであろう。

年ではなく季節的フェーズを示す時間変数は、1年のmoduloを持っている。それが全体の季節的サイクルを測るならば、同じくそれは、円トポロジーを持っている。同様に、季節的フェーズではなく昼間のフェーズを示す時間変数は、1日のmoduloを持っており、そして、それが全体の昼間のサイクルを測るならば、円トポロジーを持つ。 これらの種類の時間座標は、他の収縮した時間軸と連係したclimatologicalな時間を表すのに有益な詳細である。セクション 28を見る。

数ヶ月のうちで表された季節的なサイクルを平均しなさい: 3‐月平均としての太陽の放射のためのデータ。

次元:
time=4 ;
lat=72 ;
lon=96 ;
変数:
sol ( time、lat、lon ) を呈示しなさい;
ソル:axis="TYX ;
太陽の放射するフラックス密度; sol:units="W m-2 ;フロートtime ( time ) のsol:long_name="verticalコンポーネント;
時間:bounds="bounds_time ;
時間:long_name="seasonalフェーズ;
時間:modulo=12.0f ;
時間:topology="circular ;
%m.%fとしてのtime:units="calendar_month ;
bounds_time ( time、2 ) を呈示しなさい;
データ:
time=10.5、13.5、16.5、19.5 ;
bounds_time=9.0,12.0、12.0,15.0、15.0,18.0、18.0,21.0 ;

最初ポイントは、月9の初めから月12の初め、すなわち、含めた11月までの9月まで適用される。代表的なメイン座標は、与えられる、の、10月の間の途中まで。第2のポイントは、同等である月15 〜 3、すなわち、modulo 12の下の3月、そして、2月までのカバー12月の初めに達する。一般に必要とされるように、moduloの使用は、メインコーディネートがモノ‐トニックとして指定されることを可能にする。その軸が同じく円であるので、異なる季節で始まるために、順番に値を回転させることは、許すことができるであろう。

年で表された季節的なサイクルを平均しなさい:従って、時間の対等の上記は、暦年に等しくよく与えられるであろう:

次元:
time ( time ) を2倍にしなさい;
時間:bounds="bounds_time ;
時間:long_name="seasonalフェーズ;
時間:modulo=1.0 ;
時間:topology="circular ;
.%fとしてのtime:units="calendar_year ;
bounds_time ( time、2 ) を呈示しなさい;
データ:
time=0.7917、1.0417、1.2917、1.5417 ;
bounds_time=0.6667,0.9167、0.9167,1.1667、1.1667,1.4167、1.4167,1.6667 ;

ここで、その年の間ずっと方法の3分の2を始めて、それらの期間は、ちょうど1年の4分の1として組み立てられた。 360日カレンダーにおいて、これは、9月の初めにスタートする3ヶ月の期間の最後の例と同じである。しかし、標準のカレンダーにおいて、1年の4分の1がちょうど3暦月ではないので、それは、僅かに異なる。

26グレコリー暦

この標準は、Gregorian時がデータタイプを二重の ( セクション 25 ) 状態にして%Y%m%d.%fとして日のユニットにおいて与えられることを勧める。互換性が絶対的時代を処理し得ないアプリケーションによって本質的でない限りは。そのような場合、Gregorian時代は、ユニットを指定するUnidata udunitsパッケージの推薦、及び、参照時、すなわち、相対的時 ( セクション 24 ) と同様にフォーマットされた単位時間を持っているかもしれない。データタイプを二重の状態にして、推薦されたユニットは、日である。

標準のグレコリー暦における2回の間の間隔は、Unidata udunitsパッケージによって計算され得る。 Udunitsは、英国 ( ユリウス暦を用いるために1582-10-15の前の日付が推測される ) で進められた混ざったグレコリー暦/ユリウス暦システムを実行する。他のソフトウェアは、同じ方法でカレンダーの変更を扱うために、頼られることができない。従って、たくましさのために、基準日付が1582より新しいということが勧められている。初期の日付が使われなければならないならば、1 ADと同じであるので、udunitsが0 ADを扱うことが注目されるべきである。

データタイプダブル相対的な時代 ) における約16の10進数字 ( , rp_which means that it x_can ve_resolve tenths of a second for years of up to O ( 1 million ) の精度を与える。 365よりむしろ、1年が10 000日のようであるので、絶対的時代の精度は、桁更に悪い。更に大きいもの、その年、更に病気の、絶対的精度。非常に大きい年が必要とされ、そして、その精度が十分ではないならば、参照年は、間隔を十分に小さい状態に保つために、修正されなければならないであろう。

時間変数に適用されるカレンダー属性がないならば、それらの値は、正常なグレコリー暦にあるために、推測される。これは、カレンダーを標準、または、gregorianにセットすることによって明白にされ得る。

27非‐Gregorianカレンダー

他のカレンダーにおける時代がデータタイプを二重の ( セクション 25 ) 状態にして%Y%m%d.%fとして日のユニットにおいてコード化されるべきであるということが勧められている。相対的時代は、可能にされる、データタイプダブルを持つ1-1-1 ( 年1の1月1日の夜半 ) 以来日である推薦されたユニット。 Unidata udunitsパッケージが標準のカレンダーのみ処理し得るので、拡張は、他のカレンダーの相対的な時を処理するのに必要とされるであろう。

Gregorianは別として、この標準で識別されたカレンダーは、ユリウス暦 ( 4で分けられる全ての年がうるう年である ) のためのjulian、毎年の365日を持つカレンダーのためのnoleap、及び、360である、各月に毎年に30日があるとき。他のカレンダーが使われるならば、適当な記述は、カレンダー属性に現れるべきである。しかし、一般的アプリケーションは、相対的時代をコード化して、解読する、もしくは、関係のあるカレンダーにおいて間隔を計算することができると予測されることができない。

28の多重時間軸、及び、climatologicalな時間

次元が異なる名前を持っている限り、特別な量で1を超える次元を持つ与件変数に関してバーがない。これの特別な使用は、時間を多重の部分的時間次元 ( セクション 25 ) に分解することである、の、1つ、〜もしくは、崩壊するかもしれない ( セクション 22 ) 。これは、示す方法を与える、季節的な、もしくは、昼間のサイクルの一致する部分に属する時間の間隔を解体する。変数が2もしくは3の時間軸を持っているとき、それらがカバーする時間の最初の間隔は、全ての軸の境界値を早くとも始めるために、推測される。崩壊した軸と結合して崩壊されない軸があるならば、それは、「climatologicalな時」である、軸。 例のために下の1‐理解する以上があるかもしれない。

COARDSは、climatologicalな時間を示すために、年0の使用を推薦する。我々は、この規定を支持しない。第一に、それは、年がどちらであったかが気候学を作ったものだったことを記録する方法を全く提供しない。第二に、同じであるので、udunitsは、年0、及び、年1を扱う ( 年0が役立つので、妥当である、ない、exist-thereは、1 AD、及び、1 BCの間で年ではない ) 。

一致の平均、いくつかの年の月: 含めた1990年まで1月の月の間ずっと平均を1961年に示すための時間軸を持つ経度‐緯度沈澱フィールド:

次元:
con_year=1 ;
year=30 ;
month=1 ;
変数:
precipitation ( con_year、月、lat、lon ) を呈示しなさい;
precipitation:axis="-TYX ;
precipitation:subgrid="monthcon_yearを意味しなさい:以下を意味しなさい。
int con_year ( con_year ) ;
con_year :bounds="bounds_con_year ;
con_year :expand="year ;
con_year :long_name="year ;
con_year :old_interval=1 ;
%Yとしてのcon_year:units="calendar_year ;
int bounds_con_year ( con_year、2 ) ;
int year ( year ) ;
month ( month ) を呈示しなさい;
月:bounds="bounds_month ;
月:long_name="seasonalフェーズ;
%m.%fとしてのmonth:units="calendar_month ;
bounds_month ( month、2 ) を呈示しなさい;
データ:
con_year=1975 ;
bounds_con_year=1961、1990年;
year=1961、1962年、1963年、...、1990年;
month=1.5 ;
bounds_month=1.0、2.0 ;

代表的年は、この場合特に有益でありそうにない;重要な情報は、境界である。それは、年の範囲がclimatologicalな平均を形成したものだったことを示す。参考までに、これらの年は、明白に、そして、随意に同じく与えられる。以来、con_year軸は、別個の形の時間 ( を持っている%.ftime-string-seeセクション 25 ) において我々が軸の両端を入れなければならないように思われない、成功する、何年、包含される、で、意味する: bounds_con_year双方共1961年、及び、1990年であるとみなして、1961年から1990年までの年が使われた ( 30年に達する ) と我々に告げる。

我々が1960年から1989年まで同じ与件変数にDecembers上の平均を入れることを望む、と仮定しなさい。我々は、これをするために、与える、月変数modulo=12.0f以前に必要とされなかった、次元を変える、に、month=2そして、データ、に、

month=0.5、1.5 ;
bounds_month=0.0,1.0、1.0,2.0 ;

規定によれば、結合された軸によって示された最も早期の時間は、それらの全ての更に低い境界である、0th月のスタートである、の、modulo 12の下の1960年の第12月のスタートに相当する1961年。代りに、我々、持つ、

bounds_con_year=1960,1989 ;
month=12.5、13.5 ;
bounds_month=12.0,13.0、13.0,14.0 ;

これは、正確に同等である。前と同様に、去る1月は、1990年2月のスタートである1989年の第14月の最初にエンドを使った。

平均からの行方不明の月が1974年12月にこの場合言うことを示す標準化された方法がない、を除いて、含む、con_year:old_spacing="disjoint"。その情報は、ノートとして含まれるであろう、で、サブ‐グリッド属性、このように、con_year :平均 ( 1974年12月に欠けている ) 。

数十年のClimatologicalの季節的な方法: これは、前のケース、そして、セクション 25における平均の季節的なサイクルの例の拡張である。ここで、それらの軸は、3の連続する十年に季節のうちの2つのclimatologicalな方法を示すために、セットアップされる。

次元:
decade=3 ;
season=2 ;
変数:
precipitation ( decade、季節、lat、lon ) を呈示しなさい;
precipitation:axis="-TYX ;
precipitation:subgrid="season十年を意味しなさい:以下を意味しなさい。
int decade ( decade ) ;
十年:bounds="bounds_decade ;
十年:old_interval=1 ;
%Yとしてのdecade:units="calendar_year ;
int bounds_decade ( decade、2 ) ;
int season ( season ) ;
季節:bounds="bounds_season ;
季節:calendar="standard ;
季節:modulo=1200 ;
%m%dとしてのseason:units="day ;
int bounds_season ( season、2 ) ;
データ:
decade=1966、1976年、1986年;
bounds_decade=1961,1970、1971,1980、1981,1990 ;
season=115、415 ;
bounds_season=1,228、301,531 ;

ここ、precipitation[0][0][*][*]十年1960-1970年 ( 1960年の最初の12月、1970年の去る2月 ) の12月‐2月 ( すなわち、含めた12月1日〜 2月28日 ) 、時間のデータである[ 2][1][*][* ]3月‐5月1981-1990年である。月だけよりむしろ、数ヶ月内での季節的なフェーズ、及び、日を与えるためにその選択が行われた; 従って、moduloは、12よりむしろ1200である。 modulo 1200の下で、12月1日の夜半は、1、または、1201として同等に表現され得る。 1201が指定されたならば、それは、時間の最初の間隔が1961年12月1日 ( 1960年よりむしろ ) に始まったことを意味するであろう ( 双方の時間軸の更に低い境界の結合を行って ) ; 値1は、1年前である。これの欠点%m%d計画は、特に、2月が可変長を持つので期間の半ばの正確な代表的な約束を行うことが厄介である、もしくは、不可能であることである。絶対的時間フォーマット%m.%f季節的フェーズのために、更にかなりこの見地から来た。季節軸は、円トポロジーを持つとして示されない。なぜなら、情報が他の2季節頃意味されないからだ。

6月初旬に数年の間最高気温を平均しなさい: この例において、それらの次元が示すのは、最大の毎日の温度 ( レコードの日の午前9時、及び、前日の午前9時の間に ) が6月1-10日、及び、各々の年1980-1984年にこれらの10日の間発見された平均最大のために示されたということである。

次元:
year=5 ;
con_season=1 ;
con_day=1 ;
変数:
temperature ( year、con_season、con_day ) を呈示しなさい;
temperature:axis="T、--、;、temperature:subgrid="con_day :最大のcon_season、:、意味する、;、int year ( year ) ;
年:long_name="year ;
%Yとしてのyear:units="calendar_year ;
int con_season ( con_season ) ;
con_season :bounds="bounds_con_season ;
con_season :long_name="seasonalフェーズ;
con_season :old_interval=1 ;
%m%dとしてのcon_season:units="day ;
int bounds_con_season ( con_season,2 )
con_day ( con_day ) を呈示しなさい;
con_day :bounds="bounds_con_day ;
con_day :long_name="diurnalフェーズ;
con_day :modulo=24.0f ;
%H.%fとしてのcon_day:units="hour ;
bounds_con_day ( con_day、2 ) を呈示しなさい;
データ:
year=1980、1981年、1982年、1983年、1984年;
con_season=605 ;
bounds_con_season=601、610 ;
con_day=-3.0 ;
bounds_con_day=-15.0、9.0 ;

-15 hの昼間のフェーズは、問題の日の初め、すなわち、前日の午前9時以前に15時間を意味する。バウンドは、その年の間行われない。なぜなら、それが別個の量であり、そして、加えられるであろうそれ以上の情報がないからだ。しかし、5年が共に平均してなられたならば、これは、年の軸を崩壊させるであろう、そして、1980年、及び、1984年の極端な年は、崩壊した軸の境界として記録されるであろう。約1981年が平均を形成する際使われなかったならば、崩壊した軸は、属性を持っているであろうold_spacing="disjoint。

サブ‐毎日の値の平均としての毎日の値: 瞬間的な圧力測定は、日の5月6日〜 1937年6月9日の間中の3時間 ( 夜半の最初の測定 ) の間隔で行われ、そして、毎日の方法は、夜半から夜半まで生じた。

次元:
con_subday=1 ;
day=35 ;
変数:
pressure ( day、con_subday ) を呈示しなさい;
pressure:axis="T‐;
pressure:subgrid="con_subdaycon_subdayを指し示しなさい:以下を意味しなさい。
con_subday ( con_subday ) を呈示しなさい;
con_subday :bounds="bounds_con_subday ;
con_subday :long_name="diurnalフェーズ;
con_subday :old_interval=0.125f ;
con_subday :old_spacing="uniform ;
.%fとしてのcon_subday:units="days ;
フロートbounds_con_subday ( con_subday,2 )
int day ( day ) ;
日:long_name="year、及び、季節的フェーズ;
日:%Y%m%dとしてのunits="days ;
データ:
con_subday=0.5 ;
bounds_con_subday=0.0、0.875 ;
day=19370506、19370507、...、19370608、19370609 ;

それに注目する、con_subday軸は、2つのサブ‐グリッド方法によって示される ( その崩壊の前或いはその後のサブ‐グリッド変化を参照して ) 。ここ日、及び、昼間のフェーズのために個別の軸を持つ際の唯一のポイントは、いつ全体として瞬間的測定が各日に行われたかを示すことである。これがレコードにとって重要ではないならば、2つの軸は、共にこのようにマージされるであろう:

次元:
day=35 ;
変数:
pressure ( day ) を呈示しなさい;
pressure:subgrid="day :日を指し示しなさい:以下を意味しなさい。
day ( day ) を呈示しなさい;
con_subday :bounds="bounds_day ;
con_subday :old_interval=0.125f ;
con_subday :long_name="time ;
con_subday :old_spacing="uniform ;
%Y%m%d.%fとしてのcon_subday:units="days ;
bounds_day ( day、2 ) を呈示しなさい;
データ:
day=19370506.5、19370507.5、...、19370608.5、19370609.5 ;
bounds_day=19370506.0,19370507.0、19370507.0,19370508.0、...、19370608.0,19370609.0、19370609.0,19370610.0 ;

35日がそれから共に平均してなられたならば、日付軸は、19370506.0、及び、19370610.0のバウンドと共に崩壊するであろう。 サブ‐グリッドそれが平均として既に示されるので、属性は、修正を必要としないであろう、越えて、日軸。

昼間のサイクルを平均しなさい: 次の軸は、緯度のファンクションとしての1970-1979年7月に沈澱レートの平均の昼間のサイクルに適している:

次元:
con_year=1 ;
con_month=1 ;
hour=8 ;
lat=45 ;
con_lon=1 ;
変数:
ppnrate ( con_year、con_month、時間、lat、con_lon ) を呈示しなさい;
ppnrate:axis=、--、TYX ;
ppnrate :subgrid="con_lon :con_monthを意味しなさい:平均
con_year :以下を意味しなさい。
ppnrate:units="kg m-2 s-1 ;
int con_year ( con_year ) ;
con_year :bounds="bounds_con_year ;
con_year :old_interval=1 ;
%Yとしてのcon_year:units="calendar_year ;
int bounds_con_year ( con_year、2 ) ;
con_month ( con_month ) を呈示しなさい;
con_month :bounds="bounds_con_month ;
%m.%fとしてのcon_month:units="calendar_month ;
bounds_con_month ( con_month、2 ) を呈示しなさい;
hour ( hour ) を呈示しなさい;
時間:bounds="bounds_hour ;
時間:modulo=24.0f ;
時間:topology="circular ;
%H.%fとしてのhour:units="hour ;
bounds_hour ( bounds_hour、2 ) を呈示しなさい;
データ:
con_year=1975 ;
bounds_con_year=1970、1979年;
con_month=7.5 ;
bounds_con_month=7.0、8.0 ;
hour=1.5、4.5、7.5、10.5、13.5、16.5、19.5、22.5 ;
bounds_hour=0.0,3.0、3.0,6.0、6.0,9.0、9.0,12.0、12.0,15.0、15.0,18.0、18.0,21.0、21.0,24.0 ;

与件変数における 29の無効の値

無効の値は、正当な範囲の外に落下するどれでもである、もしくは、ここで示されたUnidata‐標準属性によって示されたように、フィル値に等しい。無効の値は、悪いデータ、すなわち、ソフトウェア問題 ( 未知の、もしくは、欠けているデータ ) と異なる情況であるを示す ( セクション30を見なさい ) 。無効の値は、対等の変数において可能にされない。しかし、正当な範囲を定義する属性は、限界のないセルを示すために、境界変数 ( セクション 20 ) に使われるかもしれない。

属性のvalid_minは、変数のために最小の正当な値を指定するスカラである。属性のvalid_maxは、最大の正当な値を指定する、一方、valid_rangeは、最小の、そして最大の正当な値を指定する2つの数のベクトルである ( valid_minと、valid_max属性の両方のために値を指定することに相当するその順番に ) 。これらの属性のうちのどれでも、正当な範囲を定義する。valid_minかvalid_maxのいずれかが定義されるならば、属性のvalid_rangeは、定義されてはいけない。無効であるので、一般的アプリケーションは、正当な範囲の外で値を扱うべきである。各valid_range、valid_min、及び、valid_max属性のタイプは、その変数のタイプにマッチするべきである。Unidataの特別な処置、の、バイト我々がそのタイプの使用を推薦しないので、タイプは、ここに含まれない ( セクション3を見なさい ) 。

名前_FillValueを持つ、そして、その変数と同じタイプの段階状の属性は、変数のためのフィル値として使われる。netCDFパッケージは、各タイプの変数のためにデフォルトフィル値を定義する。従って、そのデフォルトが適当であるならば、あなた自身の_FillValue属性を定義することは、必要ではない。プログラマの好まれた値によって即座にオーバーライトされるために、フィル値の目的は、データを前‐満たすことのワークをアプリケーションプログラマにとっておくことであり、更に、複写を消去することは、その不履行と共に定義されないデータを埋めるnetCDFからの結果が値を満たすと書く。この値は、特別な値 ( 定義されないデータを示し、そして、書かれなかった値を読んでいるとき、返される ) であると考えられる。_FillValueは、変数のためのvalid_range ( 使われるならば ) によって指定された範囲の外にあるべきである。与件変数がscale_factor、及び、add_offset属性 ( セクション 32 ) を用いてパックされる場合、_FillValue属性は、適用される、数、満員であるので、従って、それらは、荷を解く前にそれと照合されなければならない。

その時valid_min、valid_max、及び、valid_rangeのうちのいずれも定義されないならば、一般的アプリケーションは、フィル値を使うことによって正当な範囲を定義するべきである ( 明白に定義されたか否かに拘らず、〜もしくは、デフォルトによって ) ;フィル値が正であり、その後、それが正当な最大を定義するならば、他の場合は、それは、正当な最小を定義する。整数タイプのために、フィル値、及び、この正当な最小、または、最大の間に1の差異があるべきである。浮動少数点のために、タイプ、正当な極端は、フィル値の大きさの半分である大きさを持っているべきである。 我々は、1ビットの差異よりむしろ2のファクタを推薦する。なぜなら、それが更にアプリケーションプログラマにとって容易であるからだ。特別な処置がない、のために、バイト我々として、そのタイプを推薦するな ( セクション3を見なさい ) 。

与件変数における 30欠測値

欠測値は、対等の変数に可能にされない。従って、このセクションは、与件変数にのみ申し込む。missing_value属性は、知られていない、もしくは、「ミスしている」データのために使われる値を示す。この属性、である、ない、_FillValue属性 ( セクション 29 ) と異なったnetCDF APIによってあらゆる特別な方法で扱われる。一般的アプリケーションが適切にそれを扱うように、missing_valueは、正当な範囲 ( セクション 29 ) の外にあるべきである。 missing_value属性のnetCDFデータタイプは、それが示す与件変数のnetCDFデータタイプにマッチするべきである。データ変数がscale_factor、及び、add_offset属性 ( セクション 32 ) 経由でパックされる場合、missing_value属性は、マッチする、タイプ、の、そして、荷を解いた後のデータと比較すると。 この標準は、特別な解釈を間に区別に与える際のCOARDSに似ていないmissing_valueそして、_FillValue。

集合による 31圧縮

netCDFファイルにおいてスペースをセーブするために、必ず欠けているデータアレイからポイントを消去することは、望ましいかもしれない。そのような圧縮は、1以上の隣接の軸に作用し得て、そして、格納されるために、ポイントのリストに関して完遂される。そのリストは、圧縮されるための軸を単に持つマスクアレイを考察し、そして、再び‐命令せずに1つの次元にこのアレイをマップすることによって組み立てられる。そのリストは、必要とされたポイントのこの一次元のマスクにおけるインデックスのセットである。圧縮されたアレイにおいて、圧縮されるための軸は、1つの軸 ( その次元が必要とされたポイントの数である ) と全て交換される。必要とされたポイントは、同じ順番 ( それらが飛ばされた不必要なポイントを持つ圧縮されないアレイに現れる ) にこの次元に沿って現れる。圧縮、及び、展開は、リスト上で輪になることによって実行される。

そのリストは、データアレイの圧縮された軸のための対等の変数として格納される。このように、リスト変数、及び、その次元は、同じ名前を持っている。圧縮されないアレイのCDL宣言のオーダにおける圧縮によって影響を受けた次元のブランクに分離されたリストを含んで、リスト変数には、ストリング属性のコンプレスがある。この属性の存在は、そういうものとしてリスト変数を確認する。リスト、オリジナルの次元、及び、対等の変数 ( コンポーネント、関連する、そして、境界変数を含むこと ) 、及び、圧縮されない変数の全ての属性を持つ圧縮された与件変数は、archiv‐されたnetCDFファイルに書き込まれる。それらの本源的変数名前が知られていないということを除けば、それらがこの情報を使っていたので、圧縮されない与件変数は、正確に再構成され得る。

三次元のアレイの水平の圧縮: 我々は、longitude-latitude-depth一連の土温度において全ての深さの海ポイントを消去する。この場合、経度、そして、緯度軸のみが、圧縮によって影響を受けるであろう。我々は、リストを組み立てるlandpoint ( landpoint ) 土地のインデックスを含むことは、指し示す。

次元:
lat=73 ;
lon=96 ;
landpoint=2381 ;
depth=4 ;
変数:
長いlandpoint ( landpoint ) ;
landpoint:compress="lat lon ;
landsoilt ( depth、landpoint ) を呈示しなさい;
landsoilt :axis="Z‐;
landsoilt :long_name="soil温度;
landsoilt:units="K ;
depth ( depth ) を呈示しなさい;
lat ( lat ) を呈示しなさい;
lon ( lon ) を呈示しなさい;
データ:
landpoint=363、364、365、... ;

それ以来ずっとlandpoint[0]=363例えば、我々は、それを知っているlandsoilt[*][0]次元を持つオリジナルのデータのポイント363のマップ( lat、lon ) 。これは、インデックスと一致する[ 3][75 ]。

三次元のフィールドの圧縮: 我々は、海底の下方でポイントを消去することによって大洋塩分のlongitude-latitude-depthフィールドを圧縮する。この場合、連続して深さを増大させる際の活動的な大洋ポイントがほとんどないので、全ての3つの次元は、圧縮によって影響を受ける。

変数:
salinity ( oceanpoint ) を呈示しなさい;
salinity:axis="‐;
長いoceanpoint ( oceanpoint ) ;
oceanpoint:compress="depth lat lon ;
depth ( depth ) を呈示しなさい;
lat ( lat ) を呈示しなさい;
lon ( lon ) を呈示しなさい;

この情報は、塩分フィールドが次元を持つアレイに圧縮されるべきでないと意味する( 深さ、lat、lon ) 。

スケール、及び、オフセットを使う 32圧縮

この標準は、データ、及び、対等の変数のための任意のUnidata‐標準属性のscale_factor、及び、add_offsetの用途を支持する。これらの属性は、netCDFファイルにおける小さい整数としてのストア低い‐解像度浮動少数点データへのシンプルな番号圧縮 ( パッキング ) を行うために使われ得る。データの後では、変数の値は、読まれた、で、それらは、scale_offsetを掛けられるべきであり、そして、add_offsetを加えられた状態にする ( それらに ) 。 scale_factorと、add_offset属性の両方が存在するならば、そのオフセットが加えられる前に、データは、一定の基準で決められる。測定されたデータが書かれるとき、そのアプリケーションは、最初にオフセットを減じ、その後、倍率によって分かれるべきである。この手続きは、記憶装置にのみ関係する。それは、量のユニットに影響を及ぼさない。 For instance, a pressure variable with values in the range 900.0-1100.0 Pa could be converted to short integers in the range ｱ 20000 by subtracting 1000 and dividing by 0.005 i.e. multiplying by 200. 圧縮された変数のユニットは、まだパスカルとして記録される。

この標準は、netCDF User Guideよりscale_factor、及び、add_offset属性の使用に関して更に制限的である;データタイプ変換に関係した曖昧性、及び、精度問題は、これらの制限によって解決される。scale_factor、及び、add_offset属性が関連する変数と同じデータタイプであるならば、制限は、適用されない;取り出されたデータは、満員のデータと同じデータタイプであるために、推測される。しかしながら、scale_factor、及び、add_offset属性がファイルの付着における変数 ( 満員のデータを含むこと ) その時からこの標準まで異なるデータタイプであるならば、その変数は、ただ急にタイプである、または、長いかもしれない。我々、除外する、バイトセクション 3で論じられたオングラウンド。属性のscale_factor、及び、add_offset ( データタイプとマッチしなければならない ) は、タイプフロート、または、ダブルでなければならない。属性のデータタイプは、意図したタイプの取り出されたデータにマッチするべきである。( 潜在的な精度損失があるので、余裕時間まで先物株を取り出すことが勧められない。 ) ユーザーは、Unidataが今後はデータをnetCDFファイルにパックする本来の方法を提供するかもしれないことに注目するべきである。

A属性

Tは、ストリング、数値のためのNのためにSである。

使用は、対等の変数 ( マルチ‐寸法の対等の変数を含むこと ) のためのグローバルなCのためのG、与件変数のためのDから成る。

サブ‐グリッド変化を表す B方法

セクション 21を見る。

ユニット:uは、サブ‐グリッド変化がこの方法で表される量のユニットを意味する。

udunits.datへの C修正

セクション 11を見る。

ユニット統一は、1まで次元がない一定の同格者と定義される。

ユニット程度、可能にされない、‖ ( 経度、及び、緯度の対等の変数を区別しようと試みているとき、それが曖昧性を作成するので ) 。このユニットは、ファイルの現在のバージョンに現れない。

ユニットcalendar_month、及び、calendar_yearは、単位時間である。しかし、12暦月の倍数が暦年の必須の数に等しいということを除けば、相互、及び、他の単位時間に変換されることができない。ユニット年、及び、月は、許されない。なぜなら、それらが混乱を引き起こすことができるからだ。

量のための Dの長い名

セクション 12を見る。このAppendixは、まだ利用可能ではない。この標準の一部として存在することのように、それは、ウェブ上で利用可能にされるであろう。

バージョン:この量が導入されたアペンディクスのバージョン。
long_name :ケース、スペース、及び、句読点は、long_nameにおいて有意ではない。

LLNLの注意書き

UCRL-MI-127703