Rendering data base

Principles

Each data rendering process should avoid complex operations on a data base especially when it comes to huge data. OHDM stores a huge amount of data in well-formed data base, see OHDM-Datenmodell. That data model has no redundancy but can hardly basis of a rendering process.

For that reason, we have a rendering data base which optimized for the rendering process which is actually achieved by some redundancies. That's not a very new idea, though. It's simply state of the art.

The idea is very simple. We follow OSM in some way and create a tables for each imported (and supported) major feature (see OSM-Import-Rules) and geometries. Thus, there is a table for all lines describing highways of any kind, e.g. geological things can be either geometry. There are three tables: geological_points, geological_lines and geological_polygones.

We use GeoServer to produce maps. For each table there is a style, e.g. for geological_points. Each style is associated with a layer and layers can be combined to a layer group. There is a e.g. geological_points layer but also a geological_lines and geological_polygones layer. All those layers are combined to a geological layer.

Each of those (group) layers is offered with GeoServer as WMS. Another group layer combines all layers and is called basic layer - which becomes standard layer for our OHDM WMS server.

Version 0 (zero)

In the first (or zero) version, rendering only uses a very small set of available annotations. Each rendering table includes

• depending what that table is dealing with: [point | line | polygone] (type is always geometry)
• subclass number (see OHDM classification)
• name
• valid_since
• valid_until

That version 0 is just a start to set up our GeoServer and to test the whole system. More sophisticated versions will follow.