Re: [galeon] Features and Coverages

NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.

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
  • 2008 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the galeon archives: