NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
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 much additional complexity is imposed on clients. A process for describing the 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 would not 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 angle than the general coverage concept (i.e. less generalized coverage capability) Are there cases I am forgetting that might cause problems for 2D implementors? Aaron Wenli Yang wrote:
George, Core requires a "DomainSubset" element. While the DomainObject can be n-D. Core requires the DomainSubset with BoundingBox parameter but does not require TemporalSubset. For the BoundingBox, it requires 2D, which I believe refer to "two near horizontal Ds". If an implementation implements 3D (or >2D), it should have the capability of 2D as well, unless the 3- or n-D (n>2) does not include the "two near horizontal Ds). I guess that the requirement in core on "two near horizontally Ds", which are traditionally geographic/cartographic Ds (i.e., geographic or projected CRSs), may cause problem for some of the metaocean data such as the vertical profile data I mentioned in one of my previous email. A profile may have only one horizontal D and one or more other Ds such as time and pressure. Wenli
galeon archives: