CF Cluster

The CF Cluster has expanded to include consideration of the more general problem of conventions and best practices for documenting scientific datasets in any format using a variety of dialects. This Category includes pages that are relevant to the CF Conventions.

Objectives

Propose extensions to the CF naming conventions that are relevant to observational data

Create use cases and interoperability demos that demonstrate the value of CF usage in remote sensing

Provide tutorials at Federation meetings on the use of the CF conventions

Possible CF Extensions

1. Spectral bands

Define as dimension rather than coordinate variable

Pre-define band names

Pre-define by wavelength/frequency range

Proposal by Tom Whittaker

2. Data quality

Modifiers such as "percent_cloud_free"

3. Level 3-specific

Local/solar time

4. Level 2-specific

Orbital parameters/swath geometry

5. Level 1-specific

Calibration tables/engineering parameters

netCDF and ISO

Some ideas about the relationship between the netCDF metadata model and ISO are available. Input on those topics are welcome on the NOAA GEO-IDE wiki or here!

netCDF Templates for in-situ data types

NODC has recently proposed a set of netCDF Templates for in-situ data types. These are important potential extensions to the CF Conventions.

netCDF files with groups

Here is a netCDF-4 file created by NDBC which uses groups. The THREDDS link to the dataset is here.

Developing CF standard names for data from ADCPs and current meters

            draft draft draft draft

This is workspace for developing a DRAFT list of terms and definitions to be proposed to the Climate and Forecast standard names committee. Please consider adding your ideas!

Working principles:

• CF is unconcerned with methodologies, and wants to include terms that convey a concept; so e.g. the instrument_heading field should represent the same concept whether the data is from a shipboard ADCP or a current meter attached to a mooring line. In the former case, the value is derived from external sensors (ships gyro, among others) and known constants that describe the instrument's alignment with respect to the ship's hull; in the latter case, it's recorded by the instrument. Broadly applicable terms will be most useful.

• Likewise, it might be possible to define a term like echo_amplitude and re-use it for any number of beams; using variable names and long_name attributes to distinguish between them (EAMP1: long_name='echo_amplitude_beam_1"). This takes a lot of the complexity out of the project, because we don't need names for the outputs of differently configured instruments.

• We can't request standard names for every output of every type of instrument, at least not if we hope to get anything approved, so let's concentrate on instrument alignment first, and then some common outputs (percent good, error velocity ...). Where possible, we should use earth coordinate systems, not relative-to-platform terms.

• The most useful terms will be for processed data that's got earth-relative velocities; this is the data most often shared and so most in need of standard names (and definitions).

CF-Aware Tools

H4CF Conversion Library- provides CF-compliant access to HDF4 and HDF-EOS2 files

Join the Cluster e-mail list

http://www.lists.esipfed.org/mailman/listinfo/esip-cf

External Links

CF Home Page

http://cf-pcmdi.llnl.gov

Read the CF-satellite archives (UCAR):

http://www.unidata.ucar.edu/mailing_lists/archives/cf-satellite

Join the CF-satellite e-mail list (UCAR):

http://mailman.unidata.ucar.edu/mailman/listinfo/cf-satellite

NCAR's proposed CF-compliant format for fixed and mobile radars and lidars (Cf/Radial):

http://www.ral.ucar.edu/projects/titan/docs/radial_formats/cfradial.html

Governance

Chairs: Ted Habermann (ted.habermann@noaa.gov) and Ed Armstrong (Edward.M.Armstrong@jpl.nasa.gov)