Custom Query (124 matches)

1. Title

Identifying horizontal coordinate variables using the axis attribute

2. Moderator

Russ Rew

3. Requirement

A method is needed to identify which are the horizontal coordinate axes of a data variable

4. Initial Statement of Technical Proposal

The axis attribute of coordinate variables (1D, in the Unidata sense) is optional. The value axis="X" can be used on a longitude coordinate variable (CF 4.2), and axis="Y" on a latitude coordinate variable (CF 4.1) (case-insensitive). CF is ambiguous about its use on other coordinate variables. The introduction of CF 4 states that the axis attribute is recommended for other kinds of spatial coordinate, but without giving an interpretation to its values. However in CF 4.1 and 4.2 it is prohibited for coordinate variables of rotated latitude and longitude. This proposal aims to clarify the use of the axis attribute for horizontal coordinate variables.

The proposal is

• to modify the sentence "We attach no specific meaning ..." in the introduction to CF 4 with: "The values X and Y for the axis attribute should be used to identify horizontal coordinate variables. If both X- and Y-axis are identified, X-Y-up should define a right-handed coordinate system i.e. rotation from the positive X direction to the positive Y direction is anticlockwise if viewed from above."

• to delete the prohibition on the axis attribute for rotated latitude in CF 4.1, and rotated longitude in CF 4.2.

• to append the following to the paragraph beginning "The use of coordinate variables" in the introduction to CF 5: "The axis attribute is not allowed for auxiliary coordinate variables. Auxiliary coordinate variables which lie on the horizontal surface can be identified as such by their dimensions being horizontal, which can in turn be inferred from their having an axis attribute of X or Y, or from their units in the case of latitude and longitude (see section 4)."

• to append the following to the paragraph beginning "If the coordinate variables" in the introduction to CF 5: "The use of the axis attribute with values X and Y is recommended for the coordinate variables (see section 4)."

5. Benefits

The axis attribute, thus redefined, provides a clear way to identify horizontal coordinate variables and horizontal auxiliary coordinate variables.

As an example, we can modify the one in CF 5.2:

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" ;

The axis attributes identify xc and yc as horizontal dimensions, and indicate that xc-yc-up is right-handed. Because xc and yc are the dimensions of lon and lat, these auxiliary coordinate variables are also implied to be horizontal. In this case, we can also deduce that from the fact that they are identifiable as longitude and latitude, but for a general 2D coordinate variable it might not be obvious.

There is no backward incompatibility because the redefinition permits the axis attribute in cases where it was formerly not allowed, but does not change its meaning in existing cases.

6. Status Quo

With the CF standard as it is, latitude and longitude coordinate variables can be identified by their units or standard_name, and they are well known to be horizontal. Other horizontal coordinate variables can be identified only by recognising specific standard_names e.g. those in Appendix F on map projections. The axis attribute is a more general solution that works without any knowledge of the possible choices of horizontal grid.

1. Title

Proposed Extensions to CF Grid Mapping Attributes to support CRS Properties

2. Moderator

Jonathan Gregory

3. Requirement

Previous posts to the CF mailing list have identified the requirement for additional attributes that could be used to provide a fuller definition of the characteristics of the coordinate reference system (CRS) used by spatial coordinates within a netCDF file. This proposal attempts to define attributes for several commonly used CRS properties.

4. Initial Statement of Technical Proposal

Owing to the length of this proposal, the full specification text is included in the attached PDF document.

(NB: If it is considered more convenient, e.g. for discussion purposes, to upload the full text of this proposal into this Trac ticket, then the author is happy to do so.)

5. Benefits

Scope: potentially all producers and end-users of netCDF datasets could exploit the proposed new attributes.

New capabilities: the proposed new attributes would enable data producers to more accurately record the specific characteristics of the coordinate reference system (or systems) used to define spatial coordinates within netCDF files.

Example use-case 1: A data producer has collected meteorological observations using a sensor platform which uses, for example, a particular geodetic datum (e.g. WGS 84, NAD 83, OSGB 36) to record spatial coordinates. It is desirable for this piece of CRS metadata, and others like it, to be recorded in appropriate netCDF CF attributes.

Example use-case 2: A climate data center wishes to convert a legacy dataset to netCDF format and make it available over the internet. The legacy dataset is based upon an unusual or customised coordinate reference system (e.g. transverse mercator projection using, say, the Clarke 1880 ellipsoid). As before, these CRS details need to be encoded in agreed, standardised CF attributes.

6. Status Quo

The author is not aware of alternative CF attributes or mechanisms that could be used to encode the desired additional CRS properties.

1. Title

A standard for CF variable names ("short names") should be added.

2. Moderator

22. Balaji

3. Requirement

In any of the data formats associated with CF (e.g netCDF) the variable name is its most convenient handle. Most command-line and script-based data tools use this handle. The NCO utilities for manipulating netCDF data, visualization and analysis tools such as ferret or grads or Matlab, all use the variable name as a handle.

This name is not currently included in the standard, though some de facto standards exist. In the absence of a standard, users cannot write scripts or methods that are general enough to apply across datasets from many sources.

For instance, a typical user request from GFDL is to make our internal variables names match what PCMDI (via the CMOR program) required for IPCC AR4: this would enable users who have developed new scientific analyses on their own data to apply them instantly to any model in the IPCC archive.

The CF standard_name attribute does not satisfy this need. Shortcomings include:

• the standard_name is too long to type.
• the standard_name attribute along does not uniquely identify a single variable in a file (example: "high", "middle" and "low" cloud amount all have the standard name cloud_area_fraction_in_atmosphere_layer, and are disambiguated using other attributes (height limits of associated layer).

4. Initial Statement of Technical Proposal

We propose a list of "CF short names".

• Names should be short (6 character max) and human-typable.
• Names should uniquely identify a physical variable.
• Proposals to the standard_name list should also list a recommended short name.
• It is desirable that names be vaguely mnemonic: e.g "slp" for sea level pressure. But this should not be a reason to have long debates over the short name.
• The "PCMDI short name" used by IPCC AR4 is a good starting point for climate variables. Perhaps someone can suggest an equally useful starting point for weather (e.g based on ERA-40 or NCEP reanalysis datasets).

5. Benefits

Benefits and use cases are coverd in some slides prepared for GO-ESSP are attached here, and also available ​from Balaji's home page.

6. Status Quo

Without changing the standard, we might get by with de facto standards such as the AR4 short names; but the benefit is limited as many of us participate in multiple international modleing campaigns. There is no guarantee that all such campaigns remain consistent in their use of short names.