NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
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 thatthe 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 anN-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 mandateany particular encoding format or specific CRS/data projection, it wouldnot mandate the dimensionality of the data. As in cases where anunknown 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 thecurrent extensions are described and laid out. Minimizing the number ofextensions 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 coveragecapability) Are there cases I am forgetting that might cause problems for 2D implementors? Aaron
galeon archives: