WCS services

The Open Geospatial Consortium, Inc. (OGC), Web Coverage Service (WCS) provides an open specification for sharing raster datasets on the web. ArcGIS for Server allows you to publish WCS services from imagery collections, maps, or geodatabases that contain rasters.

A WCS service returns data in a format that can be used as input for analysis and modeling. This is in contrast with the OGC Web Map Service (WMS), which only returns a picture of the data. The raster datasets made available through WCS services are referred to as coverages. These should not be confused with the vector datasets available in previous versions of ArcGIS, which were also known as coverages.

WCS services are useful if you want to make your raster datasets available online in an open, recognized way across different platforms and clients. Any client built to support the WCS 1.0.0, 1.1.0, 1.1.1, and 1.1.2 specifications can view and work with your service.

Client applications work with a WCS service by appending parameters to the service's URL. WCS services published to ArcGIS Server support the following operations:

You can learn more about WCS services at the Open Geospatial Consortium website. Esri also maintains an Interoperability and Standards web page detailing its support for OGC services in ArcGIS.

Creating a WCS service

In ArcGIS Server, WCS is exposed as a capability of a map service, an image service, or a geodata service. To create a WCS service, you need to create one of these three services and enable the WCS capability. The sources for WCS services should be one of the following:


Personal geodatabases are not supported in ArcGIS 10.1 for Server or later releases.

A WCS service created from a map service or a geodata service may contain multiple coverages. However, the source raster data must have a valid spatial reference. A WCS service from an image service contains a single WCS coverage.

Configuring WCS service properties

A WCS service's properties are reflected in its capabilities files so that whoever consumes the service can have a better understanding of the service publisher. When publishing a WCS service with system-generated capabilities files (the default), it is recommended that you populate the WCS service properties. For information about each WCS service property you can set, see Available WCS service properties. Additionally, the following topics include instructions on how to get to the location where you can set WCS service properties:

Setting WCS properties using an external capabilities file

If you want more flexibility in how the service advertises its capabilities, you can use external capabilities files. For example, WCS services hosted on ArcGIS Server only support their native spatial reference system and WGS84. Given that ArcGIS Server supports thousands of predefined spatial reference systems, these can be added to a WCS service and advertised to WCS clients by using external WCS capabilities files. See Using external capabilities files with WCS services for more information.

Securing WCS services

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 regardless of whether they try to consume it through Simple Object Access Protocol (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 Integrated Windows Authentication, HTTP Basic, or HTTP Digest. Most OGC clients (both non-Esri and Esri clients) will understand and work with these widespread standard authentication schemes.

Consuming WCS services

To connect to a WCS service, you need to provide the endpoint of the WCS service URL. For WCS services published through ArcGIS Server, the URL takes this format:

http://gisserver.domain.com:6080/services/folder/service/service type (can be MapServer, ImageServer, or GeoDataServer)/WCSServer?

WCS service URL examples

If you have a folder named Japan containing the map service Tokyo running on gisserver with the port number 6080, the URL of your WCS service would look like this:


If you have an image service named IdahoImages running on myServer with the port number 6080, your URL for the WCS service would look like this:


If you have a folder named Ohio containing the geodata service SummitCounty running on myServer with the port number 6080, your URL for the WCS service would look like this:


For more information on how to consume a WCS service, see Communicating with a WCS service in a web browser.

WCS query URL examples

In general, query parameters should be avoided in the connection URL. WCS Capabilities URL is not a valid input. In some workflows, you may need to provide optional parameters in the connection URL to support vendor-specific parameters, or access a particular slice from the service. These query parameters will be carried on in GetCapabilities, DescribeCoverage, and GetCoverage requests, for example:

Make a WCS connection that deals with a particular image in a mosaic dataset through a vendor-specific IMAGES parameter:


Make a WCS connection to a particular time slice:


Supported output formats

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 Supported raster dataset file formats in the ArcGIS help.