WCS Service version 1.1: Difference between revisions

From OPeNDAP Documentation
⧼opendap2-jumptonavigation⧽
 
(60 intermediate revisions by 2 users not shown)
Line 4: Line 4:
== Overview ==
== Overview ==


This WCS service is designed to be used in conjunction with one or more Hyrax data servers. The Hyrax servers must be of version 1.6.2 or higher, as the service relies on Hyrax features that were added to 1.6.2 in support of the WCS catalog generation and data subsampling activities.
This WCS service is designed to be used in conjunction with one or more Hyrax data servers. The Hyrax servers may be either local or remote to the WCS service.  
=== The Servlet ===


The WCS service is written as a [http://jcp.org/en/jsr/detail?id=315 Java Servlet] implementation for the Tomcat (essentially a plug-in). It is distributed as a Web ARchive (.war) file. The WCS Service utilizes its own configuration directory and files which are stored in a the directory: ''$CATALINA_HOME/content/WCS/'' (more details below)
See also:  [[WCS Technical Description]]


=== Catalog Implementation ===
=== Catalog Implementation ===
Line 14: Line 12:
One of the challenges encountered when implementing a WCS service for Hyrax is catalog generation: ''How do we generate a list of coverages from existing holdings in Hyrax? '' The DAP contains the mechanism for transmitting the information, but lacks the explicit semantics required to describe a WCS Coverage. Luckily many of the users of DAP servers have provided metadata that complies to some type of metadata convention or standard.  This WCS service can build its catalog by using semantic web technology to crosswalk from existing DAP data sets which use the Climate Forecast (CF-1.0) and Unidtata Dataset Discovery v1.0 metadata conventions into the WCS metadata space.  
One of the challenges encountered when implementing a WCS service for Hyrax is catalog generation: ''How do we generate a list of coverages from existing holdings in Hyrax? '' The DAP contains the mechanism for transmitting the information, but lacks the explicit semantics required to describe a WCS Coverage. Luckily many of the users of DAP servers have provided metadata that complies to some type of metadata convention or standard.  This WCS service can build its catalog by using semantic web technology to crosswalk from existing DAP data sets which use the Climate Forecast (CF-1.0) and Unidtata Dataset Discovery v1.0 metadata conventions into the WCS metadata space.  


==== [[StaticRDFCatalog]] ====
==== [[StaticRdfCatalog | WCS Catalog]] ====


The StaticRdfCatalog uses semantic web technologies to create mappings between DAP data sets and WCS Coverages. A WCS Coverage is a very specific data type and is much more constrained than the more general DAP data model. Thus, only certain DAP data sets will be representable as WCS Coverages. Evaluating which ones can be represented as WCS Coverages requires the semantic analysis of the metadata associated with each data set. Since the DAP has no actual semantic metadata requirements for metadata it is necessary (at least for the moment) to look only at DAP data sets that have metadata that conforms to some well known metadata convention or standard. Since the semantics of the convention are know it is then possible to write inferencing rules that relate pieces of information in one convention/standard to the equivalent information in another convention/standard.
The WCS catalog uses semantic web technologies to create mappings between DAP data sets and WCS Coverages. A WCS Coverage is a very specific data type and is much more constrained than the more general DAP data model. Thus, only certain DAP data sets will be representable as WCS Coverages. Evaluating which ones can be represented as WCS Coverages requires analysis of the metadata associated with each data set. Since the DAP has no actual semantic metadata requirements for metadata it is necessary (at least for the moment) to look only at DAP data sets that have metadata that conforms to some well known metadata convention or standard. Since the semantics of the convention are known it is possible to write inferencing rules that relate pieces of information in one convention/standard to the equivalent information in another convention/standard.
 
----


== Requirements ==
== Requirements ==
Line 26: Line 22:
* [http://tomcat.apache.org/ Tomcat 6.x] (''The WCS service has not been tested against Tomcat 7.x'')
* [http://tomcat.apache.org/ Tomcat 6.x] (''The WCS service has not been tested against Tomcat 7.x'')


In addition, the WCS service requires DAP datasets served by [http://www.opendap.org/download/hyrax.html Hyrax 1.6.2] or newer.  
In addition, the WCS service requires DAP datasets served by [http://www.opendap.org/download/hyrax Hyrax 1.8] or newer.
 
----


== Installation ==
== Installation ==


=== Install The Software ===
=== Install The Software ===
* Download and install the BES for Hyrax 1.6 including:
** [http://www.opendap.org/download/libdap++.html libdap version x.x.x]
** [http://www.opendap.org/download/BES.html BES version x.x.x]
** [http://www.opendap.org/download/general_purpose_handlers.html General Purpose Handlers version x.x.x]
** [http://www.opendap.org/download/nc_server.html NetCDF Data Handler version x.x.x]
** [http://www.opendap.org/download/fileout_netcdf.html Fileout for NetCDF Handler version x.x.x]
** [http://www.opendap.org/download/ncml_module.html NcML Handler version x.x.x]
* Verify that the BES is working correctly.
* [http://tomcat.apache.org/download-60.cgi Download and install Tomcat 6.x]
* [http://tomcat.apache.org/download-60.cgi Download and install Tomcat 6.x]
* Download the OLFS WCS Service WAR file, opendap.war
* Download the WCS Service distribution, a gzipped tar file, and it's associated gpg signature.
* Copy the opendap.war file to $CATALINA_HOME/webapps
* Verify the distribution. (You will need to [http://www.opendap.org/security_at_opendap.org.pub.asc  get the public security key for OPeNDAP] first) In the directory containing the file and the downloaded signature run the command:
* Start Tomcat
:: <font size="2"><code>gpg --verify <file>.sig</code></font>
: If that fails - don't proceed and please contact support@opendap.org
* Unpack the distribution
* Copy the WCS.war file to $CATALINA_HOME/webapps
* Start Tomcat. Make sure that you tell Tomcat to use a JVM with at minimum 1GB of memory. You can do this easily by setting the environment variable JAVA_OPTS to 1000MB prior to launching Tomcat. (csh: <font size="2">'<tt>setenv JAVA_OPTS -Xmx1000m</tt></font>',  bash: <font size="2">'<tt>export JAVA_OPTS=-Xmx1000m</tt></font>')
 
=== Wait... ===
 
Once the server is up it won't show any Coverages for a few minutes. The default set of Coverages will take from between 2 - 30 minutes to process, depending on network speeds (loading documents) and the host system's processing capability. You can watch the processing by viewing the log file ''<code>$CATALINA_HOME/logs/catalina.out</code>''
 
Once the semantic engine completes it's run the WCS catalog should be updated and you should be able to see the default coverages generated by datasets on http://test.opendap.org:8080/opendap/
 
If that's not the case and no coverages are found then STOP and start trouble shooting.
 
== Testing the sample data ==
 
The WCS service comes with some sample datasets already configured. To view a web page listing these, type the following URL in a browser: ''<nowiki>http://localhost:8080/WCS</nowiki>''. Of course, adjust ''localhost:8080'' to match your site.
 
To force the service to update its catalog, either:
# Start and stop Tomcat
# If enabled in the web.xml for the WCS service you can access the URL ''<nowiki>http://localhost:8080/WCS/update()</nowiki>''.
 
If you choose the later, go back to the main web page for the WCS service (<nowiki>http://localhost:8080/WCS</nowiki>) and refresh that page. While the catalog is rebuilding the main page will display the message: "''WCS catalog is currently being updated.''" that will change to "''WCS catalog is up to date.''" when the process is complete. What is happening here? The inferencing software is reevaluating the information describing your datasets and then using that new information to build coverages.
 
== Configuration ==


At this point, assuming that the BES and the OLFS are running on their default ports on the same system the Service should be running, although in an un-configured state.
''Note: Configuration changes will not take effect until Tomcat is restarted.''


=== Configure the software ===
In order to correctly configure your WCS service you will need to:
The following changes will not take effect until Tomcat is restarted.
* Localize the WCS service metadata
** [[#Service Provider|Edit <font face="Courier>$CATALINA_HOME/content/opendap/<prefix>/ServiceProvider.xml</font> so that the specific information about the contact point, address and other information about the service reflect the needs of your organization.]]
**  [[#Service Identification|Edit  <font face="Courier>$CATALINA_HOME/content/opendap/<prefix>/ServiceIdentification.xml</font> so that the Title and Abstract sections reflect your needs. '''''DO NOT alter the ServiceType or ServiceTypeVersion element content.''''']]
**  [[#Operations Metadata|Edit  <font face="Courier>$CATALINA_HOME/content/opendap/<prefix>/OperationsMetadata.xml</font> so that the links to the service reflect the domain names and ports upon which you are running the service. ]]
* [[#WCS Catalogs|Configure the catalog for the WCS service.]]
* Stop and restart Tomcat.


# Localize the WCS service metadata
#* Edit <font face="Courier>$CATALINA_HOME/content/WCS/ServiceProvider.xml</font> so that the specific information about the contact point, address and other information about the service reflect the needs of your organization. ([[#Service Provider|Jump to Service Provider localization details on this page.]])
#*  Edit  <font face="Courier>$CATALINA_HOME/content/WCS/ServiceIdentification.xml</font> so that the Title and Abstract sections reflect your needs. '''''DO NOT alter the ServiceType or ServiceTypeVersion element content.''''' ([[#Service Identification|Jump to Service Identification localization details on this page.]])
#* Edit <font face="Courier>$CATALINA_HOME/content/WCS/OperationsMetadata.xml</font> so that the links to the service reflect the domain names and ports upon which you are running the service.  ([[#Operations Metadata|Jump to Operations Metadata localization details on this page.]])
# Configure the catalog (i.e. add datasets) for the WCS service. [[#WCS Catalog Configuration |Jump to WCS Catalog Configuration details on this page.]]
# Stop and restart Tomcat.


=== WCS Service Configuration ===


----
The WCS Service utilizes its own configuration directory and files which are stored in a well known location within the directory  content/''context'' directory (where ''context'' of the web application that the WCS service is running. By default ''context='WCS'''):
<font size="2">
$CATALINA_HOME/content/'''<context>'''
</font>
where <font  face="Courier">'''<context>'''</font> is context of the WCS web application. By default this value is '''WCS'''.


== WCS Service Configuration ==


The WCS Service utilizes its own configuration directory and files which are stored in a well known location within the OLFS content directory:
In the WCS Service directory (<font  face="Courier">'''$CATALINA_HOME/content/WCS'''</font>) is kept various documents used by the WCS Service including:
$CATALINA_HOME/content/opendap/'''<prefix>'''
where <font  face="Courier">'''<prefix>'''</font> is defined in the in the WCS [http://docs.opendap.org/index.php/Hyrax_-_OLFS_Configuration DispatchHandler] configuration element in the [http://docs.opendap.org/index.php/Hyrax_-_OLFS_Configuration#olfs.xml_Configuration_File olfs.xml] file. In the WCS Service directory (<font  face="Courier">CATALINA_HOME/content/opendap/<prefix></font>) is kept various documents used by the WCS Service including:


;wcs_service.xml
;[[#WCS Catalog Configuration | wcs_service.xml]]
:The <font face="Courier">wcs_service.xml</font> file identifies and configures the WCS catalog implementation.
:The <font face="Courier">wcs_service.xml</font> file controls which datasets are contained in the catalog and the catalog update behavior..


;[[#Service Identification|ServiceIdentification.xml]]
;[[#Service Identification|ServiceIdentification.xml]]
Line 84: Line 95:
# wcs:GetCapabilities
# wcs:GetCapabilities
# wcs:DescribeCoverage
# wcs:DescribeCoverage
# wcs;GetCoverage
# wcs:GetCoverage
The response for a wcs:GetCapaibilities request requires localization information that can only be determined by the individual(s) that are installing the service. The responses for both the  wcs:DescribeCoverage and wcs:GetCoverage requests can be generated directly from the WCS "catalog".
The response for a wcs:GetCapaibilities request requires localization information that can only be determined by the individual(s) that are installing the service. The responses for both the  wcs:DescribeCoverage and wcs:GetCoverage requests can be generated directly from the WCS "catalog".


Line 95: Line 106:


In this WCS implementation the ows:ServiceIdentification, ows:ServiceProvider and ows:OperationsMetadata sections are each stored as a separate XML file that is loaded by the server at startup.  Default versions of these files are installed into the OLFS's persistent content directory the first time that the WCS Service is launched. They can be found in the directory:
In this WCS implementation the ows:ServiceIdentification, ows:ServiceProvider and ows:OperationsMetadata sections are each stored as a separate XML file that is loaded by the server at startup.  Default versions of these files are installed into the OLFS's persistent content directory the first time that the WCS Service is launched. They can be found in the directory:
  $CATALINA_HOME/content/opendap/'''<prefix>'''
<font size="2">
where <font  face="Courier">'''<prefix>'''</font> is defined in the in the WCS [http://docs.opendap.org/index.php/Hyrax_-_OLFS_Configuration DispatchHandler] configuration element in the [http://docs.opendap.org/index.php/Hyrax_-_OLFS_Configuration#olfs.xml_Configuration_File olfs.xml] file.
  $CATALINA_HOME/content/'''<context>'''
</font>
where <font  face="Courier">'''<context>'''</font> is defined by the Tomcat ''service context'' in which the WCS web application is running. By default the value of <font  face="Courier">'''<context>'''</font> is '''WCS'''




=== Service Identification ===
==== Service Identification ====


The Service Identification metadata as described in section 7.4.4 of  OGC document ''[http://www.opengeospatial.org/standards/common OGC 06-121r3]''.   
The Service Identification metadata as described in section 7.4.4 of  OGC document ''[http://www.opengeospatial.org/standards/common OGC 06-121r3]''.   
Line 105: Line 118:
Localization should include (but may not be limited to)  updating the ows:Keytwords, ows:Fees and ows:AccessConstraints
Localization should include (but may not be limited to)  updating the ows:Keytwords, ows:Fees and ows:AccessConstraints


==== Example Document ====
===== Example Document =====
<pre><?xml version="1.0" encoding="UTF-8"?>
<font size="2">
<source lang="xml">
<?xml version="1.0" encoding="UTF-8"?>
<!-- ************************************************************ -->
<!-- ************************************************************ -->
<!-- * SERVICE IDENTIFICATION SECTION                          * -->
<!-- * SERVICE IDENTIFICATION SECTION                          * -->
Line 126: Line 141:
   <ows:AccessConstraints>NONE</ows:AccessConstraints>
   <ows:AccessConstraints>NONE</ows:AccessConstraints>
</ows:ServiceIdentification>
</ows:ServiceIdentification>
</pre>
</source>
</font>


;File Location
;File Location
:<font  face="Courier">$CATALINA_HOME/content/opendap/'''<prefix>'''/ServiceIdentification.xml</font> where <font  face="Courier">'''<prefix>'''</font> is defined in the in the WCS [http://docs.opendap.org/index.php/Hyrax_-_OLFS_Configuration DispatchHandler] configuration element in the [http://docs.opendap.org/index.php/Hyrax_-_OLFS_Configuration#olfs.xml_Configuration_File olfs.xml] file.
:<font  face="Courier">$CATALINA_HOME/content/'''<context>'''/ServiceIdentification.xml</font> where <font  face="Courier">'''<context>'''</font> is the Tomcat ''service context'' in which the WCS web application is running. By default this ''''WCS''''. (So the default location of the ServiceIdentification.xml file would be:<font  face="Courier">$CATALINA_HOME/content/WCS/ServiceIdentification.xml</font>)


=== Service Provider ===
==== Service Provider ====


The Service Provider metadata as described in section 7.4.5 of  OGC document ''[http://www.opengeospatial.org/standards/common OGC 06-121r3]''.   
The Service Provider metadata as described in section 7.4.5 of  OGC document ''[http://www.opengeospatial.org/standards/common OGC 06-121r3]''.   
Line 137: Line 153:
The ows:ServiceProvider section should be localized to identify the local operator of the system. Typically this would be the name and contact information of the individual or group responsible for installing and maintaing the WCS service.
The ows:ServiceProvider section should be localized to identify the local operator of the system. Typically this would be the name and contact information of the individual or group responsible for installing and maintaing the WCS service.


==== Example Document ====
===== Example Document =====
<pre>
<font size="2">
<source lang="xml">
<?xml version="1.0" encoding="UTF-8"?>
<?xml version="1.0" encoding="UTF-8"?>
<!-- ************************************************************ -->
<!-- ************************************************************ -->
Line 171: Line 188:
   </ows:ServiceContact>
   </ows:ServiceContact>
</ows:ServiceProvider>
</ows:ServiceProvider>
</pre>
</source>
</font>


;File Location
;File Location
:<font  face="Courier">$CATALINA_HOME/content/opendap/'''<prefix>'''/ServiceProvider.xml</font> where <font  face="Courier">'''<prefix>'''</font> is defined in the in the WCS [http://docs.opendap.org/index.php/Hyrax_-_OLFS_Configuration DispatchHandler] configuration element in the [http://docs.opendap.org/index.php/Hyrax_-_OLFS_Configuration#olfs.xml_Configuration_File olfs.xml] file.
:<font  face="Courier">$CATALINA_HOME/content/'''<context>'''/ServiceProvider.xml</font> where <font  face="Courier">'''<context>'''</font> is the Tomcat ''service context'' in which the WCS web application is running. By default this ''''WCS''''. (So the default location of the ServiceProvider.xml file would be:<font  face="Courier">$CATALINA_HOME/content/WCS/ServiceProvider.xml</font>)


=== Operations Metadata ===
==== Operations Metadata ====


The Operations Metadata  as described in section 7.4.6 of  OGC document ''[http://www.opengeospatial.org/standards/common OGC 06-121r3]''.   
The Operations Metadata  as described in section 7.4.6 of  OGC document ''[http://www.opengeospatial.org/standards/common OGC 06-121r3]''.   


Careful localization of this information is crucial to the correct function of the WCS service. Many clients will use this section of the wcs:Capabilities document to ascertain where and how they can interact with the service. It is required that the Get and Post URL's for each WCS operation point to the correct terminus on your server. If the server is behind a firewall which is port-forwarding the incoming requests the URL's may have little to do with the local network configuration.
The service will look at the ''xlink:href'' links in the Operations Metadata document and it will detect the default value of <font  face="Courier">''http://your.domain.name:8080/opendap/WCS'''</font> and replace it with the service URL that it determines from the incoming request. For most situations this will be completely adequate and the Operations Metadata will require no localization.


<hr>
However,  if the server is behind a firewall which is port-forwarding the incoming requests the URL's may only reflect the local network configuration and not the clients view of the service from outside the firewall. Careful localization of this information is crucial to the correct function of the WCS service. Many clients will use this section of the wcs:Capabilities document to ascertain where and how they can interact with the service. It is required that the Get and Post URL's for each WCS operation point to the correct terminus on your server.  
<font color="grey">
Looking at this again I am wondering if this could be either configured or determined?
: The base URL for their system could be added to the DispatchHandler configuration and the service URL's generated from that.
OR
: It is the case that the servlet request contains the URL to be dereferenced. I think it might work to dynamically determine the URL that brought the GetCapabilities request to the service and to pluck it from the request and build the service URLs from it.


Either one of these would diminish the configuration burden presented to the Hyrax user.
'''''Edit this file very thoughtfully'''''


Comments?
===== Example Document =====
 
<font size="2">
[[User:Jimg|jimg]] 10:54, 15 April 2009 (PDT)
<source lang="xml">
 
What about the case you mention above where a firewall and port-forwarding make the external and internal URLs structurally different?
 
[[User:Ndp|ndp]] 19:57, 14 April 2009 (PDT)
 
Also - the URLs for the POST and SOAP interfaces are defined in the olfs.xml file, but not in the part of the configuration that is used by the promary WCS DispatchHandler. Determining the values of each ones '''<prefix>''' element will require some architectural redesign...
 
--[[User:Ndp|ndp]] 07:28, 13 January 2010 (PST)
 
</font>
 
==== Example Document ====
<pre>
<?xml version="1.0" encoding="UTF-8"?>
<?xml version="1.0" encoding="UTF-8"?>
<!-- ************************************************************ -->
<!-- ************************************************************ -->
Line 289: Line 289:
     </ows:Operation>
     </ows:Operation>
</ows:OperationsMetadata>
</ows:OperationsMetadata>
</pre>
</source>
</font>


;File Location
;File Location
:<font  face="Courier">$CATALINA_HOME/content/opendap/'''<prefix>'''/OperationsMeadata.xml</font> where <font  face="Courier">'''<prefix>'''</font> is defined in the in the WCS [http://docs.opendap.org/index.php/Hyrax_-_OLFS_Configuration DispatchHandler] configuration element in the [http://docs.opendap.org/index.php/Hyrax_-_OLFS_Configuration#olfs.xml_Configuration_File olfs.xml] file.
:<font  face="Courier">$CATALINA_HOME/content/'''<context>'''/OperationsMeadata.xml</font> where <font  face="Courier">'''<context>'''</font> is the Tomcat ''service context'' in which the WCS web application is running. By default this ''''WCS''''. (So the default location of the OperationsMetadata.xml file would be:<font  face="Courier">$CATALINA_HOME/content/WCS/OperationsMetadata.xml</font>)


=== WCS Catalogs ===
=== WCS Catalog Configuration ===


The WCS service must maintain a catalog of ''Coverages''.  In the Hyrax WCS service the implementation of this catalog is identified at server start-up from the ''wcs_service.xml'' file located here: <font  face="Courier">$CATALINA_HOME/content/opendap/'''<prefix>'''/wcs_service.xml</font> where <font  face="Courier">'''<prefix>'''</font> is defined in the in the WCS [http://docs.opendap.org/index.php/Hyrax_-_OLFS_Configuration DispatchHandler] configuration element in the [http://docs.opendap.org/index.php/Hyrax_-_OLFS_Configuration#olfs.xml_Configuration_File olfs.xml] file.
The WCS service must maintain a catalog of ''Coverages''.  In the Hyrax WCS service, the implementation of this catalog is identified at server start-up from the WCS service configuration file.  


==== [[StaticRDFCatalog]] Configuration ====
;File Location
:The configuration file is located (by default) here: <font  face="Courier">$CATALINA_HOME/content/WCS/wcs_service.xml</font>.


[[StaticRDFCatalog|StaticRDFCatalog configuration instructions can be found here]]
:The default location of the file can be changed by changing the name of the WCS servlet's ''service context''. If you do that, the catalog file will be located at: <font  face="Courier">$CATALINA_HOME/content/'''<context>'''/wcs_service.xml</font>, where <font  face="Courier">'''<context>'''</font> is the Tomcat ''service context'' in which the WCS web application is running.


==== [[LocalFileCatalog]] Configuration====
The default  '''''wcs_service.xml''''' file contains:
''This is a development tool and is not expected to be used by data providers.''


[[LocalFileCatalog| LocalFileCatalog configuration instructions can be found here]]
<font size="2">
<source lang="xml">
<WcsService>
    <WcsCatalog>
        <useUpdateCatalogThread updateInterval="28800" firstUpdateDelay="10"/>


==WCS  DispatchHandler Configuration ==
        <dataset>http://test.opendap.org:8080/opendap/ioos/200803061600_HFRadar_USEGC_6km_rtv_SIO.ncml</dataset>
        <dataset>http://test.opendap.org:8080/opendap/ioos/ECMWF_ERA-40_subset.ncml</dataset>
        <dataset>http://test.opendap.org:8080/opendap/ioos/mday_joinExist.ncml.ddx</dataset>


    </WcsCatalog>
</WcsService>
</source>
</font>


The Hyrax WCS service is made of a collection 4 implementations of the opendap.coreServlet.DispatchHandler interface.
==== Adding Datasets To The Catalog ====


* HTTP GET: opendap.wcs.v1_1_2.DispatchHandler
In order for the WCS service to work it must know which DAP data sets are to be served as WCS coverages. Datasets can be added to the catalog in the following ways.
* HTTP POST (For posting unadorned XML WCS requests): opendap.wcs.v1_1_2.PostHandler
* HTTP POST (For posting SOAP envelopes containg WCS requests): opendap.wcs.v1_1_2.SoapHandler
* HTTP POST (For handling WCS requests posted from an HTML form): opendap.wcs.v1_1_2.FormHandler


The service is enabled by creating an entry for each service component in the olfs.xml file.
;<dataset>
:A '''dataset''' element identifies a single DAP data set that is to be served as a WCS coverage. The '''dataset''' element must contain the fully qualified data access URL for a DAP data set.  This URL will be examined and the software will attempt to get the RDF version of the data set's DDX from the DAP server.  


The primary DispatchHandler is opendap.wcs.v1_1_2.DispatchHandler. It is required for the WCS service and its Handler declaration contains the configuration information for the service. In its Handler declaration the location of the ServiceIdentification, ServiceProvider, and OperationsMetadata documents are identified, along with a WCS catalog implementation to be used by the service.
Example:
<font size="2">
<source lang="xml">
  <WcsCatalog>
  <dataset>http://localhost:8080/opendap/data/nc/examples/200803061600_HFRadar_USEGC_6km_rtv_SIO.nc.ddx</dataset>
</WcsCatalog>
</source>
</font>


A WCS catalog implementation (and its configuration)  must be provided in the WcsCatalog element.
;<ThreddsCatalog>


:A '''ThreddsCatalog''' element identifies a THREDDS catalog which contains DAP data access URLs that point to DAP data sets that will be served as WCS coverages. Each DAP data set  in the catalog will be served as a separate wcs:Coverage. The '''recurse'''  attribute determines if the software will follow '''catalogRef''' links in the THREDDS catalog to ingest the entire catalog hierarchy starting at the node identified by the URL.


Example:
<font size="2">
<source lang="xml">
<WcsCatalog>
    <ThreddsCatalog recurse="false" >http://test.opendap.org:8080/opendap/coverage/catalog.xml</ThreddsCatalog>
</WcsCatalog>
</source>
</font>


To "turn on" the service Handler declarations must appear in the olfs.xml opendap.wcs.v1_1_2.DispatchHandler Configuration
==== Controlling Catalog Update Behavior ====
The '''useUpdateCatalogThread''' element is used to control the way in which the catalog updates its semantic repository and Coverage catalog. Using this element will cause the catalog to spawn a worker thread that will update the semantic repository (and thus the WCS catalog holdings) in the background. If the '''useUpdateCatalogThread''' element is omitted the catalog will not spawn a worker thread, and will attempt to update it's holdings at startup, and no additional catalog update attempts will be made.


The '''firstUpdateDelay'''  attribute controls how long (in seconds)  the worker thread will wait before making the first update, I like to use 10 seconds, or whatever number allows tomcat to fully start before the worker thread goes to work. It also makes the log easier to understand.


=== Example olfs.xml ===
The '''updateInterval''' attribute is used to specify how frequently (in seconds) the catalog should be updated.
 
Example:
<font size="2">
<source lang="xml">
<WcsCatalog>
    <useUpdateCatalogThread updateInterval="3600" firstUpdateDelay="60"/>
</WcsCatalog>
</source>
</font>




  <?xml version="1.0" encoding="UTF-8"?>
[[StaticRdfCatalog| More detailed catalog configuration instructions can be found here]]
  <OLFSConfig>
    <DispatchHandlers>
        <HttpGetHandlers>
            <Handler className="opendap.bes.BESManager">
                <BES>
                    <!-- The prefix is a URL token between server address/port
                    and catalog root used to designate a particular BES instance
                    in the case that multiple Back-End-Servers are available to
                    a single OLFS.  The default is no additional tag,
                    designated by "/". So, for a single BES the prefix MUST be
                    set to "/".  -->
                    <prefix>/</prefix>
                    <!-- The hostname (or IP address) for this BES -->
                    <host>localhost</host>
                    <!-- The port number for this BES -->
                    <port>10002</port>
                    <!-- The ClientPool maximum number of concurrent
                      -  BES client connections allowed.
                      -->
                    <ClientPool maximum="10" />
                </BES>
            </Handler>
<b>
            <Handler className="opendap.wcs.v1_1_2.DispatchHandler">
                <prefix>WCS</prefix>
            </Handler>
  </b>
            <Handler className="opendap.threddsHandler.StaticCatalogDispatch">
                <prefix>thredds</prefix>
                <useMemoryCache>true</useMemoryCache>
            </Handler>
            <Handler className="opendap.bes.DapDispatchHandler" />
            <Handler className="opendap.bes.DirectoryDispatchHandler" />
            <Handler className="opendap.coreServlet.SpecialRequestDispatchHandler" />
            <Handler className="opendap.bes.VersionDispatchHandler" />
            <Handler className="opendap.bes.FileDispatchHandler" >
                <!-- AllowDirectDataSourceAccess
                  - If this element is opresent then the server will allow users to request
                  - the data source (file) directly. For example a user could just get the
                  - underlying NetCDF files located on the server without using the OPeNDAP
                  - request interface.
                  -
                  - THINK TWICE before allowing this, as data sources can be quite large
                  - and allowing their transmission with out subsetting can put heavy loads
                  - on the network and the server.
                  -->
                <AllowDirectDataSourceAccess />
            </Handler>
            <Handler className="opendap.bes.BESThreddsDispatchHandler" />
        </HttpGetHandlers>
        <HttpPostHandlers>
<b>
            <Handler className="opendap.wcs.v1_1_2.PostHandler" >
                <prefix>WCS/post</prefix>
            </Handler>
            <Handler className="opendap.wcs.v1_1_2.SoapHandler" >
                <prefix>WCS/soap</prefix>
            </Handler>
            <Handler className="opendap.wcs.v1_1_2.FormHandler" >
                <prefix>WCS/form</prefix>
            </Handler>
</b>
            <Handler className="opendap.coreServlet.SOAPRequestDispatcher" >
                <OpendapSoapDispatchHandler>opendap.bes.SoapDispatchHandler</OpendapSoapDispatchHandler>
            </Handler>
        </HttpPostHandlers>
    </DispatchHandlers>
</OLFSConfig>

Latest revision as of 03:20, 9 March 2012



Overview

This WCS service is designed to be used in conjunction with one or more Hyrax data servers. The Hyrax servers may be either local or remote to the WCS service.

See also: WCS Technical Description

Catalog Implementation

One of the challenges encountered when implementing a WCS service for Hyrax is catalog generation: How do we generate a list of coverages from existing holdings in Hyrax? The DAP contains the mechanism for transmitting the information, but lacks the explicit semantics required to describe a WCS Coverage. Luckily many of the users of DAP servers have provided metadata that complies to some type of metadata convention or standard. This WCS service can build its catalog by using semantic web technology to crosswalk from existing DAP data sets which use the Climate Forecast (CF-1.0) and Unidtata Dataset Discovery v1.0 metadata conventions into the WCS metadata space.

WCS Catalog

The WCS catalog uses semantic web technologies to create mappings between DAP data sets and WCS Coverages. A WCS Coverage is a very specific data type and is much more constrained than the more general DAP data model. Thus, only certain DAP data sets will be representable as WCS Coverages. Evaluating which ones can be represented as WCS Coverages requires analysis of the metadata associated with each data set. Since the DAP has no actual semantic metadata requirements for metadata it is necessary (at least for the moment) to look only at DAP data sets that have metadata that conforms to some well known metadata convention or standard. Since the semantics of the convention are known it is possible to write inferencing rules that relate pieces of information in one convention/standard to the equivalent information in another convention/standard.

Requirements

The WCS service needs:

In addition, the WCS service requires DAP datasets served by Hyrax 1.8 or newer.

Installation

Install The Software

gpg --verify <file>.sig
If that fails - don't proceed and please contact support@opendap.org
  • Unpack the distribution
  • Copy the WCS.war file to $CATALINA_HOME/webapps
  • Start Tomcat. Make sure that you tell Tomcat to use a JVM with at minimum 1GB of memory. You can do this easily by setting the environment variable JAVA_OPTS to 1000MB prior to launching Tomcat. (csh: 'setenv JAVA_OPTS -Xmx1000m', bash: 'export JAVA_OPTS=-Xmx1000m')

Wait...

Once the server is up it won't show any Coverages for a few minutes. The default set of Coverages will take from between 2 - 30 minutes to process, depending on network speeds (loading documents) and the host system's processing capability. You can watch the processing by viewing the log file $CATALINA_HOME/logs/catalina.out

Once the semantic engine completes it's run the WCS catalog should be updated and you should be able to see the default coverages generated by datasets on http://test.opendap.org:8080/opendap/

If that's not the case and no coverages are found then STOP and start trouble shooting.

Testing the sample data

The WCS service comes with some sample datasets already configured. To view a web page listing these, type the following URL in a browser: http://localhost:8080/WCS. Of course, adjust localhost:8080 to match your site.

To force the service to update its catalog, either:

  1. Start and stop Tomcat
  2. If enabled in the web.xml for the WCS service you can access the URL http://localhost:8080/WCS/update().

If you choose the later, go back to the main web page for the WCS service (http://localhost:8080/WCS) and refresh that page. While the catalog is rebuilding the main page will display the message: "WCS catalog is currently being updated." that will change to "WCS catalog is up to date." when the process is complete. What is happening here? The inferencing software is reevaluating the information describing your datasets and then using that new information to build coverages.

Configuration

Note: Configuration changes will not take effect until Tomcat is restarted.

In order to correctly configure your WCS service you will need to:

  1. Localize the WCS service metadata
  2. Configure the catalog (i.e. add datasets) for the WCS service. Jump to WCS Catalog Configuration details on this page.
  3. Stop and restart Tomcat.

WCS Service Configuration

The WCS Service utilizes its own configuration directory and files which are stored in a well known location within the directory content/context directory (where context of the web application that the WCS service is running. By default context='WCS'):

$CATALINA_HOME/content/<context>

where <context> is context of the WCS web application. By default this value is WCS.


In the WCS Service directory ($CATALINA_HOME/content/WCS) is kept various documents used by the WCS Service including:

wcs_service.xml
The wcs_service.xml file controls which datasets are contained in the catalog and the catalog update behavior..
ServiceIdentification.xml
The ServiceIdentification.xml file contains WCS metadata used in the wcs:Capabilities document.
ServiceProvider.xml
The ServiceProvider.xml file contains WCS metadata used in the wcs:Capabilities document.
OperationsMetadata.xml
The OperationsMetadata.xml file contains WCS metadata used in the wcs:Capabilities document.

Every installation of a WCS service requires a localization step in which much of the required metadata about the particular service instance and its keepers is captured so that it can be returned to clients.

From a client's perspective a WCS service is made up of three commands:

  1. wcs:GetCapabilities
  2. wcs:DescribeCoverage
  3. wcs:GetCoverage

The response for a wcs:GetCapaibilities request requires localization information that can only be determined by the individual(s) that are installing the service. The responses for both the wcs:DescribeCoverage and wcs:GetCoverage requests can be generated directly from the WCS "catalog".

The wcs:Capabilites document contains 4 sections:

  • Service Identification (ows:ServiceIdentification)
  • Service Provider (ows:ServiceProvider)
  • Operations Metadata (ows:OperationsMetadata)
  • Contents (wcs:Contents)

For any given installation of a WCS service the first three sections must be carefully localized. Their contents cannot realistically be ascertained by an automation. Thus, they are really part of the WCS configuration activity that must be performed by the service installer. The last section, Contents, can be automatically generated from the catalog of Coverages.

In this WCS implementation the ows:ServiceIdentification, ows:ServiceProvider and ows:OperationsMetadata sections are each stored as a separate XML file that is loaded by the server at startup. Default versions of these files are installed into the OLFS's persistent content directory the first time that the WCS Service is launched. They can be found in the directory:

$CATALINA_HOME/content/<context>

where <context> is defined by the Tomcat service context in which the WCS web application is running. By default the value of <context> is WCS


Service Identification

The Service Identification metadata as described in section 7.4.4 of OGC document OGC 06-121r3.

Localization should include (but may not be limited to) updating the ows:Keytwords, ows:Fees and ows:AccessConstraints

Example Document

<?xml version="1.0" encoding="UTF-8"?>
<!-- ************************************************************ -->
<!-- * SERVICE IDENTIFICATION SECTION                           * -->
<!-- ************************************************************ -->
<ows:ServiceIdentification xmlns="http://www.opengis.net/wcs/1.1"
xmlns:ows="http://www.opengis.net/ows/1.1"
xmlns:xlink="http://www.w3.org/1999/xlink" >
  <ows:Title>OPeNDAP Hyrax Prototype WCS Service</ows:Title>
  <ows:Abstract>A prototype WCS server intended to provide WCS 1.1 (1.1.2) access to DAP datasets</ows:Abstract>
  <ows:Keywords>
     <ows:Keyword>Web Coverage Service</ows:Keyword>
     <ows:Keyword>OPeNDAP</ows:Keyword>
     <ows:Keyword>nectcdf</ows:Keyword>
     <ows:Keyword>DAP</ows:Keyword>
  </ows:Keywords>
  <ows:ServiceType>WCS</ows:ServiceType>
  <ows:ServiceTypeVersion>1.1.2</ows:ServiceTypeVersion>
  <ows:Fees>NONE</ows:Fees>
  <ows:AccessConstraints>NONE</ows:AccessConstraints>
</ows:ServiceIdentification>

File Location
$CATALINA_HOME/content/<context>/ServiceIdentification.xml where <context> is the Tomcat service context in which the WCS web application is running. By default this 'WCS'. (So the default location of the ServiceIdentification.xml file would be:$CATALINA_HOME/content/WCS/ServiceIdentification.xml)

Service Provider

The Service Provider metadata as described in section 7.4.5 of OGC document OGC 06-121r3.

The ows:ServiceProvider section should be localized to identify the local operator of the system. Typically this would be the name and contact information of the individual or group responsible for installing and maintaing the WCS service.

Example Document

<?xml version="1.0" encoding="UTF-8"?>
<!-- ************************************************************ -->
<!-- * SERVICE PROVIDER SECTION                                 * -->
<!-- ************************************************************ -->
<ows:ServiceProvider  xmlns="http://www.opengis.net/wcs/1.1"
xmlns:ows="http://www.opengis.net/ows/1.1"
xmlns:xlink="http://www.w3.org/1999/xlink">
  <ows:ProviderName>OPeNDAP Inc.</ows:ProviderName>
  <ows:ProviderSite xlink:href="http://www.opendap.org"/>
  <ows:ServiceContact>
     <ows:IndividualName>Nathan D. Potter</ows:IndividualName>
     <ows:PositionName>Senior Software Engineer</ows:PositionName>
     <ows:ContactInfo>
        <ows:Phone>
           <ows:Voice>123-456-7890</ows:Voice>
           <ows:Facsimile>234-567-8901</ows:Facsimile>
        </ows:Phone>
        <ows:Address>
           <ows:DeliveryPoint>165 Dean Knauss Dr</ows:DeliveryPoint>
           <ows:City>Narragansett</ows:City>
           <ows:AdministrativeArea>Rhode Island</ows:AdministrativeArea>
           <ows:PostalCode>02882</ows:PostalCode>
           <ows:Country>USA</ows:Country>
           <ows:ElectronicMailAddress>support[a.t]opendap[d.o.t]org</ows:ElectronicMailAddress>
        </ows:Address>
        <ows:OnlineResource xlink:href="http://ndp.opendap.org:8080/opendap/"/>
        <ows:HoursOfService>24x7x365</ows:HoursOfService>
        <ows:ContactInstructions>email</ows:ContactInstructions>
     </ows:ContactInfo>
     <ows:Role>Developer</ows:Role>
  </ows:ServiceContact>
</ows:ServiceProvider>

File Location
$CATALINA_HOME/content/<context>/ServiceProvider.xml where <context> is the Tomcat service context in which the WCS web application is running. By default this 'WCS'. (So the default location of the ServiceProvider.xml file would be:$CATALINA_HOME/content/WCS/ServiceProvider.xml)

Operations Metadata

The Operations Metadata as described in section 7.4.6 of OGC document OGC 06-121r3.

The service will look at the xlink:href links in the Operations Metadata document and it will detect the default value of http://your.domain.name:8080/opendap/WCS' and replace it with the service URL that it determines from the incoming request. For most situations this will be completely adequate and the Operations Metadata will require no localization.

However, if the server is behind a firewall which is port-forwarding the incoming requests the URL's may only reflect the local network configuration and not the clients view of the service from outside the firewall. Careful localization of this information is crucial to the correct function of the WCS service. Many clients will use this section of the wcs:Capabilities document to ascertain where and how they can interact with the service. It is required that the Get and Post URL's for each WCS operation point to the correct terminus on your server.

Edit this file very thoughtfully

Example Document

<?xml version="1.0" encoding="UTF-8"?>
<!-- ************************************************************ -->
<!-- * OPERATIONS METADATA                                      * -->
<!-- ************************************************************ -->
<ows:OperationsMetadata xmlns="http://www.opengis.net/wcs/1.1"
                        xmlns:ows="http://www.opengis.net/ows/1.1"
                        xmlns:xlink="http://www.w3.org/1999/xlink">
    <ows:Operation name="GetCapabilities">
        <ows:DCP>
            <ows:HTTP>
                <ows:Get xlink:href="http://ndp.opendap.org:8080/opendap/WCS?"/>
                <ows:Post xlink:href="http://ndp.opendap.org:8080/opendap/WCS/post">
                    <ows:Constraint name="PostEncoding">
                        <ows:AllowedValues>
                            <ows:Value>XML</ows:Value>
                        </ows:AllowedValues>
                    </ows:Constraint>
                </ows:Post>
                <ows:Post xlink:href="http://ndp.opendap.org:8080/opendap/WCS/soap">
                    <ows:Constraint name="PostEncoding">
                        <ows:AllowedValues>
                            <ows:Value>SOAP</ows:Value>
                        </ows:AllowedValues>
                    </ows:Constraint>
                </ows:Post>
            </ows:HTTP>
        </ows:DCP>
    </ows:Operation>
    <ows:Operation name="GetCoverage">
        <ows:DCP>
            <ows:HTTP>
                <ows:Get xlink:href="http://ndp.opendap.org:8080/opendap/WCS?"/>
                <ows:Post xlink:href="http://ndp.opendap.org:8080/opendap/WCS/post">
                    <ows:Constraint name="PostEncoding">
                        <ows:AllowedValues>
                            <ows:Value>XML</ows:Value>
                        </ows:AllowedValues>
                    </ows:Constraint>
                </ows:Post>
                <ows:Post xlink:href="http://ndp.opendap.org:8080/opendap/WCS/soap">
                    <ows:Constraint name="PostEncoding">
                        <ows:AllowedValues>
                            <ows:Value>SOAP</ows:Value>
                        </ows:AllowedValues>
                    </ows:Constraint>
                </ows:Post>
            </ows:HTTP>
        </ows:DCP>
        <ows:Parameter name="Format">
            <ows:AllowedValues>
                <ows:Value>application/x-netcdf-cf1.0</ows:Value>
                <ows:Value>application/x-dap2.0</ows:Value>
            </ows:AllowedValues>
        </ows:Parameter>
    </ows:Operation>
    <ows:Operation name="DescribeCoverage">
        <ows:DCP>
            <ows:HTTP>
                <ows:Get xlink:href="http://ndp.opendap.org:8080/opendap/WCS?"/>
                <ows:Post xlink:href="http://ndp.opendap.org:8080/opendap/WCS/post">
                    <ows:Constraint name="PostEncoding">
                        <ows:AllowedValues>
                            <ows:Value>XML</ows:Value>
                        </ows:AllowedValues>
                    </ows:Constraint>
                </ows:Post>
                <ows:Post xlink:href="http://ndp.opendap.org:8080/opendap/WCS/soap">
                    <ows:Constraint name="PostEncoding">
                        <ows:AllowedValues>
                            <ows:Value>SOAP</ows:Value>
                        </ows:AllowedValues>
                    </ows:Constraint>
                </ows:Post>
            </ows:HTTP>
        </ows:DCP>
        <ows:Parameter name="Format">
            <ows:AllowedValues>
                <ows:Value>text/xml</ows:Value>
            </ows:AllowedValues>
        </ows:Parameter>
    </ows:Operation>
</ows:OperationsMetadata>

File Location
$CATALINA_HOME/content/<context>/OperationsMeadata.xml where <context> is the Tomcat service context in which the WCS web application is running. By default this 'WCS'. (So the default location of the OperationsMetadata.xml file would be:$CATALINA_HOME/content/WCS/OperationsMetadata.xml)

WCS Catalog Configuration

The WCS service must maintain a catalog of Coverages. In the Hyrax WCS service, the implementation of this catalog is identified at server start-up from the WCS service configuration file.

File Location
The configuration file is located (by default) here: $CATALINA_HOME/content/WCS/wcs_service.xml.
The default location of the file can be changed by changing the name of the WCS servlet's service context. If you do that, the catalog file will be located at: $CATALINA_HOME/content/<context>/wcs_service.xml, where <context> is the Tomcat service context in which the WCS web application is running.

The default wcs_service.xml file contains:

<WcsService>
    <WcsCatalog>
        <useUpdateCatalogThread updateInterval="28800" firstUpdateDelay="10"/>

        <dataset>http://test.opendap.org:8080/opendap/ioos/200803061600_HFRadar_USEGC_6km_rtv_SIO.ncml</dataset>
        <dataset>http://test.opendap.org:8080/opendap/ioos/ECMWF_ERA-40_subset.ncml</dataset>
        <dataset>http://test.opendap.org:8080/opendap/ioos/mday_joinExist.ncml.ddx</dataset>

    </WcsCatalog>
</WcsService>

Adding Datasets To The Catalog

In order for the WCS service to work it must know which DAP data sets are to be served as WCS coverages. Datasets can be added to the catalog in the following ways.

<dataset>
A dataset element identifies a single DAP data set that is to be served as a WCS coverage. The dataset element must contain the fully qualified data access URL for a DAP data set. This URL will be examined and the software will attempt to get the RDF version of the data set's DDX from the DAP server.

Example:

 <WcsCatalog>
   <dataset>http://localhost:8080/opendap/data/nc/examples/200803061600_HFRadar_USEGC_6km_rtv_SIO.nc.ddx</dataset>
 </WcsCatalog>

<ThreddsCatalog>
A ThreddsCatalog element identifies a THREDDS catalog which contains DAP data access URLs that point to DAP data sets that will be served as WCS coverages. Each DAP data set in the catalog will be served as a separate wcs:Coverage. The recurse attribute determines if the software will follow catalogRef links in the THREDDS catalog to ingest the entire catalog hierarchy starting at the node identified by the URL.

Example:

 <WcsCatalog>
    <ThreddsCatalog recurse="false" >http://test.opendap.org:8080/opendap/coverage/catalog.xml</ThreddsCatalog>
 </WcsCatalog>

Controlling Catalog Update Behavior

The useUpdateCatalogThread element is used to control the way in which the catalog updates its semantic repository and Coverage catalog. Using this element will cause the catalog to spawn a worker thread that will update the semantic repository (and thus the WCS catalog holdings) in the background. If the useUpdateCatalogThread element is omitted the catalog will not spawn a worker thread, and will attempt to update it's holdings at startup, and no additional catalog update attempts will be made.

The firstUpdateDelay attribute controls how long (in seconds) the worker thread will wait before making the first update, I like to use 10 seconds, or whatever number allows tomcat to fully start before the worker thread goes to work. It also makes the log easier to understand.

The updateInterval attribute is used to specify how frequently (in seconds) the catalog should be updated.

Example:

 <WcsCatalog>
    <useUpdateCatalogThread updateInterval="3600" firstUpdateDelay="60"/>
 </WcsCatalog>


More detailed catalog configuration instructions can be found here