-
Notifications
You must be signed in to change notification settings - Fork 3
RenderingDB
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 |
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.