NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
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]"
galeon archives: