Hi Peter,
So the extensions are global (GetCapabilities) but may affect some of
the options available at the coverage level (DescribeCoverage)?
For example: 1) supported encoding format extensions imply which options
will be available in the supported formats section of the
DescribeCoverage; 2) any extension that spells out the type(s) of CRS
supported imply the structure/dimensionality/etc of the CRS in
DescribeCoverage; and 3) any extension that describes a new type of
interpolation imply the options available in the interpolation section
of the DescribeCoverage.
Is it the extensions job to describe if and how it affects the
DescribeCoverage? Or does the WCS specification spell out certain
locations in the DescribeCoverage that extensions can affect?
Thanks,
Ethan
Peter Baumann wrote:
Ethan-
sorry for the delay. The idea actually is that, as part of the
GetCapabilities response, a server provides a list of all extensions
it knows. (The WCS group would take care that every extension adopted
gets some unique identifier.) As extensions in the end usually boil
down to software components this is a matter of the service instance
in general.
CRSs etc are on a finer-grain level, hence tied to individual
coverages indeed, as you correctly remark, and advertised per coverage
(see DescribeCoverage response). Note that we do not foresee
extensions for individual CRSs. Rather, the set of CRSs that make
sense in presence of a particular extension are defined by the domain
axes (dimensions) - if a server supports only 1-D time series then
probably WGS84 will not be used.
In summary, extensions currently are foreseen to be communicated
"globally" for a server, ie: in the GetCapabilities response.
Hope that helps...
-Peter
