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.
The issue is that each specification (and combination of core/extension specs) applies to both clients and servers simultaneously. That is, some spec combination X which states "a server may offer A or B or C" translates into "a client must be prepared to handle A and B and C". This is the only way that a client really can upfront (ie: before a GetCoverage response is received) decide whether it can talk to this server or not. This is one of our curses: Every "should" in the specification, every "may", every "if...else" multiplies the property space.) more inline... Aaron Braeckel wrote:
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 restricteddimensionality 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?
well, just think about 3-D image pyramids as the analogy to the well-known map navigation accelerator. Also tiling gets a new quality. -Peter
galeon archives: