NOTE: The wcsplus mailing list is no longer active. The list archives are made available for historical reasons.
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.
Thanks.
Ethan
--
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/
---------------------------------------------------------------------------
wcsplus archives: