A key point in this discussion is whether this quality-related information should be intended to be solely for users to read, or whether we ultimately want it to provide info that is actionable for programs?
Philosophically, I tend to prefer the latter, but OTOH am only too aware of how much information needs to be embedded for programs to correctly interpret quality variables. (It's harder than it looks...)
On Nov 1, 2011, at 1:44 PM, Armstrong, Edward M (388M) wrote:
> Hello,
>
> That assessment seems to be the crux of the problem. Its look like CF wants a specific quality variable standard name, an approach that won't work for one quality variable applicable to many other data variables.
>
> But the standard_name in not required, is it ? So a simple "comment:" statement could remind the user the data variables a particular quality variable is applicable for. Or could you have a list of standard_names in the quality variable (would require new CF "rules" ) ?
>
> On Nov 1, 2011, at 11:38 AM, Jonathan Gregory wrote:
>
>> Dear Upendra
>>
>>> On 11/1/2011 10:47 AM, Upendra Dadi wrote:
>>>> The same issue occurs with World Ocean Database which consists of
>>>> mainly profile data. Each profile typically consists of several
>>>> variables measured along the depth. The quality flags used for all
>>>> the variable are same.
>>
>>>> On 10/31/2011 12:12 PM, Randy Horne wrote:
>>>>> The current CF conventions dictate that quality flags are
>>>>> attached to specific variables. The implication is that
>>>>> comforming with CF conventions would require the same quality
>>>>> flags to be stored multiple times in our NetCDF product files.
>>
>> Quality flags are attached to variables using the ancillary_variables att of
>> the data variable. If several data variables had the same quality flags and
>> dimensions, they could all point to the same quality variable. Perhaps the
>> problem is that the different variables have different standard names, and
>> this means the quality variables would also have different standard names
>> (and therefore could not be the same variable)? If that is the problem, perhaps
>> we could find a way round it. Or have I missed the point?
>>
>> Best wishes
>>
>> Jonathan
>>
>> _______________________________________________
>> cf-satellite mailing list
>> cf-satellite at unidata.ucar.edu
>> For list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/
>
> -ed
>
> Ed Armstrong
> JPL Physical Oceanography DAAC
> 818 519-7607
>
>
>
> _______________________________________________
> cf-satellite mailing list
> cf-satellite at unidata.ucar.edu
> For list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/
Christopher Lynnes
Goddard Earth Sciences Data and Information Center, NASA/GSFC
301-614-5185
Received on Tue Nov 01 2011 - 11:50:54 GMT
