GSIP 92

GSIP 92 - Allow plugins to modify WMS MapContent before map rendering

Overview

Allow the WMS MapContent to be manipulated by plugins before rendering occurs

Proposed By

Andrea Aime

Assigned to Release

2.4.0

State

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

Motivation

The DispatcherCallback provides a nice way to manipulate a request to the plugin implementor will.

The WMS GetMap path ends up building a WebMapContent which is the passed to the various rendering engines, however, once build, it’s not possible to manipulate it in a pluggable way, disallowing customizations.

Proposal

We propose to create a new interface, tentatively called GetMapCallback, mimicking the DispatcherCallback basic idea, that is, to follow and manipulate the internal lifecycle of a GetMap request:

interface GetMapCallback {

/**\*
** Marks the beginning of a GetMap request internal processing
*/
 WebMapRequest initRequest (WebMapRequest request);

/**\*
** Called when the WMSMapContent is created (at this point the
WMSMapContent 
* is empty) On multidimensional requests against
* multi-frame output formats (e.g. animated GIF) this method can be
called 
* multiple times, once per generated frame
*/
 void initMapContent (WMSMapContent content);

/**\*
** Called before a layer gets added to the map content, allows the layer
to be 
* modified. If the returned value is null the layer will not be added
to the 
* map content
*/
 Layer beforeLayer (WMSMapContent content, Layer layer);

/**\*
** Inspects and eventually manipulates the WMSMapContent, returning
* a WMSMapContent that will be used for map rendering. 
* In case of multi-frame output formats this method will be called
* once per frame.
*/
 WMSMapContent beforeRender (WMSMapContent mapContent);

/**\*
** Called once when the rendering is completed, allows the output WebMap
to be 
* inspected, modified or replaced altogheter
*/
 WebMap finished (WebMap map);

}

With the above callback the implementor is allowed to:

• inspect and modify the WebMapRequest
• inspect, modify and remove Layer objects from the MapContent
• inspect and modify the WMSMapContent
• inspect and modify the resulting WebMap
• throw unchecked exceptions, covering both the case of security checks compatible with Spring security, and OGC service exceptions, suitable for other types of checks.

In case multiple GetMapCallback are found the code will “chain” them, making each one work on the results of the previous call.

The first implementation of this interface will be used to implement a WMS-EO requirement. In the WMS-EO layer tree for a certain EO product there is a <layer>\_bands sub-layer advertising the bands of the product as separate WMS dimensions using the BANDS custom dimension. If the user asks for one band, the code will have to return a gray map with that band, if three values are specified, then a RGB map will be composed with them, otherwise an exception must be thrown. The code will check the proper usage of the dimension values, and manipulate the raster layer description in order to switch the image mosaic to the STACK mode, required to perform the band merging.

Other possible usages are related to security checks, per user customization of the generated map, and custom map decoration additions using DirectLayer.

Feedback

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

Backwards Compatibility

No backwards compatibility issues found.

Voting

Alessio Fabiani: +1 Andrea Aime: +1 Ben Caradoc Davies: +1 Christian Mueller: +1 Gabriel Roldan: Jody Garnett: +1 Jukka Rahkonen: +1 Justin Deoliveira: +1 Phil Scadden: +1 Simone Giannecchini: +1

Links

JIRA Task Email Discussion Wiki Page