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
----- Original Message -----
From: Aaron Braeckel <braeckel@xxxxxxxx>
Date: Monday, October 6, 2008 4:02 pm
Subject: WCS core + extensions
Renamed thread per Ben's suggestion.
If a 2D client talks to a 4D server, it has to be able to detect that
the WCS is beyond its capabilities but otherwise I'm not sure that
muchadditional complexity is imposed on clients. A process for
describingthe dimensionality of the server is definitely important
with an
N-dimensional WCS, but I think this is already largely covered by the
CRS description in the current WCS specification. I see it as another
flexible point in the specification. Just as the WCS does not mandate
any particular encoding format or specific CRS/data projection, it
wouldnot mandate the dimensionality of the data. As in cases
where an
unknown CRS is in use by a WCS server, a client makes a decision about
whether it is capable of handling that WCS implementation.
The reason I see N-dimensionality as preferable to a restricted
dimensionality is that the restriction:
-forces non-2D WCS implementors to fulfill a more complicated
extension,even when simple core functionality is all that is needed
-increases the number of necessary extensions, at least with how the
current extensions are described and laid out. Minimizing the
number of
extensions seems beneficial to interoperability overall
-seems to cut the WCS functionality into groupings at a different
anglethan the general coverage concept (i.e. less generalized coverage
capability)
Are there cases I am forgetting that might cause problems for 2D
implementors?
Aaron
