Add a flexible WMS tool to generate animations based on sequences of WMS maps

Andrea Aime Alessio Fabiani

2.1.2 or 2.1.3

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

Current WMS can only generate static maps. There is however a number of use cases in which generating an animation is interesting. One obvious case is time based animation, but elevation based animation is just as interesting, and there are cases in which the various frames have to be generated by changing the parameters of sql views, sld substitution parameters, or plain coordinates of the generated map (to get a moving one).

This proposal wants to add an animated GIF output that can be used out of the box with time/elevation based requests, but also an “animator” endpoint, similar to the wms and kml reflectors, that would allow to template a request and replace in turn different parameters to get an animation.

The animated GIF output format would be the first format to support rendering list of rendered images contained in a WebMap. This output format will work for any kind of WMS request, no need to use the animator endpoint.

The existing code already generates a WebMap with a RenderedImageList inside in case the request specified multiple times/elevations and the output format has the “multivalueRequestsSupported” flag up, which is what the animated gif output format would have.

The format would be associated to the “image/gif;subtype=animated” mime type to tell it apart from the existing GIF output format. The format would also allow finer control of the generated animation via the following two new format options:

• loop: if true the animation will loop indefinitely (defaults to true)
• delay: time, in milliseconds, a frame stays on before moving to the next frame (aka the time between frames)

The animator would work pretty much like the WMS reflector, but would be installed on the wms/animate path: given an incomplete WMS request it would fill it put and use extra parameters to turn it into a repeated template:

• aparam: the name of the parameter that will be used to change the request at each step. Could be anything from layers, cqlfilter, bbox, style and so on. In case it is a nested parameter, like for the formatoptions, env and view_param case, it will take the form of container:name, for example, view\_params:year
• avalues: a comma separated list of the values the parameter will take.

One example of animated request based on a changing bbox will be:

wms/animate?layers=topp:states&aparam=bbox&avalues=-90\,40\,-60\,70,-80\,40\,-60\70,-70\,40\,-50\70

which would generate an animation of the layer with the camera scrolling towards east.

An example of an animation changing colors based on SLD enviroment variable would be instead:

wms/animate?layers=topp:states,topp:states&styles=polygon,selection&aparam=env:color&avalues=FF0000,00FF00,0000FF

which would generate an animated map whose selection color (coming from the color parameter and used in the selection style) would iterate between red, green and blue.

The animator would unpack the values, build the replacement parameter, kvp parse it and run the wms request which is then executed to generate one frame. This of course might generate invalid requests, it’s up to the caller to ensure the request is valid.

The animator modification is a core one, } would have a new method:

  WebMap animate(GetMapRequest request) 

and the GetMapRequest would have two additional optional fields, aparam and avalues.

The WMS configuration would get a new parameter to limit the number of frames an animation can contain. If the limit is below 2 the animator would disable itself.

The above would be added under the consideration that an animation can require significant resources to be generated, both memory and CPU wise.

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

State here any backwards compatibility issues.

Andrea Aime: +1 Alessio Fabiani: +1 Ben Caradoc Davies: +1 Gabriel Roldan: +1 Justin Deoliveira: +1 Jody Garnett: +1 Mark Leslie: +1 Rob Atkinson: +1 Simone Giannecchini:

JIRA Task Email Discussion Wiki Page