[EMAIL PROTECTED] wrote on 10/25/2005 06:17:21 AM:
> Zitat von Martin Desruisseaux <[EMAIL PROTECTED]>:
>
> > "In this International Standard, coverage is a subtype of feature.
> > A coverage is a feature that has multiple values for each
attribute
> > type, where each direct position within the geometric
representation
> > of the feature has a single value for each attribute type."
> >
> > The first sentence is easy to understand, but I admit that I have a lot
> > of trouble to understand what the second sentence means.
>
> After having read the sentence several times I believe I know what they
try to
> say:
> As we know one coverage can contain multiple attributes (f.e.
> multiple spectral
> bands in a remote sensing image).
> The second part of the sentence says that (of course) each pixel hasone
value
> for each of the attributes (bands), but since the whole coverage is a
> collection of all pixels, the coverage itself cannot have just ONE value
for
> each attribute, but has "all possible values" as the value for the
respective
> attribute (band).
> Example:
> - Pixel x of band 3 in a Landsat TM image has DN value 50
> - But in the Coverage, that contains pixel x the band 3 has the values
{0, 1,
> .., 255}
Very close, but not quite. These are different views of the _same_ data.
"band 3 in pixel x" would be 50 DN in both cases, because we're talking
about the same pixel in the same scene.
Think of features as spatial data points and coverages as spatial
functions, or operators. A data point is a data point. The data were
taken at a specific point and specific values are assigned to the result.
A function is a way of letting the result vary as a function of a spatial
parameter.
Let's get away from grids for a moment because we're reinforcing the myth
that features = vector data and coverages = raster data. Our data set is
now temperatures. For the oceanographers among us, we'll make them come
from buoys.
We have a very simple "FeatureType" to define, consisting of the "geometry
(point)" and the "temperature (double)".
Now, say all the buoys take a reading at 1200Z. We have two options on how
to organize the data:
1] Make one feature for every buoy; then dump them into a
FeatureCollection.
2] Make a DiscreteCoverage for temperature and add the readings.
With option #1, each feature is totally independent. Each feature has it's
own copy of the FeatureType. The resultant FeatureCollection contains no
inherent guarantees that every member will contain an identical
FeatureType. There is no inherent concept that the members of the
FeatureCollection are an attempt to provide different _values_ to the same
_parameters_ at different _locations_.
A Coverage addresses all of these shortcomings. The _coverage_ possesses a
FeatureType. Data added to the coverage must provide a location (which may
be a point, polygon, line, multipolygon, etc.) and an associated value
(which must conform to the Coverage's FeatureType). The Coverage
inherently knows that its members are attempting to describe the spatial
variation of the parameters in its FeatureType, in this case: temperature.
The Coverage contains a mechanism for returning all of its members. It
allows users to make queries about arbitrary locations (e.g., what is the
temperature at location X, where X may or may not be the location of one of
it's data points.)
The most important thing a Coverage brings to the table is the
understanding that all of its members describe spatial variation of a fixed
set of parameters. With this understanding, one can ask the coverage for
the 10 deg C isotherm contour. This is the function of the
evaluateInverse() method. You can ask the coverage (which consists of a
collection of point measurements) for an isotherm (which may not intersect
any of the buoys). This is only made possible because a coverage is a very
special type of featurecollection which has a very specific intent
(mapping).
The members of a coverage do not have to completely partition a spatial
region. Members can overlap. A coverage contains controls to configure
its response under these special conditions. If the requested location is
not the location of any of the buoys, a coverage can respond with "no
data", it can lookup the nearest buoy and return that value, or it can
interpolate to the desired location in a variety of ways. If more than one
member tries to supply a value for a given location (e.g., "bowtie" effect
in a satellite image), some method for resolution must be specified.
Once this is understood, then one can move on to "spatially ordered
collections of measurements": ie, grids, tins blah blah blah. These
involve making assumptions about the spatial relationships of the
coverage's members. These assumptions generally allow for more efficient
storage and retrieval of specific values. They also generally permit more
efficient interpolation to off-grid locations.
So, let's revisit the second sentence above. "A coverage is a feature that
has multiple values for each attribute type, where each direct position
within the geometric representation of the feature has a single value for
each attribute type." This is a long and confusing way of saying: "A
coverage is a feature where the value of each attribute is a function of
location."
So:
1] Regular features are "constants" (value does not depend on location, but
has a specific location assigned).
2] Coverages are FeatureFunctions (value depends on location).
3] Coverages are single-valued FeatureFunctions (one location == one
value).
4] Regular features are data points from which a coverage can be made.
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
