.. _rendering_transform: Rendering Transformations ========================= **Rendering Transformations** allow processing to be carried out on datasets within the GeoServer rendering pipeline. A typical transformation computes a derived or aggregated result from the input data, allowing various useful visualization effects to be obtained. Transformations may transform data from one format into another (i.e vector to raster or vice-versa), to provide an appropriate format for display. The following table lists examples of various kinds of rendering transformations available in GeoServer: .. list-table:: :widths: 25 75 * - **Type** - **Examples** * - Raster-to-Vector - **Contour** extracts contours from a DEM raster. **RasterAsPointCollections** extracts a vector field from a multi-band raster * - Vector-to-Raster - **BarnesSurfaceInterpolation** computes a surface from scattered data points. **Heatmap** computes a heatmap surface from weighted data points. * - Vector-to-Vector - **PointStacker** aggregates dense point data into clusters. Rendering transformations are invoked within SLD styles. Parameters may be supplied to control the appearance of the output. The rendered output for the layer is produced by applying the styling rules and symbolizers in the SLD to the result of transformation. Rendering transformations are implemented using the same mechanism as :ref:`wps_processes`. They can thus also be executed via the WPS protocol, if required. Conversely, any WPS process can be executed as a transformation, as long as the input and output are appropriate for use within an SLD. This section is a general guide to rendering transformation usage in GeoServer. For details of input, parameters, and output for any particular rendering transformation, refer to its own documentation. Installation ------------ Using Rendering Transformations requires the WPS extension to be installed. See :ref:`wps_install`. .. note:: The WPS service does not need to be **enabled** to use Rendering Transformations. To avoid unwanted consumption of server resources it may be desirable to disable the WPS service if it is not being used directly. Usage ----- Rendering Transformations are invoked by adding the ```` element to a ```` element in an SLD document. This element specifies the name of the transformation process, and usually includes parameter values controlling the operation of the transformation. The ```` element syntax leverages the OGC Filter function syntax. The content of the element is a ```` with the name of the rendering transformation process. Transformation processes may accept some number of parameters, which may be either required (in which case they must be specified), or optional (in which case they may be omitted if the default value is acceptable). Parameters are supplied as name/value pairs. Each parameter's name and value are supplied via another function ````. The first argument to this function is an ```` containing the name of the parameter. The optional following arguments provide the value for the parameter (if any). Some parameters accept only a single value, while others may accept a list of values. As with any filter function argument, values may be supplied in several ways: * As a literal value * As a computed expression * As an SLD environment variable, whose actual value is supplied in the WMS request (see :ref:`sld_variable_substitution`). * As a predefined SLD environment variable (which allows obtaining values for the current request such as output image width and height). The order of the supplied parameters is not significant. Most rendering transformations take as input a dataset to be transformed. This is supplied via a special named parameter which does not have a value specified. The name of the parameter is determined by the particular transformation being used. When the transformation is executed, the input dataset is passed to it via this parameter. The input dataset is determined by the same query mechanism as used for all WMS requests, and can thus be filtered in the request if required. In rendering transformations which take as input a featuretype (vector dataset) and convert it to a raster dataset, in order to pass validation the SLD needs to mention the geometry attribute of the input dataset (even though it is not used). This is done by specifying the attribute name in the symbolizer ```` element. The output of the rendering transformation is styled using symbolizers appropriate to its format: :ref:`sld_reference_pointsymbolizer`, :ref:`sld_reference_linesymbolizer`, :ref:`sld_reference_polygonsymbolizer`, and :ref:`sld_reference_textsymbolizer` for vector data, and :ref:`sld_reference_rastersymbolizer` for raster coverage data. If it is desired to display the input dataset in its orginal form, or transformed in another way, there are two options: * Another ```` can be used in the same SLD * Another SLD can be created, and the layer displayed twice using the different SLDs Notes ^^^^^ * Rendering transformations may not work correctly in tiled mode, unless they have been specifically written to accomodate it. Examples -------- Contour extraction ^^^^^^^^^^^^^^^^^^ ``ras:Contour`` is a **Raster-to-Vector** rendering transformation which extracts contour lines at specified levels from a raster DEM. The following SLD invokes the transformation and styles the contours as black lines. .. code-block:: xml :linenos: contour_dem Contour DEM Extracts contours from DEM data levels 1100 1200 1300 1400 1500 1600 1700 1800 rule1 Contour Line #000000 1 Arial Normal 10 2 #FFFFFF 0.6 #000000 2000 true 100 50 30 Key aspects of the SLD are: * **Lines 14-15** define the rendering transformation, using the process ``ras:Contour``. * **Lines 16-18** supply the input data parameter, named ``data`` in this process. * **Lines 19-29** supply values for the process's ``levels`` parameter, which specifies the elevation levels for the contours to extract. * **Lines 35-40** specify a ``LineSymbolizer`` to style the contour lines. * **Lines 41-70** specify a ``TextSymbolizer`` to show the contour levels along the lines. The result of using this transformation is shown in the following map image (which also shows the underlying DEM raster): .. figure:: images/transform_contour_sf_dem.png :align: center Heatmap generation ^^^^^^^^^^^^^^^^^^ ``vec:Heatmap`` is a **Vector-to-Raster** rendering transformation which generates a heatmap surface from weighted point data. The following SLD invokes a Heatmap rendering transformation on a featuretype with point geometries and an attribute ``pop2000`` supplying the weight for the points (in this example, a dataset of world urban areas is used). The output is styled using a color ramp across the output data value range [0 .. 1]. .. code-block:: xml :linenos: Heatmap Heatmap A heatmap surface showing population density data weightAttr pop2000 radiusPixels radius 100 pixelsPerCell 10 outputBBOX wms_bbox outputWidth wms_width outputHeight wms_height the_geom 0.6 Key aspects of the SLD are: * **Lines 14-15** define the rendering transformation, using the process ``vec:Heatmap``. * **Lines 16-18** supply the input data parameter, named ``data`` in this process. * **Lines 19-22** supply a value for the process's ``weightAttr`` parameter, which specifies the input attribute providing a weight for each data point. * **Lines 23-29** supply the value for the ``radiusPixels`` parameter, which controls the "spread" of the heatmap around each point. In this SLD the value of this parameter may be supplied by a SLD substitution variable called ``radius``, with a default value of ``100`` pixels. * **Lines 30-33** supply the ``pixelsPerCell`` parameter, which controls the resolution at which the heatmap raster is computed. * **Lines 34-38** supply the ``outputBBOX`` parameter, which is given the value of the standard SLD environment variable ``wms_bbox``. * **Lines 40-45** supply the ``outputWidth`` parameter, which is given the value of the standard SLD environment variable ``wms_width``. * **Lines 46-52** supply the ``outputHeight`` parameter, which is given the value of the standard SLD environment variable ``wms_height``. * **Lines 55-70** specify a ``RasterSymbolizer`` to style the computed raster surface. The symbolizer contains a ramped color map for the data range [0..1]. * **Line 58** specifies the geometry attribute of the input featuretype, which is necessary to pass SLD validation. This transformation styles a layer to produce a heatmap surface for the data in the requested map extent, as shown in the image below. (The map image also shows the original input data points styled by another SLD, as well as a base map layer.) .. figure:: images/heatmap_urban_us_east.png :align: center Running map algebra on the fly using Jiffle ------------------------------------------- The ``Jiffle`` rendering transformation allows to run map algebra on the bands of an input raster layer using the `Jiffle language `_. For example, the following style computes the NDVI index from a 13 bands Sentinel 2 image, in which the red and NIR bands are the forth and eight bands (Jiffle band indexes are zero based), and then displays the resulting index with a color map: .. code-block:: xml :linenos: Sentinel2 NDVI NDVI coverage script nir = src[7]; vir = src[3]; dest = (nir - vir) / (nir + vir); 1.0 Here are a view of the area, using the visible color bands: .. figure:: images/s2-visible.png :align: center and then the display of the NDVI index computed with the above style: .. figure:: images/s2-ndvi.png :align: center