⇐ ⇒

[CF-metadata] Satellite community use of netCDF CF (GHRSST-PP)

From: Jonathan Gregory <j.m.gregory>
Date: Mon, 16 Oct 2006 18:40:21 +0100

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
Received on Mon Oct 16 2006 - 11:40:21 BST

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:40 BST

⇐ ⇒