Hi Steve et al.,
Looks like we aren't doing too badly with regard to CF-compliance.
More standard names for the GHRSST variables seems to be in order.
The GHRSST team will need to look carefully to see what new names we
might need to propose.
Did anyone else in the CF community look at the GHRSST data products
for CF -compliance??
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_?
>
>I see that there are variety of quantities, which identify themselves via
>the long_name and the name of the variable. This is CF-compliant but greater
>interoperability could be achieved by the of standard names. (CF doesn't
>standardise long_names or variable name, but anyone is welcome to do so for
>their own purposes.) GHRSST evidently needs some new standard names. Some of
>the kinds of data are possibly ancillary data (CF 3.4), for which we would
>define new standard_name modifiers rather than standard names. If someone
>had to time to post the list of quantities to the CF email list, identifying
>which ones don't currently have standard names or modifiers, it would be a
>useful starting-point.
>
>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).
>
>It would be more self-describing to make the file_quality_index a string.
>
>In the CF standard, add_offset and scale_factor are not attributes of coord
>variables, only of data variables. I can't see a reason for this restriction,
>but perhaps someone can remember.
>
>Not really a CF issue, but I would be concerned that the global attributes of
>extreme lat and lon might be inconsistent with the coord variables, so I
>wonder whether that redundancy can be avoided.
>
>I hope that helps. Best wishes
>
>Jonathan
--
~ed
Edward M. Armstrong
Physical Oceanography DAAC Tel: 818 393-6710
Jet Propulsion Laboratory Fax: 818 393-2710
edward.armstrong at jpl.nasa.gov
Received on Thu Nov 09 2006 - 14:45:50 GMT
