Hi all,
[cc'd to wcs.rwg as well]
This is a great discussion (even as it has wandered in & out of several
mail-lists and subject headings; if someone wants to forward this to the
wfs.rwg that'd be great. :-).
Ideally (in WCS 3.0 ??), WCS would be agnostic about the underlying data
structure. It would describe a "pure" spatial function, and (as for
formats and grid sizes today) it would offer to represent that function
using the user's or providers' choice of data structure: a rectangular
grid perhaps, or contour lines, a TIN, an irregular point mesh,
hexagonal tesselation, etc. (The provider might highlight some of these
as more "natural" / "native" / "raw" than others.)
Any of these data structures could obviously be represented as a
collection of atomic features with a common schema; or as a single
feature with space-varying attribute(s); or as observations. Coverages
are a matter of interpretation; the provider can suggest a "coverage
interpretation" of the provided data by supplying an interpolation
method alongside the data; but the user might ignore this and treat each
"datapoint" in isolation. So WFS / WCS / SOS could provide different
views (or suggest different interpretations) of the same underlying
information.
In fact, one of the key reasons for limiting WCS to grids so far has
been interpolation -- needed whenever a client request entails
reexpressing the coverage using a non-native geometry (e.g., in less
spatial detail or in a different CRS); or requires values at the edges
of coverages or of bounding boxes. For WCS 1.0 and 1.1, the costs of
agreeing on a more general (non-grid) treatment of interpolation
outweighed the benefits; but it would be great to do this at some point.
Simon.Cox@xxxxxxxx wrote:
/Notwithstanding/ the current interest in fully unifying the feature
and coverage views
(through the CRS generalization activity, for which the logical
outcome is CRS=FeatureType),
I believe that feature, coverage, observation, catalogue can /already/
be seen as merely different views onto, projections of, or sections
through, the underlying data soup.
There now appears to be some agreement that a "feature" may have a
property whose value varies in some way "across" the feature, for
example in time or space (see sub-clause 6.5.3 and Figure 4 of
Observations and Measurements
- OGC 05-087r4
http://portal.opengeospatial.org/files/?artifact_id=17038) and that
this value is a "Coverage" whose domain extent is the feature.
In the proposed update to the SamplingFeatures clause (see OGC
07-002r1
http://portal.opengeospatial.org/files/?artifact_id=20934&version=1
<http://portal.opengeospatial.org/files/?artifact_id=20934&version=1>)
this is generalized further to allow variation with respect to
non-spatial axes inherent to the "feature" (see sub-clause 7.1 and
Figure 2).
I've also been thinking about the implications of this model in terms
of service composition:
For example, if a feature type has a property with a coverage value,
then a WFS "GetFeature" request for such a feature might use a
GetCoverage request to a WCS "cascaded" behind the WFS in order to
fully compose the response. There are some other similar interactions
potentially implied by other SOS and specialised WFS operations.
I had presented this in the form of what George Percivall calls "your
horrible powerpoint picture"
a couple of times in OGC forums mid last year (e.g. in the SWE WG at
the Edinburgh TC).
I think George's main problem was that my "SOS" pattern put a WFS and
WCS behind the SOS,
instead of vice-versa, which would match the idea of "observations" as
being in some sense "more primitive" that features. However, I still
stand by that analysis, and I have now added a couple of other
variants, based on the "Sampling Feature Service" viewpoint, the
"Domain Feature Service" viewpoint, and the "just the data" viewpoint.
They are still in horrible PPT-ML, pending Bryan helping me figure out
how to show it in UML,
and definitely could use some refinement, but maybe time to share the
ideas ... see attached.
Simon
