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.

Re: [galeon] WCS core + extensions

Aaron Braeckel wrote: 
For example, my WCS client knows how to read data in a Lambert Conformal Conic 
projections, but not in EPSG 2017.  My understanding is that CRS's are required to be 
"well-known", not that they be in a limited set that all client and server 
implementations understand.  I see this as a similar case, because just as a client can 
decide whether or not it knows how to deal with a particular CRS, it can also decide 
whether it is capable of dealing with any particular dimensionality of data.  Both seem 
like discoverable aspects of the native dataset.


True, the client doesn't need to understand EPSG 2017 but it MUST understand CRS.  The later is 
required in core.  Core defines what is MUST but does not say what extension is prohibited.  
When people put 2D into core, it was meant to make 2D (two near horizontal dimensions) a MUST 
but it by no means says additional Dimension is disallowed.  It now seems that this mandatory 
of 2D may cause problem for vertical profile having on one track on the surface.  However, if 
n-D (where n>2) is put into core, one must be able to deal with n>2 D in order to be 
compliant.  I understand that you meant to say "n" here is any integer ranging from 0 
to a whatever possible value.  but, once n is a variable, you will have variable parameters 
(NOT parameter VALUES).  For example, the 3rd-D of a coverage may be wavelength and you need to 
use some parameter name to refer to this 3rd D, such as parameterDimension.  This parameter 
name must be optional, rather than mandatory.  Thus, it cannot be p
ut into core.

Anyway, core means minimum and mandatory.  A client must understand all 
parameter names (again, NOT parameter VALUEs) in core.  A client may not 
understand EGSPxxx, which is a value of the CRS parameter, but it must 
understand the CRS parameter name.  A client does not have to understand a 
parameterDimensionID and, of course, neither possible VALUES for the 
parameterDimensionID parameter.

Finally, I am not defending the core/extension design but just want to point 
out again that the core means mandatory minimum requirements of which all 
server/client must support.
Wenli