Re: [galeon] WCS CF-netCDF profile document

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

Hi Steve & all,

great discussion, I am following most curiously. Two comments:

- publishing a statement of intent: The WCS group certainly would
welcome this, as it helps clarifying positions at an early stage.

- on your thoughts of an OPeNDAP / WCS coupling: That looks good indeed!
As a quick and hasty response, this seems like it mainly requires
protocol translation to obtain WCS code:

   * massage the nc request into a GetCoverage request. I don't know
whether slight modifications of your request URL are possible, but this
one could be translated straightforward:
"http://ferret.pmel.noaa.gov/
  thredds/dodsC/data/PMEL?coads_climatology.nc
,COADSX,COADSY,TIME[0:1:0],SST[0:1:0]" (note that the coverage name, as we would see it, becomes part of the 
parameters). Actually some Tomcat magic might do that even based on your
URL structure.

   * choose an asynchronous response type (still under work, because
all of OGC seems to need it, hence it has been escalated from WCS to the
five-star gurus ;-) ) which will return a URL. Most likely it will be
embedded in some SOAP, or at least XML, wrapper which needs to be
removed by the protocol translator.

...how do you feel about such a approach?

cheers,
Peter


Steve Hankin wrote:

Hi Stefano et. al.,

Ben and I just made a step towards closing the loop on this
conversation through a telephone call.  We found ourselves to be
wildly in agreement. :-)    .  Based upon your email below, it sounds
like we may all be very close to agreement (ah, the eternal optimist ;-) ...). 

On the phone Ben and I agreed to propose the following two actions for
the short term.  For everyone's comments, please:

   1. GALEON should issue some form of announcement on its *intention*
to investigate encapsulating the OPeNDAP protocol within WCS (perhaps following the template offered by JPIP). This 
      announcement would be intended to begin to erase the perception
      of a divide between OPeNDAP and WCS as soon as possible.
   2. We should conduct a quick investigation of whether there may be
      a simple approach to embedding OPeNDAP into WCS that can be
      achieved as a very small delta on the draft "WCS CF-netCDF
      profile document" (the subject line of this dialog).  _See the
      PS below_ for details about this idea (especially John Caron for
      TDS implementation thoughts)

    - Steve



P.S. Some thoughts on quickly embedding OPeNDAP into the document,
"Web Coverage Service (WCS) 1.1 extension for CF-netCDF 3.0 encoding,
1.0":

    A simplified view of OPeNDAP for purposes of this discussion is
    that it is a transparent mechanism by which an application can use
    netCDF API calls on a remote file.  Thus for any netCDF subset
    that may be derived from a TDS server, there is an OPeNDAP URL
    that is an indirect reference to that same subset.  For example
    consider the dataset coads_climatology.nc, served by TDS at
http://ferret.pmel.noaa.gov/thredds/dodsC/data/PMEL/coads_climatology.nc.html. The dataset contains 12 months of grids for seven different 
    surface met fields.  Imagine a WCS GetCoverage request that would
    return a netCDF file containing global SST for the month of
    January.  The contents of this exact netCDF subset can be
expressed by the OPeNDAP URL: "http://ferret.pmel.noaa.gov/thredds/dodsC/data/PMEL/coads_climatology.nc?COADSX,COADSY,TIME[0:1:0],SST[0:1:0]"; Essentially the netCDF file is just a de-referencing of this URL. An application program that can utilize the netCDF file can (in 
    principal) utilize the URL equivalently.  (I just tested this
    particular example with Ferret and behaved exactly as it would
    with the local file.)

    Now,  the document,  "Web Coverage Service (WCS) 1.1 extension for
    CF-netCDF 3.0 encoding, 1.0", describes a WCS GetCoverage response
    that returns a netCDF _file_ as its payload.  Could we envision a
    small change to this document that described returning an
    equivalent URL instead of the file itself?  Such an approach could
    open the door to OPeNDAP-WCS fusion now (in the document version
    1.0).  And then in a subsequent version of the document the ideas
    could be fleshed out with discussions of further OPeNDAP protocol
    issues -- access control, latency, proxying, streaming, etc.

    I realize this suggestion is awfully "sloppy", when compared to
the thorough and careful work you have done in the document. Maybe the contrast would be acceptable as long as OPeNDAP is 
    confined to an appendix at this point.  There also may be better
    ways to return the OPeNDAP URL -- perhaps as two pieces,
    separating the base URL from the key constraints:

        * base URL:
          
"http://ferret.pmel.noaa.gov/thredds/dodsC/data/PMEL/coads_climatology.nc";
        * key constraint: "SST[0:1:0]"
  • 2008 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the galeon archives: