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

NOTE: The wcsplus mailing list is no longer active. The list archives are made available for historical reasons.

Ethan et al,

As part of a Met Office project to provide the foundation for a Service
Orientated Architecture, I have produced a draft interface specification
for a WCS which will be built on top of "Visual Weather" (a software
package developed by a company called IBL), which will become the future
Met Office forecaster workstation system - I mentioned this work briefly
in an early posting to this mailing list.=20

As this is being developed by IBL, as an enhancement to their software,
it will not be open source, but the interface specification is open, and
the process of drafting this has thrown many of the issues that you have
highlighted below. Therefore, so Jeremy (Tandy) and I thought it would
be useful to share this draft document (attached) with the group. I
should highlight that fact that this is a first draft to facilitate
discussion with IBL, and not a finished specification; as such I know
there are a number of issues with it and some significant gaps.=20

The interface specification is based on WCS 1.0, but I (like others)
found that there were a number of areas, where I had to make design
decision that potentially reduce interoperability. Where this was the
case, I looked initially to follow the approach taken for a WMS that has
already been produced for Visual Weather by IBL (to a Met Office
specification), and them to the THREDDS WCS (which we have been doing
some evaluation work on) and to the early ideas for the WCS 1.0+ spec. I
should also warn you that the document effectively reproduces large
chunks of the WCS 1.0 specification (albeit in a slightly different
format) for clarity.

I'd welcome any comments of this document, but I post it mainly in the
hope of stimulating discussion through the provision of a strawman that
is ripe for criticism!

Bruce Wright  IT Architect
Met Office  FitzRoy Road Exeter EX1 3PB United Kingdom
Tel: +44 (0)1392 886481  Fax: 0870 9005050=20
E-mail: bruce.wright@xxxxxxxxxxxxxxxx

-----Original Message-----
From: wcsplus-bounces@xxxxxxxxxxxxxxxx
[mailto:wcsplus-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Ethan Davis
Sent: 20 November 2007 04:10
To: wcsplus@xxxxxxxxxxxxxxxx
Subject: [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

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.=20
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

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.


Attachment: SOAF-VW_WCS_Specification.doc
Description: SOAF-VW_WCS_Specification.doc

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