NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Ben, Regarding to the relationship between data collections in THREDDS and OGC CSW and WCS, I think that the hierarchical coverage structure currently discussed in the WCS RWG should show some equivalence between a collection in THREDDS and a parentCoverageNode in WCS. The followings are excerpted from a message I posted to the WCS RWG. I assuemed that there are three types of data, air temperature, surface temperature, and TM images in a server. -------------------------------------------- 1) there is a globalCoverageID 2) there are two coverageIDs under this globalCoverageID: one is globalTMScene and the other is globalTemperature 3) there are many TM coverageIDs under globalTMScene, such TM_pathXXXrowYYY 4) there are two temperature coverageIDs under globalTemperature, one is airTemperature and the other is surfaceTemperature, both having global coverages (the two temperatures can of course also contains multiple coverages which construct global scenes when mosaiced, as in the TM scene case). When each of the above coverages, parent and child, are announced, a client can request either one single child coverage (e.g., airTemperature, one TM scne) or one or more coverages (e.g., a mosaiced TM coverage, two temperature coverages, TM and temperature coverages). -------------------------------------------- Each of the parent coverageID is actually a directory name, which is equivalent to a collection name in THREDDS. A client can either a single coverage (e.g., a TM image data, a airTemperature data) or request all data in a parent coverageID (e.g., all TM images in the globalTMscene directory). The most significant difference is that in WCS, if a client request globalTMscene, then all the TM images included in the directory will be mosaiced into one single global TM image, while a DAP client seems to just request all TM images without being mosaiced into one single image (i.e., request a directory/collection means to request all data in the directory/collection but not to perform data merging). The hierarchical coverage concept will not be finalized in the current WCS1.1. It is target for WCS1.2. Thus, there will be more time to discuss "hierarchy" in WCS/CSW in relation to "data collection" in THREDDS. Regards. Wenli At 16:18 2006-7-7 -0600, Ben Domenico wrote:
Hi,GALEON participants who attended the OGC Technical Committee meeting in Edinburgh can add to (or correct) this brief summary of the meeting highlights from my GALEON perspective.From the GALEON point of view, an important aspect of the meeting was the fact that there appears to be agreement on (or at least not a lot of vociferous opposition to) the approach we've proposed for revising the binary encodings part of the WCS 1.1 specification. As a reminder, the relevant proposed changes will make CF-netCDF one of the supported encoding formats. The essence of the changes is provided in two documents. The first summarizes the revised section of the spec itself:<http://www.unidata.ucar.edu/projects/THREDDS/GALEON/CF-netCDFprofile/WCS_1.1_draft_SupportedFormats.htm>http://www.unidata.ucar.edu/projects/THREDDS/GALEON/CF-netCDFprofile/WCS_1.1_draft_SupportedFormats.htmand the second is the draft WCS 1.1 application profile for encoding CF-netCDF.http://www.unidata.ucar.edu/projects/THREDDS/GALEON/CF-netCDFprofile/WCS-Encoding-Profile-For-CF-netCDFforPublic.htmAccording to the revised WCS under consideration, an application profile of this sort has to be approved by OGC for WCS encoding formats. Note that the draft of the CF-netCDF application profile is preceded by background information.The OGC Technical Committee agreed to schedule an e-vote, "to begin on or before August 15," for adoption of 06-083r? as WCS 1.1.0. The OGC document 06-083 is the one that contains the changes that will make CF-netCDF one of the official encoding formats for WCS. In fact, it may be the only one with an associated application profile. Discussions are still underway on a few topics, but the WCS Revision Working Group will vote next week to stop accepting change requests for WCS 1.1.There were many additional interesting discussions and presentations at the technical committee meetings, but I'll just mention two that may be of special interest to some members of the GALEON community. One is the fact that there is considerable interest in the OGC catalog specification (CS-W). I think this is very important for WCS and GALEON because the list of coverages returned in the WCS getCapabilities request is not adequate to represent all the information in THREDDS catalogs assciated with collections of netCDF datasets. Another very interesting presentation was given by Andrew Woolf describing a project getting underway at the UK NERC (Natural Environment Research Council). It involves bringing together GRID technologies for orchestrating services with OGC Web Processing Services (WCS) and computational services associated with OPeNDAP, e.g., the GDS (GRADS Data Server).All in all -- a very productive meeting. Enough for now. -- Ben
galeon archives: