Developer’s Corner: Cartographic Rendering Improvements in GeoServer

Dear reader,

today we would like to share some recent improvements in GeoServer cartographich rendering, which will be useful for everybody, but great for those dealing with roads mapping.

The first one is z-order control, in GeoServer 2.8 there are two new FeatureTypeStyle VendorOption allowing to control in which order the features get painted, inside a single layer, or even across layers. Here is an example from our user guide, where over and under passes, as well as rail bridges, are properly honored in the map rendering:

Z-Order Control at work with OSM Data

This is made possible by specifying the following two vendor options in all FeatureTypeStyle involved in the above map (as you can see, there is extensive use of road casing, so expect to find several FeatureTypeStyle elements in the style):

<FeatureTypeStyle>
   <!-- rules here -->
   ...
   <VendorOption name="sortBy">z_order</VendorOption>
   <VendorOption name="sortByGroup">roadsGropu</VendorOption>
</FeatureTypeStyle>

The second important improvement is to leverage the SLD ability to specify multiple fonts in a more dynamic way. Up until now, the list of fonts was scanned and the first available font was used, resulting in a static decision before rendering the labels. Now, if there are multiple fonts, they are tried in turn to check if thet can actually render a certain label: if a map labels have multiple scripts they can now be seamlessly rendered without having to find a single font that can render all type of scripts (which might be a difficult proposition if your map contains all possible scripts, like OSM). Even better, if a single label contains multiple scripts, the different fonts will be used in turn for the different parts of the label. Here is an example over Hong Kong:

Advanced rendering for OSM data over Hong Kong

The style contains two fonts, “Droid Sans”, which renders many common scripts, but not traditional Chinese, and “Droid Sans Fallback”, which instead contains the traditional Chinese glyphs:

 <Rule>
<MaxScaleDenominator>32000</MaxScaleDenominator>
<TextSymbolizer>
<Label>
<ogc:PropertyName>name</ogc:PropertyName>
</Label>
<Font>
<CssParameter name="font-family">Droid Sans</CssParameter>
<CssParameter name="font-style">Normal</CssParameter>
<CssParameter name="font-size">14</CssParameter>
</Font>
<Font>
<CssParameter name="font-family">Droid Sans Fallback</CssParameter>
<CssParameter name="font-style">Normal</CssParameter>
<CssParameter name="font-size">14</CssParameter>
</Font>
<LabelPlacement>
<LinePlacement>
</LinePlacement>
</LabelPlacement>
<Halo>
<Radius>
<ogc:Literal>2</ogc:Literal>
</Radius>
<Fill>
<CssParameter name="fill">#FFFFFF</CssParameter>
<CssParameter name="fill-opacity">0.85</CssParameter>
</Fill>
</Halo>
<Fill>
<CssParameter name="fill">#000000</CssParameter>
</Fill>
<VendorOption name="group">true</VendorOption>
<VendorOption name="followLine">true</VendorOption>
</TextSymbolizer>
</Rule>

Both of this improvements have been sponsored by DLR under via a enterprise support contract.

Finally, let’s see an improvement recently developed and donated by IGN to the community, which will make many happy: better space reservation in the conflict resolution engine for tilted or line following labels. In particular, for this class of labels the space reservation is made on a char by char basis, instead of reserving the entire bounding box covering the label.  Here is a “before and after” comparison:

Entire label bbox occupancy VS single char occupancy bbox

This in turn results in a significantly denser labelling on road networks, for example, here is our sample layer nyc:roads after the cure:

Denser labels, thanks IGN!

If you want to know more about how we can help your organization, don’t hesitate and get in touch with us!

The GeoSolutions Team,