Custom Query (124 matches)

CF incorrectly deprecates the "missing_value" attribute due to a misunderstanding.

All changes refer to section 2.5.1:

1. Change the first paragraph from:

"The NUG conventions (NUG section 8.1) provide the _FillValue, valid_min, valid_max, and valid_range attributes to indicate missing data."

to:

"The NUG conventions (NUG section 8.1) provide the _FillValue, missing_value, valid_min, valid_max, and valid_range attributes to indicate missing data."

2. remove the word "strongly" from this sentence:

"If only one missing value is needed for a variable then we strongly recommend that this value be specified using the _FillValue attribute."

3. Remove this paragraph:

"The missing_value attribute is considered deprecated by the NUG and we do not recommend its use. However for backwards compatibility with COARDS this standard continues to recognize the use of the missing_value attribute to indicate undefined or missing data."

4. Change the first sentence of the last paragraph from:

"The missing values of a variable with scale_factor and/or add_offset attributes (see section Section 8.1, “Packed Data”) are interpreted relative to the variable's external values, i.e., the values stored in the netCDF file. "

to:

"The missing values of a variable with scale_factor and/or add_offset attributes (see section Section 8.1, “Packed Data”) are interpreted relative to the variable's external values ( a.k.a. the packed values, the raw values, the values stored in the netCDF file), not the values that result after the scale and offset is applied."

1. Title

2 new cell methods

2. Moderator

Moderator - Alison Pammet Proposer - Andrew Walsh. Contributors and discussion - Jonathon Gregory, Roy Lowry, Mark Kulmar

3. Requirement

Extend the cell methods table with 2 new cell methods.

4. Initial Statement of Technical Proposal

As a result of discussion around the adding 9 new sea surface wave data

parameters to the CF standard names list it was decided to reduce this proposal to 6 new standard names thereby reducing the proliferation of new names. This reduction was achieved by introducing a 'common concept' name called 'sea_surface_wave_height' qualified by one of 4 cell methods i.e.

mean maximum root_mean_square mean_of_upper_decile

which will describe 4 of the statistical wave height variables:

sea_surface_mean_wave_height sea_surface_maximum_wave_height sea_surface_root_mean_square_wave_height sea_surface_wave_mean_of_highest_one_tenth_waves

respectively.

'mean' and 'maximum' are existing cell methods. 'root_mean_square' and 'mean_of_upper_decile' are the 2 new cell methods proposed.

The other 5 new standard names proposed were:

sea_surface_wave_mean_crest_period sea_surface_wave_significant_wave_period sea_surface_wave_period_at_second_largest_peak_of_variance_spectral_density sea_surface_wave_variance_spectral_density_zeroth_frequency_moment sea_surface_wave_root_mean_square_amplitude_from_variance_spectral_density

5. Benefits

This proposal would benefit the netCDF user community as it reduces the proliferation of new names by using a common concept standard name qualified by cell methods. These 2 new cell methods may also find useful application with

other data parameters wherever statistical methods of 'root_mean_square' or 'mean_of_upper_decile' were applied.

6. Status Quo

Status quo would be to use non-standard long_names for these sea surface wave data variables with the disadvantage of poor interoperability.

This proposal is to clear up some apparent inconsistencies in the description of allowable attributes for auxiliary coordinate variables.

At the beginning of section 6.2 of the conventions, it states:

"In some situations a dimension may have alternative sets of coordinates values. Since there can only be one coordinate variable for the dimension (the variable with the same name as the dimension), any alternative sets of values have to be stored in auxiliary coordinate variables. For such alternative coordinate variables, there are no mandatory attributes, but they may have any of the attributes allowed for coordinate variables."

But in paragraph 4 of Chapter 5 it states:

"The axis attribute is not allowed for auxiliary coordinate variables."

in contradiction to the statement in section 6.2.

Furthermore, according to the definition of a scalar coordinate variable (section 1.2), it is supposed to be "functionally equivalent to either a size one coordinate variable or a size one auxiliary coordinate variable." The only way for this to be possible is for both types of scalar coordinates to include the same attributes. Currently the CF document forbids use of the axis attribute in conjunction with auxiliary coordinate variables, but allows its use for coordinate variables. To make the two consistent, the following change to paragraph 4 of Chapter 5 is proposed:

Replace "The axis attribute is not allowed for auxiliary coordinate variables. Auxiliary coordinate variables ..." by "If an axis attribute is attached to an auxiliary coordinate variable, it can be used by applications in the same way the axis attribute is used in conjunction with coordinate variables. Note that if this attribute is missing, it may still be possible to determine if a particular dimension should be associated with the auxiliary coordinate variable. For example, auxiliary coordinate variables ..."

Note that in Example 5.2, the axis attribute "X" is associated with xc, and if the above change were adopted, the axis attribute could also appear in conjunction with the auxiliary coordinate variable "lon". Would this cause problems?

Also, some folks might misinterpret the paragraph at the end of section 2.4, which states that "The advantage of using a coordinate variable is that all its attributes can be used to describe the single-valued quantity, including boundaries." to mean that this is an "advantage over a a size one auxiliary coordinate variable", when in fact it means an "advantage over *omitting* the scalar variable". I therefore propose rewriting this sentence to read:

"The use of a scalar coordinate variable is encouraged, when appropriate, because the coordinate attributes (including axis attribute and the cell bounds) can be defined to more fully describe the quantity of interest."