Not regarding GHRSST, but I too have been looking at how to map swath
data into CF, in my case, I'm looking at the design for the
NPP/NPOESS data products. I'd like to be able to provide a standard
mapping, but some of the data model conventions we have
just don't seem to map to CF.
Regarding coded flag data as mentioned below: perhaps this is an
area that needs some work in developing a CF profile.
Here is the present design for NPOESS/NPP:
In the NPOESS products, there are quite a few flag values - mostly
quality measures of various kinds and these are
stored as the minimum number of bits required for the number of
discrete flag values. So for example, if the
flag_meanings were "good" and "bad" the flag would be encoded as a
single bit, but if the flag_meanings were
"cloud", "water", "land" then we would use two bits. The flags are
then packed into 8-bit byte values and stored as
variables parallel to the "data" variable. The variable we call a
"Field" and each flag we call a "Datum" and we provide
an offset and size for each. We use the terms "LegendEntry_Name" and
"LegendEntry_Value" to mean "flag_meanings" and
"flag_values" respectively. NPOESS products are stored in HDF which
allows our attributes to be n-dimensional arrays of values.
So for example:
Field_Name:: 1 values of type string::
[0] = QF3_VIIRSNHFEDR
Datum_DatumOffset:: 5 values of type integer::
[0] = 0
[1] = 2
[2] = 4
[3] = 6
[4] = 7
Datum_DataType:: 5 values of type string::
[0] = 2 bits
[1] = 2 bits
[2] = 2 bits
[3] = 1 bits
[4] = 1 bits
Datum_Description:: 5 values of type string::
[0] = SW Radiative Flux Over Ice Quality
[1] = LW Radiative Flux Over Water Quality
[2] = LW Radiative Flux Over Ice Quality
[3] = Sea Surface Temperature Input Quality
[4] = Ice Surface Temperature Input Quality
Datum[0]_LegendEntry_Name:: 4 values of type string::
[0] = Good
[1] = Invalid
[2] = Out of Range
[3] = Exclusion (missing data)
Datum[0]_LegendEntry_Value:: 4 values of type 2-bit field::
[0] = 0
[1] = 1
[2] = 2
[3] = 3
Datum[1]_LegendEntry_Name:: 4 values of type string::
[0] = Good
[1] = Invalid
[2] = Out of Range
[3] = Exclusion (missing data)
Datum[1]_LegendEntry_Value:: 4 values of type 2-bit field::
[0] = 0
[1] = 1
[2] = 2
[3] = 3
Datum[2]_LegendEntry_Name:: 4 values of type string::
[0] = Good
[1] = Invalid
[2] = Out of Range
[3] = Exclusion (missing data)
Datum[2]_LegendEntry_Value:: 4 values of type 2-bit field::
[0] = 0
[1] = 1
[2] = 2
[3] = 3
Datum[3]_LegendEntry_Name:: 2 values of type string::
[0] = Valid
[1] = Invalid
Datum[3]_LegendEntry_Value:: 2 values of type 1-bit field::
[0] = 0
[1] = 1
Datum[4]_LegendEntry_Name:: 2 values of type string::
[0] = Valid
[1] = Invalid
Datum[4]_LegendEntry_Value:: 2 values of type 1-bit field::
[0] = 0
[1] = 1
On Nov 9, 2006, at 4:45 PM, Ed Armstrong wrote:
<snip>
>
>
> At 6:40 PM +0100 2006/10/16, Jonathan Gregory wrote:
>> Dear Steve
>>
>>> As you may know the GODAE High Resolution SST Pilot Project
>>> (GHRSST-PP,
>>> http://www.ghrsst-pp.org/) has adopted a flavor of netCDF-CF as
>>> its data
>>> standard for both the level 2 (swath) data and the level 4
>>> (gridded)
>>> fields.
>>
>> Thanks for posting this. I am glad to see this done but have only
>> just had
>> time for a look at it. In general it seems to conform very well to
>> CF.
>>
>>> 1) _the use of CF for swath data represents a
>>> significant new class of data_ that has not been directly
>>> addressed by
>>> the CF community previously
>>
>> That is true, but it appears to be unproblematic, using the
>> coordinates
>> attribute in the conventional way to provide lat and lon.
>>
>>> 2) the GHRSST community variable names
>>> are encoded as the netCDF variable names; _what considerations
>>> should be
>>> made for CF standard names_?
>>
>> <snip>
>>
>> Several of the quantities are coded flag data. The use of codes
>> isn't really
>> CF-compliant, since CF aims to be self-describing. It can be
>> improved by using
>> the attributes flag_values and flag_meanings (CF 3.5).
>>
>> <snip>
>>
- - - - - - - - - - -
Richard E. Ullman
NASA
Goddard Space Flight Center
richard.e.ullman at nasa.gov
+1 301 614-5228
NESDIS/IPO
System Engineering, Data/Information Architecture
richard.ullman at noaa.gov
+1 301 713 4866
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20061113/89b26111/attachment-0002.html>
Received on Mon Nov 13 2006 - 13:54:33 GMT
