OHDM Data Model

Requirements

We use PostGIS as basis for OHDM. Following extensions must be installed:

• HSTORE

Data Model

The following sketch of the data model is going to be redrawn to satisfy standards. Take it as a sketch right now:

Principle

OHDM distinguishes between geometry and geographic objects. We store objects in OHDM which have a footprint on mother earth. Those objects have got a geometry. That describes e.g. shape and position of that object. The geographic object has more features, though.

It has a name. It can be classified. An object can be e.g. a highway, a building, a river or just a stop of a bus in public transport.

A classification can change, though. A residential way can become a larger highway. A building can change its usage. Sometimes a cloister becomes a school. Sometimes a university is lodged into a building that used to be a factory. Sometime, even highly militarized borders become a park.

A geometry describes shape, position of something that has a footprint on mother earth.

Each geographic object is described by a geometry. A geometry describes aspects of a geographic object. A geometry can describe several geographic objects when time is passing by as to be seen with the cloister.

A geographic object can change geometry. A building can be extended. Offices of a company can change their position. We assume those offices the same geographic object with a changed geometry.

An obelisk can be found in the center of Paris. That obelisk was brought from Egypt in 19. century. The object (geographic object) is the same. Its geometry (position) has changed.

Lets summarize:

• Geographic objects are things that have a footprint on earth.
• Geographic objects have a geometry.
• A geometry describes a geographic object
• Relations between geographic objects and geometry can change over time. That makes up history.

OHDM will have several source:

• OSM will be major source for very young history. We are going to make an annual import of all OSM data
• We are working on extracting geometries from digitized old maps
• Volunteers can add information.

OHDM will keep those source information. There are two tables: external users stores an id and a reference to source systems. We keep a (growing) list of source systems in another table.

We keep source information on both. geometries and geographic objects.

We are going to describe the tables of the OHDM data model. (Note, that model is used for OHDM editors and is source for the rendering data base. The rendering data base is optimized for it use by GeoServer.)

OHDM tables

geoobjects

All geographic objects (which ever existed) are stored in that table.

Name	Typ	Description
id	bigint	primary key
name	character varying	Each object has got a name. (We are going to introduce multilingual aspects into OHDM.. in a subsequent edition.
classification_id	bigint	It's a foreign key that refers to an entry in the classification table. That table names all possible classes of geographic object, like _highways, rivers_ etc.
source_user_id	bigint	Foreign key: refers to external users table that keeps information about source of those information. Might be people or organizations.

classification

Each geographic object must be classified. Classification describes type (and sub-type) of the object. Object-classification is a n-1 relation: Each object has only one class but each class can have multiple objects. Of course, there can be numerous highways but each object can only be e.g. either a highway or a river.

Classification can change over time. In that case, a new object must be created which gets that new classification. (We had some discussion about that point. That's our decision).

The table contains classes and subclasses which are actually a subset of OSM map features, see our OSM-Import-Rules.

Name	Typ	Description
classcode	bigint	primary key
class	character varying	name of a class of object
subclass	character varying	name of a subclass

content

OHDM allows to attach arbitrary content to geographic objects. That table contains the content. Relation between content and object depends on time of course. There is another table which represents that relationship.

Name	Typ	Description
id	bigint	primary key
name	character varying	a name of that content
value	bytea	Arbitrary content of arbitrary format
mime type	character varying	MIME type of that content

geoobject_content

That table describes relationships between content and objects and validity in time.

Name	Typ	Description
id	bigint	primary key
valid_since	date	First date that content is valid for that object
valid_until	date	Last date that content is valid for that object
valid_since_offset	bigint	We need an offset to go back in time even before 3.00 b.c. which is the end of date
valid_until_offset	bigint	We need an offset to go back in time even before 3.00 b.c. which is the end of date
geoobject_id	bigint	Foreign key: Geoobject
content_id	bigint	Foreign key: Content

url

OHDM allows to attach arbitrary content to geographic objects. That content can either kept in the OHDM data base or outside. URL table keeps references to information outside OHDM. The geoobject_url table represents relationship between geoobject and those external information.

Name	Typ	Description
id	bigint	primary key
url	character varying	The URL

url_content

That table describes relationsship between url and objects and validity in time.

Name	Typ	Description
id	bigint	primary key
valid_since	date	First date that url is valid for that object
valid_until	date	Last date that url is valid for that object
valid_since_offset	bigint	Offset to go back to stone age.
valid_until_offset	bigint	Offset to go back to stone age.
geoobject_id	bigint	Foreign key: Geoobject
url_id	bigint	Foreign key: URL

external_systems

Each line in this table describe a system that is source of our OHDM data.

Name	Typ	Description
id	bigint	primary key
name	geometry	Systeme name
description	geometry	Brief description

external_users

Each line describes a user that was source of OHDM data.

Name	Typ	Description
id	bigint	primary key
userid	bigint	Foreign key: user id in that external system (if available)
username	character varying	Username (if available)
external_system_id	bigint	Foreign key to external_system table: id of the external system

points

The points table contains all geometrical description which descibe a single point. Each point in that table describes the actual position of at least one geographic object that was valid at least a single day. In other words: That table does not contain points which are only required to describe a line or polygon. At least one object can be found that existed on that point and was worth to be stored in OHDM.

Multipoints are allowed.

Name	Typ	Description
id	bigint	primary key
point	geometry	The point
source_user_id	bigint	Foreign key: refers to external users table that keeps information about source of those information. Might be people or organizations.

lines

Similar to points but for lines. Multilines are allowed.

Name	Typ	Description
id	bigint	primary key
line	geometry	The line
source_user_id	bigint	Foreign key: refers to external users table that keeps information about source of those information. Might be people or organizations.

polygons

Similar to points but for lines. Multipolygons are allowed.

Name	Typ	Description
id	bigint	primary key
polygon	geometry	The polygon
source_user_id	bigint	Foreign key: refers to external users table that keeps information about source of those information. Might be people or organizations.

geoobject_geometry

We have already discussed the temporal relationship between geographic objects and geometries. That table actually keeps those information. Each lines describes when that relationship was true. In other words, it describes when an object had that shape and position as described by the geometry.

That table allows also to describe a relationship between two geographic objects. Sometimes, objects have a relationship. E.g. a company can have a subsidiary company. Those, the subsidiary company is a part of the huger company. Each geometry of the subsidiary company is also a geometry of the mother company. Those relationships have temporal aspects. (E.g. there was once a fusion between Daimler and Crysler. They split again years later.) OHDM allows to describe those kinds of relationships.

Name	Typ	Description
id	bigint	primary key
id_geoobject_source	bigint	Foreign key: The geographic object that has a connection the either geometry (geometries) or other geographic objects
id_point	bigint	Foreign key: Point that describes the geographic object
id_line	bigint	Foreign key: Line that describes the geographic object
id_polygone	bigint	Foreign key: Polygon that describes the geographic object
id_geoobject_target	bigint	Foreign key: Another geographic object that is part of the source object. That could be the subsidiary company in our previous example
valid_since	date	First date that relationship is valid
valid_until	date	Last date that relationsship is valid
valid_since_offset	bigint	Offset to go beack to stone age.
valid_until_offset	bigint	Offset to go beack to stone age.