WCS configuration¶

Coverage processing¶

The WCS processing chain can be tuned in respect of how raster overviews and read subsampling are used.

The overview policy has four possible values:

While reading coverage data at a resolution lower than the one available on persistent storage its common to use subsampling, that is, read one every N pixels as a way to reduce the resolution of the data read in memory. Use subsampling controls whether subsampling is enabled or not.

Resource consumption limits¶

The request limit options allow the administrator to limit the resources consumed by each WCS GetCoverage request.

The request limits limit the size of the image read from the source and the size of the image returned to the client. Both of these limits are to be considered a worst case scenario and are setup to make sure the server never gets asked to deal with too much data.

To understand the limits let’s consider a very simplified example in which no tiles and overviews enter the game:

• The request hits a certain area of the original raster. Reading it at full resolution requires grabbing a raster of size rw * rh, which has a certain number of bands, each with a certain size. The amount of memory used for the read will be rw * rh * pixelsize. This is the value measured by the input memory limit

• The WCS performs the necessary processing: band selection, resolution change (downsampling or upsampling), reprojection

• The resulting raster will have size ow * oh and will have a certain number of bands, possibly less than the input data, each with a certain size. The amount of memory used for the final raster will be ow * oh * pixelsize. This is the value measured by the output memory limit.

• Finally the resulting raster will be encoded in the output format. Depending on the output format structure the size of the result might be higher than the in memory size (ArcGrid case) or smaller (for example in the case of GeoTIFF output, which is normally LZW compressed)

In fact reality is a bit more complicated:

• The input source might be tiled, which means there is no need to fully read in memory the region, but it is sufficient to do so one tile at a time. The input limits won’t consider inner tiling when computing the limits, but if all the input coverages are tiled the input limits should be designed considering the amount of data to be read from the persistent storage as opposed to the amount of data to be stored in memory

• The reader might be using overviews or performing subsampling during the read to avoid actually reading all the data at the native resolution should the output be subsampled

• The output format might be tile aware as well (GeoTIFF is), meaning it might be able to write out one tile at a time. In this case not even the output raster will be stored in memory fully at any given time.

Only a few input formats are so badly structure that they force the reader to read the whole input data in one shot, and should be avoided. Examples are: * JPEG or PNG images with world file * Single tiled and JPEG compressed GeoTIFF files

Limited SRS list¶

Some clients may have problems processing a GetCapabilities document listing the complete list of SRS (projections) that GeoServer supports by default. You may also find some projections are not appropriate for your data products.

Use this setting to limit the default list of supported SRS (projections) for the service. This list will be used by default, individual coverages define their own list of SRS (projections).

To limit the service to only the required projections use the Limited SRS List text box to list the desired EPSG codes separated by commas, e.g. 4326,27700 .