NOTE: The cf-satellite mailing list is no longer active. The list archives are made available for historical reasons.
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
cf-satellite archives: