Hi all -
I have a couple of minor problems with the solution that's been proposed
for this question. Maybe I'm not understanding how this data will be
represented,
but it sounds like the actual melt conditions will be encoded into a
variable
that has to be masked to extract the values. If that's correct, I think
we can
do better than calling this a status_flag and suggesting a long name be used
to describe the data.
First of all, while it's true that data can be included in a CF file
without a standard
name, if it's useful geophysical data, we should come up with an
appropriate
name for it. A file with standard names that don't express anything
about the
scientific contents of the file may be CF compliant, but isn't the best
use of CF.
A long name is useful, but not the best way to describe data, since it's
not from
a controlled vocabulary.
It seems to me that there should be a data variable with a standard_name
that
provides the concept of 'surface melt' and has a an attribute that describes
the meanings of the different values Our existing melt terms all seem
to be
more specific than what Thomas needs.
Also, Thomas, with binary masks, the values 0 & 1 just indicate which
bits are on
or off; if the value 4001 has a specific meaning, you convert that to
binary and see
if that bit pattern matches the data record.
Regards - Nan
On 11/12/13 2:44 PM, Jim Biard wrote:
> Thomas,
>
> I think the sort of thing you are wanting to do is covered in a new
> standard name that I thought should have been in the latest release.
> Here's the info about it from previous emails on the topic.
>
> status_flag
>
> A variable with the standard name of status_flag contains an
> indication of quality or other status of another data variable. The
> linkage between the data variable and the variable with the
> standard_name of status_flag is achieved using the ancillary_variables
> attribute.
>
> This is a dimensionless quantity (canonical units = 1).
>
> The status_flag standard name allows you to have a variable that is
> filled with status information about another variable. Notice that a
> variable that uses this standard name is assumed to be linked to
> another variable that contains some sort of measurement data (via the
> ancillary_variables attribute on the other variable).
>
> I don't think that standard names are otherwise associated with
> variables containing only status flags. Standard names are intended
> (for the most part) to identify kinds/classes of scientific measurements.
>
> The specific meanings to associate with particular bit patterns is
> accomplished via the flag_values, flag_masks, and flag_meanings
> attributes on the variable containing the status information.
>
> And one more thing. I don't think it's a violation of CF to have a
> variable without a standard_name attribute. If none applies, none
> applies. The same goes with units.
>
> Grace and peace,
>
> Jim
>
>
>
>
>
> On Nov 12, 2013, at 2:34 PM, Thomas Estilow <esti at rci.rutgers.edu
> <mailto:esti at rci.rutgers.edu>> wrote:
>
>> Hello,
>>
>> My apologies for several messages to the list, I thought separate
>> threads would be best, as each message relates to an individual data
>> product.
>>
>> Our team is working on a gridded product (EASE-Grid 2.0) showing
>> daily Greenland surface melt extent. We discussed possible standard
>> names such as:
>>
>> surface_snow_melt_binary_mask
>>
>> or
>>
>> surface_snow_and_ice_melt_binary_mask
>>
>>
>> Please note, the data flags we are using in each layer of the netCDF
>> are not simply 1 and 0. Any advice or recommendations on how to
>> proceed would be much appreciated.
>>
>>
>> Thank you,
>> Tom
>> _
>> _
>>
>> ---
>> Thomas Estilow
>> Rutgers University Global Snow Lab
>> esti at rutgers.edu <mailto:esti at rutgers.edu>
>>
>>
>>
>>
>>
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
*******************************************************
* Nan Galbraith Information Systems Specialist *
* Upper Ocean Processes Group Mail Stop 29 *
* Woods Hole Oceanographic Institution *
* Woods Hole, MA 02543 (508) 289-2444 *
*******************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20131119/e71c9aa7/attachment-0001.html>
Received on Tue Nov 19 2013 - 08:46:05 GMT
