Custom Query (124 matches)


Show under each result:

Results (70 - 72 of 124)

Ticket Resolution Summary Owner Reporter
#62 fixed scalar auxiliary coordinate clarifications cf-conventions@… taylor13

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

#61 fixed 2 new cell methods cf-conventions@… awalsh

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


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

#60 invalid CF Checker Version 2.0.1 cf-checker@… ros

Holding ticket to detail changes/fixes made to the CF Checker for version 2.0.1

Note: See TracQuery for help on using queries.