# Custom Query (124 matches)

Filters

Or

 Status accepted assigned closed new reopened And  CcComponentCreatedDescriptionKeywordsMilestoneModifiedOwnerPriorityReporterResolutionStatusSummaryTicketTypeVersion Or  CcComponentCreatedDescriptionKeywordsMilestoneModifiedOwnerPriorityReporterResolutionStatusSummaryTicketTypeVersion
Columns

Show under each result:

## Results (79 - 81 of 124)

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

#139 fixed Update to conformance document: standard_names of area_type & region davidhassell ros
Description

Section 3.3. of the CF convention states:

"Some standard names (e.g. region and area_type) are used to indicate quantities which are permitted to take only certain standard values. This is indicated in the definition of the quantity in the standard name table, accompanied by a list or a link to a list of the permitted values."

but there is no corresponding statement in the conformance document. I therefore propose to add the following to section 3.3 of the CF Conformance document:

"If a variable has a standard_name of region or area_type, it must have value(s) from the permitted list."

#140 fixed Clarifying the role of attributes on boundary variables. cf-conventions@… davidhassell
Description

## 1. Title

Clarifying the role of attributes on boundary variables.

## 2. Moderator

TBC (any offer will be gladly accepted).

## 3. Requirement

To disallow inconsistencies between particular attributes of a boundary variable and its associated coordinate or auxiliary coordinate variable.

For example, it is currently possible for a boundary variable to have a different standard_name attribute to its associated coordinate or auxiliary coordinate variable. This would be unsatisfactory because the user of the data cannot know which of the possibilities is correct.

It is proposed that if a boundary variable has attributes which determine the coordinate type (units, standard_name, axis and positive) or those which affect the interpretation of the boundary variable array values (units, calendar, leap_month, leap_year and month_lengths) then they must always agree exactly with the same attributes of its associated coordinate or auxiliary coordinate variable. In addition, it is recommended that these attributes are not provided to a boundary variable since they are already inherited implicitly.

No restriction is made on any other boundary variable attributes.

This does not affect datasets encoded with previous versions of CF

## 4. Initial Statement of Technical Proposal

The following changes should be made to section 7.1. Cell Boundaries (additions marked by TEXT, deletions by TEXT):

To represent cells we add the attribute bounds to the appropriate coordinate variable(s). The value of bounds is the name of the variable that contains the vertices of the cell boundaries. We refer to this type of variable as a "boundary variable". A boundary variable will have one more dimension than its associated coordinate or auxiliary coordinate variable. The additional dimension should be the most rapidly varying one, and its size is the maximum number of cell vertices. Since a boundary variable is considered to be part of a coordinate variable's metadata, it is not necessary to provide it with attributes (such as long_name and units). and providing no attributes is always acceptable. Boundary variable attributes which determine the coordinate type (units, standard_name, axis and positive) or those which affect the interpretation of the array values (units, calendar, leap_month, leap_year and month_lengths) must always agree exactly with the same attributes of its associated coordinate or auxiliary coordinate variable. To avoid duplication, however, it is recommended that the attributes units, standard_name, axis, positive, calendar, leap_month, leap_year and month_lengths are not provided to a boundary variable.

In section 7.1 Cell Boundaries of the conformance document (additions marked by TEXT, deletions by TEXT):

• Requirements:
• The type of the bounds attribute is a string whose value is a single variable name. The specified variable must exist in the file.
• A boundary variable must have the same dimensions as its associated variable, plus have a trailing dimension (CDL order) for the maximum number of vertices in a cell.
• A boundary variable must be a numeric data type.
• If a boundary variable has units or standard_name attributes, they must agree with those of its associated variable. units, standard_name, axis, positive, calendar, leap_month, leap_year and month_lengths attributes, they must agree exactly with those of its associated variable.
• Recommendations:
• The points specified by a coordinate or auxiliary coordinate variable should lie within, or on the boundary, of the cells specified by the associated boundary variable.
• Boundary variables should not have the _FillValue or missing_value _FillValue, missing_value, units, standard_name, axis, positive, calendar, leap_month, leap_year or month_lengths attributes.

## 5. Benefits

It would be disallowed to encode type-determining attributes (units, calendar, standard_name, axis and positive) or array value interpretation attirbutes (units, calendar, leap_month, leap_year and month_lengths) on a boundary variable if they conflict with the associated coordinate or auxiliary coordinate variable.

## 6. Status Quo

Attributes on a boundary variable may conflict with the associated coordinate or auxiliary coordinate variable, and this is not always checked by the CF checker.

This proposal does not affect datasets encoded under previous versions of CF, other than via the potential for extra warnings being raised by the CF checker.

David Hassell

Note: See TracQuery for help on using queries.