GSIP 47

GSIP 47 - WMS cascading

Overview

Add WMS cascading abilities to GeoServer

Proposed By

Andrea Aime

Assigned to Release

The proposal will be made available in release 2.1. Branch 2.0.x won’t be affected.

State

Choose one of: Under Discussion, In Progress, Completed, Rejected, Deferred

Motivation

WMS cascading allows for proxying a remote WMS server and merging the results with locally rendered data. This can be useful for a number of reasons:

• printing
• watermarking and decoration in general
• proxying a secured remote WMS into an intranet available server

Proposal

The patch attached to [http://jira.codehaus.org/browse/GEOS-623] contains a relatively full fledged implementation of WMS cascading. The following describes the patch changes in some details.

Catalog level

The catalog sees two new CatalogInfo subclasses, WMSStoreInfo and WMSLayerInfo.

WMSStoreInfo, a StoreInfo subinterface, describes a WMS server connection such as the capabilities link, and could contain other information such as authentication credentials and http timeout.

WMSLayerInfo, which extends ResourceInfo contains the layer name and eventually will be be place to host the cascaded named style list as well as cascading image format and other eventual vendor parameter to be used during the cascading.

The ResourcePool has been modified to cache the WebMapServer object used during the cascading operations so that the capabilities request gets cached as a result.

The persistence subsystem (XStream, loader and persister) have been modified to store the new objects following the same conventions as the other stores and resources, the main difference being that the store is described in a wmssstore.xml file whilst the the cascaded WMS layer is described in a wmslayer.xml file.

Example XML file contents for WMS stores:

<wmsStore>
 <id>WMSStoreInfoImpl~~4d27aabd:1285e50e612:~~7fd4</id>
 <name>Atlas of Canada</name>
 <type>WMS</type>
 <enabled>true</enabled>
 <workspace>
 <id>WorkspaceInfoImpl—570ae188:124761b8d78:–7ff3</id>

</workspace>

<capabilitiesURL>[http://atlas.gc.ca/cgi-bin/atlaswms\_en?VERSION=1.1.0&amp;request=GetCapabilities](http://atlas.gc.ca/cgi-bin/atlaswms_en?VERSION=1.1.0&amp;request=GetCapabilities)</capabilitiesURL>
</wmsStore>

and for a WMS layer:

<wmsLayer>
  <id>WMSLayerInfoImpl-4d27aabd:1285e50e612:-7fd3</id>
  <name>cirpolar_bound</name>
  <nativeName>cirpolar_bound</nativeName>
  <namespace>
    <id>NamespaceInfoImpl--570ae188:124761b8d78:-7ff4</id>
  </namespace>

  <title>Boundaries</title>
  <description>Boundaries in the North circumpolar region.  The representation of political features on this map may not necessarily represent the position of the Government of Canada on international issues of recognition, sovereignty or jurisdiction.</description>
  <abstract>Boundaries in the North circumpolar region.  The representation of political features on this map may not necessarily represent the position of the Government of Canada on international issues of recognition, sovereignty or jurisdiction.</abstract>
  <nativeCRS>GEOGCS[&quot;WGS84(DD)&quot;,
  DATUM[&quot;WGS84&quot;,
    SPHEROID[&quot;WGS84&quot;, 6378137.0, 298.257223563]] ,
  PRIMEM[&quot;Greenwich&quot;, 0.0],
  UNIT[&quot;degree&quot;, 0.017453292519943295],
  AXIS[&quot;Geodetic longitude&quot;, EAST],
  AXIS[&quot;Geodetic latitude&quot;, NORTH]] </nativeCRS>

  <srs>EPSG:4326</srs>
  <nativeBoundingBox>
    <minx>-179.667</minx>
    <maxx>179.062</maxx>
    <miny>40.739</miny>
    <maxy>59.105</maxy>

    <crs>EPSG:4326</crs>
  </nativeBoundingBox>
  <latLonBoundingBox>
    <minx>-179.667</minx>
    <maxx>179.062</maxx>
    <miny>40.739</miny>
    <maxy>59.105</maxy>

    <crs>EPSG:4326</crs>
  </latLonBoundingBox>
  <projectionPolicy>FORCE_DECLARED</projectionPolicy>
  <enabled>true</enabled>
  <store class="wmsStore">
    <id>WMSStoreInfoImpl-4d27aabd:1285e50e612:-7fd4</id>
  </store>

</wmsLayer>

The CatalogBuilder has been extended to deal with the new objects, as a bonus the builder feeds all metadata coming from the WMS server capabilities document into the WMSLayerInfo ones.

User interface

The usual store \-> layer workflow has been maintained adding a new custom page to configure the WMS store and modifying the layer listing and layer configuration pages to deal with the fact cascaded layers cannot be styled via SLD (at the time of writing at least).

Icons to identify a WMS store, layer and type have been taken from GeoSilk.

Adding a new store

Listing stores including WMS layers

Configuring a new cascaded layer with metadata coming from the server capabilities document

Cascaded WMS layer showing up in the preview panel

WMS module

Cascading has been implemented by using the GeoTools WMS client, and in particular the WMSMapLayer class, a MapLayer that makes most of the work making the renderer think it’s dealing with a coverage.

Supported features:

• Standard cascading
• Reprojected cascading, including the ability to pass the SRS down to the remote server should the SRS be included among the remote server supported list, otherwise the request is passed down in a supported SRS, adjusting the image ratio accordingly, and reprojecting client side
• GetFeatureInfo cascading for servers that do support the application/vnd.ogc.gml feature info format. Works in both standard and reprojected case.

The following screenshot shows a topp:states layer cascaded from demo.opengeo.org/geoserver, with reprojection and cascaded GetFeatureInfo results:

REST configuration

The patch adds new resources to represent a WMS store and a WMS layer. The follow the same patters as data stores and feature types, but use different locations:

/workspaces/{workspace}/wmsstores/{wmsstore}.{format}
/workspaces/{workspace}/wmsstores/{wmsstore}
/workspaces/{workspace}/wmsstores.{format}
/workspaces/{workspace}/wmsstores
/workspaces/{workspace}/wmsstores/{wmsstore}/wmslayers/{wmslayer}.{format}
/workspaces/{workspace}/wmsstores/{wmsstore}/wmslayers/{wmslayer}
/workspaces/{workspace}/wmsstores/{wmsstore}/wmslayers.{format}
/workspaces/{workspace}/wmsstores/{wmsstore}/wmslayers
/workspaces/{workspace}/wmslayers/{wmslayer}.{format}
/workspaces/{workspace}/wmslayers/{wmslayer}
/workspaces/{workspace}/wmslayers.{format}
/workspaces/{workspace}/wmslayers

Besides the path the behavior to the various kind of HTTP methods is exactly the same as with data stores and resources, meaning they both can be listed, shown, created by POST, updated by PUT, removed by DELETE. It’s also possible to list the available, but still unpublished, wms layers in a given store.

Missing features

The proposal does not include any of the following desirable features, which will be implemented as time allows:

• add support for alternate named styles
• support for specifying extra request parameters in the layer configuration (time, elevation, cql*filters and whatnot). Could be also used to provide a primitive interface for specifying named styles .
• allow the admin to specify a timeout
• full support in Restconfig
• improve the GeoTools client code so that we can use HTTP 1.1 persistent connections and limit the number of parallel connections we make to a single server .
• allow the user to choose the format used for cascading. Now we try png
• add a pure proxy mode, if the request contains only cascaded layers avoid decoding the image to just re-encode it afterwards
• add support for WMS with access restrictions
• support cascaded layers in GetMap requests that use &SLD and &SLD*BODY

Feedback

This section should contain feedback provided by PSC members who may have a problem with the proposal.

Backwards Compatibility

There are no backwards compatibility issues.

Voting

• Alessio Fabiani
• Andrea Aime +1
• Chris Holmes (Chair)
• Jody Garnett +1
• Rob Atkinson
• Simone Giannecchini +1
• Ben Caradoc-Davies +1
• Mark Leslie +1

Links

JIRA Task Email Discussion Wiki Page