The Open Geospatial Consortium, Inc. (OGC) Web Coverage Service (WCS) provides an open specification for sharing raster datasets on the Web. The raster datasets made available through WCS services are coverages. These should not be confused with the vector datasets available in previous versions of ArcGIS, which were also called coverages.
A WCS service returns data in a format that can be used as input for analysis and modeling. This is in contrast with OGC WMS services, which only return a picture of the data.
You can do three things with a WCS service:
To learn more about WCS services, see http://www.opengeospatial.org/standards/wcs.
Publishing any GIS service requires you to first define or create the GIS resource. To create a WCS service, you need to prepare one of the following, then publish it as a service:
Once you have one of these GIS resources, you can publish it as a service, enabling the WCS capability. The WCS capability is available for map services, image services, and geodata services. In order to be published as WCS coverage, the source raster data must have a valid spatial reference.
To enable the WCS capability for a map service, use ArcMap to create the map document containing the raster layers you want to serve. When doing so, keep in mind that only the raster data in the map will be served in a WCS service; the layer properties will not be maintained, and any feature data will be excluded from the WCS service. When you've saved your map document, use either Manager or ArcCatalog to publish it as a map service. The service can then be consumed by any client that supports the OGC WCS specification.
To enable the WCS capability for an image service, prepare the raster dataset, layer file referencing a raster dataset, or compiled image service definition that you want to publish, then publish it as an image service with the WCS capability enabled, using either ArcCatalog or ArcGIS Server Manager.
To enable the WCS capability for a geodata service, create a geodatabase (file, personal, or ArcSDE geodatabase), load the raster data you want to serve into the geodatabase, then publish the geodatabase as a geodata service with the WCS capability enabled, using either ArcCatalog or ArcGIS Server Manager.
WCS services created with ArcGIS Server only support their native spatial reference system and WGS84. Given that ArcGIS Server supports thousands of predefined spatial reference systems, these spatial reference systems can be added to a WCS service and advertised to WCS clients by using external WCS capabilities files (see the subsection "Using external capabilities files" below for information on using additional spatial reference systems).
The WCS versions supported by ArcGIS Server are 1.0.0, 1.1.0, and 1.1.1.
Each WCS service exposes service-level metadata through its capabilities file. The capabilities file is the XML response that clients receive when they make a GetCapabilities request on the service.
There are two ways you can work with the capabilities files of your WCS services in ArcGIS Server:
Publishing with a system-generated capabilities file is the default option. The following steps will help you add important information to the file:
Make sure that "Enter service properties below" is selected. This means your service is going to use a system-generated capabilities file.
Type metadata about your services in the text box.
Note: The OnlineResource field is necessary for a WCS client to communicate correctly with your WCS service. Usually its value is a URL and it should show up in the Web Access section of the Capabilities tab.
External capabilities files give you the flexibility to do the following:
To use external capabilities files for your WCS service, you must have at least one WCS capabilities file ready. You can create the file from scratch, but it's often easier to first publish your service with a system-generated capabilities file, then use that file as a template for creating the external capabilities file.
If you want your WCS service to support different versions of WCS protocol--for example, 1.0.0, 1.1.0, and 1.1.1--you must have one capabilities file for each version of WCS you want to support.
Once you've created all the necessary capabilities files, name them with a common prefix (for example, "capabilities") plus the unique three-digit version number (for example, "capabilities100", "capabilities110", "capabilities111").
Place all your capabilities files under a common folder which is accessible from a URL. Then follow the steps below to configure your service to use the files:
In the "Specify the location prefix" box, type the URL of the folder where you placed your capabilities files plus the common prefix you used for them (for example, if you used "capabilities" as your common prefix and placed your files under C:\Inetpub\wwwroot\<instance name>\wcs and you are using IIS with ArcGIS Server for .NET, you can just type "http://<server name>/<instance name>/wcs/capabilities").
Note: By using external capabilities files for your WCS service, you must be responsible for validating your capabilities files against the DTD or XML schema from OGC. You also assume responsibility for all the synchronization between your capabilities files and the source data from which your WCS service is published.
Tip: Although you can create an external capabilities file from scratch, it is easier and safer to use a system-generated capabilities file as a template and make appropriate changes to it.
The following characters cannot be included in any of the service properties: &, <, >, ", '. If you need to use one of these characters, you must substitute the appropriate escape sequence from the table below:
A WCS service exposes an ArcGIS Server map, geodata, or image service to WCS consumers. The security for a WCS service is managed by controlling the security of its parent map, geodata, or image service. If a particular role, for example Planners, is denied access to a map, then Planners will not be able to access the map no matter whether they try to consume it through SOAP, representational state transfer (REST), or WCS interfaces.
ArcGIS Server supports a number of different authentication schemes. Services that are expected to be accessed via OGC interfaces should be secured using HTTP Basic, HTTP Digest, or Integrated Windows Authentication. Most OGC clients (both non-ESRI as well as ESRI clients) will understand and work with these widespread standard authentication schemes.
To connect to a WCS service, you need to know the URL. When you use ArcGIS Server to publish a WCS service, its URL takes this format:
http://<server name>/<instance name>/services/<folder name (if applicable)>/<service name>/<service type (can be MapServer, ImageServer, or GeoDataServer)>/WCSServer?
For example, if you had a folder Japan that contained the map service Tokyo running on a machine myServer with the default instance name arcgis, the URL of your WCS service would look like this:
If you had an image service IdahoImages running on myServer with the instance name of PublicLands, your URL for the WCS service would look like this:
Supported output formats for WCS services are GeoTIFF, NITF, HDF, JPEG, JPEG2000, and PNG. To learn more about how these image formats are supported in ArcGIS, see Technical specifications for raster dataset formats in the ArcGIS Desktop Help.
A Web browser is the simplest client of a WCS service. WCS requests can be issued through HTTP, and the responses or exceptions are returned through the browser. WCS services support three operations: GetCapabilities, DescribeCoverage, and GetCoverage. Through URL parameters, a client can use these operations to obtain service metadata, coverage information, and coverages from the WCS service. These operations and parameters are detailed in the OGC WCS specifications.
ArcCatalog and ArcMap can act as clients for WCS services. To learn how to add a WCS service to ArcMap, see Connecting to GIS servers in the ArcGIS Desktop Help. Additionally, many third-party applications are available for working with WCS and other OGC services.