Re: [CF Metadata] #52: Clarification of _FillValue attribute

[CF Metadata]

#52: Clarification of _FillValue attribute
-+--
  Reporter:  ros |  Owner:  cf-conventions@…
  Type:  defect  | Status:  closed
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  fixed   |   Keywords:
-+--
Changes (by jonathan):

 * status:  new => closed
 * resolution:   => fixed


--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/52#comment:9>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #152: Time mean over area fractions which vary with time

[CF Metadata]

sion accommodating the
 maximum string length).

 "A cell_methods attribute with a string of the form "`area: mean where`
 type1 over type2" indicates the mean is calculated by integrating over the
 type1 portion of the cell and dividing by the area of the type2 portion.
 When “over type2” is omitted, it is assumed to be the same as type1.

 "When “area” is not the only “dimension” for which the “where… over”
 construct is used in a cell_methods, the interpretation more generally is
 that a “weighted” mean is being reported.  Specifically, the quantity of
 interest is integrated over the specified dimension(s) with weights
 proportional to the fraction of “type1” area_type that exists, and then
 this is divided by the integral of the fraction of “type2” area_type that
 exists.

 "Note that “all_area_types” is one of the valid strings permitted for a
 variable with the standard_name area_type, so a cell_methods string of the
 form "area: `mean where all_area_types over` type2" indicates the mean is
 calculated by integrating over all types of area and dividing by the area
 of the type2 portion.

 "The following three examples illustrate cases when one might want to use
 “where” or “where … over” in defining the cell_methods:

 1.  Suppose that in a grid cell the fractional sea ice varies over
 time, but there is interest in the time-mean surface temperature of the
 sea ice.  The time-samples, each representing a spatially-averaged sea ice
 temperature can be summed and then divided by the number of samples to
 obtain an unweighted mean where sea ice exists.  This would be indicated
 with:

   cell_methods = “area: mean where sea_ice time: mean”

 2.  Suppose there is interest in recording the mean fractional area
 covered by sea ice and the mean sea ice thickness in such a way that their
 product would equal the time-mean volume of sea ice in each grid cell.  In
 this case the sea ice area would be reported as an unweighted time-mean,
 while the mean sea ice thickness would be calculated with time samples
 weighted by the fractional area of sea ice. Thus, for sea ice thickness:

   cell_methods = “area: time: mean where sea_ice”

 3.  Suppose the time-mean contributions to total heat flux from
 different portions of a grid cell (e.g., ice-free and ice-covered) are of
 interest, and there are reasons to report these in such a way that the
 total heat flux is the sum of the individual contributions.  Then the
 cell_methods attribute would be defined:

   cell_methods=”area: mean where sea_ice over sea time: mean”


 
 best regards,
 Karl

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/152#comment:9>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #152: Time mean over area fractions which vary with time

[CF Metadata]

#152: Time mean over area fractions which vary with time
-+--
  Reporter:  martin.juckes   |  Owner:  cf-conventions@…
  Type:  enhancement | Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--

Comment (by taylor13):

 Hi all,

 One further note:

 There is a use-case that would be nice to fit into all of this, but I
 suspect it would be difficult:

 Consider "sea ice velocity".  If you wanted to report the time-mean
 velocity such that ice transport could be a correctly calculated as the
 product of time-mean velocity and time-mean sea ice mass, then each
 velocity time-sample would have to be weighted by the mass of sea ice (not
 its area) and then we would divide by the sum of the weights.   The "where
 ... over" construct would not cover this case, so the mass-weighting
 scheme would have to appear as a "comment" in cell_methods.

 Karl

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/152#comment:10>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #152: Time mean over area fractions which vary with time

[CF Metadata]

#152: Time mean over area fractions which vary with time
-+--
  Reporter:  martin.juckes   |  Owner:  cf-conventions@…
  Type:  enhancement | Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--

Comment (by taylor13):

 Hi all,

 And one additional note:

 The 3rd example assumes that the grid cell is occupied by open ocean plus
 sea ice (but no land or ice shelves).  This should be made clear, or the
 cell_methods should be changed to:

 cell_methods="area: mean where sea_ice over all_surface_types time: mean

 Karl

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/152#comment:11>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #152: Time mean over area fractions which vary with time

[CF Metadata]

#152: Time mean over area fractions which vary with time
-+--
  Reporter:  martin.juckes   |  Owner:  cf-conventions@…
  Type:  enhancement | Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--

Comment (by jonathan):

 Dear Karl

 Thanks for thinking about this. You've proposed to rewrite parts of text
 which seem clear enough already to me and don't need to be rewritten for
 the sake of this proposal. That might be an improvement, but it makes me
 uneasy because I'm not sure what's changed, and it would take more work to
 check it! Please could you propose text with the minimum necessary
 modification, alongside the existing text for comparison? That would be
 very helpful.

 I agree that the case `time: mean where sea_ice` is an obvious extension,
 but it hasn't yet been requested (see comments 7 and 8 above) and thus
 following our normal rule we would not add it. The same applies to your
 comment 10.

 Best wishes

 Jonathan

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/152#comment:12>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #152: Time mean over area fractions which vary with time

[CF Metadata]

#152: Time mean over area fractions which vary with time
-+--
  Reporter:  martin.juckes   |  Owner:  cf-conventions@…
  Type:  enhancement | Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--

Comment (by martin.juckes):

 Dear Karl, Jonathan,

 Karl's last comment is correct: there is an inconsistency between the 3rd
 example and the text. I think the best resolution is to make the example
 consistent with the text be replacing "over sea" with "over
 all_area_types". The example as it stands is a possible construction, but
 I think the mean over the whole grid cell, as stated in the text, is the
 more useful example to present.

 For the 2nd comment: the statement that we cannot encode a the weighted
 mean of a velocity, with the current convention, in such a way that the
 time mean mass transport is correctly represented. The approach followed
 by SIMIP to deal with this in CMIP6 is to request mass transport variables
 (for which standard names exist, e.g. sea_ice_x_transport).

 I agree that we should omit "horizontal area of the" from the sentence at
 the start of 7.3.3: "... is assumed to have been evaluated over the entire
 horizontal area of the cell." We may have, for instance, an array which
 represents sea ice properties at a certain point in an emsemble of
 simulations and as a fuction of time. In this case we would still be using
 an area_type, but using it to identify portions of an ensemble rather than
 portions of a horizontal area. The shorter text "  is assumed to have
 been evaluated over the entire cell" conveys all the necessary
 information. I agree with Jonathan, however, that we do not need to move
 away from the restriction to the existing area_type usage at present. A
 more general ` ... where condition_xxx` is conceivable, but I'm not sure
 we would want to fit it into the existing area_type framework.

 Reviewing the ticket again I have, however, seen an additional problem
 with the first example: `area: mean where sea_ice time: mean` .. the
 problem is the `area: mean where sea_ice` is undefined where there is no
 sea ice, so how do we take the time mean? There are 3 options: (1) fill
 with zero where there is no sea ice, (2) report the time mean as undefined
 or (3) take the time average over those cells where there is sea ice. The
 last should be encoded `area: mean where sea_ice time: mean where
 sea_ice`. As far as the convention is concerned, we should try to avoid
 usage which is ambiguous. I think that (2) is the best interpretation of
 the first example as far as the convention goes, but this probably means
 it is not a very useful formulation from a scientific perspective and we
 should perhaps advise against its use. If people want a time mean over the
 whole time period they should use a formulation which gives a completely
 unambiguous definition at each time. Thus, I would change the wording to
 say that the first example is ambiguous for time varying area_type and
 should, in general be avoided in this case.

 regards,
 Martin

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/152#comment:13>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

[CF Metadata] #153: Requires related to specific standard names

[CF Metadata]

#153: Requires related to specific standard names
+--
 Reporter:  martin.juckes   |  Owner:  cf-conventions@…
 Type:  enhancement | Status:  new
 Priority:  medium  |  Milestone:
Component:  cf-conventions  |Version:
 Keywords:  |
+--
 This ticket is still under constrcution ..

 A significant number of standard names contain, in their definitions,
 explicit specifications for additional required metadata. For instance, if
 the standard_name is "region" then there are constraints on the allowed
 values of the data variable. The standard name descriptions cannot include
 examples or markup, and the specification of the rules is not as clear as
 in the convention text. It also appears that the rules are not checked by
 the CF checker (at least not the few that I have looked at in detail) and
 I think the best way to get consistent checking would be to first create a
 well structured summary of these rules in the conventions document.

 The specific proposal is add a new Appendix which lists the rules with
 examples where appropriate.

 = Appendix D: Rules associated with standard names =

 Some standard names bring additional constraints on the meta-data and/or
 data values of the variables they are associated with. This appendix list
 such names, grouped according to the types of constraint, and provides
 usage examples where needed.

 The following table lists the rules and associated standard names. An
 explanation of each rule follows below.

  =Rule= || =Standard Name(s)= ||
 || 1 || Area Fraction || area_fraction ||
 || 2 || Lifted from || atmosphere_convective_available_potential_energy,
 atmosphere_convective_inhibition, atmosphere_level_of_free_convection,
 atmosphere_lifting_condensation_level ||
 || 3 || Lifting range ||
 temperature_difference_between_ambient_air_and_air_lifted_adiabatically ||
 |||| to be completed || ||

 == Area fraction ==

   Variables with standard name area_fraction require a coordinate with
 standard name area_type;
 {{{
float cropcover(lat,lon);
   standard_name: area_fraction;
   coordinate: crop
character crop(nchar);
   standard_name: area_type;
data:
   crop: 'crop';
 }}}

 == Lifted from ==

 atmosphere_lifting_condensation_level + 3 others: requires an
 original_air_pressure_of_lifted_parcel coordinate.

 == Lifting range ==

 == Quantities representing a layer average or sum ==

 Many "layer" quantities (e.g.
 dry_static_energy_content_of_atmosphere_layer): require vertical
 coordinate with bounds.

 == Variation of variables in sigma coordinates due to surface pressure
 change ==
 
change_in_energy_content_of_atmosphere_layer_due_to_change_in_sigma_coordinate_wrt_surface_pressure:
 must have a vertical coordinate variable (axis=Z)

 == Time rate of change or displacement over time ==

 change_over_time_... and .._displacement: require bounds on time
 coordinate

 == Radiances ==

 downwelling_photosynthetic_photon_radiance_in_sea_water and other radiance
 variables: direction must be specified, e.g. with coordinate of
 "zenith_angle".

 == Variables which depend on reference air temperature and humidity ==

 mass_concentration_of_pm..._ambient_aerosol_in_air (and
 mass_fraction_of_pm..): require air_temperature and relative_humidity

 == Functions of wavelength ==

 isotropic_radiance_per_unit_wavelength_in_air (and other
 per_unit_wavelength varables): the definition is slightly ambiguous with
 the sentence  "A coordinate variable for radiation wavelength should be
 given the standard name radiation_wavelength" which, taken literally,
 means the use of a wavelength coordinate is optional: should it be "A
 coordinate variable for radiation wavelength should be given with the
 standard name radiation_wavelength", making the wavelength coordinate
 required?

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/153>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #153: Requires related to specific standard names

[CF Metadata]

at I have looked at in detail) and
 I think the best way to get consistent checking would be to first create a
 well structured summary of these rules in the conventions document.

 The specific proposal is add a new Appendix which lists the rules with
 examples where appropriate.

 It will take some time to complete the list. I propose that we add a
 provisional list, after agreeing the format and approach, and work towards
 completion later.

 = Appendix D: Rules associated with standard names =

 Some standard names bring additional constraints on the meta-data and/or
 data values of the variables they are associated with. This appendix list
 such names, grouped according to the types of constraint, and provides
 usage examples where needed.

 == Required Coordinates ==

 A common constraint involves the requirement that a particular coordinate
 or set of coordinates be present.

 The following table lists the rules and associated standard names. An
 explanation of each rule follows below.

 = Rule =||= Description =||
 ||= ''Standard Name(s)'' =||
 ||= '''Required coordinate(s)''' =||
 || 1 || Area Fraction || The fractional area in a cell covered by a
 particulate area type. ||
  || ''area_fraction'' ||
  || '''area_type''' ||
 || 2 || Lifted from || Parameters defined in terms of lifting from a
 reference level ||
  ||''atmosphere_convective_available_potential_energy,
 atmosphere_convective_inhibition, atmosphere_level_of_free_convection,
 atmosphere_lifting_condensation_level'' ||
  || '''original_air_pressure_of_lifted_parcel''' ||
 || 3 || Lifting range || Parameter defined in terms of lifting through a
 specified range  ||
    ||
 ''temperature_difference_between_ambient_air_and_air_lifted_adiabatically''
 ||
    ||
 
'''original_air_pressure_of_lifted_parcel,final_air_pressure_of_lifted_parcel'''
 ||
 || 4 || Radiances || For radiance variables a direction must be specified
 ||
   || ''downwelling_photosynthetic_photon_radiance_in_sea_water'' and
 others
   ||  '''zenith_angle''' ||
 || 5 || Reference state || Variables which depend on reference air
 temperature and humidity ||
    ||  ''mass_concentration_of_pm_*_ambient_aerosol_in_air,
 mass_fraction_of_pm_*_ambient_aerosol_in_air'' ||
 ||  '''air_temperature, relative_humidity''' ||
 || 6 || Wavelength || Functions of wavelength ||
    ||  ''*_per_unit_wavelength_in_air'' ||
    ||   '''radiation_wavelength''' ||

 In all cases, the structure follows the same pattern, illustrated by the
 following examples for case 1. Area Fraction:

 {{{
float cropcover(lat,lon);
   cropcover:standard_name = 'area_fraction';
   cropcover:coordinates =  'crop';
   cropcover:units = '1';
character crop(nchar);
   crop:standard_name = 'area_type';
data:
   crop = 'crop';
 }}}

 == Other rules ==

 === Quantities representing a layer average or sum ===

 Many "layer" quantities require vertical coordinates with bounds.
 * ''*_atmosphere_layer[_*]'';
 * ''*_ocean_layer[_*]'';
 * ''*_soil_layer[_*]'';

 === Variation of variables in sigma coordinates due to surface pressure
 change ===
 
change_in_energy_content_of_atmosphere_layer_due_to_change_in_sigma_coordinate_wrt_surface_pressure:
 must have a vertical coordinate variable (axis=Z).

 {{{
float deltae(sig);
   deltae:standard_name =
 
'change_in_energy_content_of_atmosphere_layer_due_to_change_in_sigma_coordinate_wrt_surface_pressure';
   deltae:units = 'J m-2';
float sig(sig);
   sig:axis = 'Z';
   sig:standard_name = 'atmosphere_sigma_coordinate';
   sig:bounds = 'sig_bnds';
   sig:units = '1';
float sig_bnds(2,sig);  # required because of _atmosphere_layer
 }}}

 === Temporal change ===

 Time rate of change or displacement over time require bounds on time
 coordinate:
  * ''change_over_time_*'';
  * ''*_displacement'';

 

 = Comments for discussion =

 In some cases the wording of standard_name definitions could be
 interpreted as a recommendation or suggestion rather than a requirement.
 If some of these are intended only as suggestions, that should be flagged.

--

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/153#comment:1>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #153: Requirements related to specific standard names (was: Requires related to specific standard names)

[CF Metadata]

;crop';
 }}}

 == Other rules ==

 === Regions and Area Types ===

 If the standard name of a variable is `region` or `area_type` then the
 variables must either be of character type or use flag values to associate
 each element to a character string. The string values must be from the CF
 standard region and area type lists respectively.

 === Quantities representing a layer average or sum ===

 Many "layer" quantities require vertical coordinates with bounds.
 * ''*_atmosphere_layer[_*]'';
 * ''*_ocean_layer[_*]'';
 * ''*_soil_layer[_*]'';

 === Variation of variables in sigma coordinates due to surface pressure
 change ===
 
change_in_energy_content_of_atmosphere_layer_due_to_change_in_sigma_coordinate_wrt_surface_pressure:
 must have a vertical coordinate variable (axis=Z).

 {{{
float deltae(sig);
   deltae:standard_name =
 
'change_in_energy_content_of_atmosphere_layer_due_to_change_in_sigma_coordinate_wrt_surface_pressure';
   deltae:units = 'J m-2';
float sig(sig);
   sig:axis = 'Z';
   sig:standard_name = 'atmosphere_sigma_coordinate';
   sig:bounds = 'sig_bnds';
   sig:units = '1';
float sig_bnds(2,sig);  # required because of _atmosphere_layer
 }}}

 === Temporal change ===

 Time rate of change or displacement over time require bounds on time
 coordinate:
  * ''change_over_time_*'';
  * ''*_displacement'';

 

 = Comments for discussion =

 In some cases the wording of standard_name definitions could be
 interpreted as a recommendation or suggestion rather than a requirement.
 If some of these are intended only as suggestions, that should be flagged.

--

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/153#comment:2>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #153: Requirements related to specific standard names

[CF Metadata]

#153: Requirements related to specific standard names
-+--
  Reporter:  martin.juckes   |  Owner:  cf-conventions@…
  Type:  enhancement | Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--

Comment (by jonathan):

 Dear Martin

 I think this is a good idea, thank you, and I agree with the proposal
 except that I suggest it would be better to have it as a separate document
 on the standard name page, like the guidelines, rather than as an appendix
 in the CF convention document. That is because

   * It relates to standard names only and does not affect the convention.
   * As a separate document, it could be updated more easily and frequently
 than the convention document, and it would make sense to update it with
 the standard name table.

 The CF checker could consult it in either case. For use by the CF checker
 or other software, I suppose that this list of constraints should be made
 available in an form convenient for reading by programs. Ros's opinion
 would be useful.

 Best wishes

 Jonathan

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/153#comment:3>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #153: Requirements related to specific standard names

[CF Metadata]

#153: Requirements related to specific standard names
-+--
  Reporter:  martin.juckes   |  Owner:  cf-conventions@…
  Type:  enhancement | Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--

Comment (by martin.juckes):

 Dear Jonathan,

 I'm happy with that proposal .. perhaps with one extra line in the
 conventions document to say that "Use of some standard names introduces
 additional constraints on the variable attributes and/or values, as
 detailed in `link to: Requirements Related to Specific Standard Names` . "

 I also agree on the need for a machine readable form. I was thinking that
 something would be needed to assist the proof reading. E.g. a JSON file
 which can be used to generate a spreadsheet displaying the definitions of
 all the variables listed under each constraint.

 I think the more legible wiki form is also necessary, in order to provide
 the usage examples. In the earlier email discusion, Roy Lowry suggested
 encoding the rules in RDF and serving them through the NERC Vocab Server
 alongside the standard names. This would be neat, but I think it may be
 worth generating wiki and JSON versions first, in order to get a clearer
 view of the range of constraints that we are dealing with,

 regards,
 Martin

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/153#comment:4>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #153: Requirements related to specific standard names

[CF Metadata]

#153: Requirements related to specific standard names
-+--
  Reporter:  martin.juckes   |  Owner:  cf-conventions@…
  Type:  enhancement | Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--

Comment (by jonathan):

 Dear Martin

 OK, good. I agree we also need a human-readable version - wiki and JSON
 would be fine.

 Best wishes

 Jonathan

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/153#comment:5>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #153: Requirements related to specific standard names

[CF Metadata]

#153: Requirements related to specific standard names
-+--
  Reporter:  martin.juckes   |  Owner:  cf-conventions@…
  Type:  enhancement | Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--

Comment (by martin.juckes):

 Dear Jonathan,

 On 2nd thoughts, however, in connection with updating "frequently and
 easily", we need to be careful about backward compatibility. E.g. if we
 introduce it in parallel with CF-1.7, files which were considered valid
 under CF-1.6 might become invalid. We want, I think, such files to
 continue to be considered as vaild under CF-1.6, hence the checker should
 not use this extension when checking against earlier convention versions.
 This differs from the policy with the standard name list, for which the
 latest is always used. This implies, I think, that this document would
 need to be clearly versioned in a way which makes the link to convention
 versions clear, eg. we might start with 1.7.00 and increment to 1.7.01 etc
 until the convention moves to 1.8.

 I can see that we want flexibility to add rules about new standard names
 when the standard name table is updated, and this is far more frequent
 that convention updates. We need to be careful about dealing with rules
 for existing standard names which might have been overlooked. Once we have
 a 1.7.00 version, we should not change any rules for existing standard
 names until 1.8.00 is launched, though we could perhaps add advisory notes
 where appropriate.

 Does this sound workable?

 regards,
 Martin

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/153#comment:6>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #153: Requirements related to specific standard names

[CF Metadata]

#153: Requirements related to specific standard names
-+--
  Reporter:  martin.juckes   |  Owner:  cf-conventions@…
  Type:  enhancement | Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--

Comment (by jonathan):

 Dear Martin

 I appreciate your caution but I think we can be a bit more relaxed. This
 new document does not have any information which isn't already in the
 standard name table, so it may be regarded as an adjunct to that. Hence I
 think the new document should have the same version numbers as the
 standard name table, though it will probably not be updated every time.
 Although at the moment the CF checker doesn't verify that the constraints
 are satisfied, it ''could'' already have done so - it's a matter of
 implementation, not the convention. The constraints are not new. We're
 simply making it easier to check them. We aren't changing anything about
 the convention. We also have a choice to make about whether the checker
 would regard not meeting these constraints as an error (i.e. breaking a
 requirement) or bad practice (i.e. not respecting a recommendation).

 Best wishes

 Jonathan

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/153#comment:7>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #82: Extend cell_methods attribute to document multi-step operations on a variable

[CF Metadata]

#82: Extend cell_methods attribute to document multi-step operations on a
variable
---+-
  Reporter:  mgschultz |  Owner:  cf-conventions@…
  Type:  enhancement   | Status:  new
  Priority:  medium|  Milestone:
 Component:  Philip Cameron-Smith  |Version:
Resolution:|   Keywords:  cell_methods, averaging
---+-

Comment (by cofino):

 Dear David and Cameron,

 Because `duration` it's linked to a time concept I would suggest more
 general term like `size` or `window` which are been using on the
 mathematical concept of moving averages.

 My vote is for `size`.

 Antonio

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/82#comment:8>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #152: Time mean over area fractions which vary with time

[CF Metadata]

#152: Time mean over area fractions which vary with time
-+--
  Reporter:  martin.juckes   |  Owner:  cf-conventions@…
  Type:  enhancement | Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--
Changes (by taylor13):

 * Attachment "cell_methods_new2.docx" added.

 proposed text

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/152>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #152: Time mean over area fractions which vary with time

[CF Metadata]

#152: Time mean over area fractions which vary with time
-+--
  Reporter:  martin.juckes   |  Owner:  cf-conventions@…
  Type:  enhancement | Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--
Changes (by taylor13):

 * Attachment "cell_methods_new2.pdf" added.

 proposed text pdf

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/152>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #152: Time mean over area fractions which vary with time

[CF Metadata]

#152: Time mean over area fractions which vary with time
-+--
  Reporter:  martin.juckes   |  Owner:  cf-conventions@…
  Type:  enhancement | Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--
Changes (by taylor13):

 * Attachment "cell_methods_new2_clean.docx" added.

 proposed text (clean)

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/152>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #152: Time mean over area fractions which vary with time

[CF Metadata]

#152: Time mean over area fractions which vary with time
-+--
  Reporter:  martin.juckes   |  Owner:  cf-conventions@…
  Type:  enhancement | Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--

Comment (by taylor13):

 I have attached a word document with "track changes" turned on showing the
 proposed changes in text to the conventions.  I also have rendered it in
 pdf form (also attached).  The 3rd attached document is a clean version of
 the proposed text without mark-up.   Comments welcome.

 Karl Taylor

 From an offline discussion, I copy the following comment from Martin
 Juckes:

 Dear Karl,

 thanks, it is good that you have tackled the section on cell_methods for
 area_type arrays.

 There is one place where I think there is an inconsistency between your
 text and the text in the ticket at present: you suggest that 'the
 interpretation more generally is that a “weighted” mean is reported.', and
 that this would also apply to "area: mean where sea_ice time: mean". I had
 interpreted this differently, that "time: mean" should mean an unweighted
 mean over time, and the way to report a weighted mean was to use "area:
 time: mean where sea_ice". The example in the current text reflects this,
 giving different results for the weighted and un-weighted time mean. This
 followed earlier discussion with Jonathan and Jim Baird, in which I learnt
 that the complete cell_methods string should be treated as a sequence of
 operations, carried out in the order presented from left to right. I feel
 that it is clearer, syntactically, to keep this distinction, but would be
 interested to hear the views of others,

 regards,
 Martin

--
Ticket URL: <http://cf-pcmdi.llnl.gov/trac/ticket/152#comment:14>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #149: correction of standard name in example 7.3

[CF Metadata]

#149: correction of standard name in example 7.3
-+--
  Reporter:  taylor13|  Owner:  cf-conventions@…
  Type:  defect  | Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--

Comment (by davidhassell):

 Thanks, Karl.

 This defect has not been commented on for much more than  3 weeks, so I
 think that we can regard it as accepted now.

 All the best,

 David

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/149#comment:1>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #152: Time mean over area fractions which vary with time

[CF Metadata]

#152: Time mean over area fractions which vary with time
-+--
  Reporter:  martin.juckes   |  Owner:  cf-conventions@…
  Type:  enhancement | Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--

Comment (by jonathan):

 Dear Martin and Karl

 I suppose that the sentence "The interpretation more generally ..." in
 Karl's text applies to the particular cell_method concerned, not to the
 entire cell_methods attribute. if that is so, it doesn't contradict
 Martin's statement, which I agree with, about different methods for
 different dimensions. It would be good to clarify this by specifying this
 remark replies to an entry in the attribute. Also, I find the phrase "when
 area is not the only dimension to which is applies" rather confusing. I
 ''guess'' this phrase is there because if the cell method is about `area`
 it surely must be area-weighted, so it's redundant rather than wrong - is
 that the idea, Karl? If it is, I think we could omit it. I suggest running
 together this paragraph and the preceding one in Karl's new text, as
 follows:

 An entry in the `cell_methods` attribute with the form "`area: mean where`
 ''type1'' `over` ''type2''" indicates the mean is calculated by
 integrating over the ''type1'' portion of the cell and dividing by the
 area of the ''type2'' portion. When "`over` ''type2''" is omitted, it is
 assumed to be the same as ''type1''. When the "where" construct is used,
 the interpretation is that a "weighted" mean is reported. Specifically,
 the quantity of interest is integrated over all dimensions associated with
 the method with weights proportional to the fraction of ''type1''
 area_type that exists, and then this is divided by the integral over the
 same dimension(s) of the fraction of ''type2'' area_type that exists.

 Best wishes

 Jonathan

--
Ticket URL: <http://cf-pcmdi.llnl.gov/trac/ticket/152#comment:15>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #152: Time mean over area fractions which vary with time

[CF Metadata]

id cell
 “portions” that can be considered are only those permitted to be
 associated with the   `standard_name` of `area_type`. There are two
 options for indicating when a quantity represents a portion of a cell.

 The first method can be used for the common case that the cell_method
 applies to a single area-type. In this case, the cell_methods attribute
 may include a string of the form `name: method where type`. Here name
 could, for example, be area and type may be any of the strings permitted
 for a variable with a standard_name of area_type. As an example, if the
 method is `area: mean where sea_ice`, then the data would represent a mean
 over only the sea ice portion of the grid cell. When this first option is
 adopted, none of the variables in the netCDF file should be given a name
 identical to the string that names the `area_type`.  This restriction is
 imposed so that it will be clear that the metadata should not be
 interpreted following the second option (described in the next paragraph),
 which takes precedence.
 The second method for indicating that a statistic applies to only a
 portion of a cell is more general because it can reference multiple area-
 types.  This may be needed when a variable has a dimension that ranges
 across various area types.  In this case, the cell_methods entry is of the
 form `name: method where typevar`. Here `typevar` is a string-valued
 auxiliary coordinate variable or string-valued scalar coordinate variable
 (see Section 6.1, "Labels") with a `standard_name` of `area_type`. The
 variable `typevar` contains the name(s) of the selected portion(s) of the
 grid cell to which the method is applied. This method provides a
 convenient way to store output from land surface models, for example,
 since they deal with many area types within each surface gridbox (e.g.,
 vegetation, bare_ground, snow, etc.).

 == Clarification at start of section 7.3.3 (not needed if above is
 accepted) ==

 ''Add a clarification after this sentence in the first paragraph of 7.3.3
 "Sometimes, however, it is useful to limit consideration to only a portion
 of a cell (e.g. a mean over the sea-ice area)", to introduce the idea of
 time-varying area fractions:''

 The portion concerned is constant in time in many cases, but it could be
 time-varying.

 == New example for time-varying area fractions ==

 ''The following new example and explanatry text should be added in section
 7.3.3:''

 Example 7.8: Time mean over area fractions which vary with time

 {{{
 float simple_mean(lat,lon):
simple_mean:cell_methods: area: mean where sea_ice time: mean

 float weighted_mean(lat,lon):
weighted_mean:cell_methods: area: time: mean where sea_ice

 float partial_mean(lat,lon):
partial_mean:cell_methods: area: mean where sea_ice over sea time: mean
 }}}

 When the area fraction is varying with time, there are several different
 ways in which a time mean can be formulated. Three of these are
 illustrated in this example. Suppose, for instance, we are averaging over
 three time steps and the data at one grid point is -10, -6, -2 with area
 fractions .75, .50, .25. The values of the simple_mean, weighted_mean and
 partial mean are, respectively, (-10 -6 -2)/3 = -6, (-10*.75 - 6*.5
 -2*.25)/(.75+.5+.25) = -7.33 , and (-10*.75 - 6*.5 -2*.25)/3 = -3.667. The
 partial mean provides the contribution to the mean over the entire grid
 from a specified area type. The simple mean is weighting each time period
 equally, while the weighted mean provides equal weighting to each unit
 area of `sea_ice`.

 In example 7.8, `time` could be replaced by any other coordinate over
 which an average is taken, such as an ensemble index.

--

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/152#comment:16>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #152: Time mean over area fractions which vary with time

[CF Metadata]

pe1
 over type2` indicates the mean is calculated by integrating over the type1
 portion of the cell and dividing by the area of the type2 portion.  When
 `over type2` is omitted, it is assumed to be the same as type1.

 == Clarification at start of section 7.3.3 (not needed if above is
 accepted) ==

 ''Add a clarification after this sentence in the first paragraph of 7.3.3
 "Sometimes, however, it is useful to limit consideration to only a portion
 of a cell (e.g. a mean over the sea-ice area)", to introduce the idea of
 time-varying area fractions:''

 The portion concerned is constant in time in many cases, but it could be
 time-varying.

 == New example for time-varying area fractions ==

 ''The following new example and explanatry text should be added in section
 7.3.3:''

 Example 7.8: Time mean over area fractions which vary with time

 {{{
 float simple_mean(lat,lon):
simple_mean:cell_methods: area: mean where sea_ice time: mean

 float weighted_mean(lat,lon):
weighted_mean:cell_methods: area: time: mean where sea_ice

 float partial_mean(lat,lon):
partial_mean:cell_methods: area: mean where sea_ice over sea time: mean
 }}}

 When the area fraction is varying with time, there are several different
 ways in which a time mean can be formulated. Three of these are
 illustrated in this example. Suppose, for instance, we are averaging over
 three time steps and the data at one grid point is -10, -6, -2 with area
 fractions .75, .50, .25. The values of the simple_mean, weighted_mean and
 partial mean are, respectively, (-10 -6 -2)/3 = -6, (-10*.75 - 6*.5
 -2*.25)/(.75+.5+.25) = -7.33 , and (-10*.75 - 6*.5 -2*.25)/3 = -3.667. The
 partial mean provides the contribution to the mean over the entire grid
 from a specified area type. The simple mean is weighting each time period
 equally, while the weighted mean provides equal weighting to each unit
 area of `sea_ice`.

 In example 7.8, `time` could be replaced by any other coordinate over
 which an average is taken, such as an ensemble index.

--

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/152#comment:17>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #152: Time mean over area fractions which vary with time

[CF Metadata]

onstant in time in many cases, but it could be
 time-varying.

 == 5. New example for time-varying area fractions ==

 ''The following new example and explanatry text should be added in section
 7.3.3:''

 Example 7.8: Time mean over area fractions which vary with time

 {{{
 float simple_mean(lat,lon):
simple_mean:cell_methods: area: mean where sea_ice time: mean

 float weighted_mean(lat,lon):
weighted_mean:cell_methods: area: time: mean where sea_ice

 float partial_mean(lat,lon):
partial_mean:cell_methods: area: mean where sea_ice over sea time: mean
 }}}

 When the area fraction is varying with time, there are several different
 ways in which a time mean can be formulated. Three of these are
 illustrated in this example. Suppose, for instance, we are averaging over
 three time steps and the data at one grid point is -10, -6, -2 with area
 fractions .75, .50, .25. The values of the simple_mean, weighted_mean and
 partial mean are, respectively, (-10 -6 -2)/3 = -6, (-10*.75 - 6*.5
 -2*.25)/(.75+.5+.25) = -7.33 , and (-10*.75 - 6*.5 -2*.25)/3 = -3.667. The
 partial mean provides the contribution to the mean over the entire grid
 from a specified area type. The simple mean is weighting each time period
 equally, while the weighted mean provides equal weighting to each unit
 area of `sea_ice`.

 In example 7.8, `time` could be replaced by any other coordinate over
 which an average is taken, such as an ensemble index.

--

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/152#comment:18>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #152: Time mean over area fractions which vary with time

[CF Metadata]

#152: Time mean over area fractions which vary with time
-+--
  Reporter:  martin.juckes   |  Owner:  cf-conventions@…
  Type:  enhancement | Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--

Comment (by martin.juckes):

 Hello Karl, Jonathan,

 I've copid Karl's proposed text into the ticket .. I thought it might make
 the discussion easier. I've also split it into 3 parts .. (1) modification
 of existing text, (2) modification of example 7.6 caption, (3) new text.
 The last is a variation on my original submission .. expanded.

 I'm happy with with the first two of these parts. For the 3rd part, I see
 an ambiguity between the text saying "the interpretation more generally is
 that a “weighted” mean is reported" and the first example (area: mean
 where sea_ice time: mean) which I would not interpret as a weighted mean.
 This latter interpretation is supported by Jonathan's last comment, but it
 is not, I think, consistent with the bracketted part of Karl's text about
 dealing with time series when sea_ice is completely absent for part of the
 time period. In such cases, I would interpret `area: mean where sea_ice`
 as yielding a time series with some missing values, when sea_ice is
 completely absent, and `time: mean` would then also give a missing value.
 The construct `area: mean where sea_ice time: mean where sea_ice` would be
 needed to average over the portions of the time series for which sea ice
 is present,

 Martin

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/152#comment:19>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #108: Defining a domain for a cell_method

[CF Metadata]

~~Currently the only standardized information is~~ __The interval
 spacing keyword is used__ to provide the typical interval between the
 original data values to which the method was applied, in the situation
 where the present data values are statistically representative of original
 data values which had a finer spacing. The syntax is (interval: value
 unit), where value is a numerical value and unit is a string that can be
 recognized by UNIDATA's Udunits package [UDUNITS].  The unit will usually
 be dimensionally equivalent to the unit of the corresponding dimension,
 but this is not required (which allows, for example, the interval for a
 standard deviation calculated from points evenly spaced in distance along
 a parallel to be reported in units of length even if the zonal coordinate
 of the cells is given in degrees). Recording the original interval is
 particularly important for standard deviations. For example, the standard
 deviation of daily values could be indicated by cell_methods="time:
 standard_deviation (interval: 1 day)" and of annual values by
 cell_methods="time: standard_deviation (interval: 1 year)".

 If the cell method applies to a combination of axes, they may have a
 common original interval e.g. cell_methods="lat: lon: standard_deviation
 (interval: 10 km)". Alternatively, they may have separate intervals, which
 are matched to the names of axes by position e.g. cell_methods="lat: lon:
 standard_deviation (interval: 0.1 degree_N interval: 0.2 degree_E)", in
 which 0.1 degree applies to latitude and 0.2 degree to longitude.

 __To explicitly define the domain over which the statistic was
 calculated, the syntax (domain: varname [varname]) may be used.  In this
 case, each 'varname' listed is the name of an ancillary variable,
 explicitly referenced by the data variable.  Each of the ancillary
 variables referenced contributes to the definition of the domain over
 which the cell_method operation was conducted.__


 == 5. Benefits ==

 The community will benefit by having enhanced capabilities for
 defining cell_methods for data variables calculated across complex
 domains.

 [wiki:aggregateExampleMH] presents a use case for this capability.

 == 6. Status Quo ==

 The capability to define complex domains for cell_methods will not be
 standardised.

--

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/108#comment:11>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #108: Defining a domain for a cell_method

[CF Metadata]

al between the
 original data values to which the method was applied, in the situation
 where the present data values are statistically representative of original
 data values which had a finer spacing. The syntax is (interval: value
 unit), where value is a numerical value and unit is a string that can be
 recognized by UNIDATA's Udunits package [UDUNITS].  The unit will usually
 be dimensionally equivalent to the unit of the corresponding dimension,
 but this is not required (which allows, for example, the interval for a
 standard deviation calculated from points evenly spaced in distance along
 a parallel to be reported in units of length even if the zonal coordinate
 of the cells is given in degrees). Recording the original interval is
 particularly important for standard deviations. For example, the standard
 deviation of daily values could be indicated by cell_methods="time:
 standard_deviation (interval: 1 day)" and of annual values by
 cell_methods="time: standard_deviation (interval: 1 year)".

 If the cell method applies to a combination of axes, they may have a
 common original interval e.g. cell_methods="lat: lon: standard_deviation
 (interval: 10 km)". Alternatively, they may have separate intervals, which
 are matched to the names of axes by position e.g. cell_methods="lat: lon:
 standard_deviation (interval: 0.1 degree_N interval: 0.2 degree_E)", in
 which 0.1 degree applies to latitude and 0.2 degree to longitude.

 __To explicitly define the domain over which the statistic was
 calculated, the syntax (domain: varname [varname]) may be used.  In this
 case, each 'varname' listed is the name of an ancillary variable,
 explicitly referenced by the data variable.  Each of the ancillary
 variables referenced contributes to the definition of the domain over
 which the cell_method operation was conducted.__


 == 5. Benefits ==

 The community will benefit by having enhanced capabilities for
 defining cell_methods for data variables calculated across complex
 domains.

 [wiki:aggregateExampleMH] presents a use case for this capability.

 == 6. Status Quo ==

 The capability to define complex domains for cell_methods will not be
 standardised.

--

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/108#comment:12>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #72: Adding the geostationary projection.

[CF Metadata]

#72: Adding the geostationary projection.
-+--
  Reporter:  martin.raspaud  |  Owner:  cf-conventions@…
  Type:  enhancement | Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--

Comment (by rkaiser):

 Folks,

 GOES-16 has launched and needs this projection added in order to be CF
 compliant.  Can we change the state of this ticket to "accepted" and get
 the suggested text added to v 1.7?

 Rob Kaiser
 (follow-on to Randy Horne in this area)

--
Ticket URL: <http://cf-pcmdi.llnl.gov/trac/ticket/72#comment:22>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #72: Adding the geostationary projection.

[CF Metadata]

#72: Adding the geostationary projection.
-+--
  Reporter:  martin.raspaud  |  Owner:  cf-conventions@…
  Type:  enhancement | Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--

Comment (by jonathan):

 Dear Rob

 There are many tickets that have been agreed, including this one, but
 unfortunately we have not yet tackled implementing them all in 1.7,
 although the document is now in a form which can be updated. Although it's
 not in the 1.7 working version yet, it ''will'' be included in 1.7, so
 please proceed as though it was already there.

 Best wishes

 Jonathan

--
Ticket URL: <http://cf-pcmdi.llnl.gov/trac/ticket/72#comment:23>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #111: New web site

[CF Metadata]

#111: New web site
-+--
  Reporter:  painter1|  Owner:  cf-conventions@…
  Type:  defect  | Status:  closed
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  fixed   |   Keywords:
-+--
Changes (by jonathan):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 I am closing this ticket because as far as I know the new website is
 complete and functional (and has been some time). Thanks to Jeff, Matthew
 and others who migrated it.

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/111#comment:16>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #153: Requirements related to specific standard names

[CF Metadata]

#153: Requirements related to specific standard names
-+--
  Reporter:  martin.juckes   |  Owner:  cf-conventions@…
  Type:  enhancement | Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--

Comment (by ros):

 Sorry, coming to this rather late Happy to have these rules listed in
 a separate document so long as it is easily readable by the CF Checker.
 With the standard-name and area-types tables being in XML that would
 obviously require the least amount of work, but not against another format
 if that would be more appropriate to fit other requirements.

 The extra rules has obviously been overlooked and not made it into the CF
 Checker document.  I'm happy to add these in in the next release.

 Cheers,
 Ros.

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/153#comment:8>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #153: Requirements related to specific standard names

[CF Metadata]

#153: Requirements related to specific standard names
-+--
  Reporter:  martin.juckes   |  Owner:  cf-conventions@…
  Type:  enhancement | Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--

Comment (by martin.juckes):

 Dear Ros,

 OK, I think the rules could be expressed in a simple XML format, one
 element per rule. e.g.
 ``  to
 specify that "area_fraction" must have and area_type variable as a
 coordinate. Where a variable has more than one required coordinate, I
 would list this in two separate XML elements.
 Other rules would be of the form  ``, to specify that a variable must have a dimension or
 coordinate with "axis=Z" `` to
 specify additional that the dimension or coordinate in question must have
 bounds set.

 The `region` and `area_type` rules have a choice, which we could encode as
 follows:
 {{{
 
   
   
 <\choice>
 
 }}}
 The data values referred to in the last case should be interpreted as th
 flag values if present. On the other hand, it may be easier to just have a
 named test for these two, rather than using a complex schema like this.

 Cheers,
 Martin

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/153#comment:9>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #153: Requirements related to specific standard names

[CF Metadata]

#153: Requirements related to specific standard names
-+--
  Reporter:  martin.juckes   |  Owner:  cf-conventions@…
  Type:  enhancement | Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--

Comment (by ros):

 Dear Martin,

 I think that would work absolutely fine from my point of view.  (I have
 just briefly looked at reading JSON, having no experience with it, into
 python which does look pretty easy if that was deemed to be more
 appropriate.)

 One thing we would also need to do is put the Standardised Region List
 into a readable format as it currently only appears to exist on the
 website as an HTML list.  I have just discovered that I did put the check
 of valid regions into the checker but it never got released - I'll include
 it in the next release.

 Regards,
 Ros.

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/153#comment:10>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #153: Requirements related to specific standard names

[CF Metadata]

#153: Requirements related to specific standard names
-+--
  Reporter:  martin.juckes   |  Owner:  cf-conventions@…
  Type:  enhancement | Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--

Comment (by martin.juckes):

 Dear Ros,

 Loading json files is trivial ... a one line command and then you get a
 python object (e.g. a list or a dictionary). You then have to parse the
 object .. the advantage of XML is that there is a well tested approach to
 enforcing structure on the object, which, I find, tends to make parsing
 more reliable. I can easily export it as json as well, as I suspect that
 will make it more accessible to others.
 Thinking about defining the structure, it will be easier to have rules of
 the form:
 ``.

 The `region`/`area_type` rule could be encoded more simply as
 {{{
 <\rule>
 }}}
 This would then give 4 rules to encode: requiredCoordinate, requiredAxis,
 requiredBoundAxis, charOrFlagIn.

 regards,
 Martin

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/153#comment:11>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #153: Requirements related to specific standard names

[CF Metadata]

#153: Requirements related to specific standard names
-+--
  Reporter:  martin.juckes   |  Owner:  cf-conventions@…
  Type:  enhancement | Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--

Comment (by martin.juckes):

 Dear Ros,

 I agree that we need a machine readable version of the Standardised Region
 List .. I'll start a new ticket for that,

 regards,
 Martin

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/153#comment:12>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

[CF Metadata] #154: Machine Readable Standardised Region List

[CF Metadata]

#154: Machine Readable Standardised Region List
+--
 Reporter:  martin.juckes   |  Owner:  cf-conventions@…
 Type:  defect  | Status:  new
 Priority:  medium  |  Milestone:
Component:  cf-conventions  |Version:
 Keywords:  |
+--
 The CF Standardised Region List http://cfconventions.org/Data/cf-standard-
 names/docs/standardized-region-names.html is currently only available as a
 HTML page. Ideally, it should be available as a machine readable document,
 so that the CF checker and other software can access the names, as
 discussed, for instance, in #153.

 This, with #153, would bring the number of CF vocabulary documents to 4:
  * CF Standard Names
  * CF Area Types
  * CF Standardised Regions
  * CF Rules Related to Standard Names (under discussion: #153)

 There should be some common approach to structuring these documents.

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/154>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #154: Machine Readable Standardised Region List

[CF Metadata]

#154: Machine Readable Standardised Region List
-+--
  Reporter:  martin.juckes   |  Owner:  cf-conventions@…
  Type:  task| Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--
Changes (by martin.juckes):

 * type:  defect => task


Old description:

> The CF Standardised Region List http://cfconventions.org/Data/cf-
> standard-names/docs/standardized-region-names.html is currently only
> available as a HTML page. Ideally, it should be available as a machine
> readable document, so that the CF checker and other software can access
> the names, as discussed, for instance, in #153.
>
> This, with #153, would bring the number of CF vocabulary documents to 4:
>  * CF Standard Names
>  * CF Area Types
>  * CF Standardised Regions
>  * CF Rules Related to Standard Names (under discussion: #153)
>
> There should be some common approach to structuring these documents.

New description:

 The CF Standardised Region List http://cfconventions.org/Data/cf-standard-
 names/docs/standardized-region-names.html is currently only available as a
 HTML page. Ideally, it should be available as a machine readable document,
 so that the CF checker and other software can access the names, as
 discussed, for instance, in #153.

 This, with #153, would bring the number of CF vocabulary documents to 4:
  * CF Standard Names
  * CF Area Types
  * CF Standardised Regions
  * CF Rules Related to Standard Names (under discussion: #153)

 There should be some common approach to structuring these documents, based
 on the establised practise with the CF Standard Names (an XML reference
 document, exported to SKOS). There is also an interest in having JSON
 versions, which are easier to import into python.

--

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/154#comment:1>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #154: Machine Readable Standardised Region List

[CF Metadata]

#154: Machine Readable Standardised Region List
-+--
  Reporter:  martin.juckes   |  Owner:  cf-conventions@…
  Type:  task| Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--
Description changed by martin.juckes:

Old description:

> The CF Standardised Region List http://cfconventions.org/Data/cf-
> standard-names/docs/standardized-region-names.html is currently only
> available as a HTML page. Ideally, it should be available as a machine
> readable document, so that the CF checker and other software can access
> the names, as discussed, for instance, in #153.
>
> This, with #153, would bring the number of CF vocabulary documents to 4:
>  * CF Standard Names
>  * CF Area Types
>  * CF Standardised Regions
>  * CF Rules Related to Standard Names (under discussion: #153)
>
> There should be some common approach to structuring these documents,
> based on the establised practise with the CF Standard Names (an XML
> reference document, exported to SKOS). There is also an interest in
> having JSON versions, which are easier to import into python.

New description:

 The CF Standardised Region List http://cfconventions.org/Data/cf-standard-
 names/docs/standardized-region-names.html is currently only available as a
 HTML page. Ideally, it should be available as a machine readable document,
 so that the CF checker and other software can access the names, as
 discussed, for instance, in #153.

 This, with #153, would bring the number of CF vocabulary documents to 4:
  * CF Standard Names
  * CF Area Types
  * CF Standardised Regions
  * CF Rules Related to Standard Names (under discussion: #153)

 There should be some common approach to structuring these documents, based
 on the establised practise with the CF Standard Names (an XML reference
 document, exported to SKOS). There is also an interest in having JSON
 versions, which are easier to import into python.

 The general structure used for the standard names and area types is clear:
 some header information followed by a sequence of "entry" elements, each
 with an "id" attribute and one or more simple child elements. The schema
 used for area types could be used directly for standard regions. The CF
 standard name schema could be adapted for the rules with some minor change
 of terminology.

--

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/154#comment:2>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #153: Requirements related to specific standard names

[CF Metadata]

#153: Requirements related to specific standard names
-+--
  Reporter:  martin.juckes   |  Owner:  cf-conventions@…
  Type:  enhancement | Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--
Changes (by martin.juckes):

 * Attachment "CF_Standard_Name_Rules.xml" added.

 CF Standard Name Rules

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/153>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #153: Requirements related to specific standard names

[CF Metadata]

#153: Requirements related to specific standard names
-+--
  Reporter:  martin.juckes   |  Owner:  cf-conventions@…
  Type:  enhancement | Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--
Changes (by martin.juckes):

 * Attachment "CF_Standard_Name_Rules.json" added.

 CF Standard Name Rules Demo (in JSON)

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/153>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #153: Requirements related to specific standard names

[CF Metadata]

#153: Requirements related to specific standard names
-+--
  Reporter:  martin.juckes   |  Owner:  cf-conventions@…
  Type:  enhancement | Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--
Changes (by martin.juckes):

 * Attachment "CFStandardNameRules-1.1.xsd" added.

 CF Standard Name Rules Schema (based on CF Standard Name Schema)

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/153>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #153: Requirements related to specific standard names

[CF Metadata]

#153: Requirements related to specific standard names
-+--
  Reporter:  martin.juckes   |  Owner:  cf-conventions@…
  Type:  enhancement | Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--

Comment (by martin.juckes):

 Hello Ros,

 After looking at the schema of the standard name list, I've adapted that
 for the rules, with typical entries of the form:
 {{{
 
   The soil layer must be described by a bounds attribute
 on a vertical coordinate.
   moisture_content_of_soil_layer
   Z

 }}}
 The "id" has to be unique, so may need to be extended beyond the standard
 name which the rule is intended to apply to. Ideally, the target standard
 name should be constrained by the schema to be in the CF list, but I
 haven't implemented that yet. attachment:CF_Standard_Name_Rules.xml is a
 demo XML document with 3 rules, and attachment:CF_Standard_Name_Rules.json
 is the same in JSON. The schema for the XML is
 attachment:CFStandardNameRules-1.1.xsd.

 This approach makes it easier to impose the schema rules on the names of
 the rules and the associated restrictions on the values (e.g.
 "requiredBoundAxis" should take a value "X", "Y", ...).

 cheers,
 Martin

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/153#comment:13>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #154: Machine Readable Standardised Region List

[CF Metadata]

#154: Machine Readable Standardised Region List
-+--
  Reporter:  martin.juckes   |  Owner:  cf-conventions@…
  Type:  task| Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--

Comment (by jonathan):

 Dear Martin

 I agree with this proposal in principle. Thanks for the initiative.
 Perhaps Alison will have some comments to make about the format.

 Best wishes

 Jonathan

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/154#comment:3>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

[CF Metadata] #156: Extension to external_variables Syntax for Masks and Area Fractions

[CF Metadata]

#156: Extension to external_variables Syntax for Masks and Area Fractions
+--
 Reporter:  martin.juckes   |  Owner:  cf-conventions@…
 Type:  enhancement | Status:  new
 Priority:  medium  |  Milestone:
Component:  cf-conventions  |Version:
 Keywords:  |
+--
 Ticket #145, now accepted, proposes a new attribute, `external_variables`,
 to indicate when a variable referred to in the `cell_measures` attributes
 is in another file. This ticket relates to masks and area fractions used
 in the `cell_methods` attribute which may be associated with another
 variable. For instance, if we have `cell_methods = area: mean where
 sea_ice` and, in another file, a variable `siconc` which contains the sea
 ice area fraction. At present, there is no way within the convention to
 indicate, in the file containing the `cell_methods` statement, that the
 variable `siconc` is supplied separately.

 The proposal is to allow the `external_variables` attribute to include
 terms of the form `sea_ice:siconc` to indicate that an `area_type` has an
 associated variable in an external file.

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/156>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #156: Extension to external_variables Syntax for Masks and Area Fractions

[CF Metadata]

#156: Extension to external_variables Syntax for Masks and Area Fractions
-+--
  Reporter:  martin.juckes   |  Owner:  cf-conventions@…
  Type:  enhancement | Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--
Description changed by martin.juckes:

Old description:

> Ticket #145, now accepted, proposes a new attribute,
> `external_variables`, to indicate when a variable referred to in the
> `cell_measures` attributes is in another file. This ticket relates to
> masks and area fractions used in the `cell_methods` attribute which may
> be associated with another variable. For instance, if we have
> `cell_methods = area: mean where sea_ice` and, in another file, a
> variable `siconc` which contains the sea ice area fraction. At present,
> there is no way within the convention to indicate, in the file containing
> the `cell_methods` statement, that the variable `siconc` is supplied
> separately.
>
> The proposal is to allow the `external_variables` attribute to include
> terms of the form `sea_ice:siconc` to indicate that an `area_type` has an
> associated variable in an external file.

New description:

 Ticket #145, now accepted, proposes a new attribute, `external_variables`,
 to indicate when a variable referred to in the `cell_measures` attributes
 is in another file. This ticket relates to masks and area fractions used
 in the `cell_methods` attribute which may be associated with another
 variable. For instance, if we have `cell_methods = area: mean where
 sea_ice` and, in another file, a variable `siconc` which contains the sea
 ice area fraction. At present, there is no way within the convention to
 indicate, in the file containing the `cell_methods` statement, that the
 variable `siconc` is supplied separately.  In earlier CMIP archives it was
 reasonably easy to determine when a mask or area fraction was available
 for a particular cell methods operation. For CMIP6 this is not so easy, as
 there are a substantial number of area fraction arrays covereing different
 aspects of the cryosphere and land surface.

 The proposal is to allow the `external_variables` attribute to include
 terms of the form `sea_ice:siconc` to indicate that an `area_type` has an
 associated variable in an external file.

--

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/156#comment:1>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #156: Extension to external_variables Syntax for Masks and Area Fractions

[CF Metadata]

#156: Extension to external_variables Syntax for Masks and Area Fractions
-+--
  Reporter:  martin.juckes   |  Owner:  cf-conventions@…
  Type:  enhancement | Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--

Comment (by martin.juckes):

 On reflection, the above proposal does not cater for those who may wish to
 store the mask or area fraction variable in the same file, so it would be
 better to have a means of identifying this variable without relying on the
 `external_variables` attribute. This could be done in the
 `cell_methods`string, with an extension to the vocabulary for standardized
 information in parenthesis: `area: mean where sea_ice (variable: siconc)`.
 The preferred approach would then be for `siconc` to be a variable in the
 file, while it would be possible to use `external_methods` for CMIP files
 which have the the mask variables in different files. The variable
 indicated in the `(variable: ..)` construct should have dimensions
 compatible with the variable carrying the `cell_methods` attribute.

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/156#comment:2>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

[CF Metadata] #157: Clarification to Section 2.3 - Naming Conventions

[CF Metadata]

#157: Clarification to Section 2.3 - Naming Conventions
+--
 Reporter:  ros |  Owner:  cf-conventions@…
 Type:  defect  | Status:  new
 Priority:  medium  |  Milestone:
Component:  cf-conventions  |Version:
 Keywords:  |
+--
 It is a requirement that variable, dimension and attribute names begin
 with a letter and be composed of letters, digits and underscores, however,
 the wording in the CF conventions document means it can be interpreted as
 only a recommendation.

 I therefore propose we change

 "Variable, dimension and attribute names should begin with a letter
 and be composed of letters, digits, and underscores. Note that this
 is in conformance with the COARDS conventions, but is more
 restrictive than the netCDF interface which allows use of the hyphen
 character. The netCDF interface also allows leading underscores in
 names, but the NUG states that this is reserved for system use."

 to read

 "Variable, dimension and attribute names '''must''' begin with a letter
 and be composed of letters, digits, and underscores '''(with the exception
 of the NUG defined attribute _FillValue)'''. Note that this
 is in conformance with the COARDS conventions, but is more
 restrictive than the netCDF interface which allows use of the hyphen
 character. The netCDF interface also allows leading underscores in
 names, but the NUG states that this is reserved for system use."

 Since this is a defect ticket, which aims to clarify the convention but
 not to alter it in meaning, it will be accepted by default unless there is
 an objection or alternative suggestion.

 Regards,[[br]]
 Ros.

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/157>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #157: Clarification to Section 2.3 - Naming Conventions

[CF Metadata]

#157: Clarification to Section 2.3 - Naming Conventions
-+--
  Reporter:  ros |  Owner:  cf-conventions@…
  Type:  defect  | Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--

Comment (by heiko.klein):

 Hi Ros,

 we store several chemical components or isotopes in CF-compliant files.
 These components often have a tendency to start with digits rather than
 letters and I used the freedom of 'should' to name these variables e.g.
 like "133Xe_concentration". I even send a ticket to the netcdf-group when
 versions of netcdf (3.6-4.0?) forbid writing digits as first character in
 variable-names. Most programs I know have no problems with these variable-
 names (ncap2 does have problems, but I never found out if escaping of
 variable-names is possible).

 Most 'should' rules in CF exist for compatibility with COARDS. Changing a
 'should' rule to a 'must' rule is definitely a change and not a defect in
 CF, and in this case just to satisfy the COARDS convention, which I
 haven't seen in active use any longer. CF does not enforce any other
 restrictions on variable-names.

 The only 'defect' in the variable-name description is the missing
 definition of 'letter', which might have been a-zA-Z in a ASCII sense from
 netcdf, but since NUG from netcdf-4 could include umlauts and is UTF-8.

 Heiko

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/157#comment:1>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #149: correction of standard name in example 7.3

[CF Metadata]

#149: correction of standard name in example 7.3
-+--
  Reporter:  taylor13|  Owner:  davidhassell
  Type:  defect  | Status:  accepted
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--
Changes (by davidhassell):

 * owner:  cf-conventions@… => davidhassell
 * status:  new => accepted


--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/149#comment:2>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #148: New cell_methods: mabs/mibs/mebs

[CF Metadata]

#148: New cell_methods: mabs/mibs/mebs
-+--
  Reporter:  zender  |  Owner:  davidhassell
  Type:  enhancement | Status:  accepted
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:  cell_methods
-+--
Changes (by davidhassell):

 * owner:  cf-conventions@… => davidhassell
 * status:  new => accepted


--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/148#comment:11>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #143: Supplement the definitions of dimensionless vertical coordinates

[CF Metadata]

#143: Supplement the definitions of dimensionless vertical coordinates
-+--
  Reporter:  jonathan|  Owner:  davidhassell
  Type:  task| Status:  accepted
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--
Changes (by davidhassell):

 * owner:  cf-conventions@… => davidhassell
 * status:  new => accepted


--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/143#comment:14>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #145: Subconvention for associated files, proposed for use in CMIP6

[CF Metadata]

#145: Subconvention for associated files, proposed for use in CMIP6
-+--
  Reporter:  jonathan|  Owner:  davidhassell
  Type:  enhancement | Status:  accepted
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--
Changes (by davidhassell):

 * owner:  cf-conventions@… => davidhassell
 * status:  new => accepted


--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/145#comment:53>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #138: Clarification of false_easting / false_northing

[CF Metadata]

#138: Clarification of false_easting / false_northing
-+--
  Reporter:  heiko.klein |  Owner:  davidhassell
  Type:  defect  | Status:  accepted
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--
Changes (by davidhassell):

 * owner:  cf-conventions@… => davidhassell
 * status:  new => accepted


--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/138#comment:10>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #123: clarification of "difference sources" in Section 3.3

[CF Metadata]

#123: clarification of "difference sources" in Section 3.3
-+--
  Reporter:  jonathan|  Owner:  davidhassell
  Type:  defect  | Status:  accepted
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--
Changes (by davidhassell):

 * owner:  cf-conventions@… => davidhassell
 * status:  new => accepted


--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/123#comment:2>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #118: Add an attribute in Appendix F to identify the geoid or other geopotential datum

[CF Metadata]

#118: Add an attribute in Appendix F to identify the geoid or other geopotential
datum
-+--
  Reporter:  jonathan|  Owner:  davidhassell
  Type:  enhancement | Status:  accepted
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--
Changes (by davidhassell):

 * owner:  cf-conventions@… => davidhassell
 * status:  new => accepted


--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/118#comment:23>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #139: Update to conformance document: standard_names of area_type & region

[CF Metadata]

#139: Update to conformance document: standard_names of area_type & region
-+--
  Reporter:  ros |  Owner:  davidhassell
  Type:  defect  | Status:  accepted
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--
Changes (by davidhassell):

 * owner:  cf-conventions@… => davidhassell
 * status:  new => accepted


--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/139#comment:3>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #109: resolve inconsistency of positive and standard_name attributes

[CF Metadata]

#109: resolve inconsistency of positive and standard_name attributes
-+--
  Reporter:  jonathan|  Owner:  davidhassell
  Type:  defect  | Status:  accepted
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--
Changes (by davidhassell):

 * owner:  cf-conventions@… => davidhassell
 * status:  new => accepted


--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/109#comment:8>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #104: Clarify the interpretation of scalar coordinate variables

[CF Metadata]

#104: Clarify the interpretation of scalar coordinate variables
-+--
  Reporter:  jonathan|  Owner:  davidhassell
  Type:  enhancement | Status:  accepted
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--
Changes (by davidhassell):

 * owner:  cf-conventions@… => davidhassell
 * status:  new => accepted


--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/104#comment:70>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #103: Corrections to Appendices A and H

[CF Metadata]

#103: Corrections to Appendices A and  H
-+--
  Reporter:  ros |  Owner:  davidhassell
  Type:  defect  | Status:  accepted
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--
Changes (by davidhassell):

 * owner:  cf-conventions@… => davidhassell
 * status:  new => accepted


--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/103#comment:3>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #100: Clarifications to the preamble of sections 4 and 5

[CF Metadata]

#100: Clarifications to the preamble of sections 4 and 5
-+--
  Reporter:  jonathan|  Owner:  davidhassell
  Type:  defect  | Status:  accepted
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--
Changes (by davidhassell):

 * owner:  cf-conventions@… => davidhassell
 * status:  new => accepted


--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/100#comment:9>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #92: Add oblique mercator projection

[CF Metadata]

#92: Add oblique mercator projection
-+--
  Reporter:  mcginnis|  Owner:  davidhassell
  Type:  enhancement | Status:  accepted
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--
Changes (by davidhassell):

 * owner:  cf-conventions@… => davidhassell
 * status:  new => accepted


--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/92#comment:13>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #89: standard names for vector components

[CF Metadata]

#89: standard names for vector components
-+---
  Reporter:  markh   |  Owner:  davidhassell
  Type:  enhancement | Status:  accepted
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:  vector, standard_name
-+---
Changes (by davidhassell):

 * owner:  cf-conventions@… => davidhassell
 * status:  new => accepted


--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/89#comment:11>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #88: Terms of Reference for the CF Data Model

[CF Metadata]

#88: Terms of Reference for the CF Data Model
-+--
  Reporter:  markh   |  Owner:  davidhassell
  Type:  task| Status:  accepted
  Priority:  medium  |  Milestone:  Unstructured Grid Data Model
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:  data model, scope
-+--
Changes (by davidhassell):

 * owner:  cf-conventions@… => davidhassell
 * status:  new => accepted


--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/88#comment:23>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #87: Allow comments in coordinate variables

[CF Metadata]

#87: Allow comments in coordinate variables
-+--
  Reporter:  ngalbraith  |  Owner:  cf-conventions@…
  Type:  defect  | Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--

Comment (by davidhassell):

 As there have been no comments for ​three weeks, I think we can accept
 this defect.

 David

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/87#comment:1>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #87: Allow comments in coordinate variables

[CF Metadata]

#87: Allow comments in coordinate variables
-+--
  Reporter:  ngalbraith  |  Owner:  davidhassell
  Type:  defect  | Status:  accepted
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--
Changes (by davidhassell):

 * owner:  cf-conventions@… => davidhassell
 * status:  new => accepted


--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/87#comment:2>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #102: Request for two additional cell_methods

[CF Metadata]

#102: Request for two additional cell_methods
-+--
  Reporter:  rhorne@…|  Owner:  davidhassell
  Type:  enhancement | Status:  accepted
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:  cell_method
-+--
Changes (by davidhassell):

 * owner:  cf-conventions@… => davidhassell
 * status:  new => accepted


--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/102#comment:14>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #86: Allow coordinate variables to be scaled integers

[CF Metadata]

#86: Allow coordinate variables to be scaled integers
-+-
  Reporter:  rhorne@…|  Owner:  davidhassell
  Type:  | Status:  accepted
  enhancement|
  Priority:  medium  |  Milestone:
 Component:  cf- |Version:
  conventions|   Keywords:  coordinate variables, scaled
Resolution:  |  integers
-+-
Changes (by davidhassell):

 * owner:  cf-conventions@… => davidhassell
 * status:  new => accepted


--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/86#comment:16>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #85: Link Appendix H from section 9, and clarify missing data requirements

[CF Metadata]

#85: Link Appendix H from section 9, and clarify missing data requirements
-+--
  Reporter:  jonathan|  Owner:  davidhassell
  Type:  defect  | Status:  accepted
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--
Changes (by davidhassell):

 * owner:  cf-conventions@… => davidhassell
 * status:  new => accepted


--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/85#comment:7>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #80: Add missing CF parameters to translate Coordinate Reference System properties to/from OGC Well-Known Text format

[CF Metadata]

#80: Add missing CF parameters to translate Coordinate Reference System
properties to/from OGC Well-Known Text format
-+-
  Reporter:  etourigny   |  Owner:  davidhassell
  Type:  enhancement | Status:  accepted
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:  projections wkt
-+-
Changes (by davidhassell):

 * owner:  cf-conventions@… => davidhassell
 * status:  new => accepted


--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/80#comment:30>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #76: More than one name in Conventions attribute

[CF Metadata]

#76: More than one name in Conventions attribute
-+--
  Reporter:  Dave.Allured|  Owner:  davidhassell
  Type:  enhancement | Status:  accepted
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:  conventions
-+--
Changes (by davidhassell):

 * owner:  cf-conventions@… => davidhassell
 * status:  new => accepted


--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/76#comment:10>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #77: Add sinusoidal projection

[CF Metadata]

#77: Add sinusoidal projection
-+--
  Reporter:  etourigny   |  Owner:  davidhassell
  Type:  enhancement | Status:  accepted
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:  projection
-+--
Changes (by davidhassell):

 * owner:  cf-conventions@… => davidhassell
 * status:  new => accepted


--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/77#comment:13>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #74: Allow sharing of ancillary variables among multiple data variables

[CF Metadata]

#74: Allow sharing of ancillary variables among multiple data variables
-+-
  Reporter:  rhorne@…|  Owner:  davidhassell
  Type:  | Status:  accepted
  enhancement|
  Priority:  medium  |  Milestone:
 Component:  cf- |Version:
  conventions|   Keywords:  "ancillary data" "standard name
Resolution:  |  modifiers"
-+-
Changes (by davidhassell):

 * owner:  cf-conventions@… => davidhassell
 * status:  new => accepted


--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/74#comment:58>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #75: fix documentation and definitions of 3 grid mapping definitions

[CF Metadata]

#75: fix documentation and definitions of 3 grid mapping definitions
-+---
  Reporter:  etourigny   |  Owner:  davidhassell
  Type:  defect  | Status:  accepted
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:  grid mapping, wkt, projection
-+---
Changes (by davidhassell):

 * owner:  cf-conventions@… => davidhassell
 * status:  new => accepted


--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/75#comment:10>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #73: Rename Appendix G as Appendix Z

[CF Metadata]

#73: Rename Appendix G as Appendix Z
-+--
  Reporter:  jonathan|  Owner:  davidhassell
  Type:  defect  | Status:  accepted
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--
Changes (by davidhassell):

 * owner:  cf-conventions@… => davidhassell
 * status:  new => accepted


--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/73#comment:7>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #72: Adding the geostationary projection.

[CF Metadata]

#72: Adding the geostationary projection.
-+--
  Reporter:  martin.raspaud  |  Owner:  davidhassell
  Type:  enhancement | Status:  accepted
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--
Changes (by davidhassell):

 * owner:  cf-conventions@… => davidhassell
 * status:  new => accepted


--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/72#comment:24>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #71: Correction of Vertical perspective projection

[CF Metadata]

#71: Correction of Vertical perspective projection
-+--
  Reporter:  martin.raspaud  |  Owner:  davidhassell
  Type:  defect  | Status:  accepted
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--
Changes (by davidhassell):

 * owner:  cf-conventions@… => davidhassell
 * status:  new => accepted


--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/71#comment:5>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #66: conformance requirement for standard name modifiers

[CF Metadata]

#66: conformance requirement for standard name modifiers
-+--
  Reporter:  jonathan|  Owner:  davidhassell
  Type:  defect  | Status:  accepted
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--
Changes (by davidhassell):

 * owner:  cf-conventions@… => davidhassell
 * status:  new => accepted


--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/66#comment:5>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #156: Extension to external_variables Syntax for Masks and Area Fractions

[CF Metadata]

#156: Extension to external_variables Syntax for Masks and Area Fractions
-+--
  Reporter:  martin.juckes   |  Owner:  cf-conventions@…
  Type:  enhancement | Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--

Comment (by jonathan):

 Dear Martin

 Thanks for the proposal. It seems to me that this is probably going a bit
 beyond the role of CF metadata, which is to describe what the data is i.e.
 the mean within sea-ice areas - that's a sufficient description to
 distinguish it from other quantities for most purposes. Your aim here is
 to provide more information about how it was calculated, perhaps to enable
 further calculations. That could be done, but I'm not convinced of the
 case for providing special CF metadata for it unless it's an important
 use-case. An alternative would be to record this information in some
 unstandardised attribute, such as the history, which is where people do
 sometimes record how variables were calculated. This could be standardised
 by a CMIP6 convention, of course, in which there is a more systematic
 relationship between quantities requested.

 Best wishes

 Jonathan

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/156#comment:3>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #157: Clarification to Section 2.3 - Naming Conventions

[CF Metadata]

#157: Clarification to Section 2.3 - Naming Conventions
-+--
  Reporter:  ros |  Owner:  cf-conventions@…
  Type:  defect  | Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--

Comment (by davidhassell):

 Hello,

 Starting an attribute with a [0-9] (e.g. `133Xe_concentration`) is a
 different case to starting it with an underscore (e.g. `_myAttribute`),
 because of the netCDF "system use" rule. I think that I'm in favour of
 disallowing leading underscores, because of the potential conflicts
 between the netCDF and CF namespaces. Could we allow:

   Variable, dimension and attribute names '''must''' begin with a letter
 '''or digit''' ...

 Are there many existing dataset which use leading underscores?

 David

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/157#comment:2>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #157: Clarification to Section 2.3 - Naming Conventions

[CF Metadata]

#157: Clarification to Section 2.3 - Naming Conventions
-+--
  Reporter:  ros |  Owner:  cf-conventions@…
  Type:  defect  | Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--

Comment (by heiko.klein):

 Hi,

 concerning beginning underscores. We have alread one exception for
 attributes with _FillValue. Currently we have to add some other attributes
 starting with _ because netcdf-java needs them, e.g. _CoordinateAxisType
 when distributing through thredds. I wouldn't like to invalidate these
 datasets.

 I see any good reason why we would need a '''must''' rather than a
 '''should''' for variables/attributes and dimensions? Where does this
 cause problems or misunderstandings?

 Heiko

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/157#comment:3>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #156: Extension to external_variables Syntax for Masks and Area Fractions

[CF Metadata]

#156: Extension to external_variables Syntax for Masks and Area Fractions
-+--
  Reporter:  martin.juckes   |  Owner:  cf-conventions@…
  Type:  enhancement | Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--

Comment (by martin.juckes):

 Dear Jonathan,

 The specific use-case that motivated this proposal, which I should have
 included, was analysing some data which was masked by the sea_ice, and
 wanting to access the appropriate variable describing the mask. The masked
 area might be the same as the area of data having missing values, but it
 might not, so the only way to be sure that the analysis deals with the
 appropriate masked area is to have the array defining the mask. E.g. if
 there are missing data in the unmaksed area you may want to fill them in.

 I think this is at the same level of importance as providing the
 cell_measures variable: it is a spatially varying field which is critical
 to analysis of fields which are defined through it.

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/156#comment:4>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #152: Time mean over area fractions which vary with time

[CF Metadata]

#152: Time mean over area fractions which vary with time
-+--
  Reporter:  martin.juckes   |  Owner:  cf-conventions@…
  Type:  enhancement | Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--

Comment (by apamment):

 Hi Martin, Jonathan and Karl,

 On the mailing list I expressed support for Martin's suggestion to extend
 the use of 'where' in
 cell_methods to accommodate time means and I support the changes proposed
 in this ticket. I agree that we
 should confine ourselves to addressing Martin's current use cases and
 leave further extensions until they
 are needed.

 The inclusion of the additional examples and detailed explanation is very
 useful - without them
 it would be difficult to understand the proposed changes. I can see that a
 lot of work has already gone
 into making the text as clear as possible. I am struck by the fact that
 this section of the conventions is getting steadily longer and more
 complicated so to help people navigate
 through the text it would be useful to signpost even more clearly which
 parts describe the use
 cases for constant grid cell portions and time varying portions,
 respectively.

 I suggest re-ordering and extending the first proposed paragraph so that
 it serves as an introduction and
 overview for the whole of section 7.3.3:[[BR]]

 'By default, the statistical method indicated by cell_methods is assumed
 to have been evaluated over the
 entire horizontal area of the cell. Sometimes, however, it is useful to
 limit consideration to only a
 portion of a cell (e.g. a mean over the sea-ice area). Grid cell
 “portions” that can be considered are
 only those permitted to be associated with the standard_name of area_type.
 There are two options for
 indicating when a quantity represents a portion of a cell and these are
 explained in the following two
 paragraphs. The portion of the grid cell to which the statistical method
 is applied may remain constant
 in time, for example, the portion occupied by land or sea; examples 7.6
 and 7.7 illustrate this use
 case. The remainder of the section following example 7.7 describes
 instances when the grid cell portion
 varies in time, for example, when the area occupied by sea-ice changes
 during the sampling period.'

 The first sentence of the second paragraph would then need to be reworded
 slightly:
 'The first method for indicating that a statistic applies to only a
 portion of a cell can be used for
 the common case that the cell_method applies to a single area-type.'

 The penultimate sentence in the paragraph following the proposed example
 7.8 currently reads:
 'The partial mean provides the contribution to the mean over the entire
 grid from a specified
 area type.' Shouldn't this say 'entire grid cell' rather than 'entire
 grid'?

 Best wishes,
 Alison

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/152#comment:20>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #152: Time mean over area fractions which vary with time

[CF Metadata]

d, and when “area” is not the only
 “dimension” to which it applies, the interpretation more generally is that
 a “weighted” mean is reported. Specifically, the quantity of interest is
 integrated over the additional dimension(s) with weights proportional to
 the fraction of “type1” area_type that exists, and then this is divided by
 the integral over the same dimension(s) of the fraction of “type2”
 area_type that exists.   [Note that certain variables might be undefined
 if the fraction of the area_type considered is 0; for example the
 temperature of sea ice is not defined if there is no sea ice.  In this
 case, a time-mean value can still be computed for cells containing some
 sea ice during at least a portion of the averaging interval because no
 matter what the value assumed for temperature when sea ice is missing,
 those values are given zero weight in computing the time-mean.]

 Note that "`all_area_types” is one of the valid strings permitted for a
 variable with the standard_name area_type,  so a cell_methods string of
 the form “area: mean over type1 where all_area_types” indicates the mean
 is calculated by integrating over the type1 portion of the grid cell and
 dividing by the entire area of the grid cell.

 The following three examples illustrate cases when one might want to use
 “where” or “where … over” in defining the cell_methods:

 1. Suppose that in a grid cell the fractional sea ice varies over time,
 but there is interest in the time-mean surface temperature of the sea ice.
 The time-samples, each representing a spatially-averaged sea ice
 temperature can be summed and then divided by the number of samples to
 obtain an unweighted mean where sea ice exists. This would be indicated
 with:
 cell_methods = “area: mean where sea_ice time: mean”

 2. Suppose there is interest in recording the mean fractional area covered
 by sea ice and the mean sea ice thickness in such a way that their product
 would equal the time-mean volume of sea ice in each grid cell. In this
 case the sea ice area would be reported as an unweighted time-mean, while
 the mean sea ice thickness would be calculated with time samples weighted
 by the fractional area of sea ice. Thus, for sea ice thickness:
 cell_methods = “area: time: mean where sea_ice”

 3. Suppose the time-mean contributions to total heat flux from different
 portions of a grid cell (e.g., ice-free and ice-covered) are of interest,
 and there are reasons to report these in such a way that the total heat
 flux is the sum of the individual contributions. Then the cell_methods
 attribute would be defined:
 cell_methods=”area: mean where sea_ice over all_area_types time: mean”

 In some cases a variable referencing a specific area_type will actually be
 defined even in the absence of that area_type (i.e., over the entire grid
 cell).  Consider the surface_snow_thickness, which could sensibly be
 considered to be 0 in the absence of snow.  In this case one might in some
 instances want to report “area: time: mean where snow” (giving a measure
 of the typical snow depth when snow exists) and in other instances “area:
 time: mean where snow over all_area_types” (which in this case would be
 identical to “area: time: mean”) or “area: time: mean where snow over
 land”.


 == 4. Clarification at start of section 7.3.3 (not needed if above is
 accepted) ==

 ''Add a clarification after this sentence in the first paragraph of 7.3.3
 "Sometimes, however, it is useful to limit consideration to only a portion
 of a cell (e.g. a mean over the sea-ice area)", to introduce the idea of
 time-varying area fractions:''

 The portion concerned is constant in time in many cases, but it could be
 time-varying.

 == 5. New example for time-varying area fractions ==

 ''The following new example and explanatry text should be added in section
 7.3.3:''

 Example 7.8: Time mean over area fractions which vary with time

 {{{
 float simple_mean(lat,lon):
simple_mean:cell_methods: area: mean where sea_ice time: mean

 float weighted_mean(lat,lon):
weighted_mean:cell_methods: area: time: mean where sea_ice

 float partial_mean(lat,lon):
partial_mean:cell_methods: area: mean where sea_ice over sea time: mean
 }}}

 When the area fraction is varying with time, there are several different
 ways in which a time mean can be formulated. Three of these are
 illustrated in this example. Suppose, for instance, we are averaging over
 three time steps and the data at one grid point is -10, -6, -2 with area
 fractions .75, .50, .25. The values of the simple_mean, weighted_mean and
 partial mean are, respectively, (-10 -6 -2)/3 = -6, (-10*.75 - 6*.5
 -2*.25)/(.75+.5+.25) = -7.33 , and (-10*.75 - 6*.5 -2*.25)/3 = -3.667. The
 partial mean provides the contribution to the mean over the entire grid
 cell from a specified area type. The simple mean is weighting each time
 period equally, while the weighted mean provides equal weighting to each
 unit area of `sea_ice`.

 In example 7.8, `time` could be replaced by any other coordinate over
 which an average is taken, such as an ensemble index.

--

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/152#comment:21>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #152: Time mean over area fractions which vary with time

[CF Metadata]

#152: Time mean over area fractions which vary with time
-+--
  Reporter:  martin.juckes   |  Owner:  cf-conventions@…
  Type:  enhancement | Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--

Comment (by taylor13):

 Responding to Alison's last paragraph, I have changed "entire grid" to
 read "entire grid cell".  I also changed one instance of "gridbox" to read
 "grid cell".  That change was made to the sentence just before section 2.

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/152#comment:22>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

[CF Metadata] #158: data_type=char|string

[CF Metadata]

#158: data_type=char|string
+--
 Reporter:  bob.simons  |  Owner:  cf-conventions@…
 Type:  enhancement | Status:  new
 Priority:  medium  |  Milestone:
Component:  cf-conventions  |Version:
 Keywords:  |
+--
 In NetCDF-3 files, in order to make it clear whether an array of chars
 should be interpreted as an array of chars or an array of Strings,
 I propose that we replace this sentence in CF section 2.2:

   NetCDF does not support a character string type, so these must be
   represented as character arrays. In this document, a one dimensional
   array of character data is simply referred to as a "string".

 with:

   Since NetCDF-3 files do not have a built-in string data type, strings
   in NetCDF-3 files must be represented as character arrays. To clarify
   how a char array should be interpreted, char arrays must have a
   "data_type" attribute with a value of "char" (for individual chars)
   or "string". (In older files with char variables that lack a data_type
   attribute, it remains ambiguous whether a char array should be
   interpreted as an array of individual characters or an array of
   Strings.)

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/158>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

[CF Metadata] #159: charset attribute

[CF Metadata]

#159: charset attribute
+--
 Reporter:  bob.simons  |  Owner:  cf-conventions@…
 Type:  enhancement | Status:  new
 Priority:  medium  |  Milestone:
Component:  cf-conventions  |Version:
 Keywords:  |
+--
 In order to specify the character set of char and string variables,
 I propose that we append this paragraph to the end of CF section 2.2:

   All char and string variables must include a charset attribute to
   identify the character set (encoding) used by the variable. The
   value of the attribute must be the "Preferred MIME Name" or "Name"
   of one of the 8-bit encodings (so not UTF-16 or UTF-32, since CF
   chars are 8-bits) listed at
   http://www.iana.org/assignments/character-sets/character-sets.xhtml .
   Charset names are case-insensitive.
   The only recommended charset names are "ISO-8859-1" (which is
   useful for European languages and for backwards compatibility
   with 7-bit ASCII characters) and "UTF-8" (which is useful when
   full Unicode is needed). (In older files with variables that
   don't specify a charset, the character set being used remains
   ambiguous.)

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/159>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #159: charset attribute

[CF Metadata]

#159: charset attribute
-+--
  Reporter:  bob.simons  |  Owner:  cf-conventions@…
  Type:  enhancement | Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--

Comment (by heiko.klein):

 I very much appreciate the clarification of the character-set for string
 and char variables, but I would like to modify your approach to harmonize
 with the NUG, where this is handled differently. The default is since over
 10years UTF-8 (this change came together with netcdf4) and the attribute
 to specify the character set is named _Encoding rather than 'charset'.

 From: http://www.unidata.ucar.edu/software/netcdf/netcdf-4/reqs_new.html
   * Strings are stored in UTF-8 Unicode.
   * String data is stored without being interpreted by the library, but an
 encoding for Unicode strings may be specified with a separate attribute
 (e.g. "_Encoding"). A global or group attribute could be used to specify
 the encoding of all strings in a file or group.

 I propose therefore the following modification:


All char and string variables may include a '_Encoding' attribute to
 idenfity the character set (encoding) used by the variable. The value of
 the attribute must be the "Preferred MIME Name" or "Name" listed at
 http://www.iana.org/assignments/character-sets/character-sets.xhtml .
 Charset names are case-insensitive. The recommended charset names are
 "ISO-8859-15" and "UTF-8". A missing _Encoding attribute defaults to
 UTF-8.



 I omit here the 8bit encodings restriction since I don't really see the
 point. It is technically possible to use 2chars for one UTF-16 character,
 but it is not recommended.

 Both UTF-8 and ISO-8859-15 are backwards compatible with 7-bit ASCII
 characters, so I dropped the comment about backward compatibility.

 I use ISO-8859-15 instead of ISO-8859-1 because -15 is the updated (1999)
 version, with the mayor change of including the € sign.

 I prefer a strict default over ambiguity, and the UTF-8 default aligns
 with the NUG.

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/159#comment:1>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #159: charset attribute

[CF Metadata]

#159: charset attribute
-+--
  Reporter:  bob.simons  |  Owner:  cf-conventions@…
  Type:  enhancement | Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--

Comment (by jonathan):

 Dear Bob and Heiko

 Thanks for these contributions. I support this change in Heiko's version.

 Best wishes

 Jonathan

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/159#comment:2>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #158: data_type=char|string

[CF Metadata]

#158: data_type=char|string
-+--
  Reporter:  bob.simons  |  Owner:  cf-conventions@…
  Type:  enhancement | Status:  closed
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  wontfix |   Keywords:
-+--
Changes (by bob.simons):

 * status:  new => closed
 * resolution:   => wontfix


--
Ticket URL: <http://cf-pcmdi.llnl.gov/trac/ticket/158#comment:1>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #159: charset attribute

[CF Metadata]

#159: charset attribute
-+--
  Reporter:  bob.simons  |  Owner:  cf-conventions@…
  Type:  enhancement | Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--
Description changed by bob.simons:

Old description:

> In order to specify the character set of char and string variables,
> I propose that we append this paragraph to the end of CF section 2.2:
>
>   All char and string variables must include a charset attribute to
>   identify the character set (encoding) used by the variable. The
>   value of the attribute must be the "Preferred MIME Name" or "Name"
>   of one of the 8-bit encodings (so not UTF-16 or UTF-32, since CF
>   chars are 8-bits) listed at
>   http://www.iana.org/assignments/character-sets/character-sets.xhtml .
>   Charset names are case-insensitive.
>   The only recommended charset names are "ISO-8859-1" (which is
>   useful for European languages and for backwards compatibility
>   with 7-bit ASCII characters) and "UTF-8" (which is useful when
>   full Unicode is needed). (In older files with variables that
>   don't specify a charset, the character set being used remains
>   ambiguous.)

New description:

 In order to specify the character set of char and string variables,
 I propose that we append this paragraph to the end of CF section 2.2:

   Each char array variable that is to be interpreted
   as an array of individual characters (not string(s))
   must have a "charset" attribute which
   clarifies that the variable is to be interpreted as
   individual characters (not string(s)) and specifies
   the 8-bit character set used by the chars.
   Currently, the only values allowed for "charset"
   are "ISO-8859-1" and "ISO-8859-15".
   A scalar char variable may also use the "charset"
   attribute, which defaults to "ISO-8859-15" if
   it is not specified.

   A string or string array variable (including a char
   array variable that is to be interpreted as a string
   or array of strings) may have an "_Encoding" attribute.
   Alternatively, a file may have a global "_Encoding"
   attribute which applies to all strings (scalar and
   array) in the file. Currently, the only values
   allowed for "_Encoding" are "ISO-8859-1",
   "ISO-8859-15" and "UTF-8". A missing "_Encoding"
   attribute defaults to UTF-8.

 (This 2017-03-02 version is the consensus revised proposal from Chris
 Barker, Heiko Klein, and Bob Simons. This replaces the original proposed
 text.)

--

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/159#comment:3>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #159: charset attribute

[CF Metadata]

#159: charset attribute
-+--
  Reporter:  bob.simons  |  Owner:  cf-conventions@…
  Type:  enhancement | Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--

Comment (by jonathan):

 Dear Bob

 This seems more complicated than Heiko's version. I think he was proposing
 just one paragraph - isn't that right? His version makes other useful
 points too: the encoding name is case-insensitive, and it would be good to
 include the IANA link for information about what these charset
 designations mean.

 The _Encoding attribute should be added to Appendix A.

 Best wishes and thanks

 Jonathan

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/159#comment:4>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #159: charset attribute

[CF Metadata]

#159: charset attribute
-+--
  Reporter:  bob.simons  |  Owner:  cf-conventions@…
  Type:  enhancement | Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--

Old description:

> In order to specify the character set of char and string variables,
> I propose that we append this paragraph to the end of CF section 2.2:
>
>   Each char array variable that is to be interpreted
>   as an array of individual characters (not string(s))
>   must have a "charset" attribute which
>   clarifies that the variable is to be interpreted as
>   individual characters (not string(s)) and specifies
>   the 8-bit character set used by the chars.
>   Currently, the only values allowed for "charset"
>   are "ISO-8859-1" and "ISO-8859-15".
>   A scalar char variable may also use the "charset"
>   attribute, which defaults to "ISO-8859-15" if
>   it is not specified.
>
>   A string or string array variable (including a char
>   array variable that is to be interpreted as a string
>   or array of strings) may have an "_Encoding" attribute.
>   Alternatively, a file may have a global "_Encoding"
>   attribute which applies to all strings (scalar and
>   array) in the file. Currently, the only values
>   allowed for "_Encoding" are "ISO-8859-1",
>   "ISO-8859-15" and "UTF-8". A missing "_Encoding"
>   attribute defaults to UTF-8.
>
> (This 2017-03-02 version is the consensus revised proposal from Chris
> Barker, Heiko Klein, and Bob Simons. This replaces the original proposed
> text.)

New description:

 In order to specify the character set of char and string variables,
 I propose that we append these two paragraphs to the end of CF section
 2.2:

   Each char array variable that is to be interpreted
   as an array of individual characters (not string(s))
   must have a "charset" attribute which
   clarifies that the variable is to be interpreted as
   individual characters (not string(s)) and specifies
   the 8-bit character set used by the chars.
   Values for "charset" are case-insensitive. See
   http://www.iana.org/assignments/character-sets/character-sets.xhtml .
   Currently, the only values allowed for "charset"
   are "ISO-8859-1" and "ISO-8859-15".
   A scalar char variable may also use the "charset"
   attribute, which defaults to "ISO-8859-15" if
   it is not specified.

   A string or string array variable (including a char
   array variable that is to be interpreted as a string
   or array of strings) may have an "_Encoding" attribute.
   Alternatively, a file may have a global "_Encoding"
   attribute which applies to all strings (scalar and
   array) in the file. Values for "_Encoding" are
   case-insensitive. See
   http://www.iana.org/assignments/character-sets/character-sets.xhtml .
   Currently, the only values
   allowed for "_Encoding" are "ISO-8859-1",
   "ISO-8859-15" and "UTF-8". A missing "_Encoding"
   attribute defaults to "UTF-8".

 (This 2017-03-02b version is the consensus revised proposal from Chris
 Barker, Heiko Klein, and Bob Simons, with further changes requested by
 Jonathon Gregory.)

--

Comment (by bob.simons):

 Well, this has more information than Heiko's version. The debate leads me
 to write like a lawyer. ;-)

 Yes, Heiko's version was one paragraph, but there are two attributes which
 cover two situations and I think deserve two paragraphs for clarity.

 I have brought back the "case-insensitive" sentence and the IANA link from
 my original version.

 If approved "charset" should be added to Appendex A, too.

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/159#comment:5>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #159: charset attribute

[CF Metadata]

#159: charset attribute
-+--
  Reporter:  bob.simons  |  Owner:  cf-conventions@…
  Type:  enhancement | Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--

Comment (by jonathan):

 Dear Bob et al.

 I think _Encoding is good. I've just consulted the netCDF user guide, and
 I see they don't include _Encoding as one of their attribute conventions
 there. Yet the use of the underscore should imply it means something
 special to the netCDF library, according to their conventions (like
 _FillValue). Does it have a function in Unidata software?

 I see you've combined your two tickets, and the choice between charset or
 _Encoding indicates whether it's char or string data. I'm not convinced
 still that we need this distinction. On the email list we are discussing
 Example H4. To my mind this example shows that there is a problem with the
 convention as it stands - and thanks for drawing attention to it. But
 supposing it's legal, so that the cf_role variable identifies a single
 timeseries location to which the file refers, there is then no ambiguity,
 is there? Would you use an array of chars (rather than a string) to
 identify a timeseries location? If you did, what is really the difference
 of meaning between a single 1D char array and a single string? They're
 practically equivalent, I would have thought. Are there any other cases
 where CF is ambiguous about whether a variable is a char array or a
 string?

 Best wishes and thanks

 Jonathan

--
Ticket URL: <http://cf-pcmdi.llnl.gov/trac/ticket/159#comment:6>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #159: charset attribute

[CF Metadata]

#159: charset attribute
-+--
  Reporter:  bob.simons  |  Owner:  cf-conventions@…
  Type:  enhancement | Status:  closed
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  wontfix |   Keywords:
-+--
Changes (by bob.simons):

 * status:  new => closed
 * resolution:   => wontfix


--
Ticket URL: <http://cf-pcmdi.llnl.gov/trac/ticket/159#comment:7>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

[CF Metadata] #160: Proposal to use GitHub instead of trac

[CF Metadata]

#160: Proposal to use GitHub instead of trac
+--
 Reporter:  jonathan|  Owner:  cf-conventions@…
 Type:  task| Status:  new
 Priority:  medium  |  Milestone:
Component:  cf-conventions  |Version:
 Keywords:  |
+--
 Dear CF committee and all

 I'm pleased to say that Tanya Reshel at PCMDI is making good progress with
 working through the tickets which had been accepted by the end of Jan,
 which we agreed would define CF1.7, and implementing them in the new
 !AsciiDoc source of the CF document on !GitHub, with some advice from Jeff
 Painter, David Hassell and me. Thank you, Tanya.

 It's been suggested several times, and most recently by Rich Signell on
 the email list, that we should consider moving CF conventions discussions
 to !GitHub. We agreed as a committee (recorded in cf-
 trac.llnl.gov/trac/ticket/146) to revisit this issue when we had more
 experience of managing the CF document on !GitHub, so perhaps this is now
 the time to discuss it. The suggestion is to replace trac tickets, for
 discussions of changes to the convention, with !GitHub issues; the email
 list, for more general discussion, not directed to agreeing a particular
 proposal, could continue as it is.

 At the moment we have a system, maintained by Jeff, to synchronise the CF
 email list, maintained at NCAR, with an email distribution list for trac
 ticket updates, so that everyone receives both after subscribing to the
 email list. The present system in principle allows people to be on one but
 not the other, but in practice there is no-one who's chosen to do that, so
 it does not seem to be a requirement. I think it's important that everyone
 should be notified of conventions discussions, because otherwise not
 enough people will engage with them, since they won't know.

 Jeff thinks it would be simple to forward all !GitHub notifications from
 CF conventions discussions to the CF email list. People who don't want
 them can filter them out. Subscribers who are mentioned by !GitHub name in
 an issue would receive two copies; that's a minor inconvenience, but if
 everyone is getting them anyway there's probably no need to mention anyone
 by name. Clearly this would be an easier system to maintain.  There would
 probably be no need to have a list of subscribers to CF on !GitHub; anyone
 with a !GitHub account could open an issue.

 trac is quite familiar to us now and has served our purpose well. !GitHub
 is a bit more complicated because it can do more. !GitHub is probably more
 popular now. Would !GitHub be suitable for us, do you think?

 It would have the advantage that, when there is text to discuss, the
 proposer could make a branch of the CF conventions document and edit it,
 to show exactly what is proposed. I do not think that it should be
 ''required'' to do it that way, though, because (a) it's not always the
 clearest way to see things, when they're scattered through several parts
 of the document, (b) it could be an obstacle to some proposers, who would
 prefer to write out their proposed changes in their postings to the issue.
 An editor would then still be needed to implement the changes, once
 agreed, in the document source.

 If we decide to migrate, I think we should do it once CF1.7 is finalised,
 so that there are no agreed tickets to be migrated. We could then leave
 the trac system in place for reference, but not permit new tickets. Any
 existing active tickets could be allowed to come to a conclusion on trac.

 Standard name proposals could also be done as !GitHub issues, I suppose.
 They come from a much wider range of contributors than conventions
 proposals. Would !GitHub be a barrier for proposers?

 Best wishes

 Jonathan

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/160>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #160: Proposal to use GitHub instead of trac

[CF Metadata]

#160: Proposal to use GitHub instead of trac
-+--
  Reporter:  jonathan|  Owner:  cf-conventions@…
  Type:  task| Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--

Comment (by balaji):

 Dear Jonathan and others: I have been following the exchanges and I am in
 favour of moving to Github. The branching alone, as outlined, would be a
 significant step forward toward a way of working on provisional standards
 within small groups.

 The danger is of branches becoming long-lived enough to become more of a
 fork than a branch. Developers of software that is dependent on a
 particular version of the conventions have to be aware of the risks of
 committing themselves to a version not on the trunk; but beyond that I can
 very easily see a lot more flexibility builtin into a github-based
 approach.

--
Ticket URL: <http://cf-pcmdi.llnl.gov/trac/ticket/160#comment:1>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #160: Proposal to use GitHub instead of trac

[CF Metadata]

#160: Proposal to use GitHub instead of trac
-+--
  Reporter:  jonathan|  Owner:  cf-conventions@…
  Type:  task| Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--

Comment (by ngalbraith):

 I agree that GitHub is a good option, although I'd like to keep the email
 list available for standard name proposals. For some people, having to use
 GitHub might be enough of a challenge that they'd simply bypass the
 process altogether.

--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/160#comment:2>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #160: Proposal to use GitHub instead of trac

[CF Metadata]

#160: Proposal to use GitHub instead of trac
-+--
  Reporter:  jonathan|  Owner:  cf-conventions@…
  Type:  task| Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--

Comment (by david.arctur):

 On using github for the discussion of standard names, one part of me
 prefers the current approach of using the mail list without even trac;
 keeps the cognitive barrier as low as possible to encourage the broadest
 discussion. The other part of me feels that a reference like standard
 names needs stronger guidance and would perhaps benefit from a more rule-
 based approach like used for CSDMS names. How are CSDMS names proposed,
 discussed & decided?

--
Ticket URL: <https://cf-pcmdi.llnl.gov/trac/ticket/160#comment:3>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #160: Proposal to use GitHub instead of trac

[CF Metadata]

#160: Proposal to use GitHub instead of trac
-+--
  Reporter:  jonathan|  Owner:  cf-conventions@…
  Type:  task| Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--

Comment (by lowry):

 GitHub seems very popular in the technical fora that I follow whereas Trac
 is virtually unknown outside CF. I would therefore support the migration
 and the clear, thought through migration strategy proposed by Jonathan. I
 would also strongly support Nan and David's view that GitHub isn't the
 place for CF-Standard Name discussions. As they both point out,
 participation in those discussions should be made as easy as possible. I
 would also recommend that we decouple any discussions on the Standard Name
 process and possible alternatives from this ticket.

--
Ticket URL: <https://cf-pcmdi.llnl.gov/trac/ticket/160#comment:4>
CF Metadata <http://cf-convention.github.io/>
CF Metadata

Re: [CF Metadata] #160: Proposal to use GitHub instead of trac

[CF Metadata]

#160: Proposal to use GitHub instead of trac
-+--
  Reporter:  jonathan|  Owner:  cf-conventions@…
  Type:  task| Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--

Comment (by mggrant):

 Moving to !GitHub is a good idea.  It will be more accessible to more
 people - getting a trac account here is a bit more manual, which
 inevitably imposes barriers to participation.  It'll reduce maintenance
 burdens for LLNL too.

 While I think issues might be good way to organise standard name requests,
 there might be some problems ensuring that everyone relevant hears about
 them and is able to easily respond - the mailing list is certainly
 simplest.  Perhaps trial github with the tickets/issues/as a trac-
 replacement first, and consider a process for standard names later if the
 community seems to like the github workflow.

--
Ticket URL: <https://cf-trac.llnl.gov/trac/ticket/160#comment:5>
CF Metadata <http://cf-convention.github.io/>
CF Metadata