[wcsplus] 2D vs 3D domain and multiple parameters in range

Hi all,

Most of our gridded data is on a projection though a few are lat/lon (all use a spherical earth). Height is on isobaric pressure levels, some height above ground, and some on various layers between two vertical points (in meters, pressure, or sigma). In each "dataset", there are generally several parameters on each coordinate system (x, y, z, and t combination).

Our current 1.0 implementation separates each parameter into a separate coverage and uses the range for Z. Though the spatialDomain/gml:RectifiedGrid contains x, y, and z which seems counter to having Z in the range. Any thoughts on that?

Anyway, since one of the goals of WCS 1.0+ is to "allow multiple fields (with different units) in a coverage range", I'd like to get everyones thoughts on how to describe our data. It seems best to have x, y, and z in the CRS and the various parameters in the range. However, how to describe/identify the CRS doesn't strike me as very straight forward:

  1. We can use any URI to identify a CRS but the 1.0 spec specifies
     "AUTO:4200*", "EPSG:*", "Image", and "Engineering" but not much else.
  2. The OGC URNs for CRS aren't part of WCS 1.0 (and aren't too
     appealing in terms of their complexity for compound CRS that
     require parameters.
  3. Am I missing another option in 1.0?
  4. 1.1 seems to be going down the OGC URN route
  5. Is there a better way?

Also, most of our parameters are not vector fields, so the structure of the 1.0 RangeSet seems a bit ill fitting. The 1.1 Range seems better. And the KVP encoding for GetCoverage range specifications seem much easier to implement. (I.e., you don't have to know the names of a particular coverages range parameters just to validate the HTTP KVP parameters.)

What I would like to do:

  1. Put X, Y, Z in the CRS but I'm not sure how to encode our
     non-standard (spherical earth, parameterized) projections and
     (non-height, layer) Z.
  2. Parameters in a more 1.1 Range rather than 1.0 RangeSet
  3. Native and response CRS as in 1.
  4. Allowed request CRS as lat/lon and our non-standard Z
  5. Would there be any advantage to also allowing "imageCRS" in the
     request CRS? Can we use HEIGHT, WIDTH, DEPTH or RESX, RESY, RESZ
     in that case to specify an array index stride even thought we only
     support "none" for interpolation?

That's all I have for now.


Ethan R. Davis                                Telephone: (303) 497-8155
Software Engineer                             Fax:       (303) 497-8690
UCAR Unidata Program Center                   E-mail:    edavis@xxxxxxxx
P.O. Box 3000
Boulder, CO  80307-3000                       http://www.unidata.ucar.edu/