NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
A few thoughts are below, spanning several emails: Jon Blower wrote:
Hi Steve, Stefano, John et al., This looks like a good starting point for harmonization. John Caron described one method of bridging between WCS and OPeNDAP: 1) Client discovers Coverage somehow 2) Client gets description of coverage via DescribeCoverage() 3) Client calls GetCoverage() 4) Server returns OPeNDAP URL to the result Another alternative (to complement, not replace, the above) might be to bypass GetCoverage() altogether: 1) Client discovers Coverage somehow 2) Client gets description of coverage via DescribeCoverage(). Description includes OPeNDAP URL to entire Coverage. 3) Client opts to use OPeNDAP to access subsets, without calling GetCoverage() at all. A client might choose this so that it can access more precise subsets, accepting the extra complexity. What do others think of this?
The equivalent of DescribeCoverage in opendap is getDDX(), and in netcdf is "ncdump -h". Both dump out the metadata of the dataset. They are very likely to be semantically equivalent to what a server like the TDS can return in a DescribeCoverage response.
BTW, just to reiterate, returning an opendap URL of a dataset with CF metadata is the same as returning a netcdf/CF file. If you can do one, you can do the other. And they have the same information content. We have to be a little careful here because some might draw incorrect inferences from the terminology. When you see the phrase "return an opendap URL" you should read "return an opendap URL of a dataset with CF metadata". Wright, Bruce wrote:
Hi Jon, Steve, Stefano, John et al., This is a very interesting discussion that the WCS CF-netCDF profile document and the GO-ESSP meeting had triggered! Looking at the two suggestions below for the use of OPeNDAP with WCS, I would suggest that the second is cleaner and simpler. In effect, this adds OPeNDAP as extra operation (in addition to GetCapabilities, DescribeCoverage and GetCoverage), and keeps the details of the GetCoverage request completely separate. This picks up on a theme discussed earlier, which was that one of the key benefits of the WCS was the metadata capability.
Im not convinced theres a lot of new functionality in the WCS metadata per se. Im guessing thats what Peter has in mind in his comment "Probably you would need to define some structure on the free metadata part so that the extra info becomes useful."If we want to pursue, perhaps we should look at a concrete example?
..whilst OPeNDAP provides a powerful but fairly straightforward data access 'request format'. It does mean that the client has to generate all the 'subsetting constraints', but... Using GetCoverage to return an OPeNDAP URL implies that the server has to map the WCS GetCoverage arguments (e.g. BBOX, CRS, INTERPOLATION, FORMAT, etc) onto the OPeNDAP constraints. Our experience (at the Met Office) trying to map WFS filtering arguments onto an OPeNDAP call (a similar issues) suggest that this is not likely to be straightforward and that you may loose the benefits of the two approaches due to mismatches in capability.
I guess the argument is that putting the hard stuff on the server makes client adoption easier. Jon Blower wrote:
1) Mapping GetCoverage parameters to OPeNDAP is likely to be non-trivial (as Bruce says) and I think they actually represent two rather separate ways of accessing data, aimed at different applications and users. Roughly speaking, I see GetCoverage as being most suitable when the user knows what CRS and resolution he/she wants the data to be in, but accepts that the server will generally have to interpolate to fulfil the request. OPeNDAP is more suitable when the user wants the data in as close to the original form as possible, accepting that this has consequences of increased complexity. If all our data were on regular lat-lon grids (or even if they were in the "GIS standard" projections defined by EPSG codes) the job would be easier, but it's a lot more complicated than that.
Peter Baumann wrote:
One option WCS offers is to use just the Image CRS, i.e.: the integer array coordinates if you will. If this CRS is the only one the WCS offers then no detailed handling is necessary - DescribeCoverage offers some identifier, GetCoverage uses it.
Let me explore the idea to keep opendap/CF as an output format, rather than push it up into the GetRequest semantics.
Following Peter's train of thought, I could see the following being worth pursuing, and ill just describe in terms of the TDS to be concrete: TDS currently always uses the actual CRS of the dataset in DescribeCoverage response, and allows requests in either lat/lon CRS or the actual CRS (often in projection coordinate). If it also could publish the "image CRS", which i assume is the index coordinate space (apologies for not understanding exactly what an image CRS looks like), and if a request can be made in image CRS, and allows specifying index strides, then I think thats the same functionality that you get from an opendap request. 1) Anyone who can formulate an opendap request could formulate a request in image CRS coordinates, and get exactly the same response. 2) Anyone who understands projections can formulate in data CRS, and get pretty much exactly the same thing (may be some edge case details to consider). 3) Generic clients can get aproximate data from lat/lon reque sts. For Polar data, a client will likely have to use 1 or 2. The motivation here continues to be to return subsets of the actual, unmodified data in the native CRS and data type (eg floating point).Once you want reprojected data, resampled to your grid, then you are probably in the WMS category of use cases.
> why then use a WCS at all? This is the core of the whole thing. As I've said from the beginning, we need to understand what WCS is likely to be useful for, and what it isn't. We can't assume that it will solve all our problems for us,and neither can we assume that it will be irrelevant.
I agree this continues to be the core issue. The most obvious argument from a "metocean" POV is that it provides a standard way to make requests in coordinate space. Weighing against it is that the complexity of the data model makes interoperability unlikely without further technical and market-focusing developments.
galeon archives: