Custom Query (125 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (34 - 36 of 125)

2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
Ticket Resolution Summary Owner Reporter
#138 fixed Clarification of false_easting / false_northing davidhassell heiko.klein
Description

The explanation of false_easting/northing has left us often puzzled weather false_easting should be added to the existing x-axis values, or subtracted. To clarify this, I suggest the following modification to Table F.1:

false_easting

The value applied to all abscissa values in the rectangular coordinates for a map projection. This value frequently is assigned to eliminate negative numbers. Expressed in the unit of the coordinate variable identified by the standard name projection_x_coordinate. The formula to convert from a projection-axis value without false_easting (x0) to a projection-axis value with false_easting is (xf) is:
x0 = xf - false_easting

false_northing

The value applied to all ordinate values in the rectangular coordinates for a map projection. This value frequently is assigned to eliminate negative numbers. Expressed in the unit of the coordinate variable identified by the standard name projection_y_coordinate. The formula to convert from a projection-axis value without false_northing (y0) to a projection-axis value with false_northing is (yf) is then:
y0 = yf - false_northing

#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.

#13 fixed Procedure for correcting errors in the CF documents cf-conventions@… jonathan
Description

Rich Signell has pointed out an error in the CF standard document by raising a trac ticket. I think we need rules for deciding to make corrections, or there's a danger they might not be implemented. I propose the following:

  1. These rules apply to the CF conventions document, the conformance document, the standard name table and its guidelines.
  1. Errors in these documents can be corrected under these rules if it is clear that the text as it stands isn't what was agreed, because of a typographical or some other error. These rules can't be followed for making substantive changes. Errors in the standard names can alternatively be pointed out on the CF email list, and implemented by the manager of CF standard names (Alison) as part of a regular update.
  1. If someone thinks there is an error in a document, they should open a Trac ticket of type "defect" to point it out and to state what should be done to the text in order to correct the error.
  1. The correction is held to have been agreed if three weeks pass without anyone disagreeing with it. After that period, the ticket should be closed by the manager of the CF conventions (Kyle) or the manager of CF standard names (Alison), who will make the change. No moderator is needed because there cannot be any substantive discussion under these rules.
  1. If anyone disagrees that the correction should be made, because they think the document does have the intended meaning, then a correction cannot be made by these rules, the ticket should be closed, and the change should be proposed as an enhancement instead, following the rules for making changes to the CF standard, if the proposer wants to pursue the issue.

It feels a bit bureaucratic to have rules, but I think it may be necessary because experience shows that without rules we find it hard to reach conclusions. Please post your comments to this ticket.

Jonathan

2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
Note: See TracQuery for help on using queries.