Developer’s Corner: Dynamic ColorMaps support for ImageMosaic
recently at GeoSolutions we worked on developing the ability to set up RenderingTransformations for raster data which leverage the statistics contained within persistent auxiliary metadata files (PAM) generated by GDAL in order to render coverages by using well known or custm colormaps adapting them to the statistics of the underlying raster.
In the short term these enhancements will be available only for the ImageMosaic plugin, but we plan to port them quickly to other raster plugins.
In this post we would like to share some insights on the improvements we made, in order to be useful to users which may want to do some custom rendering of datasets like remsens/metoc/physical params without the need of “manually” set up a list of values/ranges for each of them.
A new configuration parameter has been introduced yo the imageMosaic indexer mechanism (as new entry in the indexer.properties file or as new parameter in the parameters section within the indexer.xml) when configuring a new mosaic:
(It is worth to notice that you may add that entry to the mosaic property in case the mosaic has been already configured; just make sure to reload the mosaic).
This parameter suggests to the ImageMosaic machinery to look for .aux.xml file alongside the granules on disk. This parameter needs to be explicitly specified if you want that feature being enabled, in order to avoid small potential loss of performances for the classic cases where you don’t want to support it. (Suppose you have a 1000 granules mosaic then looking on disk for 1000 .aux.xml files should be avoided if you don’t need that feature).
If you want to play with this feature, you need to run gdalinfo -stats for each granule in order to generate the PAM auxiliary file for it. This will be serialized into a PAM Dataset object to be used for future statistics retrieval.
GeoServer DynamicColorMap Rendering Transformation
A new DynamicColorMap WPS Process ( and RenderingTransformation) has been implemented.
It basically takes an input coverage and a ColorMap reference (more on this later on…) to be applied to the input coverage for rendering.
An SLD Style that defines such a rendering transformation could be like this:
Notice the colorRamp function representing a filterFunction which allows to setup a ColorMap on top of the specified parameters:
- a literal _VALUE_ that defines how colors are mapped (see below)
- minimum and maximum values
- Note the minimum and maximum values are automatically computed by a gridCoverageStats filterfunction which takes these stats from the underlying coverage which have been previously setup by the ImageMosaic plugin though the PAM metadata.
How to specify colors
The literal _VALUE_ can be specified in three ways:
- A semi-colon separated list of RGB colors in this format:
- A semi-colon separated list of HEX colors in this format:
- A reference to a SVG file. See the next section.
Colors defined with method 1) and 2) will be equally distributed across the min – max statistics range
Therefore, a _VALUE_ like #0000FF;#00FF00;#FF0000 may result into this rendering
We have imported SVG files from QuantumGIS, by copying the QuantumGIS SVG resources folder from apps/qgis/resources/cpt-city-qgis-min to the GEOSERVER_DATA_DIR as a styles/ramps subfolder.
These SVG files contain a LinearGradient element which will be used to setup a ColorMap. An example of SVG content is this:
Which represents this color gradient:
We can use it within the previously defined style by setting the literal _VALUE_ like this:
Where we have defined the path and the name of the required SVG. Using such ColorMap will result into this rendering:
Current Status of the code
The code is currently available in the following fork/branches:
GeoTools ImageMosaic update: https://github.com/
GeoServer wps update: https://github.com/geosolutions-it/geoserver/tree/dynamiccolormap
It would be part of master branch for both GeoServer and GeoTools in a few days after release of ImageIO-Ext 1.1.8, hence they will be available at least for GeoServer 2.5.
Last but not least, we believe it is worth to mention that this work was performed via our GeoSolutions Enterprise Services frame contract.
If you’d like to know more about what you could achieve with GeoServer, do not hesitate and get in touch with us. If you need professional services to get started with Open Source software make sure to have a look at our GeoSolutions Enterprise Services.
The GeoSolutions team,