Dear Jonathan et al.,
what is the difference between a mean value and an observation count?
You may add the 25th percentile to this list as well. As far as I can tell, the
cell_methods attribute should be best suited for all of these and I don't see a
need to work with standard_name modifiers. Blank separated lists would indeed
be useful for this case.
float thetao(lat,lon);
thetao:standard_name="sea_water_potential_temperature";
thetao:ancillary_variables="nobs flags";
thetao:units="degC";
float so(lat,lon);
thetao:standard_name="sea_water_salinity";
thetao:ancillary_variables="nobs flags";
thetao:units="psu"; // not allowed currently---but that's a different story!
int nobs(lat,lon);
nobs:standard_name=" sea_water_potential_temperature sea_water_salinity";
nobs:cell_methods="count(time)" // syntax may be wrong - I didn't look
it up
int flags(lat,lon);
flags:flag_values = 0, 1, 2;
flags:flag_meanings = "accepted_value range_outlier failed_inversion_check";
Cheers,
Martin
> Message: 2
> Date: Sat, 5 Nov 2011 09:16:18 +0000
> From: Jonathan Gregory <j.m.greg...@reading.ac.uk>
> Subject: Re: [CF-metadata] [cf-satellite] Sharing quality flags
> amongmultiple variables
> To: upendra.d...@noaa.gov
> Cc: cf-metadata@cgd.ucar.edu, cf-satell...@unidata.ucar.edu
> Message-ID: <20111105091618.ga16...@met.reading.ac.uk>
> Content-Type: text/plain; charset=us-ascii
>
> Dear all
>
> Referring to Mike's comment. I agree that the ancillary_variables attribute
> indicates that the status_flag variable is associated with its data variable,
> and
> that alone identifies it to some extent, but (a) it doesn't specifically
> indicate
> its purpose, since there could be more than one ancillary variable for a given
> data variables (status flag, standard error, number of observations, ...); (b)
> the status flag variable can be regarded as a data variable in its own right,
> and
> as such needs a standard_name to be self-describing; it is quite possible, for
> example, that variables for status_flag or number_of_observations might be
> stored in different netCDF files from the variables they describe, and then
> the correspondence would depend on them being distinguishable e.g. by
> standard_name="sea_water_salinity number_of_observations"
> standard_name="sea_water_potential_temperature
> number_of_observations".
> However, when the standard_name modifiers were introduced, I don't think
> we foresaw the possibility that several data variables might need to share
> the same ancillary variable e.g. when the number of observations for salinity
> and temperature are the same.
>
>
> Referring to Upendra's comment. We could introduce both changes, but I
> think we should do that only if really necessary for existing examples that
> are
> likely to represent common use-cases. We should not complicate the CF
> standard more than we have to! I would say the same about Mike's
> ingenious scheme for include-statements.
>
> If it would serve the purpose that began this discussion, personally I would
> favour the first solution, and generalise the use of the standard_name att,
> like Edward said e.g.
>
> float thetao(lat,lon);
> thetao:standard_name="sea_water_potential_temperature";
> thetao:ancillary_variables="nobs flags";
> thetao:units="degC";
> float so(lat,lon);
> thetao:standard_name="sea_water_salinity";
> thetao:ancillary_variables="nobs flags";
> thetao:units="psu"; // not allowed currently---but that's a different story!
> int nobs(lat,lon);
> nobs:standard_name="sea_water_potential_temperature
> sea_water_salinity number_of_observations"; int flags(lat,lon);
> flags:flag_values = 0, 1, 2;
> flags:flag_meanings = "accepted_value range_outlier
> failed_inversion_check";
>
> That is, we would change the text in CF sect 3.3 that reads
>
> "A standard name is associated with a variable via the attribute
> standard_name which takes a string value comprised of a standard name
> optionally followed by one or more blanks and a standard name modifier (a
> string value from Appendix C, Standard Name Modifiers)."
>
> to
>
> "A standard name is associated with a variable via the attribute
> standard_name which takes a string value that can have either of two forms.
> The first form is a standard name alone. The second form is a blank-
> separated list beginning with one or more standard names and ending with a
> single standard name modifier (a string value from Appendix C, Standard
> Name Modifiers) i.e. standard_name [standard_name ...]
> standard_name_modifier. This second form permits a single variable to
> provide ancillary data (see Section 3.4) for several variables that have
> various
> standard names."
>
> Naturally this would require change to software, such as the CF_checker,
> which analyses the standard_name att, but it would not require any change
> to software which uses the complete att simply as an identifying string, to
> label plots, etc.
>
> What does you think?
>
> Cheers
>
> Jonathan
>
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
