This message came from the CF Trac system. Do not reply. Instead, enter your
comments in the CF Trac system at http://kitt.llnl.gov/trac/.
#113: Review of CF feature types
-------------------------------------------------+-------------------------
Reporter: mgschultz | Owner: cf-
Type: enhancement | conventions@…
Priority: medium | Status: new
Component: cf-conventions | Milestone:
Keywords: featureType, Grid, Point, | Version:
TimeSeries, Profile |
-------------------------------------------------+-------------------------
\
\
While comparing the CF1.6 document with the INSPIRE data specifications
for atmospheric conditions and meteorological features and the Unidata
THREDDS code/web pages, I found large overlap, but also a few
inconsistencies or ambiguities plus the promise that future versions of
the convention would deal with "difficult" feature types such as time
series of regionally aggregated information, the description of fronts
etc. Maybe this is a good time to initiate this discussion?
This post has two sections: 1) some specific suggestions for changing the
contents of the (1.6) conventions document, 2) an overview of feature
types including their definitions and representations that tries to
harmonize across the three different sources. I have not yet dared to
tackle the new feature types mentioned above.
1) Specific changes recommended to the conventions document:
* The text in section 9.1 just below Table 9.1 says "The space-time
coordinates that are indicated for each feature are mandatory.". However,
in section 9.2 there is a seemingly contradictory statement "If there is
only a single feature to be stored in a data variable, there is no need
for an instance dimension and it is permitted to omit it." -- I propose to
clearly label the optional indices as optional in table 9.1 and describe
features versus collections before Table 9.1 (i.e. interchange sections
9.1 and 9.2 with potential minor rewriting).
* Would it make sense to specify the maximum allowed dimensions or is this
too restrictive? As far as I can see there may be a small set for each
feature type and it could thus be helpful to have these listed explicitly
rather than stating that extra dimensions can be added at will.
2) Collection of feature types from CF, THREDDS, and INSPIRE:
Note that definitions of terms further down are often incomplete.
* RectifiedGridCoverage: coverage whose domain consists of a rectified
grid – a grid for which there is an affine transformation between the grid
coordinates and the coordinates of a coordinate reference system.
Basically, this means that the 2-dimensional grid can be described by two
1-dimensional vectors (examples: longitude and latitude or UTM easting and
UTM northing). The grid can have additional dimensions such as a vertical
dimension z or an ensemble coordinate e. Thus the representation is
data(m, i, j, k, o) e(m) x(i) y(j) z(k) t(o) with m, k, o optional.
* ReferenceableGridCoverage: coverage whose domain consists of a
referenceable grid – a grid associated with a transformation that can be
used to convert grid coordinate values to values of coordinates referenced
to a coordinate reference system. Thus the representation is data(m, i, k,
o) e(m) x(i) y(i) z(k) t(o) with m, k, o optional.
* Point: one or more parameters measured at a set of points in time and
space (having no implied coordinate relationship to other points). Thus
the representation is data(i) x(i) y(i) t(i) with i optional.
* TimeSeries: a time-series of data points at the same location, with
varying time. A series of data points at the same spatial location with
monotonically increasing times. Thus the representation is data(i, o) x(i)
y(i) t(i, o) with i optional.
* Trajectory: A series of data points along a path through space with
monotonically increasing times (example: backtrajectory model calculation;
aircraft flight path). Thus the representation is data(i, o) x(i, o) y(i,
o) z(i, o) t(i, o) with i, z optional.
* Profile: an ordered set of data points along a vertical line at a fixed
horizontal position and fixed time (example: one balloon sounding or
aircraft takeoff or landing). Thus the representation is data(i, k) x(i)
y(i) z(i, k) t(i) with i optional.
* TimeSeriesProfile: a series of profile features at the same horizontal
position with monotonically increasing times (example: balloon soundings
from a station). Thus the representation is data(i, k, o) x(i) y(i) z(i,
k, o) t(i, o) with i optional.
* TrajectoryProfile: a series of profile features located at points
ordered along a trajectory (example: aircraft lidar profiles). Thus the
representation is data(i, k, o) x(i, o) y(i, o) z(i, k, o) t(i, o) with i
optional.
* ForecastModelRunCollection: a collection of forecast model runs, which
can be uniquely identified by the start of the model run, called the model
run time, also called the analysis time or generating time. Each model run
has a series of forecast times. A collection of these runs therefore has
two time coordinates, the run time and the forecast time. An FMRC creates
a 2D ctime collection dataset, and then creates various 1D time subsets
out of it.
• Image: Image data which may consist of several layers or channels.
Thus the representation is data(i, j, h) c(h) with h optional. (?? Need
optional geo-rectification of images, time series of images etc. ??)
* RADIAL: Radial data
* SECTION: Section data
* STATION: Station data (alias for TimeSeries) -- should aliases be
allowed?
* STATION_PROFILE: Stations of profiles (alias for TimeSeriesProfile) --
should aliases be allowed?
* SWATH: Swath Data
* ANY: No specific type (?? Shall this be allowed??)
* ANY_POINT: Any of the point types (?? What is this needed for ??)
Best regards, Martin
\
\
\
--
Ticket URL: <http://cf-pcmdi.llnl.gov/trac/ticket/113>
CF Metadata <http://cf-convention.github.io/>
CF Metadata
This message came from the CF Trac system. To unsubscribe, without
unsubscribing to the regular cf-metadata list, send a message to
"[email protected]" with "unsubscribe cf-metadata" in the body of your
message.
