This is all an improvement. I like Roy's change to the definition of the
aggregate flag, 'an algorithmic combination of the results of all relevant
quality tests', in place of 'set to the highest-level (worst case) flag found'.
I DO have an issue with the term 'related ancillary parent data variable,'
which I think could be shortened to the 'subject data variable', 'parent data
variable', or something similar.
And, I'm not sure I agree with the decision to intentionally NOT describe what
went into the aggregate - doesn't this render it more or less useless? A
handful of new tests might be run on, and added to, a file, without updating
the existing aggregate_quality_flag. This would lead to the assumption that the
agg flag represented a lot of testing, when in fact it did not.
I'd still like to use the ancillary_variable attribute to explicitly tie the
component tests to the aggregate, but that doesn't cover the case of files
where the components are not included in the data file. Could we recommend an
attribute like 'component_tests' for this?
The case where tests are run that follow different standards also seems to
require an additional attribute. If the aggregate isn't going to define the
testing system used, then maybe all the _quality_flag variables need to
indicate which standard was used.
So here is what I'd like to see:
This flag is an algorithmic combination of the results of all relevant quality
tests run for the related data variable. The linkage between the data variable
and this variable is achieved using the ancillary_variables attribute on the
data variable. The aggregate quality flag provides a summary of all quality
tests performed on the data variable whether present in the dataset as
independent ancillary variables or not. It is highly recommended that the
aggregate_quality_flag have an attribute 'component_tests' that includes the
test standards and test names, e.g.
int psal_qc_agg(time, z);
psal_qc_agg:standard_name = "aggregate_quality_flag";
psal_qc_agg:component_tests = "QARTODv1.1_SpikeTest,
QARTODv1.1_RateOfChangeTest, QARTODv1.1_FlatLineTest";
Is that too much information for the data user to expect? Of course, we can
always implement this additional info outside of CF, if it seems too detailed
for the standard name guidance.
--
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-582055078
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].
