GEOSS Banner

Section 2 : Introduction to the topic

Table of contents
  1. 1. 2.1 Discussion of tutorial use
  2. 2. 2.2 How interoperability is improved through the use of this server/service
    1. 2.1. 2.2.1 Sharing regular gridded coverages interoperability problem
      1. 2.1.1. WCS compatibility
      2. 2.1.2. Coverage data model
      3. 2.1.3. Domain Set
      4. 2.1.4. Range type
      5. 2.1.5. Range Set
      6. 2.1.6. Changing the data model
      7. 2.1.7. Trimming a coverage
      8. 2.1.8. Resampling a coverage
      9. 2.1.9. Slice a coverage
    2. 2.2. 2.2.2 The OGC-WCS Service interoperable Operation
      1. 2.2.1. Descriving your WCS Server: The GetCapabilities Operation
      2. 2.2.2. GetCapabilities request
      3. 2.2.3. Capabilities document
      4. 2.2.4. Describing Your Coverages: The DescribeCoverage Operation
      5. 2.2.5. Describing Your Coverages: The DescriveCoverage Request
      6. 2.2.6. Describing Your Coverages: The DescribeCoverage Response
      7. 2.2.7. Serving a Coverage: The GetCoverage Request
      8. 2.2.8. Implementing GetCoverage: Required Parameters
      9. 2.2.9. GetCoverage Response
      10. 2.2.10. WCS 1.0
      11. 2.2.11. WCS 1.1.1
      12. 2.2.12. The Axis order Issue
      13. 2.2.13. Exception Handeling
    3. 2.3. 2.2.3. WCS 2.0. The modular standard (core and extension model)
      1. 2.3.1. WCS 2.0. The core
      2. 2.3.2. WCS 2.0 service model
      3. 2.3.3. WCS 2.0 Coverage Service Extensions
      4. 2.3.4. WCS 2.0 Application profiles
  3. 3. 2.3 Reference to associated videos, books, and other resources, if in existence

This chapter establishes the background information of web coverage, system interoperability, and the OpenGIS® WCS Standard.

This chapter also presents the technologies and tools for WCS client and server development. WCS Specification version 1.0 is directly referenced to the corresponding "WCS requests" sections (GetCapabilities, DescribeCoverage, GetCoverage) of the specification for the information needed when implementing the WCS interface.

How to contribute the resources and the developed WCS service to the GEOSS?

How to follow this tutorial to publish other Earth Observation data through WCS interface?

Things need to consider when providing robust WCS interface in an operation environment How to use the example data for GEOSS SBA application

<<Prev T.O.C Next>>

2.1 Discussion of tutorial use

2.2 How interoperability is improved through the use of this server/service

2.2.1 Sharing regular gridded coverages interoperability problem

Formally, a coverage is a feature that associates positions within a bounded space (its domain) to feature attribute values (its range). In other words, it is both a feature and a function. Commonly, a coverage is a representation of a set of continuous variables (functions) in the space, measured following a particular geometric pattern defined by a geometric feature.

This definition might seam a bit too abstract. To make it more concrete, we are going to define continuous and discrete coverages.

When storing spatial distribution as variables as a mathematical function, then we say that we are dealing with a continuous coverage. Examples of continuous coverages are a statistical trend surface, a mathematical description of a climate change model, etc. In this tutorial we are not going to deal with this kind of coverages.

Functions representing continuous attribute values generate an unlimited number of attribute values in the space, these can not be stored in a computer system, and a common approach for a coverage representation is to capture sampled values of this attributes following a sequence of positions. By doing this, we are generating a discrete coverage. Examples of this kind of coverages are satellite images, triangular irregular networks (TIN) and raster digital elevation models (DEM).

The limits between these two kinds of coverages are not completely clear. On one hand, a discrete coverage can be used to sample values on a continuous coverage. And on the other hand, discrete values on discrete coverages can be extrapolated by interpolation algorithms, and thus giving the impression of a continuous description of the space. E.g. the values of the 3 vertices of a particular triangle of a TIN, can be interpolated to get a value in any position inside this triangle.

A particular case of a discrete coverages is a regular spaced grid of values. The WCS standard focuses on an interoperable way of sharing regular grids in 0, 1, 2 or 3 axes, which define regular spaced locations in the domain. For each location in the domain, a single attribute value (e.g elevation), a set of values (e.g temperature, pressure, humidity, etc) or a vector of discrete samples of a function (e.g. the brightness values in different parts of the electromagnetic spectrum) will be provided.

A WCS can serve that coverage as a whole at the exact resolution of the coverage, or it can also serve a fragment of it, and optionally, it can resample the data. It is also able of subsetting the data, as well as reducing the number of dimensions.

The WCS may be compared to the OGC Web Map Service (WMS) and the Web Feature Service (WFS); like them it allows clients to choose portions of a server's information holdings based on spatial constraints and other criteria.

Unlike the WMS [OGC 06-042], which portrays spatial data to return static maps (rendered as pictures by the server), the Web Coverage Service provides data together with their detailed descriptions; defines a rich syntax for requests against these data; and returns data with its original semantics (instead of pictures) which may be interpreted, extrapolated, etc. – and not just portrayed.

Unlike WFS [OGC 04-094], which returns discrete geospatial features (e.g. point, lines, polygons…), the Web Coverage Service returns coverages representing space-varying phenomena that relate a spatio-temporal domain to a (possibly multidimensional) range of properties. WCS compatibility

The current version of WCS is 2.0. Earlier versions are still used in most of the servers and clients and will be supported by implementations in the future because there is still some demand for them; however, note should be taken that WCS 1.x is no longer maintained by OGC and that WCS 2.0 is not compatible with WCS 1.x.

Starting with WCS 2.0, OGC’s modular specification scheme has been implemented. Following this scheme, WCS is organized into a Core, which every client and server must realize, and a set of optional extensions, which a vendor may or may not decide to implement. The Capabilities document that a WCS delivers upon request indicates which service extensions are implemented by the server. The figure below, gives an informal representation of the WCS suite. Note that, at the time of this writing, not all extension specifications are available, so this constitutes a roadmap of future coverage standardization in OGC.

image1.png Coverage data model

In this section we describe the coverage data model used in WCS 2.0 because it is clearer than the previous versions and even if it is incompatible with WCS 1.x models, some of the concepts used in 2.0 are present somehow in previous versions.

The GML Application Schema for Coverages
[09-146r1] defines the data model of a coverage based on the idea that a coverage can be seen as a set of positions in space (called domain set), a type of measure made for these positions (called range type) and the measures themselves (called range set). Usually, conventional coverage files (image files) are focused on the range set, providing an array of binary values, limiting the information on the range type to the value type, while limiting the information on the domain set to the number of rows and columns of the image. Moreover, each image format has its own way to express theses information (generally included in the header of the file). This is the case for the basic tiff format and the jpeg2000 format.

The coverage model used in WCS includes more information. We are going to use the WCS 2.0 model to better illustrate the 3 concepts as introduced above. You have to be aware that not all versions of WCS have the division as explicit as WCS 2.0, but they all have the same principles.

IMAGE 2 Domain Set

It is in the domain set where the dimensions of the coverage (spatial, temporal, etc) have to be defined. For example, a RectifiedGrid will have the size of the grid specified (which determines the number of rows and columns), as well as specifications on the point of origin of the grid, and the offset vector of the cells of the grid (allowing the grid to have a rotated orientation versus the real coordinates; this property is rarely used).

This is an example of a domain set


<gml:RectifiedGrid dimension="2">



<gml:low>0 0</gml:low>

<gml:high>640 480</gml:high>



<gml:axisLabels>x y</gml:axisLabels>


<gml:Point gml:id="origin" srsName="urn:x-ogc:def:crs:EPSG:6.6:23031">

<gml:pos>344323.66 4716647.00</gml:pos>



<gml:offsetVector srsName="urn:x-ogc:def:crs:EPSG:6.6:23031">0.5 0</gml:offsetVector>

<gml:offsetVector srsName="urn:x-ogc:def:crs:EPSG:6.6:23031">0 -0.5</gml:offsetVector>



There are some points in common with the usual Word files used to accompany image files such us the TFW that accompanies a TIF file. The previous example would look like this in a Word file format:

4711869.75 Range type

The range type defines the name and description of the property that is held, the limits of the possible values, the number of significant figures, the units, the null value support, etc.

This is an example of a range type

This is an example of range type


<swe:field name="white">

<swe:Quantity definition="">





reason=""> 0



reason=""> 255



<swe:uom code="W/cm2"/>



<swe:interval>0 255</swe:interval>






</rangeType> Range Set

In the range set, the actual values are transported or  linked to the binary file that contains values provided.

This is an example of a range set with the values embedded in GML:

        <tupleList> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 </tupleList>

</gml:rangeSet> Changing the data model

The WCS server can serve the coverage completely or can extract a subset of the original data. This alters and simplifies some characteristics of the data model of the resulting coverage. Trimming, resampling and slicing are 3 different ways of altering the original data model to generate a simplified one. Trimming a coverage

A WCS can serve a coverage at its full extend, but commonly, it will only serve a subset of it in response to a request when containing a bounding box. Resampling a coverage

A WCS can serve a coverage in its original resolution or can resample the cell size to any other value. When resampling, it is possible to request the interpolation method that fits best. Slice a coverage

Normally, a WCS can serve a coverage in its original number of dimensions, the WCS 2.0 introduces the possibility of reducing the original dimension number of the coverage. E.g. this is useful to extract a 2D layer from 3D data.


2.2.2 The OGC-WCS Service interoperable Operation Descriving your WCS Server: The GetCapabilities Operation GetCapabilities request

All  OGC Web Services (OWS) services following OWS are self-describing. In the case of WCS this means that you are able to request enough information from the service, in order to know the service details, and thus formulate further request until getting the coverage data desired. In the case that you already know the coverage identifiers/names and characteristics you want, it is always possible to request the data without requesting information about the service itself. In any case, the fact that the services are self-describing is considered to be an asset. There is just one thing you always need to explore in a WCS service and that is the URL to a service. It can be done in two ways:

• You get a URL to a GetCapabilities request. In this case, you do not need to know anything more. Just using this URL in a web browser will get you the service description. This is what the CSR provides to you with. For example, for the CIESIN/SEDAC WCS Service CSR record ( you have an entry called "Interface URL" that contains:

• You could get only the URL of the service application: In this case, you will need to add two mandatory parameters that are the same for all WCS service versions:

Many WCS implementations support more than one standard version (e.g. you can add "&version=1.0.0" to previous requests to get a WCS 1.0.0 description). In fact, many current services support WCS 1.0.0 and 1.1.x. If you do not request any version you will get the information requested for the latest version available. Capabilities document

The response of a correct GetCapabilities request is a capabilities document (also known as "OGC service metadata document". This is a XML document that has different sections that are slightly different from one version to the other but the general idea is the same. Since we are using the CIESIN server as an example, and this one offers by default the capabilities in version 1.1.1, we are going to use this version as reference



In the CIESIN example GetCapabilities response document that uses all this sections that will be examined one by one:

<wcs:Capabilities version="1.1.1" xmlns:wcs="" xmlns:xlink="" xmlns:ogc="" xmlns:ows="" xmlns:gml="" xmlns:xsi="" xsi:schemaLocation=" file://d:/docs/INFO/i2cat/ogc/schemas/wcs/1.1/wcsGetCapabilities.xsd" updateSequence="2189">

The first two sections do not require much explanation because XML element names are quite clear: they provide general information about the service we are going to use such as a title, a description, etc and information bout the responsible people that set it up and operating it, as we can see in this XML fragment:

        <ows:Title>Web Coverage Service</ows:Title>
        <ows:Abstract>This server implements the WCS specification 1.0 and 1.1.1, it's reference implementation of WCS 1.1.1. All layers published by this service are available on WMS also.</ows:Abstract>

As a good practice, ServiceIndentification section has to talk about this particular instance of the service. So it is recommended that the title and the abstract describe this service (including a general content description and the organization name) and not a generic description of the WCS specification or WCS software vendor.

        <ows:ProviderName>CIESIN, Columbia University</ows:ProviderName>
        <ows:ProviderSite xlink:href=""/>
            <ows:IndividualName>CIESIN User Services</ows:IndividualName>
                <ows:OnlineResource xlink:href=""/>

The previous section describes this server provider and need to cover the relevant data and service provider contact information and, for example, avoid generic references to the WCS specification or to the software vendor URLs.

The OperationsMetadata section is a more interesting for us because it reveals operations that the service supports while allowing us to introduce 2 new operations for this service: DescribeCoverage and GetCoverage. It also describes the supported formats for POST encoding. Since most the operations performed by a WCS can be encoded directly in the URL using Key Value PAirs (KVPs), we are not going to talk about POST operations anymore.

        <ows:Operation name="GetCapabilities">
        <ows:Operation name="DescribeCoverage">
        <ows:Operation name="GetCoverage">
            <ows:Parameter name="store">
        <ows:Constraint name="PostEncoding">

WMS services structure the service content in layers that has a name. A WCS server does a similar thing structuring the content in individual coverages that can be n dimensional. A typical example of a multidimensional coverage is collection of Landsat images that have 2 spatial dimensions but also can be repetitively acquired in time and also have several bands, configuring a 4 dimensional coverage. Obviously, an important thing to know is the names of these coverages. The next section, Contents, tells us the identifiers of these coverages and their characteristics, including the number of bands. This service has up to 55 coverages but this fragment shows only two of them:

            <ows:Title>Population Density Future Estimates 2010</ows:Title>
            <ows:Abstract>Generated from GeoTIFF</ows:Abstract>
                <ows:LowerCorner>-180.0 -58.0</ows:LowerCorner>
                <ows:UpperCorner>180.0 85.0</ows:UpperCorner>
            <ows:Title>World Database of Protected Areas</ows:Title>
            <ows:Abstract>Generated from GeoTIFF</ows:Abstract>
                <ows:LowerCorner>-180.0 -55.749</ows:LowerCorner>
                <ows:UpperCorner>180.0 83.634</ows:UpperCorner>

At this point, we know that there is a coverage with identifier "gpw-v3-population-density-future-estimates_2010", and from the information on the BoundingBox description we also know that this coverage covers almost the whole world. It is strongly recommended to add additional information describing the data whether in the form of a complete abstract or by including metadata fields in the description. It is also recommended to use keywords to describe the coverage itself. Describing Your Coverages: The DescribeCoverage Operation Describing Your Coverages: The DescriveCoverage Request

To build a DescribeCoverage request we use the server URL and, for the WCS version 1.1.1, we add "?SERVICE=WCS&REQUEST=DescribeCoverage&version=1.1.1&identifiers=". Then, we have two situations:

•    We left the request like this. Then, we are going to get all coverages in the response.
•    We add a coma separated list of coverages identifiers. Coverage identifiers can be got from the capabilities document for the content of the elements "/wcs:Capabilities/wcs:Contents/wcs:CoverageSummary[]/wcs:Identifier". Describing Your Coverages: The DescribeCoverage Response

The response to a well formed DescribeCoverage request is a document describing the coverage generically. Versions previous to WCS 2.0 use their own type of document, but the version 2.0 uses GMLCOV. In this example based on 1.1.1, the document has 5 sections. The first section repeats the content in the CoverageSummary section of the Capabilities document.

<?xml version="1.0" encoding="UTF-8"?>
        <ows:Title>Population Density Future Estimates 2010</ows:Title>
        <ows:Abstract>Generated from GeoTIFF</ows:Abstract>

The second section describing its domainSet (called only "Domain" in WCS 1.1). This gives us information about the grid geometry. Particularly we now about the BoundingBox (in our case, -180.0 -58.0,180.0 85.0) and the original pixel size extracted from the GridOffsets (in our case 0.0416666666667).

                <ows:BoundingBox crs="urn:ogc:def:crs:OGC:1.3:CRS84"
                    <ows:LowerCorner>-180.0 -58.0</ows:LowerCorner>
                    <ows:UpperCorner>180.0 85.0</ows:UpperCorner>
                <ows:BoundingBox crs="urn:ogc:def:crs:EPSG::4326"
                    <ows:LowerCorner>-58.0 -180.0</ows:LowerCorner>
                    <ows:UpperCorner>85.0 180.0</ows:UpperCorner>
                -179.97916666666666 84.97916666678104</wcs:GridOrigin>
                0.0416666666667 0.0 0.0 -0.0416666666667</wcs:GridOffsets>

The third section is the rangeType (called only "Range" in WCS 1.1) describes the types of values that the cells of the grid contains, the extra dimensions present and the interpolation types.

                <wcs:Axis identifier="Bands">

From the previous section, we now know that there is a extra axis in this coverage called BANDS, which contains a single possible value called GRAY_INDEX.
Fourth and fifth sections list the supported CRSs and formats


Now, we know all the necessary information to generate a valid GetCoverage request. Serving a Coverage: The GetCoverage Request

This operation allows us to retrieve a subset of a coverage that a WCS stores. Implementing GetCoverage: Required Parameters

The syntax of a GetCoverage request has been evolving through the several available versions; therefore we will show you two different examples of requests.Also, many server products recognize requests in several versions, this allow us to make the same request to a particular service in more than one version.

The request syntax for the WCS 1.0 is very similar to the WMS GetMap request syntax. It shares with it that both have the same parameters REQUEST, SERVICE, VERSION, CRS, BBOX, WIDTH, HEIGHT and FORMAT. It only allows requesting a single coverage, so LAYERS parameter in WMS is COVERAGE= in WCS 1.0. Furthermore, it is needed to specify any extra axis and values they have.Note that these constrains requests to 2D data – 3D image time series, 4D climate data, etc. can not be retrieved properly as there is no way to indicate scaling in height and time axes.

In version 1.0.0 the GetCoverage request follows the following URI template:{coverage_identifier}&CRS={crs_identifier}&BBOX={xmin},{ymin},{xmax},{ymax}&WIDTH={width}&HEIGHT={height}&FORMAT={format}&{extra_axis_identifier}={extra_aixes_value}

Note that these constrains requests to 2D data – 3D image time series, 4D climate data, etc. cannot be retrieved properly as there is no way to indicate scaling in height[1] and time axes.

In our case, we are going to request a raster map of the whole world with 1800x715 pixels (cells) in a GeoTIFF format, and in latitude / longitude projection. From the capabilities document we already know that there is a coverage called gpw-v3-population-density-future-estimates_2010, and from the DescribeCoverage we found out that the range for this coverage is called BANDS, which has a single component called GRAY_INDEX. This is the resulting request example:


WCS version 1.1.1 has substantially extended reprojection capabilities. Hence, it uses a different syntax that makes more emphasis in the fact that when we request a coverage in WCS, we can simultaneously request some changes in the coverage CRS. To do that, it introduces GridBaseCRS, GridType, GridOffsets and GridOrigin.

[1]Note that the HEIGHT parameter in the request refers to the latitude axis, not altitude.

In our case, we are going to request a raster map of the whole world with 1800x715 pixels (cells) in a GeoTIFF format, and in latitude / longitude projection. From the capabilities document we already know that there is a coverage called gpw-v3-population-density-future-estimates_2010, and from the DescribeCoverage we found out that the range for this coverage is called BANDS, which has a single component called GRAY_INDEX. This is the resulting request example:

WCS version 1.1.1 has substantially extended reprojection capabilities. Hence, it uses a different syntax that makes more emphasis in the fact that when we request a coverage in WCS, we can simultaneously request some changes in the coverage CRS. To do that, it introduces GridBaseCRS, GridType, GridOffsets and GridOrigin.

In our case, we are going to use a grid transformation from a 2D CRS to another 2D CRS (expressed as a GridType 2dGridIn2dCrs). Under these conditions, the CRS transformation can be expressed with some parameters that describe a translation (expressed in the GridOrigin vector, i.e. Ox,Oy) and an affine transformation (expressed in a sequence of 2 vectors in GridOffsets, i.e. v1x,v1y,v2x,v2y). The following diagram graphically represents this transformation.



In version 1.1.1 the GetCoverage request follows the following URI template:{coverage_identifier}&FORMAT={format}&BoundingBox={xmin},{ymin},{xmax},{ymax},{crs_identifier}&GridType={grid_type}&GridOffsets={v1x},{v1y},{v2x},{v2y}&{extra_axis_identifier}={extra_aixes_value}

In the case we are illustrating here, we are going to request a raster map of the world but we are no longer providing the number of rows and columns in the image (in this case 1800x715 pixels) but instead, we are going to provide the GridOffsets to express the transformation from the original CRS to the desired one. In our case, a size of 0.2 degrees in the offset vector length for the whole world, it is going to generate (180-(-180))/0.2=1800 and 90-(-90)/0.2=900, a GeoTIFF format in latitude longitude projection. From the capabilities document obtained in a previous GetCapabilities request, we know that there is a coverage called gpw-v3-population-density-future-estimates_2010, we also know that this particular coverage has an extra axis called BANDS, which has a single possible value called GRAY_INDEX, this information is extracted from a DescribeCoverage request. This is the resulting request example:;subtype="geotiff"&/>BoundingBox=-90,-180,90,180,urn:ogc:def:crs:EPSG::4326&GridType=urn:ogc:def:method:WCS:1.1:2dGridIn2dCrs&GridOffsets=0,0.2,-0.2,0&BANDS=GRAY_INDEX

To build a GetCoverage request we use the server URL and, for the WCS version 1.1.1, we add "?service=WCS&request=GetCoverage&version=1.1.1&identifier=". Then we add a coma separated list of feature type names. FeatureType names can be got from the capabilities document for the content of the elements "/wfs:WFS_Capabilities/FeatureTypeList/FeatureType[]/Name".

In our example, we are going to use: north_poles_wfs or greenland_elevation_contours. Requesting two features for both feature types will be something like this:

and GetCoverage Response

Here is where we really see the difference between a WMS and a WCS. Although the request syntax for both services is very similar and the response can even be in the same format, we will explain particular cases to illustrate where these two services differ.

Let’s suppose we have a population dataset, where the data is presented in persons per km2. This data cannot be represented in an integer format so a WCS will return a GeoTIFF that includes floating data. This is a variant of tiff which is not supported by many common image viewers, so e.g. cannot be previewed by the windows operating system common tools. On the other hand, a WMS will return an image in a tiff format but in a way that is ready to be viewed on the screen. This will result in an image of 255 color degrees specified in an internal palette. It will be easier to see in common image viewers; the values in the actual cells will no longer represent a physical magnitude but a color index. Additionally, the WMS returned image will not be useful for GIS population related analysis but the image
returned from a WCS will.

Another example would be a satellite image e.g. from Landsat with multiple bands. Via WMS only RGB representations can be obtained while via WCS any number of bands can be requested and directly used in a GIS system. WCS 1.0

WCS 1.0 returns directly a GeoTIFF document that is compressed with lossless LZW compression algorism. Some softwares products are not able to deal with this format variant. Fortunately, there is a toolbox called FWTools that can help us to generate an uncompressed version of the same file. Once installed, we can execute the OpenEV_FW graphical tool and use the File|Export option that starts the GDAL export tool. This tool is able to export a TIFF file as a TIFF file. That may seem to be a silly thing to do, but it allows us to get a TIFF file without compression.



wcs_lzw.tiff is 883Kbytes long and the uncompressed version is 5034Kbytes long.

It really is a GeoTIFF file, because it contains the needed information to reference it. An old tool called GeoTIFFExamine helps us to see the georeferenced information and to verify that the pixel size is 0.2 degree and the origin of the image is longitude=-180, latitude=85.



At first glance, the image is a bit shocking, since the only thing that can be discerned is the difference between the sea and the land.


Even if we cannot see population gradients, the image is queryable and, for instance, a query on the population of Barcelona returns that in Barcelona region there are 1432.86 people/km2.



Data visualization can be improved by knowing the NODATA value ( 3.40282346638529E+38) used for the sea cells, and thus exclude it from the palette ranging.


image9.png WCS 1.1.1

The WCS 1.1.1 standard defines another possible response that allows providing some additional information along with the binary data in a multipart message. In a previous subsection we have been discussing the GML encoding for a coverage. In the CIESIN example, even if you request a GeoTIFF file, you are going to get a multipart file which includes two parts, one with a GML description of the coverage, and another with a binary data file (GeoTIFF). Each part has a different Content-ID, being the GML part urn:ogc:wcs:1.1:coverages (required in the specification). GML encoding uses a xlink:href attribute in the element Reference to link to the binary data file using the "cid:" prefix and the corresponding Content-ID.

MIME-Version: 1.0
Content-Type: multipart/mixed;

Content-Type: text/xml
Content-Transfer-Encoding: 7bit
Content-ID: <urn:ogc:wcs:1.1:coverages>

<?xml version="1.0" encoding="UTF-8"?>
<wcs:Coverages xmlns:wcs="" xmlns:xlink="" xmlns:ogc="" xmlns:ows="" xmlns:gml="" xmlns:xsi="" xsi:schemaLocation="">
    <ows:Title>Population Density Future Estimates 2010</ows:Title>
    <ows:Abstract>Generated from GeoTIFF</ows:Abstract>
    <ows:Reference xlink:href="cid:theCoverage"/>

Content-Type: image/tiff;subtype="geotiff"
Content-Transfer-Encoding: base64
Content-ID: <theCoverage>


Some mail programs such as OutlookExpress, ThunderBird, etc., identify MIME multipart files as their own format and can open them directly in the form of emails. The email representation has the GML part in the body of the message and the binary data file as an attachment.

image10.png The Axis order Issue

One of the most common geospatial reference systems is latitude/longitude in WGS84 (EPSG code database identifier: 4326). There is a well known issue with the axis order interpretation in EPSG:4326. OGC edited the document 08-038r5 ( to settle down this issue and determine that axis order specified in the EPSG database is going to be adopted by all OGC standards. In practice, this means that EPSG:4326 shall be used in latitude/longitude ordering.

Unfortunately, many implementations continue to follow the reverse longitude-latitude ordering, weather because implementations where done before 08-038r5 or because they have chosen to ignore it.

In fact, WCS 1.0 does not provide any mechanism to control this issue. Nevertheless, servers often correct the axis order automatically and return the image in the expected appearance and direction. CIESIN WCS 1.1.1 server deals with this issue in a surprising way. A request not containing GridOffset parameter, or containing parameters that do not specify any axe rotation like GridOffset=0.2,0,0,0.2, delivers the following response:


To correct this behavior, we use GridOffset and specify an axes permutation as well as the inversion of the latitude axe ordering. This is done by switching the order of the offset vector coordinates and adding a negative sign to it: GridOffset=0,0.2,-0.2,0.

Recovering the previous figure used to explain the GridOffset concept, we can represent the current example like this:


vector3.PNG Exception Handeling

Sometimes the client does not provide a well formed request, or for some reason the service is not able to perform the requested task. Under these circumstances, the service will respond with an XML file that explains the origins of the problem.

For example, if we send a GetFeature request to a WCS service such as

We are going to get the following exception report back:

<?xml version="1.0" encoding="UTF-8" ?>

-<ows:ExceptionReport version="1.1.0" xsi:schemaLocation="" xmlns:ows="" xmlns:xsi="">

-<ows:Exception exceptionCode="OperationNotSupported" locator="GetFeature">

<ows:ExceptionText>No such operation WCS 1.1.1 GetFeature</ows:ExceptionText>



The sentence: "OperationNotSupported" reveals the reason of the problem.

• If the origin of the problem is on our side, we could try to identify it and fix it.

• If the origin of the problem is not on our side, there is not much to do except to contact the service provider using the contact information in the ServiceProvider section of the capabilities document.

2.2.3. WCS 2.0. The modular standard (core and extension model)

In August 2010, the completely overhauled WCS 2.0 version was embraced by OGC. To make coverages interchangeable across all OGC-based services, WCS 2.0 has been based on the Geography Markup Language (GML) 3.2.1, with a small, backwards compatible addition to achieve informational completeness. Simultaneously, specification writing, reference implementation and online demo are being pursued.

WCS 2.0 offers several advantages over previous versions, such as support for general n-D raster data and non-raster coverage types; crisp, modular, and easy to understand; flexible and adaptive; harmonized with GML and Sensor Web Enablement (SWE); improved testability; and it allows efficient and scalable implementations.

In this tutorial we present WCS 2.0 and some central design rationales. We also give an outlook on the WCS Earth Observation Application Profile.

WCS 2.0 is a completely overhauled WCS version. It is no longer a single standard but a modular, structured suite of specifications fitting into an extensible overall concept. Technically, this WCS is based on the Geography Markup Language (GML) and on the Sensor Web Enablement (SWE) and, hence, achieves a high degree of interoperability with related standards.

Following the OGC core/extension model for modular specifications, WCS is split into a Core and an open-ended set of extensions. The Core defines properties that any WCS implementation must offer in order to be conformant with WCS overall. Extensions define further functionalities which additionally the WCS may have implemented. WCS 2.0. The core

In this subsection, we first review the WCS Core data model and then its service model.

WCS 2.0 is based on the ASC coverage model. In the specification, the overall service offered is modeled as a single (virtual) GML document with root CoverageOfferings.


It consists of several service specific parameters plus its set of available coverages. Each of the OfferedCoverage in turn consists of a coverage defined in the ASC plus coverage-specific service parameters, such as the CRSs in which a coverage can be requested. In the WCS Core, only a placeholder is reserved so that extensions have a canonical place to add such information. In order to allow the WCS service functionality a few restrictions are imposed coverages as compared to ASC. For example, the id attribute of an AbstractCoverage must be unique across the server offering document tree. Furthermore, every coverage must contain a bounding box definition summarizing its extent and its axis names. WCS 2.0 service model

WCS services offer three mandatory request types: GetCapabilities, DescribeCoverage, and GetCoverage. GetCapabilities is the canonical OGC Web Service discovery request where a server unveils its service capabilities and, optionally, a list of the offered coverage’s identifiers. Using DescribeCoverage a client can request details – i.e., metadata – about one or more coverages by providing such identifiers.

The actual workhorse is the GetCoverage request. For a given identifier, it allows to retrieve all or part of the corresponding coverage. In the Core, domain subsetting is defined. As a novelty, WCS 2.0 is subdivided into trimming and slicing for reasons of conciseness. A trim operation reduces the extent of a coverage in the axis dimension that was indicated in the request, thereby preserving the number of dimensions. A slice operation, on the other hand, performs a cut through the coverage in the axis and at the slice coordinate specified, thereby reducing dimensionality by one. Trim and slice operations can be combined arbitrarily in a GetCoverage request. Care has to be taken, though, to indicate an output format in the request which is capable of handling the resulting dimensionality and range type. For example, the output of a trimming on a 3-D cube, which will also be 3-D, can be delivered in NetCDF, but not in JPEG. A 2-D slice, on the other hand, can be delivered in JPEG. For reasons of modularity, some mandatory functionality packages have been separated into extensions. One such extension is raster subsetting based on array indexes; this is required if the server offers raster coverages. Furthermore, a minimal complete WCS implementation must support at least one format and one protocol extension. We will discuss such extensions next. WCS 2.0 Coverage Service Extensions

At early stages of the design of WCS 2.0, it was obvious that the number of extensions would not just be two or three. Nowadays, the current count of extensions developed and foreseen are already fifteen. This has prompted the need to structure the "WCS extension universe" in a suitable way, that is: allowing readers of the specifications to easily grasp the "big picture".


The figure shows the structuring using UML class diagram notation where each specification is represented as class. Notably, this UML diagram does not capture all dependencies – UML has turned out to be insufficient for representing all the details of semantic relationships between the specifications. This is not a big issue, though - it is understood that the diagram serves for overview purposes only, it is not normative.

Extensions are grouped into five categories: Data model, coverage encoding format, service, protocol binding and usability. Data model extensions add further information to coverages. An example of extension that has not been addressed yet, the uncertainty extension, is going to add error estimates, uncertainty information, and other quality relevant metadata to coverages.

Service model extensions, on the other hand, extend functionality on the coverages offered. WCS-T allows modifying a server’s offering by adding, updating or deleting coverages. The Processing extension ties in the OGC Web Coverage Processing Service (WCPS) Standard which defines a declarative query language on multi-dimensional raster data in the tradition of SQL. The scaling and interpolation extension adds scaling, resampling and interpolation to the GetCoverage request. As such, it paves the way (and, hence, it is a mandatory prerequisite) for the CRS extensions. The simple CRS extension version adds EPSG coordinate reference systems so that CRS transformation of coverages becomes possible in GetCoverage requests. The general version additionally allows ad-hoc defined and nested CRSs. The family of coverage format encoding extensions will support coverage delivery in the various well-known image and scientific data formats. First in line are GeoTIFF, NetCDF, and JPEG2000; more will follow pending on demand and on resources. Among coverage format extensions, a special role is played by the GML extension; on the one hand, it defines XML as an output format (GML 3.2.1. already foresees four different, semantically equivalent, encodings). On the other hand, this format defines a wrapper around the other formats. This allows three different variants to be delivered, which all have been requested by the user community:

• Delivery of the image/data file alone. This allows existing applications to readily digest the coverage file delivered. This approach has the problems that metadata can be missing or represented only incompletely, depending on the particular format.
• Delivery of pure GML. This format delivers all metadata according to the standardized XML schema, plus the range value data also encoded in GML. While for in-situ sensor time series, for example, this is appropriate, it is not efficient for high-volume coverages.
• Delivery of a GML metadata record together with an encoded file, MIME-encapsulated (multipart/related). This allows taking advantage of the encodings while delivering a complete set of metadata in the canonical XML format.
The fourth extension category consists of the Protocol Bindings. Currently, the supported protocols bindings are GET/KVP, XML/POST, and XML/SOAP; a RESTful binding might be added depending on demand and on resources.

Finally, the Usability group collects extensions which add neither coverage data structures nor coverage functionality. Currently, multilingual support has been placed here. Only few extensions have been written so far, some are in progress and several more are waiting to be scheduled. In the spirit of the volunteering approach of standardization bodies like OGC there will be a natural line-up: extensions will be written once somebody considers them important enough to write them. WCS 2.0 Application profiles

Given the substantial number of extensions, the question arises on how to achieve interoperability among implementations choosing different extensions, and also on how to give guidance to implementers on a wide selection of extensions. To this end, the concept of Application Profiles (APs) is provided by OGC. An Application Profile represents a bundle of specifications together with some suitable additional data structures and functionalities as well as bespoke rules for the envisaged application domain. For WCS, an Earth Observation Application Profile (EO-AP) is already available which focuses and extends WCS specifically to remote sensing data services. It incorporates at least one of GET/KVP and XML/SOAP protocol bindings, at least one of the formats GeoTIFF, NetCDF, and JPEG2000, and the range subsetting extension. Further specializations include, in terms of data structures, requiring GML Earth Observation Metadata to be present in the coverages delivered and also requiring support for 2-D x/y and 3-D x/y/t coverages. In terms of functionality it requires the scaling and interpolation extension and the CRS/EPSG extension.
Another application profile aimed at atmospheric and ocean data is foreseen for the future.

2.3 Reference to associated videos, books, and other resources, if in existence




<<Prev T.O.C Next>>


Files (0)

You must login to post a comment.