[CF-metadata] stations and trajectories (the OTS standard)

From: Nancy Galbraith <ngalbraith>
Date: Thu, 16 Jun 2005 10:35:12 -0400

Thanks for bringing OTS into the discussion, Steve, and thanks for your
comments
Jonathan.

Our operational data is so much simpler than that of some other CF users
that it
sometimes seems we don't exactly fit here, but the CF community and
resources
have been really helpful, and your standard was the obvious choice for
our data.

> But instead they could be CF-compliant by dimensioning
> the data variable as (time,depth) and giving it a coordinates
> attribute to point to auxiliary coordinate variables of lat(time)
> and lon(time).... These are what CF calls "scalar coordinate
> variables" and they avoid introducing a size-one dimension
> just to attach coordinate info.

Maybe I didn't think this through well enough, or I completely missed
one of
the basic CF concepts. I somehow missed that CF files should "avoid
introducing
a size-one dimension just to attach coordinate info" and thought that 4
dimensions was
a reasonable way to go, as it gives you the overall size of the dataset
in one query.
For mooring data, this seems to make perfect sense, or maybe I just
expect it because
it was standard in our old NetCDF implementation, EPIC.

We have not ruled out files containing data from more than one platform
- as we
sometimes deploy arrays of sensors. Such a file would have lat/lon
dimensions > 1,
in all other files these dimensions would be 1. This does lead to a
problem with drifters,
where the X and Y dimensions of the measured parameters are 1 but lat
and long are
of dimension T.

> CF provides a method to attach quality-control info to data
> variables, which OTS could extend to meet their needs in this
> area (CF 3.4).

The CF scheme for QC might help us give the different data providers
more flexibility
than having a defined table as we currently do. The down side is that if
the flag_meanings
are not defined as part of the standard, they can't be interpreted by
software; I'm not
sure how CF users implement this.

We also have some data sets (mine, for instance) where QC information is
more
logically supplied as an attribute, because the data is interpolated
over time to correct
clock drift after initial QC procedures. The original individual points
are gone,
and point-specific QC becomes meaningless.

> They probably would like some additions to the standard
> name table.

I haven't had a problem finding standard names for our parameters yet. I'm
still hoping the udunits system will at some point include conductivity and
salinity units other than 1, though. Meanwhile I'm dealing with this by
specifying CF-compliant "units" and "text_units" that are useful for labels
and don't have to be accepted by udunits.

Cheers - Nan

 
*************************************************************
*Nan Galbraith Upper Ocean Processes Group *
*Woods Hole Oceanographic Institution Woods Hole, MA 02540 *
*************************************************************
Received on Thu Jun 16 2005 - 08:35:12 BST