For the WCS not to disallow N-D access in the core, all of the
operators/functions/concepts for operating on N-D data (such as time,
altitude, and all other non-horizontal spatial
coordinates/operators/filters) must be listed but not be required. The
mechanisms need to be there even though they are not required, or there
is no standardized way to access N-D data through the core specification
alone.
Is a client who does not understand a particular CRS offered by a WCS
implementation non-compliant? For example, my WCS client knows how to
read data in a Lambert Conformal Conic projections, but not in EPSG
2017. My understanding is that CRS's are required to be "well-known",
not that they be in a limited set that all client and server
implementations understand. I see this as a similar case, because just
as a client can decide whether or not it knows how to deal with a
particular CRS, it can also decide whether it is capable of dealing with
any particular dimensionality of data. Both seem like discoverable
aspects of the native dataset.
Aaron
Wenli Yang wrote:
I might be wrong about why the core vs extension design was introduced. But I guess that the reason to have a
"core" was to set a MINIMUM requirement for a WCS server to be considered compliant. Anything in
"core" means mandatory. Thus,the reason that ONLY 2-D, but not a more general n-D, is mandatory was to make it
easier for servers/clients to be considered "compliant". If the core requires n-D, with n being > 2
included, then a 2-D client is considered "NOT compliant" when it fails to understand a 4-D server's offering of
subsetting along some non-spatial dimensions/axes.
On the other hand, I would like to see n-D data to be included in WCS. Most of
the data sets I have used are 3D data arrays (two spatial D plus a parameter D)
and some are 4D (two spatial plus one time plus a parameter dimensions). I
perhaps feel more comfortable of seeing my data as just an n-D data array
without having to tell domain dimensions from range axes.
-- Wenli
