Custom Query (124 matches)


Show under each result:

Results (64 - 66 of 124)

Ticket Resolution Summary Owner Reporter
#20 fixed Incorrect parsing of flag_values attribute ros ros

Section 3.5 of the conventions document states that "The flag_values attribute is the same type as the variable to which it is attached, and contains a list of the possible flag values."


current_speed_qc:flag_values = 0b, 1b, 2b ;

But Appendix A specified the flag_values type as string. This is what the checker based the check on which is incorrect.

The conventions document has been corrected. The CF checker needs to implement this change too.

#8 fixed Identifying horizontal coordinate variables using the axis attribute cf-conventions@… jonathan

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:

  xc = 128 ;
  yc = 64 ;
  lev = 18 ;
  float T(lev,yc,xc) ;
    T:long_name = "temperature" ;
    T:units = "K" ;
    T:coordinates = "lon lat" ;
  float xc(xc) ;
    xc:long_name = "x-coordinate in Cartesian system" ;
    xc:units = "m" ;
  float yc(yc) ;
    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.

#63 fixed GRIDSPEC: aggregation of block-structured and time dependent data cf-conventions@… pletzer

1. Title

GRIDSPEC to aggregate block-structured and time dependent data

2. Moderator

Balaji (v.balaji@…)

3. Requirement

Current conventions support logical rectangular data stored in a single file. The proposed extension will allow users to aggregate data stored in multiple files, whether the data represent different time slices or are associated with different logically rectangular grids as in the case of the cubed sphere mosaic for instance.

4. Initial Statement of Technical Proposal

GRIDSPEC comprises of two parts: M-SPEC for representing the grid connectivity in mosaics and F-SPEC for time and mosaic data aggregation.

For M-SPEC, a mosaic file contains the list of files where grid information can be extracted with inter-tile connectivity information provided as a map between the set of indices on one tile to indices on the neighbouring tile. This covers both surfacial and volumetric coupling. The former arises for instance when two three-dimensional grids share a surface while the latter arises when the grids are overlapping.

The F-SPEC describes the format of the host file, which acts as a single entry point to the aggregation. Variable data scattered among many files appear as one logical entity when viewed through the host file. Brittleness, in other words the fragility of the aggregation resulting from inadvertent file corruption, file movement and other file operations, is minimized by consolidating all the file names in the host file, which can be straightforwardly re-generated by scanning directories and inspecting the global attributes of the files residing therein.

5. Benefits

Data producers will be able to store data in multiple files while allowing data consumers to access the data as if all the data were stored in a single file.

A number of codes are moving away from longitude-latitude grids because of the singularity of such grids at the pole, which can cause severe limitations in the maximum time steps than models can take. M-SPEC will allow atmospheric and ocean models to store data on their native grids, without having to incur inaccuracies due to lon-lat regridding.

6. Detailed Proposal

Because of the length of this proposal, a separate web page was created to explain in more details our proposed enhancements. The web page contains many examples and is supported by illustrations.

Note: See TracQuery for help on using queries.