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

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 that
the 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 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 wouldnot 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 anglethan the general coverage concept (i.e. less generalized coverage 
capability)

Are there cases I am forgetting that might cause problems for 2D
implementors?

Aaron
  • 2008 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the galeon archives: