Re: OGC tech committee meeting highlights

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.htm
and 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.htm

According 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


  • 2006 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the galeon archives: