Nan,
Tom sent multiple emails regarding different variables / standard names, and I think perhaps my reply was in reference to a different email than the one you replied to. My reply below was referring to a variable containing ?Snow Melt Onset? data. Here?s the relevant text.
Layer 2: Snow Melt Onset (melt onset condition at each sea ice covered pixel at start of melt season)
3000: no melt onset
3010: current melt onset
3011: future melt onset
3061-3245: day of year on which melt began
I think the basic issue was that multiple types of information were being packed into a single variable, and done in a non-separable fashion. I believe a variable such as this is too complicated and specialized to be given a standard name. If there was one variable containing the date of melt onset, and another containing the status flags, I could see the first meriting a standard name (if there isn?t an appropriate one already). It seems to me that the status flags would still be too specialized to merit their own standard name.
Grace and peace,
Jim
Visit us on
Facebook Jim Biard
Research Scholar
Cooperative Institute for Climate and Satellites NC
North Carolina State University
NOAA's National Climatic Data Center
151 Patton Ave, Asheville, NC 28801
e: jbiard at cicsnc.org
o: +1 828 271 4900
On Nov 19, 2013, at 10:46 AM, Nan Galbraith <ngalbraith at whoi.edu> wrote:
> 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> 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
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> CF-metadata mailing list
>>> 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 *
> *******************************************************
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20131119/58361d33/attachment-0001.html>
Received on Tue Nov 19 2013 - 09:09:03 GMT
