# Custom Query (125 matches)

Filters

Or

 Status accepted assigned closed new reopened And  CcComponentCreatedDescriptionKeywordsMilestoneModifiedOwnerPriorityReporterResolutionStatusSummaryTicketTypeVersion Or  CcComponentCreatedDescriptionKeywordsMilestoneModifiedOwnerPriorityReporterResolutionStatusSummaryTicketTypeVersion
Columns

Show under each result:

## Results (43 - 45 of 125)

Ticket Resolution Summary Owner Reporter
#104 fixed Clarify the interpretation of scalar coordinate variables davidhassell jonathan
Description

David Hassell and I propose the following changes to the CF standard document to clarify the interpretation of scalar coordinate variables. We do not think this is a material change to the convention, which already implies this interpretation, and we believe this interpretation is what was intended when scalar coordinate variables were introduced.

Section 5.7, Scalar coordinate variables.

The convention contains the following sentences:

Under COARDS the method of providing a single valued coordinate was to add a dimension of size one to the variable, and supply the corresponding coordinate variable. The new scalar coordinate variable is a convenience feature which avoids adding size one dimensions to variables. Scalar coordinate variables have the same information content and can be used in the same contexts as a size one coordinate variable.

These sentences are OK as they stand, we think, but it would be better to describe the current situation without emphasising its history, so we would propose to replace them with the following. In addition, we propose to add a bit extra, as shown, to the second sentence below:

The use of scalar coordinate variables is a convenience feature which avoids adding size one dimensions to variables. A scalar coordinate variable has the same information content and can be used in the same contexts as a size one coordinate variable, if numeric, or a size one auxiliary coordinate variable, if a string (Section 6.1).

The next sentence would be unchanged; it mentions how this situation relates to that of the COARDS convention.

At the end of the section, after the example, we propose to append the following sentences:

If a data variable has two or more scalar coordinate variables, they are regarded as though they were all independent coordinate variables with dimensions of size one. If two or more single-valued coordinates are not independent, but have related values (for instance, time and forecast period, or vertical coordinate and model level number, Section 6.2), they should be stored as coordinate or auxiliary coordinate variables of the same size one dimension, not as scalar coordinate variables.

We think the above interpretation and implications are consistent with the convention already, which says in this section that, "Scalar coordinate variables have the same information content and can be used in the same contexts as a size one coordinate variable". However, it would be an improvement to spell it out.

Section 6.1, Labels

Replace the last sentence

If a character variable has only one dimension (the maximum length of the string), it is regarded as a string-valued scalar coordinate variable, analogous to a numeric scalar coordinate variable (see Section 5.7, Scalar Coordinate Variables).

with

If a character variable has only one dimension (the maximum length of the string), it is a string-valued scalar coordinate variable (see Section 5.7, Scalar Coordinate Variables). As such, it has the same information content and can be used in the same contexts as a string-valued auxiliary coordinate variable of a size one dimension. This is a convenience feature which avoids adding the size one dimension to the data variable.

The last part is a repetition of what Section 5.7 says. The reason for the change is that the existing wording is careless in implying that a string could be a coordinate variable; in fact, this is not possible, since string- value coordinates must be auxiliary coordinate variables.

The interpretation of scalar coordinate variables in Section 9 may be different from the above, and this may require further clarification if the above is agreed.

#103 fixed Corrections to Appendices A and H davidhassell ros
Description

### Appendix A:

• cf_role, featureType, instance_dimension and sample_dimension should all be of type "S" not C or N.
• It is not obvious that the "Use" should be D for instance_dimension and sample_dimension. The count and index variables are not data variables, but not coord vars either. Suggest putting "-" for them, and add to the key that "-" is for variables with a special purpose.

### Appendix H:

• Section H2: In the examples station_name is an auxiliary coord var and so needs to be identified as one in the coordinates attribute.
• Section H2: _FillValue for the variables humidity and temp should be -999.9f
• Example H8: coordinates attribute for pressure, temperature and humidity should be set to "time lon lat z"

I've not looked beyond Section H4 so some of these might apply there as well.

#102 fixed Request for two additional cell_methods davidhassell rhorne@…
Description

The GOES-R ground system generates products that conmtains two statistics that are not defined in the current set of cell methods in the CF standard. The two statistics are:

(1) root_mean_square (2) total_sum_of_squares

This trac item requests that these two statistics be added to the set of CF defined cell_methods. The changes to the CF standard required to support this are as follows...

In CF standard paragraph 7.3. Cell Methods, change this sentence:

The values of method should be selected from the list in Appendix E, Cell Methods, which includes point, sum, mean, maximum, minimum, mid_range, standard_deviation, variance, mode, and median.

To:

The values of method should be selected from the list in Appendix E, Cell Methods, which includes point, sum, mean, maximum, minimum, mid_range, standard_deviation, variance, mode, median, root_mean_square, and total_sum_of_squares.

In CF standard Appendix E Cell Methods, add the following two rows to Table E.1 Cell Methods:

(first new row)

cell_methods column: root_mean_square

Units column u

Description column: Root mean square (RMS)

(second new row)

cell_methods column: total_sum_of_squares

Units column u2

Description column: Total sum of squares (TSS)

Note: See TracQuery for help on using queries.