@jessicaaustin @mwengren many thanks for these standard name proposals and my 
apologies for the delay in responding. Thank you also to all those who have 
contributed to this interesting discussion.

It seems the discussion has reached consensus on adding the terms as standard 
names rather than standard name modifiers. I think this is the right approach - 
I haven't dug through the [CF mailing list 
archives](http://mailman.cgd.ucar.edu/pipermail/cf-metadata/) but seem to 
recall previous discussions in which the suggestion was made to deprecate the 
use of modifiers altogether, although this hasn't made its way into the 
conventions so far.

The proposals have all now been added to the [standard names 
editor](http://cfeditor.ceda.ac.uk/proposals/1?status=active&namefilter=&proposerfilter=Austin&descfilter=&unitfilter=&yearfilter=&commentfilter=&filter+and+display=Filter).
 The names themselves look fine and canonical units of '1' is correct for flag 
variables.

The proposed descriptions are very clear and understandable, even to a 
non-expert such as myself. The only change I would suggest is some additional 
text to help guide CF users to the most appropriate name. For example, the 
description of gap_test_quality_flag would be:
'A quality flag that reports the result of the Timing/Gap test, which checks 
that data has been received within the expected time window and has the correct 
time stamp. The linkage between the data variable and this variable is achieved 
using the ancillary_variables attribute. There are standard names for other 
specific quality tests which take the form of X_quality_flag. Quality 
information that does not match any of the specific quantities should be given 
the more general standard name of  quality_flag'. Similar text could be added 
to all the descriptions, except for that of aggregate_quality_flag. (This type 
of guidance is provided in the descriptions of many existing standard names, 
such as those relating to salinity or area_type).

Regarding aggregate_quality_flag, I spotted one potential problem with the 
description. The text 'This flag is a summary of all quality tests run for 
another data variable, and is set to the highest-level (worst case) flag found' 
could be understood to refer to the existing quality_flag name as well as the 
specific names in this proposal. Is that what you intend? If not, I suggest 
amending this part of the text to read 'This flag is a summary of all quality 
tests run for another data variable, which have standard names of the form 
X_quality_flag, and is set to the highest-level (worst case) flag found. 
Information contained in a variable having the generic name quality_flag is 
excluded from the aggregate.'

If you are happy with my suggestion for additional help text and can let me 
know which version of the aggregate_quality_flag description is correct, then I 
think all the proposals can be accepted for inclusion in the standard name 
table.

I do have a couple of further questions about aggregate_quality_flag which 
don't affect the current proposal but will be important for future reference:
1. If we were to add standard names for more QARTOD defined quality tests, as 
has already been suggested, would the results of those tests then also form 
part of the aggregate?
2. Would the aggregate flag include the results of quality tests that were 
defined by some standard other than QARTOD if they happened to appear in the 
same data file?

Best wishes,
Alison

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/216#issuecomment-580660455

This list forwards relevant notifications from Github.  It is distinct from 
[email protected], although if you do nothing, a subscription to the 
UCAR list will result in a subscription to this list.
To unsubscribe from this list only, send a message to 
[email protected].

Reply via email to