Skip to content

RenderingDB

Thomas Schwotzer edited this page Jun 11, 2019 · 5 revisions

Introduction

Rendering DB is primary basis for Geoserver. It is also just as source for generating mapnik rendering tables, stRDF and OSM files.

Rendering tables are redundant from information point of view. All data are already in OHDM database. That's true. Even more, OHDM tables are normalized. The problem is the huge amount of data.

Rendering means: Producing tiles (technically: raster graphics like jpeg, png) out of vector geometries. Rendering requires data which are distributed over several tables in OHDM. Extracting data from different tables for one entity is timecomsuning when dealing with data of a whole planet.

The following table describes usage and source of each column in the rendering database.

point | line | polygon geometry (depending on table, a point, line etc.) from point, lines or polygon table
object_id foreign key OHDM object table from object_geometry table
geom_id foreign key OHDM (points, lines or polygons) table - it is redundant: the actually geometry is alsoin this table from object_geometry table
classid foreign key OHDM classification table from object_geometry table
subclassname name (string) of this subclass from classification table
tags additional osm tags (can be null) from object_geometry table
valid_since valid from (date) from object_geometry table
valid_until valid until (date) from object_geometry table
user_id user id (see comments below) from object_geometry table

User ID

Up to three users can be involved in creating a single row in a rendering database. Each row describes a relationship between an object and its geometry. Each information can be created by an individual user. In OHDM, each table (object, geometries, object_geometry) has its own user_id column. In OSM, all IDs are identical. Rendering tables only contain id of user who described that relationship - to avoid confusion.