The THREDDS WCS Server implements the OGC Web Coverage Service (WCS) 1.0.0 specification. It serves gridded data in GeoTIFF or NetCDF format allowing WCS clients to specify a subset of a gridded dataset and download the resulting GeoTIFF or netCDF files.
WCS must be enabled in the threddsConfig.xml
configuration file before it can be used. This is done by adding an allow element
to the WCS element as follows:
<WCS>
<allow>true</allow>
...
</WCS>
Once WCS is enabled, datasets can be configured to have a WCS access method in the TDS catalog configuration files similar to how other services are configured. The service element's serviceType and base attribute values must be as follows:
<service name="wcs" serviceType="WCS" base="/thredds/wcs/" />
The dataset to be served must reference this service (or a containing compound service) by the service name:
<dataset ID="sample" name="Sample Data" urlPath="sample.nc">
<serviceName>wcs</serviceName>
</dataset>
The dataset can be configured by datasetRoot or datasetScan as appropriate (see "Basic Configuration"). They are listed in the resulting THREDDS catalogs as are other datasets. WCS clients may not be able to directly use the THREDDS catalogs to find the WCS services but the catalogs are useful for users to browse and for separate search services (e.g., OGC catalog services).
The TDS can also
serve remote datasets with the WCS protocol if configured to do so. It
must be explicitly configured in the threddsConfig.xml
configuration file. This is done by adding an allowRemote element to
the WCS element as follows:
<WCS>
<allow>true</allow>
<allowRemote>true</allowRemote>
...
</WCS>
A slight extension of the WCS Dataset URL format allows the TDS to serve remote datasets. The dataset is identified by adding the parameter dataset whose value is a URL:
http://servername:8080/thredds/wcs?dataset=datasetURL
The URL must be a dataset readable by the NetCDF-Java library, typically an OPeNDAP dataset on another server. It must have gridded data, with identifiable coordinate systems, etc. For example, an OPeNDAP URL might be
http://las.pfeg.noaa.gov/cgi-bin/nph-dods/data/oceanwatch/nrt/gac/AG14day.nc
This can be served remotely as a WCS dataset with this URL:
http://servername:8080/thredds/wcs?dataset=http://las.pfeg.noaa.gov/cgi-bin/nph-dods/data/oceanwatch/nrt/gac/AG14day.nc
The current TDS implementation of WCS 1.0 has the following restrictions:
Same as above (version=1.0.0) except:
The WCS 1.0.0+ implementation experiment is targeted to further the understanding of how FES datasets fit into the current WCS and what extensions they may require. The conclusions will be fed back to the WCS 1.2 RWG.
As currently expected, same as above (version=1.0.0.1) except:
All THREDDS WCS requests start with
http://servername:8080/thredds/wcs/
The next part of the path indicates which file to use
http://servername:8080/thredds/wcs/test/sst.nc
This is typically the URL you will need to pass to a WCS client. The WCS Client then forms various queries to the THREDDS WCS server for that dataset, e.g.:
http://servername:8080/thredds/wcs/test/sst.nc?service=WCS&version=1.0.0&request=GetCapabilities
The following are WCS URLs for our test datasets:
Here are example WCS queries for the first dataset:
A few WCS clients we know of (though we haven't tried all of them):
This one is not a general client. It is a server site with a web interface for accessing their served data: