Thank you Alison, this is all good. I DO have a couple of issues with this 
paragraph:

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

I like the additional text excluding the generic quality_flag from the 
aggregate, but

1)  In QARTOD, perhaps, it's always true that the aggregate is **set to the 
highest-level (worst case) flag**; that isn't true in all testing schemes. 

There are cases when a test is run and the results are not considered important 
for some reason - failing a spike test because of data is determined to 
represent an actual measurement, or ... failing a gap test because of poor 
telemetry.

The point of the long drawn out discussion was in part to make sure these 
standard names could be used by other QC systems; letting those systems 
document their own method of setting the value of the aggregate is important.

2) Quality tests **run for another data variable**  doesn't seem right - the 
aggregate is normally for tests run on this particular data variable, no?  Why 
not  **run for this or a related data variable**?


Regarding your two questions:

I'd like to have some text describing the best way to convey the name of the QC 
system being used - maybe a recommended attribute on each of these quality 
variables?  That would solve the problem of people mixing QARTOD and other 
tests. Can we do that in the standard name guidance, or does QARTOD need to 
describe that themselves?

Also, could we recommend that the aggregate have a way to list its component 
tests? These could be given as ancillary variables.


-- 
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-580802399

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