A variable’s spatiotemporal dimensions are used to locate data values in time and space. This is accomplished by associating these dimensions with the relevant set of latitude, longitude, vertical, and time coordinates. This section presents two methods for making that association: the use of coordinate variables, and the use of auxiliary coordinate variables.
All of a variable’s dimensions that are latitude, longitude, vertical, or time dimensions (see [terminology]) must have corresponding coordinate variables, i.e., one-dimensional variables with the same name as the dimension (see examples in [coordinate-types]). This is the only method of associating dimensions with coordinates that is supported by [COARDS].
All of a variable’s spatiotemporal dimensions that are not latitude,
longitude, vertical, or time dimensions are required to be associated
with the relevant latitude, longitude, vertical, or time coordinates via
the new coordinates attribute of the variable. The value of the
coordinates attribute is a blank separated list of the names of
auxiliary coordinate variables. There is no restriction on the order
in which the auxiliary coordinate variables appear in the
coordinates attribute string. The dimensions of an auxiliary
coordinate variable must be a subset of the dimensions of the variable
with which the coordinate is associated, with two exceptions. First,
string-valued coordinates ([labels]) have a dimension for maximum
string length. Second, in the ragged array representations of data
([discrete-sampling-geometries]), special methods are needed to
connect the data and coordinates
We recommend that the name of a multidimensional coordinate variable should not match the name of any of its dimensions because that precludes supplying a coordinate variable for the dimension. This practice also avoids potential bugs in applications that determine coordinate variables by only checking for a name match between a dimension and a variable and not checking that the variable is one dimensional.
The use of coordinate variables is required whenever they are applicable. That is, auxiliary coordinate variables may not be used as the only way to identify latitude and longitude coordinates that could be identified using coordinate variables. This is both to enhance conformance to COARDS and to facilitate the use of generic applications that recognize the NUG convention for coordinate variables. An application that is trying to find the latitude coordinate of a variable should always look first to see if any of the variable’s dimensions correspond to a latitude coordinate variable. If the latitude coordinate is not found this way, then the auxiliary coordinate variables listed by the coordinates attribute should be checked. Note that it is permissible, but optional, to list coordinate variables as well as auxiliary coordinate variables in the coordinates attribute.
If an axis attribute is attached to an auxiliary coordinate variable, it can be used by applications in the same way the axis attribute attached to a coordinate variable is used. However, it is not permissible for a data variable to have both a coordinate variable and an auxiliary coordinate variable, or more than one of either type of variable, having an axis attribute with any given value e.g. there must be no more than one axis attribute for X for any data variable. Note that if the axis attribute is not specified for an auxiliary coordinate variable, it may still be possible to determine if it is a spatiotemporal dimension from its own units or standard_name, or from the units and standard_name of the coordinate variable corresponding to its dimensions (see [coordinate-types]). For instance, auxiliary coordinate variables which lie on the horizontal surface can be identified as such by their dimensions being horizontal. Horizontal dimensions are those whose coordinate variables have an axis attribute of X or Y, or a units attribute indicating latitude and longitude.
If the coordinate variables for a horizontal grid are not longitude and latitude, it is recommended that they be supplied in addition to the required coordinates. For example, the Cartesian coordinates of a map projection should be supplied as coordinate variables in addition to the required two-dimensional latitude and longitude variables that are identified via the coordinates attribute. The use of the axis attribute with values X and Y is recommended for the coordinate variables (see [coordinate-types]).
It is sometimes not practical to specify the latitude-longitude location of data which is representative of geographic regions with complex boundaries. For this purpose, provision is made in [geographic-regions] for indicating the region by a standardized name.
When each of a variable’s spatiotemporal dimensions is a latitude, longitude, vertical, or time dimension, then each axis is identified by a coordinate variable.
dimensions:
lat = 18 ;
lon = 36 ;
pres = 15 ;
time = 4 ;
variables:
float xwind(time,pres,lat,lon) ;
xwind:long_name = "zonal wind" ;
xwind:units = "m/s" ;
float lon(lon) ;
lon:long_name = "longitude" ;
lon:units = "degrees_east" ;
float lat(lat) ;
lat:long_name = "latitude" ;
lat:units = "degrees_north" ;
float pres(pres) ;
pres:long_name = "pressure" ;
pres:units = "hPa" ;
double time(time) ;
time:long_name = "time" ;
time:units = "days since 1990-1-1 0:0:0" ;
xwind(n,k,j,i) is associated with the coordinate values lon(i), lat(j), pres(k), and time(n).
The latitude and longitude coordinates of a horizontal grid that was not defined as a Cartesian product of latitude and longitude axes, can sometimes be represented using two-dimensional coordinate variables. These variables are identified as coordinates by use of the coordinates attribute.
dimensions:
xc = 128 ;
yc = 64 ;
lev = 18 ;
variables:
float T(lev,yc,xc) ;
T:long_name = "temperature" ;
T:units = "K" ;
T:coordinates = "lon lat" ;
float xc(xc) ;
xc:axis = "X" ;
xc:long_name = "x-coordinate in Cartesian system" ;
xc:units = "m" ;
float yc(yc) ;
yc:axis = "Y" ;
yc:long_name = "y-coordinate in Cartesian system" ;
yc:units = "m" ;
float lev(lev) ;
lev:long_name = "pressure level" ;
lev:units = "hPa" ;
float lon(yc,xc) ;
lon:long_name = "longitude" ;
lon:units = "degrees_east" ;
float lat(yc,xc) ;
lat:long_name = "latitude" ;
lat:units = "degrees_north" ;
T(k,j,i) is associated with the coordinate values lon(j,i), lat(j,i), and lev(k). The vertical coordinate is represented by the coordinate variable lev(lev) and the latitude and longitude coordinates are represented by the auxiliary coordinate variables lat(yc,xc) and lon(yc,xc) which are identified by the coordinates attribute.
Note that coordinate variables are also defined for the xc and yc dimensions. This faciliates processing of this data by generic applications that don’t recognize the multidimensional latitude and longitude coordinates.
A "reduced" longitude-latitude grid is one in which the points are arranged along constant latitude lines with the number of points on a latitude line decreasing toward the poles. Storing this type of gridded data in two-dimensional arrays wastes space, and results in the presence of missing values in the 2D coordinate variables. We recommend that this type of gridded data be stored using the compression scheme described in [compression-by-gathering]. Compression by gathering preserves structure by storing a set of indices that allows an application to easily scatter the compressed data back to two-dimensional arrays. The compressed latitude and longitude auxiliary coordinate variables are identified by the coordinates attribute.
dimensions:
londim = 128 ;
latdim = 64 ;
rgrid = 6144 ;
variables:
float PS(rgrid) ;
PS:long_name = "surface pressure" ;
PS:units = "Pa" ;
PS:coordinates = "lon lat" ;
float lon(rgrid) ;
lon:long_name = "longitude" ;
lon:units = "degrees_east" ;
float lat(rgrid) ;
lat:long_name = "latitude" ;
lat:units = "degrees_north" ;
int rgrid(rgrid);
rgrid:compress = "latdim londim";
PS(n) is associated with the coordinate values lon(n), lat(n). Compressed grid index (n) would be assigned to 2D index (j,i) (C index conventions) where
j = rgrid(n) / 128 i = rgrid(n) - 128*j
Notice that even if an application does not recognize the compress attribute, the grids stored in this format can still be handled, by an application that recognizes the coordinates attribute.
This section has been superseded by the treatment of time series as a type of discrete sampling geometry in Chapter 9.
This section has been superseded by the treatment of time series as a type of discrete sampling geometry in Chapter 9.
When the coordinate variables for a horizontal grid are not longitude and latitude, it is required
that the true latitude and longitude coordinates be supplied via the coordinates attribute. A
grid mapping variable is required if, in addition, it is desired to describe the mapping between the
given coordinate variables and the true latitude and longitude coordinates, or to describe the
figure of the Earth used to define the latitude and longitude coordinates, or to describe another
coordinate reference system definition used by some coordinates or auxiliary coordinates. Such a
grid mapping variable provides the description of the mapping via a collection of attached
attributes. It is of arbitrary type since it contains no data. Its purpose is to act as a container
for the attributes that define the mapping. The one attribute that all grid mapping variables must
have is grid_mapping_name, which takes a string value that contains the mapping’s name. The other
attributes that define a specific mapping depend on the value of grid_mapping_name. The valid values
of grid_mapping_name along with the attributes that provide specific map parameter values are
described in [appendix-grid-mappings]
The grid mapping variables are associated with the data and coordinate variables by the
grid_mapping attribute. This attribute is attached to data variables so that variables with
different mappings may be present in a single file. The attribute takes a string value with two
possible formats. In the first format, it is a single word, which names a grid mapping variable. In
the second format, it is a blank-separated list of words "grid_mapping_variable: coordinate_variable
[coordinate_variable …] [grid_mapping_variable: …]", which identifies one or more grid mapping
variables, and with each grid mapping associates one or more coordinate_variables, i.e. coordinate
variables or auxiliary coordinate variables.
Using the simple form, where the grid_mapping attribute is only the name of a grid mapping
variable, 2D latitude and longitude coordinates for a projected coordinate reference system use the
same geographic coordinate reference system (ellipsoid and prime meridian) as the projection is
projected from.
The grid_mapping variable may identify datums (such as the reference ellipsoid, the geoid or the
prime meridian) for horizontal or vertical coordinates. Therefore a grid mapping variable may be
needed when the coordinate variables for a horizontal grid are longitude and latitude. The
grid_mapping_name of latitude_longitude should be used in this case.
The expanded form of the grid_mapping attribute is required if one wants to store coordinate
information for more than one coordinate reference system. In this case each coordinate or auxiliary
coordinate is defined explicitly with respect to no more than one grid_mapping variable. This
syntax may be used to explicitly link coordinates and grid mapping variables where only one
coordinate reference system is used. In this case, all coordinates and auxiliary coordinates of the
data variable not named in the grid_mapping attribute are unrelated to any grid mapping
variable. All coordinate names listed in the grid_mapping attribute must be coordinate
variables or auxiliary coordinates of the data variable.
In order to make use of a grid mapping to directly calculate latitude and longitude values it is
necessary to associate the coordinate variables with the independent variables of the mapping. This
is done by assigning a standard_name to the coordinate variable. The appropriate values of the
standard_name depend on the grid mapping and are given in [appendix-grid-mappings].
dimensions:
rlon = 128 ;
rlat = 64 ;
lev = 18 ;
variables:
float T(lev,rlat,rlon) ;
T:long_name = "temperature" ;
T:units = "K" ;
T:coordinates = "lon lat" ;
T:grid_mapping = "rotated_pole" ;
char rotated_pole
rotated_pole:grid_mapping_name = "rotated_latitude_longitude" ;
rotated_pole:grid_north_pole_latitude = 32.5 ;
rotated_pole:grid_north_pole_longitude = 170. ;
float rlon(rlon) ;
rlon:long_name = "longitude in rotated pole grid" ;
rlon:units = "degrees" ;
rlon:standard_name = "grid_longitude";
float rlat(rlat) ;
rlat:long_name = "latitude in rotated pole grid" ;
rlat:units = "degrees" ;
rlon:standard_name = "grid_latitude";
float lev(lev) ;
lev:long_name = "pressure level" ;
lev:units = "hPa" ;
float lon(rlat,rlon) ;
lon:long_name = "longitude" ;
lon:units = "degrees_east" ;
float lat(rlat,rlon) ;
lat:long_name = "latitude" ;
lat:units = "degrees_north" ;
A CF compliant application can determine that rlon and rlat are longitude and latitude values in the rotated grid by recognizing the standard names grid_longitude and grid_latitude. Note that the units of the rotated longitude and latitude axes are given as degrees. This should prevent a COARDS compliant application from mistaking the variables rlon and rlat to be actual longitude and latitude coordinates. The entries for these names in the standard name table indicate the appropriate sign conventions for the units of degrees.
dimensions:
y = 228;
x = 306;
time = 41;
variables:
int Lambert_Conformal;
Lambert_Conformal:grid_mapping_name = "lambert_conformal_conic";
Lambert_Conformal:standard_parallel = 25.0;
Lambert_Conformal:longitude_of_central_meridian = 265.0;
Lambert_Conformal:latitude_of_projection_origin = 25.0;
double y(y);
y:units = "km";
y:long_name = "y coordinate of projection";
y:standard_name = "projection_y_coordinate";
double x(x);
x:units = "km";
x:long_name = "x coordinate of projection";
x:standard_name = "projection_x_coordinate";
double lat(y, x);
lat:units = "degrees_north";
lat:long_name = "latitude coordinate";
lat:standard_name = "latitude";
double lon(y, x);
lon:units = "degrees_east";
lon:long_name = "longitude coordinate";
lon:standard_name = "longitude";
int time(time);
time:long_name = "forecast time";
time:units = "hours since 2004-06-23T22:00:00Z";
float Temperature(time, y, x);
Temperature:units = "K";
Temperature:long_name = "Temperature @ surface";
Temperature:missing_value = 9999.0;
Temperature:coordinates = "lat lon";
Temperature:grid_mapping = "Lambert_Conformal";
An application can determine that x and y are the projection coordinates by recognizing the standard names projection_x_coordinate and projection_y_coordinate. The grid mapping variable Lambert_Conformal contains the mapping parameters as attributes, and is associated with the Temperature variable via its grid_mapping attribute.
dimensions:
lat = 18 ;
lon = 36 ;
variables:
double lat(lat) ;
double lon(lon) ;
float temp(lat, lon) ;
temp:long_name = "temperature" ;
temp:units = "K" ;
temp:grid_mapping = "crs" ;
int crs ;
crs:grid_mapping_name = "latitude_longitude"
crs:semi_major_axis = 6371000.0 ;
crs:inverse_flattening = 0 ;
dimensions:
lat = 18 ;
lon = 36 ;
variables:
double lat(lat) ;
double lon(lon) ;
float temp(lat, lon) ;
temp:long_name = "temperature" ;
temp:units = "K" ;
temp:grid_mapping = "crs" ;
int crs ;
crs:grid_mapping_name = "latitude_longitude";
crs:longitude_of_prime_meridian = 0.0 ;
crs:semi_major_axis = 6378137.0 ;
crs:inverse_flattening = 298.257223563 ;
dimensions:
z = 100;
y = 100000 ;
x = 100000 ;
variables:
double x(x) ;
x:standard_name = "projection_x_coordinate" ;
x:long_name = "Easting"
x:units = "m" ;
double y(y) ;
y:standard_name = "projection_y_coordinate" ;
y:long_name = "Northing"
y:units = "m" ;
double z(z) ;
z:standard_name = "height_above_reference_ellipsoid" ;
z:long_name = "height_above_osgb_newlyn_datum_masl" ;
z:units = "m" ;
double lat(y, x) ;
lat:standard_name = "latitude" ;
lat:units = "degrees_north" ;
double lon(y, x) ;
lon:standard_name = "longitude" ;
lon:units = "degrees_east" ;
float temp(z, y, x) ;
temp:standard_name = "air_temperature" ;
temp:units = "K" ;
temp:coordinates = "lat lon" ;
temp:grid_mapping = "crsOSGB: x y crsWGS84: lat lon" ;
float pres(z, y, x) ;
temp:standard_name = "air_pressure" ;
temp:units = "Pa" ;
temp:coordinates = "lat lon" ;
temp:grid_mapping = "crsOSGB: x y crsWGS84: lat lon" ;
int crsOSGB ;
crsOSGB:grid_mapping_name = "transverse_mercator";
crsOSGB:semi_major_axis = 6377563.396 ;
crsOSGB:inverse_flattening = 299.3249646 ;
crsOSGB:longitude_of_prime_meridian = 0.0 ;
crsOSGB:latitude_of_projection_origin = 49.0 ;
crsOSGB:longitude_of_central_meridian = -2.0 ;
crsOSGB:scale_factor_at_central_meridian = 0.9996012717 ;
crsOSGB:false_easting = 400000.0 ;
crsOSGB:false_northing = -100000.0 ;
crsOSGB:unit = "metre" ;
int crsWGS84 ;
crsWGS84:grid_mapping_name = "latitude_longitude";
crsWGS84:longitude_of_prime_meridian = 0.0 ;
crsWGS84:semi_major_axis = 6378137.0 ;
crsWGS84:inverse_flattening = 298.257223563 ;
An optional grid mapping attribute called crs_wkt may be used to specify multiple coordinate
system properties in so-called well-known text format (usually abbreviated to CRS WKT or OGC
WKT). The CRS WKT format is widely recognised and used within the geoscience software community. As
such it represents a versatile mechanism for encoding information about a variety of coordinate
reference system parameters in a highly compact notational form. The translation of CF coordinate
variables to/from OGC Well-Known Text (WKT) format is shown in Examples 5.11 and 5.12 below and
described in detail in
https://github.com/cf-convention/cf-conventions/wiki/Mapping-from-CF-Grid-Mapping-Attributes-to-CRS-WKT-Elements.
The crs_wkt attribute should comprise a text string that conforms to the WKT syntax as
specified in reference [OGC_CTS]. If desired the text string may contain embedded newline
characters to aid human readability. However, any such characters are purely cosmetic and do not
alter the meaning of the attribute value. It is envisaged that the value of the crs_wkt
attribute typically will be a single line of text, one intended primarily for machine
processing. Other than the requirement to be a valid WKT string, the CF convention does not
prescribe the content of the crs_wkt attribute since it will necessarily be context-dependent.
The crs_wkt attribute is intended to act as a supplement to other single-property CF grid
mapping attributes (as described in Appendix F); it is not intended to replace those attributes. If
data producers omit the single-property grid mapping attributes in favour of the compound
crs_wkt attribute, software which cannot interpret crs_wkt will be unable to use the
grid_mapping information. Therefore the CRS should be described as thoroughly as possible with the
single-property attributes as well as by crs_wkt.
There will be occasions when a given CRS property value is duplicated in both a single-property grid
mapping attribute and the crs_wkt attribute. In such cases the onus is on data producers to
ensure that the property values are consistent. However, in those situations where two values of a
given property are different, then the value specified by the single-property attribute shall take
precedence. For example, if the semi-major axis length of the ellipsoid is defined by the grid
mapping attribute semi_major_axis and also by the crs_wkt attribute (via the WKT
SPHEROID[…] element) then the former, being the more specific attribute, takes
precedence. Naturally if the two values are equal then no ambiguity arises.
Likewise, in those cases where the value of a CRS WKT element should be used consistently across the CF-netCDF community (names of projections and projection parameters, for example) then, the values shown in https://github.com/cf-convention/cf-conventions/wiki/Mapping-from-CF-Grid-Mapping-Attributes-to-CRS-WKT-Elements should be preferred; these are derived from the OGP/EPSG registry of geodetic parameters, which is considered to represent the definitive authority as regards CRS property names and values.
Examples 5.11 illustrates how the coordinate system properties specified via the crs grid mapping
variable in Example 5.9 might be expressed using a crs_wkt attribute. Example 5.12 also
illustrates the addition of the crs_wkt attribute, but here the attribute is added to the
crs variable of a simplified variant of Example 5.10 (5.12 also represents a slightly modified
version of the WKT example shown in section 7.4 of [OGC_CTS]). For brevity in Example 5.11, only
the grid mapping variable and its grid_mapping_name and crs_wkt attributes are included; all other
elements are as per the Example 5.9. Names of projection PARAMETERs follow the spellings used in
the EPSG geodetic parameter registry.
Example 5.12 illustrates how certain WKT elements - all of which are optional - can be used to specify CRS properties not covered by existing CF grid mapping attributes, including:
-
use of the VERT_DATUM element to specify vertical datum information
-
use of additional PARAMETER elements (albeit not essential ones in this example) to define the location of the false origin of the projection
-
use of AUTHORITY elements to specify object identifier codes assigned by an external authority, OGP/EPSG in this instance
...
int crs ;
crs:grid_mapping_name = "latitude_longitude";
...
crs:crs_wkt =
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563]
],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433]]
...
dimensions:
lat = 648 ;
lon = 648 ;
y = 18 ;
x = 36 ;
variables:
double x(x) ;
x:standard_name = "projection_x_coordinate" ;
x:units = "m" ;
double y(y) ;
y:standard_name = "projection_y_coordinate" ;
y:units = "m" ;
double lat(y, x) ;
double lon(y, x) ;
float temp(y, x) ;
temp:long_name = "temperature" ;
temp:units = "K" ;
temp:coordinates = "lat lon" ;
temp:grid_mapping = "crs" ;
int crs ;
crs:grid_mapping_name = "transverse_mercator" ;
crs:longitude_of_central_meridian = -2. ;
crs:false_easting = 400000. ;
crs:false_northing = -100000. ;
crs:latitude_of_projection_origin = 49. ;
crs:scale_factor_at_central_meridian = 0.9996012717 ;
crs:longitude_of_prime_meridian = 0. ;
crs:semi_major_axis = 6377563.396 ;
crs:inverse_flattening = 299.324964600004 ;
crs:projected_coordinate_system_name = "OSGB 1936 / British National Grid" ;
crs:geographic_coordinate_system_name = "OSGB 1936" ;
crs:horizontal_datum_name = "OSGB_1936" ;
crs:reference_ellipsoid_name = "Airy 1830" ;
crs:prime_meridian_name = "Greenwich" ;
crs:towgs84 = 375., -111., 431., 0., 0., 0., 0. ;
crs:crs_wkt = "COMPD_CS ["OSGB 1936 / British National Grid + ODN",
PROJCS ["OSGB 1936 / British National Grid",
GEOGCS ["OSGB 1936",
DATUM ["OSGB 1936",
SPHEROID ["Airy 1830", 6377563.396, 299.3249646],
TOWGS84[375, -111, 431, 0, 0, 0, 0]
],
PRIMEM ["Greenwich", 0],
UNIT ["degree", 0.0174532925199433]
],
PROJECTION ["Transverse Mercator"],
PARAMETER ["False easting", 400000],
PARAMETER ["False northing", -100000],
PARAMETER ["Longitude of natural origin", -2.0],
PARAMETER ["Latitude of natural origin", 49.0],
PARAMETER ["Longitude of false origin", -7.556],
PARAMETER ["Latitude of false origin", 49.766],
PARAMETER ["Scale factor at natural origin", 0.9996012717],
UNIT ["metre", 1.0],
AUTHORITY ["EPSG", "27700"]
],
VERT_CS ["Newlyn",
VERT_DATUM ["Ordnance Datum Newlyn", 2005],
UNIT ["metre", 1.0]",
AXIS ["Gravity-related height", UP],
AUTHORITY ["EPSG", "5701"]
]]" ;
...
Note: To enhance readability the WKT value has been split across multiple lines and embedded quotation marks (") left unescaped - in real netCDF files such characters would need to be escaped. Also for clarity, we have dropped the quotation marks which would delimit the entire crs_wkt string. The WKT specification in [OGC_CTS] appears to silent be as regards which character(s) may be used to delimit text-valued properties; however, since all the examples in that specification use quotation marks, the use of that particular delimiting character is mandated by the CF convention.
When a variable has an associated coordinate which is single-valued, that coordinate may be represented as a scalar variable (i.e. a data variable which has no netCDF dimensions). Since there is no associated dimension these scalar coordinate variables should be attached to a data variable via the coordinates attribute.
The use of scalar coordinate variables is a convenience feature which avoids adding size one dimensions to variables. A numeric scalar coordinate variable has the same information content and can be used in the same contexts as a size one numeric coordinate variable. Similarly, a string-valued scalar coordinate variable has the same meaning and purposes as a size one string-valued auxiliary coordinate variable (Section 6.1).
Once a name is used for a scalar coordinate variable it can not be used for a 1D coordinate variable. For this reason we strongly recommend against using a name for a scalar coordinate variable that matches the name of any dimension in the file.
If a data variable has two or more scalar coordinate variables, they are regarded as though they were all independent coordinate variables with dimensions of size one. If two or more single-valued coordinates are not independent, but have related values (this might be the case, for instance, for time and forecast period, or vertical coordinate and model level number, Section 6.2), they should be stored as coordinate or auxiliary coordinate variables of the same size one dimension, not as scalar coordinate variables.
dimensions:
lat = 180 ;
lon = 360 ;
time = UNLIMITED ;
variables:
double atime
atime:standard_name = "forecast_reference_time" ;
atime:units = "hours since 1999-01-01 00:00" ;
double time(time);
time:standard_name = "time" ;
time:units = "hours since 1999-01-01 00:00" ;
double lon(lon) ;
lon:long_name = "station longitude";
lon:units = "degrees_east";
double lat(lat) ;
lat:long_name = "station latitude" ;
lat:units = "degrees_north" ;
double p500
p500:long_name = "pressure" ;
p500:units = "hPa" ;
p500:positive = "down" ;
float height(time,lat,lon);
height:long_name = "geopotential height" ;
height:standard_name = "geopotential_height" ;
height:units = "m" ;
height:coordinates = "atime p500" ;
data:
time = 6., 12., 18., 24. ;
atime = 0. ;
p500 = 500. ;
In this example both the analysis time and the single pressure level are represented using scalar coordinate variables. The analysis time is identified by the standard name "forecast_reference_time" while the valid time of the forecast is identified by the standard name "time".