[FrontPage] [TitleIndex] [WordIndex] 

WCS Development

Contents

  1. Requirements
    1. Other Issues
  2. Current status
    1. Compliance Test
    2. Test
  3. Performance
    1. GET
    2. POST
  4. Roadmap
  5. Design decisions / implementation
  6. Configuration
    1. Options
    2. Coverages
      1. SimpleDatasource
      2. MultiResolutionDatasource

Design and implementation documentation for the deegree3 coverageService.

1. Requirements

The deegree WCS will support the version 1.0.0.

1.1. Other Issues

Unfortunately gvSIG, one of the few WCS clients, is not able to parse responses (WCS_Capabilities, etc) with namespace prefixes. If we want to support this client, the output should use a default namespace.

2. Current status

There is a first implementation of the WCS 1.0.0 in deegree 3. It implements a SecuredSubController, parser for the requests and capabilities/coverageDescription exporter. All the raster coverage handling is already implemented by the raster api, see deegree3/CoverageSubsystemDevelopment.

There is a first configuration format that supports coverages from multiple raster files (directories) and multi resolution raster (one directory with raster files per resolution level). The format is not final and was not yet presented to the PSC. (See below.)

Since deegree3 is missing support for simple integration of spatial-aware sql datastores or shapefiles, the WCS cannot handle coverages with thousands of tiles.

TemporalDomains and rangeSets of the WCS spec are not implemented, but there is a basic support for multi-range raster in the raster API.

2.1. Compliance Test

The current implementation passed the CITE 1.0.0 compliance tests. The WCS test uses the old test engine that is only available online (http://cite.opengeospatial.org/tsOGC/). You need to create a free account to start the compliance tests.

The service to test needs to be reachable from the internet. So you either need to deploy the service on a web server or you can create reverse tunnel. If you have SSH access to example.com you can create a tunnel that maps port 8080 from example.com to your localhost (which is not reachable from the outside of your network) with the following command: 

ssh -nNT -R example.com:8080:localhost:8080 -luser example.com

Beware that a firewall may block access to example.com (like on web.lat-lon.de).

Read the Test Requirements for details on how to setup the service. (http://cite.opengeospatial.org/tsOGC/ViewTestSpec?SPEC=Web_Coverage_Server_1.0.0.html&TYPE=AVAILABLE&sesstype=OGC) Pay attention to the order of the supported formats.

Create a new session for your test. Type in the capabilities URL (you have updated the DCP urls, didn't you?), set the mime type to image/GeoTIFF and set the RESX and RESY to something sensible for your data. We do support XML requests but range sets are not implemented in the WCS, so don't tick that check box. Thats the configuration, now you can start the test. Be patient, it will take some time and your browser will reload for each test.

2.2. Test

There is a simple WMS to WCS proxy in resources/script/wcs/ to test the service with conventional WMS clients.

3. Performance

We did some benchmarks to see if the d3 WCS can keep up with the mature deegree 2 WCS. We loaded the official deegree WCS demo and the new d3 WCS into. Both used the same utah raster data from the demo (see resources/example/conf/wcs/wcs_configuration.xml for the d3 WCS config).

We used the Apache Benchmark (ab) util. In debian based linux distributions this program is included in the apache2-utils package.

The test configuration:

3.1. GET

We tested the both services with a single request, 1000 times with 8 concurrent requests. 

% ab -c8 -n1000 "http://localhost:8080/d3/services?service=WCS&version=1.0.0&request=GetCoverage&coverage=saltlakecity&crs=EPSG:26912&width=500&height=500&format=jpeg&BBOX=430000,4516500,431000,4517500"
% ab -c8 -n1000 "http://localhost:8080/deegree-wcs/services?service=WCS&version=1.0.0&request=GetCoverage&coverage=saltlakecity&crs=EPSG:26912&width=500&height=500&format=jpeg&BBOX=430000,4516500,431000,4517500"

The deegree-wcs results in ~19 requests per second, the d3 ~93 r/s. Tests with 16 concurrent requests, different formats (png, tiff) and larger output sizes (800, 1000) revealed a general performance boost of factor 4-5.

3.2. POST

To test GetCoverage-XML requests, we build the same requests as XML (see resources/example/requests/wcs/utah/GetCoverage/xml/GetCoverageUtah.xml). 

% ab -c16 -n500 -p ../../example/requests/wcs/utah/GetCoverage/xml/GetCoverageUtah.xml "http://localhost:8080/d3/services?"
% ab -c16 -n500 -p ../../example/requests/wcs/utah/GetCoverage/xml/GetCoverageUtah.xml "http://localhost:8080/deegree-wcs/services?"

The deegree-wcs results in ~15 requests per second, the d3 ~68 r/s.

To test the processing overhead for each request, we tested the POST requests with an output size of 50x50 pixel. The results were ~80r/s and ~800r/s, a whooping ten-fold improvement. Thats quite nice.

4. Roadmap

5. Design decisions / implementation

6. Configuration

This is a proposal for the configuration format (the ServiceConfiguration part). It is not complete, but it should give a general idea about how it could work.

6.1. Options

The SupportOptions element describes the WCS output options the service should support. 

<SupportOptions>
    <OutputFormat>tiff</OutputFormat>
    <OutputFormat>jpeg</OutputFormat>
    <OutputFormat>png</OutputFormat>
    <Interpolation>Nearest Neighbor</Interpolation>
    <SupportedCRS>EPSG:4326</SupportedCRS>
</SupportOptions>

Each Coverage may define a separate set of options or extend the global options (using the extend="true" attribute). 

<Coverage>
    <...>
    <SupportOptions extend="true">
        <SupportedCRS>EPSG:26712</SupportedCRS>
    </SupportOptions>
</Coverage>

6.2. Coverages

Each Coverage describes a raster layer of the WCS. The Identifier is a unique name that is used to address the coverage in GetCoverage and DescribeCoverage requests. Name contains a nice readable name of the coverage.

The data source of the coverage is described by the abstract DataSource element. 

<Coverage>
    <Identifier>utah</Identifier>
    <Name>Aerial photographs of Utah</Name>
    <DataSource  #substitution />
    <SupportOptions #optional />
</Coverage>

The current proposal provides two DataSource substitutions.

6.2.1. SimpleDatasource

The SimpleDatasource can contain multiple File elements that each points to a single raster file that should be included in the coverage. The crs attribute sets the CRS of the datasource, the default is the ubiquitous EPSG:4326. 

<SimpleDatasource crs="EPSG:26712">
    <File>../data/raster-1.tiff</File>
    <File>../data/raster-2.tiff</File>
</SimpleDatasource>

Or it can contain Directory elements that each points to a directory. All files in that directory will be loaded into the coverage. The files can be restricted with a filePattern and it can traverse multiple directories (recursive="true"). 

<SimpleDatasource>
    <Directory fileType="tiff" filePattern=".tif" recursive="true">../data/tiles/</Directory>
</SimpleDatasource>

In both cases the files will be loaded into a TiledRaster.

6.2.2. MultiResolutionDatasource

The MultiResolutionDatasource supports raster trees/pyramids. Each raster level is configured with a Resolution element. The resolution of the level can be set explicitly with the res attribute (<Resolution res="1.0">) or it will be calculated from the raster files. 

<MultiResolutionDatasource crs="EPSG:26912">
    <Resolution>
        <SimpleDatasource>
            <Directory fileType="jpg" filePattern=".jpg" recursive="true">../raster/saltlakecity/1.0</Directory>
        </SimpleDatasource>
    </Resolution>
    <Resolution>
        <SimpleDatasource>
            <Directory fileType="jpg" filePattern=".jpg" recursive="true">../raster/saltlakecity/2.0</Directory>
        </SimpleDatasource>
    </Resolution>
    <...>
</MultiResolutionDatasource>

CategoryDeegree3

2018-04-20 12:05