| 1997年12月4日, | バージョン1.0 |
| 1996年11月10日, | 最初のドラフト |
このドキュメントは、 NCAR Climate Systemsモデルの出力datasetsのために採用されたnetCDF規定の記述を含む。その規定は、gridd‐された地球物理学のデータの表現のために設計される。
規定の重要な潜在的な利益は、それがデータを表示するソフトウェアツールを可能にし、そして、最小のユーザー介入によってそれらのタスクをするためにデータの指定されたサブセットに対する手術を行うことができることである。いかにフィールドが時間通りに位置しているかを示すmetadata、及び、多くの異なる方法 ( 人間のリーダが等価物であると即座に承認するであろう ) におけるスペースを供給することは、netCDFを用いて可能である。metadataが表される制限における目的は、それが機械を許すソフトウェアを書くのを実用的にすることである、数字にできる、離れたところを、もの、データ、行く、人間の介入の必要性なしで。我々が課すメイン制限は、対等の変数、及び、いくらかの変数属性の使用を必要とすることである。制限は、変数の次元のオーダに置かれない。
対等の変数の使用が1Dスペースと一致する全ての次元のために必要とされる、もしくは、時間は、調和する。 NetCDF UserのGuideのセクション2.3.1において定義された対等の変数がただ直線のグリッドを描くことに十分であるので、我々は、不規則なグリッド上のデータを扱うために、下の座標属性を定義する。
ユニット属性が座標を示すために使われる全ての変数のために、そして、それが適切である全ての他の変数のために必要とされる。ユニット属性の値は、UNIDATAの udunitsパッケージによって可能ならいつでも認識されるキャラクタアレイである。例外は、ユニット「degree ( s ) 」が許されないことである。この規定は、ある情況 ( udunitsの一致した値が存在しない ) に使われるために、ユニット属性のいくらかの新しい値を示す。
グローバルな属性のタイトル、ソース、及び、歴史は、データが何であるか、それがどこから来たか、そして、何がそれに与えられたかの最小の記述をするのに必要とされる。
Conventions属性は、このドキュメントのロケーションを確認するのに必要とされる。
上でリストされた必要とされた特徴に加えて、いくらかの因習は、スペース、かつ、または、時間において間隔にわたるフィールドの特性のgridd‐されたデータの記述 ( ポイント‐にフィールドの値を表さない、しかし、むしろいくらかを表す ) に役立つために、作られた。これの一般の例は、時間がデータを平均したことである。
この規定は、 COARDS規定によって著しく影響された。COARDSではないファイルにおいて生じるかもしれない差異、従順な、下記である:
1 ) COARDSは、変数の次元のオーダを制限する。I/Oパフォーマンス考察事項のために、全てのCSMコンポーネントモデルがCOARDS要求への類似においてそれらのデータをアウトプットすることは、望ましくないかもしれない。この規定は、制限を次元のオーダに置かない。
2 ) COARDSは、次元がない垂直の座標の問題に取り組む。しかし、我々の目的のために十分に一般的である会議を行わない。そうしたい、使用する、ユニットどのように緯度、及び、経度のためのCOARDS規定がunambiguouslyに設置するためのものを許しても、類似的に垂直の座標をスペースに設置することができるための属性は、水平面において指し示す。次元がない座標の場合は、ある規則は、寸法と共に1つに変わるのに必要とされる。特別な座標に応じて多くの可能な規則があるので、我々は、値を必要とする、の、ユニット各々に特有であるために、システムを統合しなさい。このように、我々は、あまりにも漠然としているとして「レベル」、及び、「層」を拒絶する。「sigma_level」は、次元がない座標の特別なタイプを示す ( CSMの大気のコンポーネントに使われるものではなく ) 。我々が次元がない垂直の座標のために追加の規定に供給する下記ユニット属性。
3 ) COARDSは、ハイフンキャラクタの使用を含まないことによるnetCDFインタフェースによって許された名前を制限し、そして、それを推薦することによって、名前は、ケースである、無感覚な。我々は、ハイフンキャラクタを使わないことが更に良いということに同意する。しかし、netCDFインタフェースによって推測されるように、ケースの敏感な名前が許されるべきであると考える。
NCAR-CSM規定は、COARDSより一般的である。netCDFファイル ( NCAR-CSMと、COARDSの両方と共に従順である ) を書くことは、可能である。しかし、NCAR-CSM規定は、COARDSであることに、ファイルを制限しない、従順な。
long_name属性が全ての変数のために必要とされる。その値は、長い記述的名前を含むキャラクタアレイである。
ユニット属性が座標を示す全ての変数のために、そして、値が寸法の量を表す全ての他の変数のために必要とされる。ユニット属性の値は、可能ならいつでも udunitsで識別されるキャラクタアレイである。ユニットdegree ( s ) は、許されない ( 経度、及び、緯度の適切なユニットのためのセクション2.3.4、及び、2.3.5を見なさい ) 。udunitsは、パーセント、ppb、及び、小数のような次元がない量のために仕様を持っていない。我々は、それを推薦する、ユニット属性、まだ使われる、しかし、示すためのそれらを除いて次元がないspecifiersを全く標準化しなかった、垂直の、下のセクション2.3.3において定義されたように、調和する。
タームの対等の変数は、直線のグリッドで座標を述べるために使われる1Dアレイであるために、netCDF User Guideで定義される。この規定は、そのセンスにタームの対等の変数を使う。非直線のとき、グリッドは、使われ、その後、対等の情報は、対等の変数モデルに合わない更に高い次元アレイを用いて表されなければならない。座標属性が下で導入されるこの場合を扱うために。ターム座標は、属的に1Dかマルチ‐寸法のケースのいずれかを参照するために使われるであろう。
対等の変数の使用が1Dアレイとして表明され得る全てのスペース、もしくは、時間座標のために必要とされる。
対等の変数の値は、厳格に増加する、もしくは厳格に減少するどちらでもでなければならない。それらの値は、均等にスペースを開ける必要がない。欠測値は、可能にされない。マルチ‐寸法のコーディネートは、_FillValueを使うかもしれない、もしくは、格子がそれを指し示すことを示すためのmissing_value属性は、使われない、<例>、減少したグリッドにおいて、緯度サークルでの経度の数が緯度としてどこへ減少するかは、更にポールに近くなる。
ユニット属性がスペース全てのために必要とされ、そして、時間は、調和する。この要求の理由は、それである、ユニット属性は、どんなタイプの座標軸が変数の次元の各々と一致するかを確認するためのアプリケーション ( 恐らくは他のmetadataと共に ) によって使われ得る。この対応は、制限を次元注文に置くことによって確立される必要がない。
我々は、udunitsドキュメンテーションから次の修正された抜粋と同様に udunitsによって文法的に説明可能であるために当面のユニットが調和することを必要とする:
1992-10-8 15:15:42.5 -6:00以来の日
Coordinated Universal Time (
すなわち、山地夏時間 )
の西に6時間である時間帯で3時間、15分、及び、42.5秒の1992年10月8日以来日を午後示す。時間帯仕様書は、同じく1つ、または、2桁 ( 時間を示すこと
) 、または、3、または、4桁 ( 時間、及び、分を示すこと )
を使うコロンなしで書かれ得る。
時間の受け入れられるユニットは、ファイルudunits.datにリストされる。これらのストリング (
そして、それらの省略形 ) の最も一般に中古のは、日の ( d ) 、時間 ( hr、h ) 、瞬間 ( min )
、及び、瞬間 ( sec、s )
を含む。複数形は、同じく受け入れられる。日付ストリングは、単独で日付を含むかもしれない;日付、及び、時間;或いは、日付、時間、及び、時間帯。日付ストリングが必要とされる。
我々は、ユニット年が慎重に使われることを勧める。udunitsパッケージは、ちょうど365.242198781日 ( 春分の間の太陽の2本の連続する通路の間の間隔 ) であるために、1年を定義する。それは、暦年ではない。Udunitsは、何年間も次の定義を含む:common_yearは、365日であり、leap_yearは、366日であり、Julian_yearは、365.25日であり、そして、Gregorian_yearは、365.2425日である。
udunitsパッケージによって行われたカレンダー計算は、混ざったグレコリー暦/ユリウス暦を用いる、すなわち、1582-10-15の前の日付は、ユリウス暦を用いるために、推測される。他のカレンダーを使う時間座標は、このようにこの目的のためにudunitsライブラリを利用することができない。しかしながら、これがいったん、そのカレンダーが指定されたならば、カレンダー計算を行うのに必要とされる情報全てを含むので、上で示された時間単位フォーマットを使うことがまだ必要とされる。我々は、この目的のために使われるかもしれない下の時間の対等の変数のためにカレンダー属性について述べる。
climatologicalな時間 ( 12ヶ月の軸、4季節等、それは、特別な年なしに位置している ) を表す対等の変数は、加えられた制限 (
その年0000において始めるためにそれらがコード化される )
を伴ってはいるが他の時間軸のようにコード化されるべきである。例えば
0000-06-15 00:00
0以来の日
6月15日にスタートするモデル実行の初め、0Z以来日を示す。
時間座標は、paleoclimate研究のために使用した、私の、それらと異なる軌道のプレゼントのパラメータに基づくカレンダーを包含する。このケースの追加の情報において、カレンダーに含まれるそれの他に、属性が必要とされるかもしれない。軌道のパラメータの記述は、下で示された属性のorbital_parametersを使うことによって含まれるかもしれない。カレンダーの完全な記述は、グローバルな属性のdefine_calendarを用いて含まれるかもしれない。
寸法の垂直の ( 深さ、または、高さ ) 対等の変数のための受け入れられるユニットは、以下である。
1 ) ファイルudunits.datにリストされた圧力のユニット。これらの最も一般に中古のが含む縦軸のために、バー、ミリバール ( mbar ) 、decibar ( dbar ) 、空気 ( atm ) 、パスカル ( ペンシルバニア ) 、及び、hPaを含みなさい。
2 ) ファイルudunits.datにリストされた長さのユニット。縦軸のために、これらの最も一般に中古のは、メータ ( メータ、m ) 、センチメートル ( cm ) 、デシメートル ( dm ) 、キロメートル ( km ) 、及び、足 ( ft ) を含む。
3 ) 他のユニットは、傾いた、ファイルudunits.dat、それ、密度、または、温度のユニットのようなある情況参照の垂直のポジションの下で。
複数形は、同じく受け入れられる。
正 ( すなわち、方向、で、調和する、増加する ) の方向、かどうか、上を、もしくは、下を、全てにおいて、ケースは、ユニットから推論される。正の方向は、データを表示するアプリケーションにとって有益である。この理由のために、縦軸ユニットが圧力の正当なユニットではないならば、COARDS規定において定義された属性の正が必要とされる。他の場合は、その包含は、任意である。正の属性には、その価値がある、もしくは、下るかもしれない ( ケース、無感覚な ) 。
例えば、oceanographicなnetCDFファイルが表面の深さをコード化するならば、1000、そして、軸と同じくらい0、及び、1000メートルの深さは、次のとおりに属性を使うであろう:
axis_name:units="meters ;
axis_name:positive="down ;
〜ならば ( 一方
)
1000メートルの深さ、-1000として表明された、それから、正の属性の値は、アップしたであろう。ユニット属性の値が正当な圧力ユニットであるならば、正の属性のデフォルト値は、下がっている。
垂直の対等の変数が圧力のユニットを持つことによって或いは値を持つ正の属性の存在によって同定し得るであろうという通知、の、アップして、以下 ( ケース、無感覚な ) 。
次元がない垂直の座標のために、我々は、空間的にデータを設置するのに必要とされる一致する寸法の座標の計算を促進するように設計されている因習を導入する。示された次元がない垂直の座標の各々のために、CDLにおける規定の例より下で、表記法は、名前zを持つ次元のために与えられる。
1 ) ハイブリッドシグマ圧力。
z ( z ) を呈示しなさい;
z :long_name
=、「層中間点のハイブリッドレベル」;
z :ユニット=「hybrid_sigma_pressure」;
z :以下の下方の正の=。
z
:A_var =「hyam」;
z :B_var =「hybm」;
z :P0_var =「pref」;
z:PS_var
=「psurf」;
hybrid_sigma_pressureのユニット属性は、それを意味する、gridpoint
( x ( i ) の圧力、y ( j ) 、z ( k ) ) は、p ( iによって与えられる、j、k ) = A ( k ) *PO + B ( k )
*PS ( i、j )
、変数名、Aのために、B、P0、及び、PSは、与えられる、によって、属性のA_var、B_var、P0_var、及び、PS_var、各々。
2 ) シグマ。
z ( z ) を呈示しなさい;
z :long_name =、「層中間点のシグマレベル」;
z
:ユニット=「sigma_level」;
z :以下の下方の正の=。
z :B_var =「z」;
z :P0_var
=「ptop」;
z:PS_var
=「psurf」;
sigma_levelのユニット属性は、それを意味する、gridpoint
( x ( i ) の圧力、y ( j ) 、z ( k ) ) は、p ( iによって与えられる、j、k ) = P0 + B ( k ) * ( PS (
i、j ) -P0 ) 、変数名、Bのために、P0、及び、PSは、与えられる、によって、属性のB_var、P0_var、及び、PS_var、各々。
我々は、dimensionlessから変換のためにそれに規則を推薦する、に、寸法がある、調和する、名前が同じであるグローバルな属性として含まれる、〜同じくらい、ストリングdefine_を持つユニットspecifierのそれは、prependedした。ここにCCM3の垂直の座標のために例がある:
//グローバルな属性:
以下。define_hybrid_sigma_pressure = \n、グリッドポイント ( lon ( i )
、lat ( j ) のPressure、式を使って、lev ( k ) ) が\nであると算定される:\n、p ( i、j、k ) = A ( k ) *PO
+ B ( k ) *PS ( i、j )
\n、どこにA、B、PO、及び、PSが変数に含まれるか、誰の、\n、名前は、与えられる、によって、垂直の対等の\n、変数A_var、B_var、P0_var、及び、PS_var
respectively. \nの属性、
"" ;
緯度の推薦されたユニットは、degrees_northである。同じく受け入れられる、degree_north、degree_N、及び、degrees_Nである。
経度の推薦されたユニットは、degrees_east ( 東の正 ) である。同じく受け入れられる、degree_east、degree_Eである、そして、degrees_E。ユニットdegrees_west ( 西に向かう正 ) は、推薦されない。なぜなら、それがdegrees_eastから負の転換比を意味するからだ。
経度は、表されたmodulo 360であるかもしれない。このように ( 例えば ) 、-180、180、及び、540は、インターナショナルDatelineの全ての正当な表現であり、そして、0、及び、360は、Prime Meridianの双方の正当な表現である。netCDFファイルに格納される数値経度値のシーケンスが非‐moduloセンスにおいてモノ‐強壮にしなければならないことにしかしながら注目しなさい。
マルチ‐寸法の変数が座標を示すのに必要とされるとき、座標属性の使用によって調和するように、これらの変数は、確認される。属性の値は、座標系を示す変数の名前を含むストリングである。フィールド変数のために次元があるので、同数座標が少なくともなければならない。しかしながらスペースを経て軌道に沿って定義されたフィールドを描写することの場合のように更に多くがあるかもしれない。
CDL表記法における例:
1 ) 緯度、及び、経度は、2D変数を必要とする双方共統合する:
次元:
nlon = 128 ;
nlat = 64
;
lev = 18 ;
変数:
lon ( nlat、nlon ) を呈示しなさい;
lon:long_name
=「経度」;
lon:units =「degrees_east」;
lat ( nlat、nlon )
を呈示しなさい;
lat:long_name =「緯度」;
lat:units =「degrees_north」;
lev ( lev )
を呈示しなさい;
lev:long_name =「レベル」;
lev:units =「mbar」;
T ( lev、nlat、nlon )
を呈示しなさい;
T:long_name =「温度」;
T:units =「K」;
T:coordinates =「lon lat
lev」;
Tの座標属性は、グリッドが指し示す ( i , j , k ) ことをあなたに示す、位置している、際 ( lon ( i , j )
、lat ( i、j ) 、z ( k ) ) ( in FORTRAN index conventions )
。物理的スペースにおけるこのポジションのロケーションは、座標の解釈によってそれ自身で決定される。これのために、対等の名前が対等の属性のストリングに現れるオーダに対する制限がない。垂直の座標が対等の変数を使うのに必要とされることに注目しなさい。
2 ) 経度の対等の必要としている2D変数、及び、欠測値:
次元:
nlon = 128 ;
lat = 64
;
変数:
lon ( lat、nlon ) を呈示しなさい;
lon:long_name =「経度」;
lon:units
=「degrees_east」;
lon:_FillValue = -999.f ;
lat ( lat )
を呈示しなさい;
lat:long_name =「緯度」;
lat:units =「degrees_north」;
PS ( lat、nlon
) を呈示しなさい;
PS:long_name =「表面の圧力」;
PS:units =「Pa」;
PS:coordinates =「lon
lat」;
PS:_FillValue =
1.e36f
2D経度座標が示すのは、経度値が緯度によって変わるということである、そして、欠測値がある。緯度に関する経度ポイントの数がポールの方へ向かう減少を囲むグリッドを使っているとき、これは、状況である。
3 ) 軌道:
次元:
時間= 1000 ;
変数:
lon ( time )
を呈示しなさい;
lon:long_name =「経度」;
lon:units =「degrees_east」;
lat ( time )
を呈示しなさい;
lat:long_name =「緯度」;
lat:units =「degrees_north」;
z ( time )
を呈示しなさい;
z:long_name =「レベル」;
z:units =「km」;
z:positive =「up」;
time (
time ) を2倍にしなさい;
時間:long_name =「時間」;
time:units =、「1970-01-01
00:00:00以来の日」;
time:calendar =「gregorian」;
O3 ( time )
を呈示しなさい;
O3:long_name =「オゾン集中」;
O3:units =「ppbv」;
O3:coordinates =「lon
lat z時間」;
必要とされたグローバルな属性は、データがどこから起こったかに関する情報、及び、それに与えられたものを提供することを意図している。この情報は、主として人間のリーダのためである。これらの属性は、全てのキャラクタアレイである。ncdump出力における読み易さのために、それらをラインに分割するために、newlineキャラクタをアレイに埋め込むということが勧められている。
順番に、基準日、基準時間、及び、時間増分ものを与えられた新しい日付、及び、時間を計算することは、どのようなカレンダーを使うかを知らなければならない。この目的のために、我々は、そのユニットが基準日、基準時間以来のフォーム時間単位であるときはいつでも、属性のカレンダーが時間座標 ( 或いは、グローバルである ) に割り当てられることを勧める。現在カレンダーのために定義された値は、以下である。
グリッド上のデータがあるフィールド変数のポイント値を表さない、しかし、その代りにスペース、かつ、または、時間の間隔にわたるフィールド ( すなわち、いくらかの数学的オペレーションの結果は、フィールド値に関して成し遂げた ) に特有のいくらかを表すことは、しばしばそのケースである。典型的に、これは、加重平均であろう、もしくは、おそらく、最小、または、最大は、過剰を評価する、間隔。従って、我々は、述べるのに方法を必要とする、間隔にわたるフィールドの特性と、それらの間隔がそうであるものの両方、グリッドポイントに一致する。
間隔の間ずっとフィールドの特性を表すために、我々は、フォームcoord_opの属性を導入する、そして、そこで、ストリングcoordは、座標の現実の名前、例えばlat_op、または、time_opと交換されるべきである。これらの属性の値は、キャラクタアレイ
( 一致の際行われたオペレーションを示す ) が調和することである。現在定義された値は、以下である。
「ポイント」-値は、ポイントにある (
デフォルトが指定される必要がない )
最大の間の間隔「rms」 ( 間隔範囲に関する値の平方平均 ) 差異に関する値の間隔「和」 (
間隔平均に関する値の和 ) 平均に関する値、及び、間隔にわたる最小値の「最小の」 ( 間隔最大に関する値の最小 )
最大
coord_op属性は、個々の変数に適用されるかもしれない、もしくは、グローバルであるかもしれない、そのオペレーションが使用する全ての変数に適用されたと意味する、示される、調和する。coord_opがグローバルな属性であるならば、グローバルな属性の値をオーバライドすることは、まだ変数に応用されているかもしれない。
間隔を表すために、我々は、適切なものへの属性の限度が調和する、とつけ加える。限度の値は、間隔境界を含む変数の名前である。どこでそのグリッドが対等の変数によって定義されるか、そして、どこでそれらの間隔が接触しているかという場合において、これは、次元サイズが一致する対等の変数の次元サイズより1つ更に大きい変数であり得る。対等の変数の間の関係、意見x、及び、間隔限度を含む変数は、x_boundが値x ( i ) が境界x_bound ( i ) 、及び、x_bound ( i+1 ) を持つ間隔に含まれることである、と述べている。それらの間隔がどこにあるであろうかという更に一般的な場合 ( 静かな1D ) において、解体する、〜もしくは、恐らくはオーバーラップする、それから、限度を含む変数は、第2次元 ( C表記法において ) によって2Dである、である、一致する対等の変数の次元としての同じサイズ。この場合、その関係は、値x ( i ) が境界x_bound ( 0、i ) 、及び、x_bound ( 1を持つ間隔、i ) に含まれることである。
CDL表記法における例:
1 ) 時間は、変数、接触している間隔を平均した:
次元:
time_bound = 4 ;
時間= 3
;
変数:
time ( time ) を2倍にしなさい;
時間:long_name =「時間」;
time:units
=、「1970-01-01 00:00:00以来の日」;
time:calendar =「gregorian」;
time:bounds
=「time_bound」;
time_bound ( time_bound ) を2倍にしなさい;
time_bound :long_name
=「時間間隔境界」;
time_bound:units =、「1970-01-01 00:00:00以来の日」;
gaTS ( time )
を呈示しなさい;
gaTS:long_name =「グローバルな平均の表面の温度」;
gaTS:units =「K」;
gaTS
:time_op =「平均」;
データ:
時間= .25、.5、.75 ;
time_bound = 0.、.25、.5、.75
;
変数gaTSは、6時間時間平均を表す。最初サンプルは、1970-01-01
0Zの時間の平均起動、及び、1970-01-01 6Zの結末と一致する。時間座標の値は、一致する平均値算出の間隔の終りに任意に設定される。
2 ) 時間は、変数を平均した、間隔を解体する:
次元:
d2 = 2 ;
時間= 3 ;
変数:
time (
time ) を2倍にしなさい;
時間:long_name =「時間」;
time:units =、「1970-01-01
00:00:00以来の日」;
time:calendar =「gregorian」;
time:bounds
=「time_bound」;
time_bound ( d2、時間 ) を2倍にしなさい;
time_bound :long_name
=「時間間隔境界」;
time_bound:units =、「1970-01-01 00:00:00以来の日」;
gaTS ( time )
を呈示しなさい;
gaTS:long_name =「グローバルな平均の表面の温度」;
gaTS:units =「K」;
gaTS
:time_op =「平均」;
データ:
時間= 31.、396.、761。以下。
time_bound ( 0 , * ) = 0. ,
365. , 730 .以下。
time_bound ( 1 , * ) = 31. , 396. , 761
.以下。
変数gaTSは、1971年1月、及び、1972年の間毎月の時間平均を表す。
あるタイプのnetCDFの対等の変数へのマップではなく、それをする次元のために会議を採用することは、有益である、全く一般的な順序の次元ではない。例えば、我々は、特別な島、または、大洋鉢と関連していたある量をセーブする。ここで、対等の値は、netCDF座標として使われることができない島、もしくは、鉢名前を含むキャラクタストリングである。1つは、キャラクタストリング変数
( 一致するdimensions. e.gにこれらの値を結び付けるために、接続された_labelと共に次元と同じ名前を持つ
) を使うことができる、
次元:
時間=、無制限の;// ( 12、現在 ) z_t = 45 ;
nchar = 132
;
島= 8 ;
鉢= 8 ;
変数:
time ( time ) を2倍にしなさい;
時間:long_name
=「時間」;
time:units =、「0000-00-00 00:00:00以来の日」;
z_t ( z_t ) を呈示しなさい;
z_t
:long_name =「深さ ( Tグリッド ) 」;
z_t :ユニット=「センチメートル」;
以下の下方のz_t:positive
=。
islands_label ( islands、nchar ) を焦がしなさい;
islands_label:long_name
=「島」;
basins_label ( basins、nchar ) を焦がしなさい;
basins_label:long_name
=「大洋鉢」;
T_horz ( time、鉢、z_t ) を浮かべなさい;
T_horz :long_name
=「水平の平均の潜在的な温度」;
T_horz:units =「celsius」;
pisle ( time、島 )
を呈示しなさい;
pisle :long_name =「島Streamfunction」;
pisle:units
=「centimeters^3/瞬間」;
我々は、USGSソフトウェアパッケージ projをcartographicな投射のためのリファレンス・インプリメンテーションとして推薦する。これは、projが投射のためにパラメータインタフェース、及び、変化行動を定義することを意味する。あなたは、自由にprojと一致するあらゆるインプリメントを使うことができるのだが。投射を定義するために、我々は、従って属性のproj_parameters ( その値が投射をprojソフトウェアに示すために使われるであろうストリングである ) を使うことを勧める。 projソフトウェアは、ユーザーのマニュアル ( 強調されたprojストリング、その後、強調されたストリングPROJ.4.3.ps.gzをクリックすることによって見られるかもしれない ) で述べられる。
CDL表記法における例:
1 ) メルカトル図法、90Wの中央子午線。
次元:
x = 128 ;
y = 64 ;
z = 18 ;
時間=
100 ;
変数:
x ( x ) を呈示しなさい;
x:long_name =は、「x‐調和する」;
x:units
=「km」;
y ( y ) を呈示しなさい;
y:long_name =は、「y‐調和する」;
y:units =「km」;
z (
z ) を呈示しなさい;
z:long_name =「レベル」;
z:units =「km」;
z:positive
=「up」;
time ( time ) を2倍にしなさい;
時間:long_name =「時間」;
time:units
=、「1970-01-01 00:00:00以来の日」;
time:calendar =「noleap」;
U ( time、z、y、x )
を呈示しなさい;
U:long_name =「帯の風コンポーネント」;
U:units =「m/s」;
U :proj_coordinates
=「x y」;
//グローバルな属性:
:proj_parameters =「+proj=merc
+lon_0=90W」;
その投射がprojソフトウェアにおいて発見されず、その後、どこで記述が発見され得るかに、完全な記述、または、参照を供給するために属性のdefine_projectionを使うならば。
我々は、変数属性のflux_directionを用いて全てのフラックス量の方向を明白にすることを勧める。それらの値は、方向であるべきである、のような、アップして、下を、北南、東、または、西。