NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Hi Peter, The second case (which I thought might attract comment) was motivated by 2 things (sorry, I know I'm repeating earlier posts here): 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. 2) The ocean community lacks a means of describing coverages in an interoperable way (which is one reason why Stefano's document will be important). Hence I think that WCS GetCapabilities and DescribeCoverage could be useful, even if the coverage is ultimately accessed by other means. Norman (or anyone else): how does this relate to the JPEG2000/JPIP situation? Does a JPIP stream point to an entire coverage or a coverage subset?
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 would vote for spending a while focussing on this question and not the technical details of how we can push all our information through a WCS interface. I look forward to Ben and Stefano's document on the subject! ;-) Cheers, Jon On Mon, Sep 29, 2008 at 12:44 PM, Peter Baumann <p.baumann@xxxxxxxxxxxxxxxxxxxx> wrote:
Hi Jon, a really interesting discussion has evolved here. Let me throw in my 2 cents from a WCS perspective: 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 this fits nicely with one of the packaging alternatives we have in planning: GetCoverage response is an XML structure containing URLs to coverages for subsequent download by the client. Let me point out that many WCS users very much want a "single file" response, that is: direct delivery of the encoded file. By using WCS & GetCoverage you get such access variants in an interoperable way. 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. hm, this seems to employ WCS just as a catalog lookup service - why then use a WCS at all? Probably you would need to define some structure on the free metadata part so that the extra info becomes useful. In the end, you define another access protocol = standard. cheers, Peter What do others think of this?
galeon archives: