Hi Steve,
Sorry it has taken me so long to answer.
I am in serious agreement with the two actions proposed by you and
Ben. As anticipated by Ben, we will work on investigating a simple
approach to embedding OPeNDAP into WCS that can be achieved as a
small delta on the draft "WCS CF-netCDF profile document". Actually,
this is a great input to improve the profile document.
As soon as possible, we will circulate another profile specification
draft to the GALEON list. Of course, any contribution is very welcome.
Thanks,
--Stefano
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:
* 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.
* 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>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]"
