Klassen

1. Objekte

Im Simplex sind Objekte alles, was ein für sich stehendes Realweltobjekt ist, je nach Detailgrad einzeln oder kollektiv (Wald / Baum).

Beispiele für Objekte: ein Gebäude, eine Straße, eine Gemeinde, aber auch: Ein Raum in einem Haus, ein Straßenabschnitt (z.B. eine Fahrspur), ein Ortsteil einer Gemeinde.

Keine Objekte, sondern Attribute sind z.B. eine Hausfarbe, oder die Höchstgeschwindigkeit an einer Straße.

Keine Objekte, sondern eine Verbindung ist z.B.: die Verbindung Straße - Haus.

Objekte werden in Klassen angeordnet (z.B. Gebäude, Straßen, Verwaltungseinheiten). Jedes Objekt ist Teil genau einer Klasse.

2. Standardfelder

Alle Objekte im Simplex verfügen über acht definierte Standardfelder, welche ihre wichtigsten Daten enthalten sollen und eine Homogenität innerhalb des Datenpools ermöglichen. Alle weiteren Informationen zu Objekten werden durch einzeln zu spezifizierende Sachattribute ergänzt.

In Datenbank-Logik ausgedrückt, ist ein Objekt einer Klasse eine Zeile in der Datenbank und jedes Feld eine Spalte dieser Zeile.

Die acht Standardfelder wurden sorgfältig evaluiert, um auf einer abstrakten Ebene in möglichst vielen Kontexten nutzbare Informationsfelder zu liefern. Sie sollen möglichst in der hier angegebenen Art verwendet werden, um eine Einheitlichkeit und Harmonisierung der Daten zu erlauben.

Mit Ausnahme des Feldes "ndx" müssen sie nicht verwendet werden, wenn die Quelldaten nicht geeignet sind.

Name Format Funktion Kommentar Beispiel
ndx String Eindeutiger (interner) Schlüssel des Objekts Einziges obligatorisches Feld (s.u.)

Hausnummer + Straßenname +

PLZ

nam String Name des Objekts Sollte als „Hauptrufmerkmal“ benutzt werden, mit der ein Objekt bezeichnet wird. Anlage 7; Frankfurt am Main
dsc String Ergänzende Beschreibung des Objekts Kurze, beschreibende Details.

Oft auch als "die grüne Anlage" bezeichnet.

"Ein Knotenpunkt des europäischen Finanzsystems "

cmt Freitext Kommentar zum Objekt (beliebig lang) Beliebig lange Informationen in Textform. "Frankfurt wurde erstmalig urkundlich erwähnt ..."
key String Ein Datenfeld, das einen Schlüssel oder ein anderes Wiedererkennungsmal darstellt. Dieser muss nicht eindeutig sein. Platz für einen weiteren Fachschlüssel. Hausnummer
typ String Typ, Art, o.ä., Unterkategorie des Objekts innerhalb seiner Klasse, oft Eintrag eines Schlüsselwortes oder eines Elements eines ENUM.

Ein heißer Kandidat sind Felder, die als  „Art“ o.ä. bezeichnet werden.

Hier kann es sich im Konvertierungsprozess auch lohnen, eine Konstante festzulegen, z.b: "Gemeinde"

Kreisfreie Stadt
beg Zeitwert DD.MM.YYYY HH:MI:SS Start der Lebenszeit des Objekts Kann beliebig genau angegeben werden. 1977-01-01 01:00:00+01
fin Zeitwert DD.MM.YYYY HH:MI:SS Ende der Lebenszeit des Objekts Kann beliebig genau angegeben werden. 2002-05-31 02:00:00+02

Detailhinweise

(1) ndx
Ergibt sich aus dem Prozess des Updatens
Wonach ist es beim nächsten update wiedererkennbar? → das kommt in ndx

Ndx kann im Konvertierungsprozess erst gebildet werden. Eindeutigkeit kann hier "herbeigetrickst" werden. Die Konsequenz ist allerdings, dass solche Klassen dann nicht geupdated werden können.

Für nicht eindeutige Schlüssel steht das Feld key bereit.

Wenn mehrere Schlüssel für ndx und/oder key infrage kommen, hilft die Frage: welcher Schlüssel bezieht sich wirklich auf das Objekt, um das es gerade geht? (Wenn die Wohnung einen Gebäude-Key hat, dann sollte der nicht im Wohnungsobjekt landen, sondern im Gebäude-Objekt, oder in einer Verbindungstabelle zwischen Wohnungen und Gebäuden.)

(2) nam, dsc, cmt: was ist der Unterschied?

Die drei Felder nam, dsc und cmt sind oft Felder, die direkt oder indirekt aus einer händischen Eingabe von Nutzer*Innen stammen. Sie lassen sich definitorisch nur schwer voneinander abgrenzen. Es sollte darauf geachtet werden, dass innerhalb eines Datenpools möglichst gleichartige Dinge für die jeweiligen Felder benutzt werden.

Dabei ist der Vergleich verschiedener Quellstrukturen hilfreich: was würde jeweils in nam landen, was in dsc, was in cmt?

3. Taxonomie der Klassen gemäß des Simplex Modells

Jede Klasse muss in der Taxonomie des Simplex-Modells verortet werden.

Diese Taxonomie bietet die Möglichkeit, den fachlichen Hintergrund der Daten anzugeben. Die Spezifikation hat keinerlei technische Konsequenzen. Es geht hier um eine menschenlesbare grobe Einteilung, in welche „Schublade“ die Daten gehören, um leichter mit großen Datenmengen hantieren zu können.

Maximal 3 Buchstaben stehen zur Verfügung. Sie beschreiben die Klasse immer spezifischer.

Diese Einteilung muss nicht einmalig sein. Es kann z.B. mehrere Klassen mit „bhi“ geben.

Für den ersten Buchstaben gibt es nur drei Möglichkeiten:

Name Typ Beispiel
A Prozesse in unserer Umwelt z. B. Emissionen, Immissionen, Störungen, Havarien, Produktion und Konsumtion
B Betrachtungsobjekte georeferenzierte Daten, Verkehrs-, Ver- und Entsorgungsnetze, (Schutz-) Gebiete, Bebauungspläne, Gebäude
C Handlungen zur Bewertung, Messung, Steuerung und Regulierung Genehmigungen, Messungen, Planungen

Für die folgenden beiden Buchstaben dagegen gibt es die folgenden Möglichkeiten:

Die folgende Tabelle enthält einige Beispiele für mögliche Auswahlen der Buchstaben:

Objekt Typ Begründung
Gemeinde bs b=Betrachtungsobjekt s=administrative Einheit
Pegelmessstelle bmh b=Betrachtungsobjekt m=Messtelle h=Hydrosphäre
Pegelmessung cmh c=Handlung m=Messtelle h=Hydrosphäre
Fließender Verkehr avs a=Prozess v=Distribution und Verkehr s=Steuerung/Management
Schmutzwasserzufluss in ein Gewässer ajh a=Prozess j=Imission h=Hydrosphäre