Richard Ullman wrote:
> 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.
Hi Richard,
There is no explicit support for swath data in CF, so it is not
surprising to hear that there are significant gaps relative to NPOESS
needs. And I know that there is a long tradition of relatively complex
encodings for satellite calibration information in the (HDF) files, as
well. But it might still make sense to develop a specific awareness of
where the gaps are that separate CF curvilinear grids from satellite
swath data. Possibly they can be addressed quickly. Or possibly CF and
NPOESS could be heading towards compatible targets at some time in the
not-too-distant future. Say, after the release of netCDF-4.
Having failed so far to submit comments on the GHRSST spec (read "guilty
conscience"), I understand that our workloads stand in our way
continually on these "good citizen" activities. Still, if you can find
the time ...
- Steve
==========================
>
> 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 <mailto:richard.e.ullman at nasa.gov>
> +1 301 614-5228
> NESDIS/IPO
> System Engineering, Data/Information Architecture
> richard.ullman at noaa.gov <mailto:richard.ullman at noaa.gov>
> +1 301 713 4866
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20061114/6eb86264/attachment-0002.html>
Received on Tue Nov 14 2006 - 17:05:06 GMT
