[CF-metadata] CF feature types and definitions

From: Jonathan Gregory <j.m.gregory>
Date: Thu, 30 Dec 2010 15:02:21 +0000

Dear Nan, Roy and Rich

John Caron, Steve Hankin and I are working on the featureType proposal. I
think we'll publish a new draft soon. In the current version, timeSeries,
Profile and timeSeriesProfile are all distinguished. Personally I find it
helpful to define the featureTypes in terms of dimensionality:

timeSeries: a series of data points at the same spatial location with
monotonically varying time
        data(i,o) x(i) y(i) z(i) t(i,o) must have t coordinate
profile: an ordered set of data points along a vertical line at a fixed
horizontal position and fixed time
        data(i,o) x(i) y(i) z(i,o) t(i) must have z coordinate
timeSeriesProfile: a series of profiles at the same horizontal position with
monotonically varying time
        data(i,p,o) x(i) y(i) z(i,p,o) t(i,p) must have z and t coords

Here, i is the subscript of the feature, and o and p are subscripts of the
elements within the feature. Thus, the ith timeSeries has single-valued x y
and z coords associated with it, and a set of t coords. However, x y and z are
all optional, so a single timeSeries feature could have a 2D location (x,y) or
a 3D location (x,y,z). The only coord it must have is time.

The timeSeries from sensors at different depths could be contained in a single
data variable of the timeSeries feature type, each with its 3D location. But
that wouldn't indicate they were actually at the same (x,y) location, because
they'd all have different x and y coords (with the same values). For this, a
timeSeriesProfile would be better. A single feature of this type has single x
and y coords, a set of time coords t(p) and a set of depth coords z(p,o),
where p is the profile subscript and o the time subscript. If the depths are
the same at all times, the depth coord can be just z(o).

But I'm not sure that this addresses Nan's concern, "There's a big difference
between a series of profiles at a single x-y location and a time series of
data taken at the same x-y location by different instruments at different
depths." Both of these can be written as a timeSeriesProfile, so they aren't
structurally different - unless the problem is that you would like each depth
to have its own set of times, which isn't allowed above? Please could you
say more to clarify the problem?

In the current draft, the order of dimensions is not prescribed. It doesn't
matter which way round they are. Flexibility is needed because you might want
any one of them to be the netCDF unlimited dimension.

However, in the current draft the featureType is a global attribute, not a
variable attribute. That is because John's software cannot currently deal with
files that mix feature types. Of course you could have a mixture of feature
types in the file, but you wouldn't be able to specify the featureType
attribute or to use the proposed conventions for incompletely filled and
ragged arrays. In the document we say that a future version of CF might allow
a different feature type for each data variable. Is this too restrictive? If
so, a possible way forward would be to allow this flexibility now, but
recognise that John's software, which at the moment is the only implementation
of the new conventions, will not be able to process all conforming files.

Happy 2011

Jonathan
Received on Thu Dec 30 2010 - 08:02:21 GMT