deegree3 subsystem: Rendering API
Status: requirements cluster (2008/09/15)
Design and implementation documentation for the deegree3 rendering subsystem.
Contents
1. Current status
Collecting requirements, defining subsystem boundaries.
2. Requirements
The current proposal mostly concerns 2D rendering, as 3D rendering produces different requirements.
2.1. Service/WMS specific styling component
One component that is to be placed near the services module concerns the detemination of actual styles for a given geometry/feature/raster. SLD defines a complex set of expressions on feature properties that allows the user to specify the value of any attribute in a feature-dependent manner. SLD also makes use of the various filter encoding specifications so that only a limited set of features is used for a given style specification.
So a mechanism is necessary for the WMS that evaluates such a specification to a specification with the "blanks" filled in. The services specific styling component thus combines a set of SLD 1.1.0/SE 1.1.0 specifications and actual feature data to a list of geometries with styling information. Such a list could look like List<Pair<Geometry, List<Styling>>> in Java code.
The benefit is that the attribute information of the features is irrelevant after this step, as it's only needed to determine which features to render, and how exactly to render the features.
The geometries are referenced through the deegree3 geometry interface, and the actual stylings are referenced through a new deegree3 Styling interface (which will be created in commons).
2.2. Service/application independent styling component
A set of classes will be created in the commons package that encapsulates all possible styling information for (not only geometry) primitives, such as a TextStyling defining attributes such as font name, font size etc., a RasterStyling, containing information contained in a SE RasterSymbolizer or a PointStyling containing information on point symbols to use, size of the symbols etc.
"Geometry" primitives include Polygons, Points, Lines, Text and Rasters. The Multi* variants can be reduced to the simple case (since rendering of eg. MultiPolygons is the equivalent of rendering the list of polygons contained within).
2.3. Rendering component
The actual rendering component can be used to render a geometry/text/raster using styling information. The method signature of a rendering function could look like this: render(Geometry, List<Styling>)
The rendering component may be implemented using the Java2D API as backend, or using OpenGL.
Next steps include:
- create the Stylings API
- implement the rendering component for the two backends
- perform tests on the speed of the rendering component
- implement the service specific styling component (depends on filter encoding,
- which depends on feature model)
3. Wishlist
4. Roadmap