This page last changed on Jan 10, 2007 by aaime.

Tiled rendering clients such as OpenLayers are making evident a few issues in Geoserver WMS rendering, which in turn is based on the Geotools streaming renderer.

This document tries to explan the issues and describe the solutions that have been adopted so far.

Minor rendering issues

Minor rendering issues have been identified and fixed:

  • Halos are not taken into account during label conflict resolution, this may result in one label halo overwrite other labels. (GEOT-1110, fixed).
  • Labels may be cut at tile borders despite labelling algorithms tries to avoid that (GEOT-1114, fixed).
  • Graphics and marks located at tile borders may be rendered even if they would appear as cut (GEOT-1109, fixed)

Meta buffer

Streaming renderer does query the database for features to be rendered using the current rendering bounds.
This is apparently ok, but in fact it's problematic because line and polygon strokes can be so thick that a geometry in an adjacent tile can contribute to the current tile rendering.
To handle this, the rendering bounds must be enlarged enough to capture the outside geometries that do contribute to the current tile: this is what TileCache and Ka-Map! do call the meta-buffer.
The geotools renderer has been extended in two ways:

  • a "buffer" parameter can be set to manually provide a buffer extimation. The buffer is expressed in pixels, and its converted in ground units automatically (this is because stroke widths are expressed in pixels). This is handled in GEOT-1115.
  • if no buffer parameter is provided, an automated estimator is used that scans the stiles for fixed width strokes and returns, for each layer, the thickest stroke (GEOT-1116). This covers the vast majority of cases automatically, but will fail for strokes whose size is expressed as an expression of feature attributes.

Tiling and labels

The current labeling algorithms does label conflict resolution by limiting the labels and graphics that will be considered and rendered to those that are completely inside the rendering bounds. Initial thougths suggested that crossing bound tiles could be considered if the labels considered into the conflict algorithm included also those in a big enough buffer, so that the meta-buffer could be applied to labelling as well.
More in deep investigation shows this is not completely possible. A first problem is, labels may be quite long, so the meta buffer you have to take into consideration may become really big, usually bigger than the actual tile size. This is mainly a performance issue, that may be solved by tile caching and by rendering a big enough meta-tile the same way TileCache does.

Unfortunately there are more, that deal with correctness.
Let consider a first simple example: label L1, crossing the rendering bounds conflicts with L2, which is outside the rendering borders. Should L1 be removed? Well, we don't know, because we don't know if L2 will really be there or not, that is, we should do conflict resolution on L2 before being able to tell. In the end, to really know, we would need load all labels in all the layers (conflict resolution applies to all labels from the rendere layers at once), which is clearly unacceptable from a performance point of view.
To avoid that, we would need an algorithm that provides a global answer on wheter a label is rendered based on local information, but it does not seem possible to have one, since we always want to render labels that do not conflict with any other (and conflict information requires global knowledge).

Moreover, when label grouping is enabled, we are facing another global issue: how big is the group we should consider in order to decide where to place the label? There's no meta-buffer that helps here.
Let's consider a road that crosses multiple tiles, the road being made up of multiple segments (separate features). Grouping allows to gather all the features with the same label and create a single label for them. Say the expanded tile contains f1..fn features, and the label point is such that the label will cross the tile borders.
The next tile will apply the same algorithm, but will get a different group, and so a different label point. If we would allow the first label to be rendered, it would appear cut, because the label point in the second one is not the same.

So, current analysis seems to suggest that it's not possible to render labels crossing tile bounds unless rendering is performed on a global scale.
TMS and tile caching effort will provide a reasonable compromise, that is, the meta-tile approach, where rendering is performed on a big image that's then split into tiles that get cached, by reducing the number of effectively rendered tiles.

groupIssues.png (image/png)
tileLabelConflict.png (image/png)
Document generated by Confluence on May 14, 2014 23:00