Custom Query (125 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (7 - 9 of 125)

1 2 3 4 5 6 7 8 9 10 11 12 13
Ticket Resolution Summary Owner Reporter
#7 wontfix Unstructured Grids SuperGrid Requirements cf-wg-supporting-technologies@… tomgross
Description

The irregular grid specifications have brought up several spatial objects which are not precisely described by a single coordinate location. For instance the edge of a triangle, or the triangle itself. An edge must be described by two points and the triangle by three points. A variable such as heat flux or area are not, necessarily, located at a single point. For convenience we could define spatial locations, center of edge or center of triangle, which could serve as coordinate locations for these variables. As it will still be necessary to describe the edge or triangle, by calling out the locations of the vertices, these derived locations are redundant. These extra locations are very much like the gridspec supergrid points (Balaji 2006). They might be useful enough to become a requirement of the CF conventions.

Should there be a requirement for the inclusion of these auxiliary locations for the center points of higher dimensional objects, such as line segments or areas?

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

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.

#9 wontfix Extensions to CF grid mapping attributes to support coordinate reference system properties cf-conventions@… pbentley
Description

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 2 3 4 5 6 7 8 9 10 11 12 13
Note: See TracQuery for help on using queries.