This page last changed on Mar 26, 2009 by bmmpxf.


GeoServer SLD support allows for extensive use of symbols to make maps.
Symbols can be simple raster icons, SVG vector files, shapes contained in dingbat style true type fonts (think Wingdings), and there is a GeoTools API to build new kind of symbol handlers, such as, for example, charts.
Some of the symbols are pretty much served as-is, minus some rescaling, others may be generic and in need for a set of parameters to customize them, such as fill and outline color:

  • the SLD WellKnowMark named 'square', it's a simple shape, and the user must provide a fill and a outline color to draw it
  • marks can be stacked to produce a more complex shape (this can be also done in the client, should be client be able to draw more than one symbol one on top of the other)
  • charts may need a set of parameters such as a chart type, a source for the data series, chart title, background color and so on

Normally GeoServer would leverage those symbol factories to bake the symbols into a raster map and serve it back to a client. There are a few cases in which this is not enough thought:

  • a style generator client such as styler may need to list and show what symbols are actually available and allow the user to browse them, and pick the desired one
  • a remote client asking for partially styled data such as Google Earth might need to go back to the server and ask it to generate that bull eye like symbol with 3 different stripes of color that the SLD style is talking about
  • a external app needs to manipulate the available set of symbols, for example by uploading a new set of raster symbols

All of these cases require a web service API of sorts allowing remote client to list, retrive, compose and manipulate existing symbols.

Technical details

As a first step the student will need to expand the use cases and define a RESTful API that can satisfy them.
Then, a set of configuration classes will be needed to actually describe the set of available symbols, with a different strategy for each kind of symbol, for example:

  • for raster images a set of image folder sources should be scanned
  • for TTF markers one has to find a way to list the chars that do actually correspond to a symbols
    Also, these configuration classes should list what kind of parameter a symbol has. Most will just have a size and rotation parameter, others can have outline and fill as well.
    These classes will also have to deal with different ways to add new symbols, for example, raster and SVG images can be just uploaded, TTF fonts can be uploaded only as a font set, charts wise the upload could be a sort or chart template.

Time permitting, an GeoTools dynamic symbolizers extension to deal with charts would be a welcome addition (properly done it could also be a SOC project on its own, actually).

Document generated by Confluence on May 14, 2014 23:00