Hi Jon,
Feature/coverage is a distinction I've struggled with for some time. George
has pointed to one of the documents that I have found most helpful in terms of
a general conceptual definition of a coverage -- the ISO 19123 document which
is also an OGC spec as George points out.
http://portal.opengeospatial.org/files/?artifact_id=19820
It defines things from a mathematical point of view in terms of what I used to think of
as the independent variables (domain) and dependent variables (range). One area where
ISO 19123 is a bit weak from the metoceans perspective is that it has a limited view of
"continuous" coverages. Where metoceans models the continuous function space
in terms of the equations of fluid dynamics, ISO 19123 does so in terms of strictly
geometric equations. Nevertheless the defining concepts are very valuable and the
discrete coverage concepts map well into our metoceans data collections.
Others may disagree with me on this, but the other documents I find helpful in
understanding these feature/coverage concepts are those of OGC Observations and
Measurements.
http://www.opengeospatial.org/standards/om
In particular they define "features of interest," examples of which might be the Indian Ocean
or the atmosphere above London. This sort of feature fits will into metoceans community which models
such entities in terms of functions governed by the equations of fluid dynamics. Moreover, many of
our observational data collections and forecast model outputs are really just samplings of the value of
those functions at discrete points in space and time. O & M uses the concept of "sampling
features" for that sort of dataset. For me the sampling feature is very helpful for developing an
understanding from the user point of view. The sampling features are generally categorized by
dimensionality: point (a station observation), curve (a vertical sounding), surface (satellite image),
solid (forecast model output).
One other useful element of the O & M framework is that it explicitly deals with
collections of data. For example a collection of measurements and sounding profiles
from observing stations can itself be considered a sampling feature. And such a
collection is a sampling feature that fits into the coverage category just as the
satellite image and forecast model output do. So such collections are considered
coverages even though the spatiotemporal points are not regularly spaced. In the case
of observing stations, the locations have to be specified in a table rather than by an
algorithm. In the case of observations from ground-based radars, the locations are
defined by a table of stations and an algorithm describing the scanning geometry. Many
of our metoceans datasets are just such collections. But the key point is that, in the
world of ISO 19123 and OGC O & M, these data collections are indeed coverages.
Enough for now, but these documents are relatively easy to read and are very
helpful at the conceptual level.
-- Ben
On Tue, Oct 7, 2008 at 10:06 AM, Jon Blower <jdb@xxxxxxxxxxxxxxxxxxxx>wrote:
Hi all,
I'm following on from previous conversations under the subject line
"WCS CF-netCDF profile document", which was getting rather overloaded,
largely my fault. It seems to be important to get a handle on what is
a feature and what is a coverage. We've seen various viewpoints, so I
thought I'd give my view based on a number of conversations that are
slowly crystallizing in my head (thanks go to Andrew Woolf here).
I think a "feature" is just a geographic "thing". The term is not
meant to be discriminative - it's very closely analogous to an Object
in Java, C++ or any number of other programming languages. It's
simply a collection of attributes and methods (operations). A
"Feature Type" is the definition of the feature, analogous to a Class
in OO programming.
A "coverage" is a data structure. It can be used to express the value
of a particular attribute of a feature. For example, a Feature that
expresses a timeseries of temperature at a point might have attributes
encoding the geographic position of the measurement, plus all kinds of
other metadata like the name of the station and so forth. The values
themselves might be encoded as a coverage, which is the "value"
attribute of the feature. (People who are familiar with CSML will
recognise this model.)
So the relationship is that a Feature "has a" Coverage. I think. ;-)
Do others agree or have I got it wrong?
So, if everything is a feature, then perhaps in future WFS will be the
uber-specification that can serve everything? Well, maybe... I think
things will get very (i.e. even more) complicated when we start
thinking about how to subset the Coverage(s) that belong to a Feature,
in the very general case. I can't quite grasp this myself yet. Do we
embed a WCS-like subsetting query inside a WFS query?
What does this mean for the future of WCS?
Cheers, Jon
