NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
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: