7 Entwurf eines objektorientierten Datenmodells

Im folgenden Kapitel soll die entwickelte Konzeption in ein objektorientiertes Daten­modell zur Verwaltung räumlich-temporaler Daten übertragen werden. Entwurfsziel ist hierbei nicht die Entwicklung applikationsspezifischer Strukturen, wie z.B. für ein Kataster-GIS oder ein historisches GIS, sondern die Formulierung eines objektorientierten GIS-Kerns, der die anwendungsunabhängigen Basiskonstrukte liefert, aus dem dann pro­blemorientierte Klassen abgeleitet werden können.

Abbildung 42: Architektur des Datenmodells



Quelle: Eigener Entwurf

Das Datenmodell ist in einzelne, hierarchisch abgestufte Schichten aufgeteilt, wobei jede Schicht spezielle Dienste für die übergeordnete Schicht anbietet (vgl. Abbildung 42). Als Ausgangsbasis dient das ODMG-Objektmodell, das für die datenbankspezifischen Opera­tionen zuständig ist. Darauf aufbauend folgen die GIS-spezifischen Klassen:

1. Die unterste Schicht verwaltet die Geometriedaten und stellt die im vorhergehenden Kapitel vorgestellte Zerlegung zur Verfügung. Einzelne Geometrie-Objekte werden zu Layern zusammengefaßt und über ein Koordinatensystem und zusätzlichen Metadaten beschrieben.

2. Die Zerlegung wird in der nächsten Schicht dazu verwendet, räumlich-temporale Objekte darzustellen. Ein Referenzsystem definiert temporale Elemente, die Zeit­punkte und -intervalle repräsentieren. Diese werden dazu verwendet, den zeitlichen Bezug von einfach strukturierten räumlichen Objekten der Spaghetti-Ebene sowie von topologisch strukturierten räumlichen Objekten herzustellen.

3. Die oberste Schicht repräsentiert die thematische Ebene, die die Geo-Objekte mit einem Anwendungskontext verknüpft.

Entsprechend dieser Gliederung erhalten alle Klassennamen eine Kennung vorangestellt, um sie einfacher zuordnen zu können: “G” steht für “geometry”, “C” für “coordinate system”, “T” für “temporal” und “ST” für “spatiotemporal”. Einer allgemeinen Konven­tion im Software-Engineering folgend sind alle Bezeichner in englischer Sprache benannt. Das vollständige Datenmodell in einer OMT-ähnlichen Notation (vgl. RUMBOUGH u.a. 1993) befindet sich im Anhang. In den einzelnen Abschnitten sind jeweils nur Ausschnitte dieses Gesamtmodells dargestellt. Dabei zeigen grau hinterlegte Klassensymbole an, daß hier noch weitere Subklassen definiert sind, die aber der Übersichtlichkeit wegen in der Darstellung ausgespart wurden. Da nicht in allen Fällen die Assoziationen graphisch dar­zustellen sind, wurden diese teilweise mit einem Bezeichner in das Klassensymbol mit aufgenommen.

Die Verknüpfung zwischen zwei Objekten erfolgt über Objektreferenzen. Programmier­sprachen wie C++ unterterscheiden Referenzen von Pointern bzw. Zeigern. Diese Dif­ferenzierung beruht auf technischen Aspekten der Speicherverwaltung und ist für die vor­liegende Arbeit nicht von Relevanz. Deshalb werden im Folgenden die Begriffe “Referenz”, “Pointer”, “Verweis” und “Zeiger” synonym verwendet.

7.1 Das persistente Objektmodell

Das persistente Objektmodell liefert die Basisdienste zur dauerhaften Verwaltung der Objekte in einem objektorientierten Datenbankmanagementsystem. Hier wird auf das in Kapitel 4.3 erläuterte ODMG-Objektmodell zurückgegriffen. Über dieser Basis ist die datenbanktechnische Infrastruktur zur Verfügung gestellt, auf der die im Folgenden beschriebenen GIS-spezifischen Klassen aufbauen. Konkret bedeutet dies, daß die vorge­stellten Klassen alle von der Superklasse d_Object abgeleitet sind, und damit über die Fähigkeit der Objektpersistenz verfügen. Aus Gründen der Übersichtlichkeit ist diese Ab­leitung aber nicht ausdrücklich in die Klassendiagramme aufgenommen. Es wird voraus­gesetzt, daß jede Wurzel eines Vererbungsbaumes ihren Ursprung in d_Object hat und daß damit die Instanzen aller abgeleiteten Klassen in einem objektorientierten Datenbank­system gespeichert werden können.

7.2 Das geometrische Modell

7.2.1 Übersicht

Der effizienten Verwaltung von Geometrie-Daten kommt in einem GIS eine zentrale Be­deutung zu. Die Wahl einer geeigneten Datenstruktur betrifft die Performanz des Gesamt­systems, die Unterstützung analytischer Algorithmen als auch Aspekte der Datensicherheit und -integrität.

Abbildung 43: Verwaltung der Geometrie-Daten



Quelle: Eigener Entwurf

Einzelne Gruppen von Geometrie-Objekten unterliegen gemeinsamen Konsistenzbe­dingungen und werden durch gemeinsame Eigenschaften charakterisiert. Beispielsweise erfordern Netzwerk-Anwendungen, daß die Verbindung zwischen zwei Knoten ohne weitere Schnittpunkte gebildet ist, und daß dementsprechend das Hinzufügen einer neuen Linie in den Datenbestand gegebenfalls zum Aufsplitten bereits vorhandener Linien führt. Folglich muß innerhalb eines GIS eine Software-Komponente vorhanden sein, die diese Bedingungen überwacht und weitere Informationen zur Interpretation der Koordinaten vorhält. In einem objektorientierten System wäre es theoretisch denkbar, diese Ver­waltungsaufgaben an die entsprechende Geometrieklassen zu delegieren, d.h. eine hypo­thetisch angenommene Linien-Klasse lieferte in diesem Fall nicht nur die strukurelle Be­schreibung der einzelnen Objekte, sondern überwachte auch die Konsistenzbedingungen zwischen den Objekten. Diese Ebene ist aber zu grob für eine sinnvolle Anwendung, da beispielsweise die Bedingung der Planarität zwischen Straßensegmenten und Flug­verbindungslinien, deren Geometrien in beiden Fällen durch Instanzen der Linien-Klasse repräsentiert sind, unnötige und sachlich unlogische Schnittpunkte produzieren würde.

Deshalb wurde hier ein flexibler Ansatz mit Geometrie-Layern gewählt. Jeder Layer ent­hält eine Menge an Geometrieobjekten, die alle vom selben Typ sind und darüberhinaus hinsichtlich des verwendeten Koordinatensystems und der Metadaten Gemeinsamkeiten aufweisen. Diese Anordnung erinnert stark an die Datenorganisation in einem konventionellen Layer-GIS. In dem hier vorgestellten Datenmodell steht ein Layer aber nicht für eine Informationsebene, sondern verwaltet Geometrien gleichen Typs mit gleichen Konsistenzbedingungen und weiteren geometriebezogenen Informationen. Die semantische Interpretation eines Elements dieser Layer als geometrische Repräsentation einer thematische Einheit erfolgt erst durch die Verknüpfung über ein Geo-Objekt mit einem Feature.

Besondere Anforderungen ergeben sich durch den zeitlichen Bezug. Wie diese zusätzliche Dimension in Standardanwendungen für einfache Datentypen integriert werden kann, zeigen beipielsweise die Arbeiten von SNODGRASS. Das hier vorgeschlagene Daten­modell konzentriert sich auf räumliche Daten und deren Veränderung im Zeitablauf. Ein Entwurfsziel ist hierbei die redundanzfreie Darstellung geometrischer Objekte, aus denen für jeden Zeitpunkt die korrekte Topologie ableitbar ist. Dieser Aspekt betrifft linienhafte Strukturen, die topologisch einen Graphen darstellen. Da Flächen hier über ihre Randdar­stellung festgelegt sind, gilt dies auch für deren Geometrien.

Abbildung 44: Veränderung eines Grenzverlaufs über drei Zeitpunkte

Quelle: Eigener Entwurf

Abbildung 44 zeigt ein Beispiel, in dem sich der Verlauf der gemeinsamen Grenzlinie zwischen zwei Flächen (z.B. zwei Staaten) ausgehend von einem Ausgangszustand in t₁ zu zwei weiteren Zeitpunkten t₂ und t₃ verändert. Andere angrenzende Umrandungslinien sind nur angedeutet und durch einen Knoten markiert. In einem konventionellen GIS würde man bei einer Änderung die alte Linie löschen und durch eine neue ersetzen. Hier soll aber für jeden Zeitpunkt nachvollziehbar sein, wie sich der Grenzverlauf gestaltet. In dem vorliegenden Beispiel ist die Topologie von den Änderungen nicht betroffen, d.h. die topologische Situation der beiden Flächen zueinander ist zu allen drei Zeitpunkten iso­morph. Die Änderung zu t₂ ist relativ trivial, da die gesamte Grenzlinie ersetzt wird. Linie b wird digitalisiert und eine spezielle Markierung zeigt an, daß diese Linie ab t₂ die gültige Verbindung zwischen den Knoten D und C repräsentiert. Linie a bleibt im System und die von a und b eingeschlossene Fläche zeigt die flächenmäßige Veränderung zwischen t₁ und t₂. Komplexer ist der Fall in t₃: um diese Änderung ohne doppelte Datenerfassung aufzu­nehmen, muß Linie b an den beiden Schnittpunkten mit c aufgetrennt werden. Der Linien­zug über b1, c und b3 ergibt nun die vollständige Verbindung zwischen D und C im Zeit­punkt t₃. Hier zeigt sich auch eine Besonderheit dieses Verfahrens bezüglich der topologischen Abbildung von Knoten-Kanten-Strukturen: obwohl die neuen Schnittpunkte die ursprüngliche Linie aufgetrennen, stellen diese zwei Punkte für die Situationsdarstellung in t₃ keine Knoten sondern lediglich Stützpunkte für die Verbindungslinie zwischen D und C dar. Dennoch müssen diese Schnittpunkte speziell verwaltet werden, da nur durch diese zusätzliche Verknüpfung der Verlauf sowie die flächenbezogene Änderung zwischen t₂ und t₃ als Ergebnis einer Abfrage darstellbar ist. Die Verwaltung solcher Situationen in einem Datenmodell soll in den nächsten Abschnitten dargestellt werden.

7.2.2 Die Geometrie-Klassen zur Verwaltung von Punkten und Linien

Da sich die vorliegende Arbeit auf Vektordaten in der Ebene beschränkt, kann man die Geometrie letztendlich auf einzelne Punkte in einem ebenen Koordinatensystem (=Vektoren) reduzieren. Sinnvollerweise werden geordnete Punktsequenzen (= Linien) zu einem kompakten Objekt zusammengefaßt. Punktsequenzen repräsentieren dabei einzelne Linienzüge sowie die Umrandung von Polygonen. Für Polygone wird implizit eine Ver­bindung zwischen dem ersten und dem letzten Punkt der Liste angenommen, damit die Umrandung geschlossen ist. Für einfache Anwendungen wären diese beiden Klassen aus­reichend und stellen zusammen mit einer abstrakten Oberklasse GGeometry ein einfaches Grundmodell dar, das sich so ohne weiteres für das Spaghetti-Modell anwenden läßt.¹

Abbildung 45: Einfaches Grundmodell für Geometrie-Objekte



Quelle: Eigener Entwurf

Jede Instanz der Klasse GPoint enthält zwei Integer-Variablen zur Aufnahme der dis­kretisierten Koordinatenwerte, während ein GPointSeq-Objekt eine Liste mit GPoint-In­stanzen besitzt. In dieser Liste können neue Punkte eingefügt, angehängt und wieder ge­löscht werden. Die Reihenfolge der Punkte beschreibt den Linienverlauf und wird ausge­hend vom ersten Element aufsteigend durchlaufen. Für die redundanzfreie Darstellung zeitlich variierender Linienverläufe bedarf es aber einer Erweiterung dieses Grundmodells.

Abbildung 46: Verlaufsänderung



Quelle: Eigener Entwurf

Abbildung 46 zeigt die Verbindung zwischen zwei Knoten A und B. Für die Verlaufs-änderung in t₂ wird lediglich das tatsächlich geänderte Teilstück erfaßt. Um den Sachver­halt für t₂ topologisch korrekt darzustellen, d.h. als durchgängige Verbindung zwischen den Knoten A und B, muß zunächst die bestehende Linie an zwei Stellen unterbrochen werden. Anschließend sind zwei der drei entstandenen Teilstücke mit der neuen Punktse­quenz zu einer durchgehenden Linie zu verbinden. Um dies redundanzfrei zu bewerkstel­ligen, wird folgende Erweiterung des Grundmodells vorgeschlagen (vgl. Abbildung 47).

Abbildung 47: Erweitertes Klassendiagramm für Geometrie-Objekte



Quelle: Eigener Entwurf

Es wird eine abstrakte Oberklasse GLine eingeführt, die die Schnittstelle für linienhafte Geometrien definiert. Die erste Unterklasse GPointSeq dient der Aufnahme der Primär­koordinaten. In der Praxis entsprächen diese den Linienzügen, wie sie ein Bearbeiter von einer Kartengrundlage abdigitalisiert. Die Zerlegung in mehrere Teilstücke übernehmen Instanzen der Klasse GPart. Dabei werden aber keine Stützpunkte der Originallinie ko­piert, sondern lediglich ein Verweis auf ein GPointSeq-Objekt eingerichtet sowie die Indi­zes für den ersten und letzten Punkt angegeben. Da der Schnittpunkt zweier Linien nicht zwangsläufig genau auf einem bereits erfaßten Stützpunkt liegen muß, speichert das GPart-Objekt zusätzlich Anfangs- und Endpunkt. Mit Hilfe einer Instanz von GSecPointSeq (“sekundäre Punktsequenz”) können Linienstücke, die über einen gemein­samen Schnittpunkt miteinander verbunden sind, wieder zu einer umfassenden Linie kom­biniert werden. Dabei kapselt GSecPointSeq diese interne Kombination, so daß Objekte diesen Typs sich nach außen hin wie eine durchgehende Linie verhalten. Für das obige Beispiel ergäbe sich der Zustand der Datenbank wie in Abbildung 48 angegeben.

Abbildung 48: Datenbank für t₂



Quelle: Eigener Entwurf

Ein Problem, das sich durch die sukzessive Erweiterung des Datenbestands ergibt, stellt die fortschreitende Segmentierung der Linienzüge dar. Jeder Schnitt mit einer neuen Linie führt zu einer Auftrennung in zwei neue GPart-Objekte. Bereits gespeicherte Verknüp­fungen zwischen Instanzen von GPart und der Zusammenfassung in GSecPointSeq müß­ten gesucht und so abgeändert werden, daß das von der Auftrennung betroffene GPart-Objekt gelöscht und durch die zwei neuen Objekte ersetzt wird. Die hier vergeschlagene Lösung verwendet einen Binärbaum zur Verwaltung der Parts für jede Primärlinie. In die­sem Fall kann jedes GPart-Objekt alternativ zwei Objekte gleichen Typs referenzieren, die zusammen den ursprünglichen Linienbereich repräsentieren. Neue Schnittpunkte kann das System dann mit Hilfe eines neuen Knoten in diesem Baum mit zwei Verzweigungen auf die beiden Teilstücke speichern.

Abbildung 49: Fortschreitende Segmentierung



Quelle: Eigener Entwurf

Der Vorteil dieses Vorgehen liegt darin, daß im gegebenen Beispiel in Abbildung 49 eine bereits gespeicherte Referenz auf das Objekt P₃ auch nach wiederholten Schnitten gültig bleibt, da die Teilstücke P₄ und P₅ zum Zeitpunkt t₃ zusammengenommen immer noch denselben Abschnitt repräsentieren.

Insgesamt bedeutet das hier vorgeschlagene Verfahren einen nicht unerheblichen Ver­waltungsaufwand, der aber zum großen Teil durch einige Vorteile kompensiert wird. Da man die einzelnen Linienstücke für andere Zeitabschnitte wiederverwenden kann, ist es für den Anwender möglich, ohne Mehrfacherfassung die Objektgeometrien zu definieren. Diese Möglichkeit gewinnt noch an Bedeutung, wenn sich damit die Datenqualität insge­samt verbessert. Im Anwendungsbeispiel eines historischen GIS, kann man hiermit den von SWIACZNY/OTT 1999 (S.90ff.) beschriebenen Datenerfassungsablauf anwenden: ausgehend von den aktuellsten Daten werden rückschreitend von älteren und in der Regel weniger präzisen Kartenwerken ausschließlich die Veränderungen digitalisiert. Der ge­samte Verlauf einer Flächenumrandung für einen früheren Zeitpunkt kann sich dann zum Teil auf die präziseren Geometrien einer aktuellen Vermessung stützen. Zudem verhindert diese Methode das in Kapitel 6.1.2 beschriebene Wandern von Geradensegmenten. Da die ursprüngliche Linie in der Datenbank erhalten bleibt und jedes GPart-Objekt zumindest indirekt diese Ausgangslinie referenziert, kann das System Verschneidungen immer mit dem Original durchführen. Damit werden Schnittpunkte immer unter identischen Be­dingungen ermittelt, ohne daß sich Fehler fortpflanzen und verstärken können.

Unter dem Gesichtspunkt der Zugriffsgeschwindigkeit auf die Geometriedaten wirkt sich die Stückelung und Referenzierung zunächst negativ aus. Beispielsweise muß das GIS zur Darstellung eines Geo-Objektes auf dem Bildschirm zunächst eine Instanz der Klasse GSecPointSeq auslesen, die darin referenzierten GPart-Objekte suchen und schließlich mindestens ein GPointSeq-Objekt mit den eigentlichen geometrischen Daten in den Ar­beitsspeicher laden. Zahlreiche Lesezugriffe auf ein relativ langsames Sekundärspeicher­medium wie einer Festplatte vermindern die Gesamtperformanz. Dieser Effekt kann aber dadurch abgemildert werden, daß sich die vorgeschlagene Datenstruktur wie ein Cluster verhält. Unter ”Clustering” versteht man in der Datenbanktechnik Implementierungs­strategien, die den Lesezugriff auf den Sekundärspeicher derart optimieren, daß die Daten­bank-Software pro Festplattenzugriff nicht einzelne Datensätze in den schnelleren Ar­beitsspeicher ausliest, sondern in einem Zugriff ganze Blöcke überträgt. Wird dann der nächster Datensatz angefordert, besteht die Möglichkeit, daß dieser bereits im Arbeits­speicher vorliegt. In einem GIS ist die Wahrscheinlichkeit, daß zwei Geometrie-Daten­sätze nacheinander angefordert werden, umso größer, je näher diese in der Realwelt bei­sammen liegen. Damit ist zu erwarten, daß sich ein GPointSeq-Objekt häufig aufgrund eines vorhergehenden Lesevorgangs bereits im Arbeitsspeicher befindet, wenn es über eine GPart-Instanz angefordert wird.

7.2.3 Organisation der Geometrie-Objekte in Layern

Instanzen der Layer-Klassen fassen mehrere Geometrie-Objekte zusammen. Alle Elemente einer solchen Zusammenfassung sind über die Zuordnung zu einem Koor­dinatensystem verortet und durch die Metadaten des Layers beschrieben. Welche Layer-Klasse im konkreten Fall Verwendung findet, richtet sich nach der Dimension der Geo­metrie-Objekte sowie der benötigten Datenstruktur (vgl. Abbildung 50).

Abbildung 50: Klassendiagramm für Geometrie-Layer



Quelle: Eigener Entwurf

Analog zu der Strukturierung der Geometrie-Objekte kann man Layer für einzelne Punkte sowie für Punktesequenzen, die Linien und Flächenumrandungen repräsentieren, unter­scheiden. Dementsprechend verwaltet ein GPointLayer-Objekt Instanzen vom Typ GPoint, und ein GPointSeqLayer faßt die Primärkoordinaten von GPointSeq-Objekten zusammen.

Die Verwaltung von linienhaften Geometrien, für die Planarität gefordert wird, erfordert einen deutlich höheren Aufwand. Diese Aufgabe übernehmen Instanzen der Klasse GPlanarLayer. Wird einem solchen Layer eine neue Linie hinzugefügt, erfolgt eine Über­prüfung, ob mit den bereits erfaßten Linien Schnittpunkte bestehen. Falls dies der Fall ist, werden die Linien nach dem oben beschriebenen Mechanismus zerlegt. Andere Objekte können auf den von GPlanarLayer verwalteten Datenbestand nur über GPart-Objekte zugreifen und diese gegebenenfalls neu kombinieren. Die ursprünglichen Koordinaten­sequenzen in den GPointSeq-Exemplaren sind innerhalb der Layer-Organisation gekapselt und nur indirekt erreichbar. Folglich spielt die Schicht der GPart-Objekte die Rolle eines Interface, das die Schnittbedingungen abbildet und damit einen planaren Graphen für den Layer darstellt. Im Konstruktor von GPlanarLayer wird standardmäßig eine Instanz von GIntersectionLayer zur Aufnahme der Schnittpunkte und eine erste Instanz der Klasse GPointSeqLayer angelegt.

Abbildung 51: Datenorganisation in GPlanarLayer



Quelle: Eigener Entwurf

Abbildung 51 zeigt schematisch die Datenverwaltung der in Abbildung 44 gegebenen Situation. Die Ausgangssituation in t₁ wird in einem ersten GPointSeq-Layer abgelegt. Die Ereignisse in t₂ und t₃, die die Verlaufsänderung verursachen, erzeugen zusätzliche Linien-Layer und alle Schnittpunkte sind in einem GIntersection-Layer aufgeführt. Der Aufbau des GPlanarLayers ist in der Abbildung rechts noch einmal vergrößert dargestellt. Die Besonderheit liegt in der Zerlegung von Linie b, die durch den Schnitt mit Linie c not­wendig ist. Dabei wird b in zwei Teilschritten in die Bestandteile b1, b2 und b3 zerlegt.

7.2.4 Metadaten

Ein Objekt der Klasse Metadata beschreibt mehrere Geometrien hinsichtlich Datenher­kunft (Kartengrundlage, geodätische Vermessung, Photogrammetrische Auswertung), Maßstab, Aufnahmedatum usw.. Hier soll aus Vereinfachungsgründen nur ein Textfeld zur Verfügung gestellt werden, das beliebige Freitexte mit entsprechendem Inhalt auf­nehmen kann. Über den Vererbungsmechanismus ist diese “Sparversion” aber jederzeit erweiterbar, ohne daß die Geometriedatenverwaltung an sich dadurch verändert werden muß.

7.2.5 Koordinatensysteme

Auf der Ebene des Datenmodells stellt sich hier die Aufgabe, die Eigenschaften eines Ko­ordinatensystems derart zu beschreiben, daß Transformationsroutinen mit Hilfe dieser Informationen den Bezug zwischen den Systemen herstellen können.² Dazu bietet sich eine Definition der European Petroleum Survey Group (EPSG) an, die bereits Eingang in mehrere kommerzielle GIS-Applikationen gefunden hat. Die EPSG bietet darüberhinaus auf dem Internet eine Datenbank mit Parametern für die gängigsten Koor­dinatensysteme. Das dort vorzufindende relationale Schema dient als Grundlage für das Klassendiagramm in Abbildung 52 (vgl. EPSG 1999).

Abbildung 52: Klassendiagramm für Koordinatensysteme



Quelle: Eigener Entwurf.

Die abstrakte Klasse CCoordSystem dient als Generalisierung der beiden Subklassen CProjCoordSystem für ebene Projektionen und CGeoCoordSystem für geographische Ko­ordinatensysteme. Eine Instanz der Klasse CUnit beschreibt die Maßeinheit der Ko­ordinatenwerte und bietet einen Skalierungsfaktor für die Umrechnung von Metern in die betreffende Einheit. In Systemen, die Winkelgrade verwenden, ist diese Skalierung nicht anwendbar.

CEllipsoid-Objekte parametrisieren über Werte für die große Halbachse a und die kleine Halbachse b den Rotationsellipsoid als Annäherung an die Erdgestalt. Zusammen mit einer eventuellen Verschiebung relativ zum Masseschwerpunkt der Erde liefern Datum-Objekte einen Beschreibung der mathematisch definierten Näherung . Die EPSG liefert dafür 230 Konstanten, die in entsprechenden Programmen verwendet werden können. Instanzen der Klasse CPrimeMeridian definieren Hauptmeridiane, die über einen Wert für Longitude ausgehend von Greenwich festgelegt sind. Dadurch kann der Ursprung des Ko­ordinatensystems in West-Ost-Richtung verschoben werden.

Ein CGeoCoordSystem-Objekt verweist auf je eine Instanz von CDatum und CPrimeMeridian, auf deren Parameter eine Konvertierungsroutine damit zugreifen kann. Um Projektionen in die Ebene durchführen zu können, benötigt ein CProjCoordSystem-Objekt ein zugrundeliegendes geographisches Koordinatensystem sowie ein mathematisches Verfahren, das hier als ein Objekt der Klasse CProjMethod dargestellt ist.

Damit ist ein hinreichendes Objektmodell für die Verwaltung von Koordinatensytemen aufgestellt. In einer Implementierung könnten dem Anwender unter Rückgriff auf die von der EPSG definierten Typen bereits eine Vielzahl an Parametern angeboten werden. Die EPSG hat sich nicht nur auf die Strukturierung derartiger Daten beschränkt, sondern dar­überhinaus diverse Koordinatensysteme, Einheiten, Hauptmeridiane, Ellipsoide und Pro­jektionsverfahren mit eindeutigen Kennummern versehen, um damit den Datenaustausch zwischen verschiedenen GIS-Applikationen zu erleichtern (EPSG 1999, o.S.).

7.3 Das räumliche Modell

7.3.1 Übersicht

Bislang wurden nur einfache geometrische Elemente betrachtet, die in Form von einzelnen Punkten bzw. Punktsequenzen gegeben sind. Diese Klassen sollen jetzt verwendet werden, um räumliche Objekte mit zusätzlichen Eigenschaften zu bilden. Besonderes Augenmerk gilt hier den topologischen Beziehungen zwischen den Geo-Objekten, da diese häufig in räumlichen Analysen Verwendung finden. In einem weiteren Schritt wird das Modell um einen zeitlichen Bezug erweitert. Die Geometrie-Klassen sind zwar in ihrer Struktur auf diesen Aspekt hin ausgelegt, aber in den bisherigen Ausführungen wurden noch keine Information zur zeitlichen Gültigkeit räumlicher Daten explizit berücksichtigt.

Abbildung 53: Klassendiagramm für räumlich-temporale Objekte



Quelle: Eigener Entwurf

Zunächst erfolgt eine Unterscheidung in einzelne Geo-Objekte und in Objektgruppen, die als eine Einheit angesprochen werden können. Da die Klassen STObject und STObjectSet beide von STGeoObject abgeleitet sind, sind beide Konstrukte gleichwertig als Funktions­parameter verwendbar. Wichtiger ist aber diese Generalisierung hinsichtlich der Abge­schlossenheit von Operationsergebnissen. Für eine Funktion, die alle von einer gegebenen Linie geschnittenen Flächen ermittelt, kommt als Ergebnis eine einzelne Fläche, mehrere Flächen oder die leere Menge in Frage. Da eine Variable vom Typ STGeoObject sowohl einzelne Objekte als auch Mengen referenzieren kann bzw. für die leere Menge auf Null gesetzt wird, müssen in der Implementierung keine umständlichen Fallunterscheidungen getroffen werden.

7.3.2 Die STObject-Klassen

Instanzen der von STObject abgeleitetenKlassen beschreiben einzeln identifizierbare räumliche Entitäten der Realwelt zu definierten Zeitabschnitten. Während die Klas­sifizierung der Feature-Klassen thematischen Aspekten folgt, sind Geo-Objekte primär durch ihre geometrischen Eigenschaften geprägt.

Die wichtigste Eigenschaft jeder STObject–Instanz ist deshalb seine geometrische Be­schreibung, die durch eine Instanz einer GGeometry-Klasse gegeben ist. Da die von STObject abgeleiteten Klassen unterschiedliche Geometrie-Typen verwenden, kann in dieser abstrakten Oberklasse keine entsprechende Assoziation hergestellt werden. Ersatz­weise wird eine virtuelle Funktion GetGeometry() eingeführt, die in den Ableitungen zu überschreiben ist. Grundsätzlich folgt die Klassenbildung zwei Prinzipien:

1. Nach der geometrischen Dimension werden Punkte (0D) , Linien (1D) und Flächen (2D) unterschieden.

2. Hinsichtlich der topologischen Eigenschaften erfolgt eine Unterteilung in ”Spaghetti”-Klassen, die keinen topologischen Konsistenzbedingungen unterliegen, und topo­logisch strukturierten Klassen, die Inzidenz- und Adjazenzbeziehungen abbilden.

7.3.2.1 Spaghetti-Ebene

Geo-Objekte dieser Ebene sind einfach strukturiert. Jedes STPoint-Objekt referenziert ein Exemplar der Klasse GPoint, das die Position angibt. Instanzen der Klassen STLine und STArea verweisen auf ein GPointSeq - Objekt, wobei für Flächen angenommen wird, daß der erste und der letzte Punkt in der Liste miteinander verbunden sind.

Abbildung 54: Spaghetti-Flächen



Quelle: Eigener Entwurf

Zusätzlich kann jedes STArea-Objekt beliebig viele Objekte gleichen Typs aufnehmen. Damit können Instanzen dieser Klasse auch Polygone mit Löchern darstellen. Um die Darstellung der Löcher von der äußeren Umrandung abgrenzen zu können, wird per Kon­vention vereinbart, daß die umschriebene Fläche immer rechts der Linie liegt. Da die Punkte in einer Punktsequenz sortiert und deshalb gerichtet vorliegen, beschreibt eine Um­randung im Uhrzeigersinn eine Fläche und eine Umrandung gegen den Uhrzeigersinn ein Loch. Diese Konvention besitzt somit die Funktion eines Vorzeichens, die eine von einer Punktsequenz umschlossenen Fläche dahingehend beschreibt, ob sie im Anwendungs­kontext zu einem anderen Geo-Objekt hinzuzählen oder abzuziehen ist. Neben der Dar­stellung von Löchern können damit auch Flächen verglichen werden, wobei das ”Vorzeichen” angibt, ob es sich um eine Flächenzunahme oder –abnahme handelt.

7.3.2.2 Topologie-Ebene

Das Design der topologisch strukturierten Klassen orientiert sich an dem in Kapitel 6.2.3 vorgestellten Konzept nach DAVID/ RAYNAL/ SCHORTER 1993. Hier soll zunächst die grundlegende Realisierung erläutert werden (vgl. Abbildung 55).

Abbildung 55: Die Topologische Struktur



Quelle: Eigener Entwurf

Jeder Knoten ist in seiner Position durch eine Instanz von GPoint festgelegt. Die topo­logische Struktur wird hier durch eine Liste der eingehenden Kanten abgebildet. Da alle Kanten vom Typ STEdge gerichtet sind, wird jede Verbindungslinie zumindest indirekt von zwei Kanten referenziert, je eine für jede Richtung. Die Verbindungslinie ist geometrisch durch eine GSecPointSeq-Instanz repräsentiert, die von einem GPlanarLayer-Objekt verwaltet wird. Eine direkte Referenz auf die Geometrie richten nur Objekte von SEdgePos (”positive Kante”) ein. Da jede Kante einen Zeiger auf die inverse Kante be­sitzt, kann eine Instanz von SEdgeNeg (”negative Kante”) über diese Verbindung auf die Geometrie zugreifen, ohne diese selbst direkt referenzieren zu müssen. Zusätzlich besitzt jede Kante einen Zeiger auf den Endknoten sowie die Fläche, die rechts von ihr liegt. Da­mit verfügen die Knoten und Kanten neben ihrer geometrischen Beschreibung über fol­gende Informationen, über die die drei Permutationen und damit ein vollständiges Netz­werk festgelegt sind:

• Kante (SEdge, spezialisiert in SEdgePos und SEdgeNeg): inverse Kante, Endknoten, Fläche rechts.

• Knoten (SNode): Liste der eingehenden Kanten

In der Arbeit von DAVID/ RAYNAL/ SCHORTER 1993 sind alle Permutationen als Pointer umgesetzt. Das ist hier durch die Erweiterung auf temporale Daten nicht möglich. Eine Kante kann zum Beispiel für zwei unterschiedliche Zeitpunkte auch verschiedene Nachfolger besitzen. Aus der Datenstruktur selbst läßt sich lediglich die  - Permutation in Form der inversen Kante direkt ablesen. Da die anderen Verknüpfungen algorithmisch bestimmt werden müssen, ist es hier notwendig, die Permutationen durch Funktionen zu ersetzen. Das Ergebnis jeder Funktion ist vom Typ SEdge.

1. Die Funktion GetInverse() entspricht der  - Permutation und gibt die von dem einge­richteten Zeiger referenzierte Kante zurück.

2. Die  - Permutation für eine gegebene Kante läßt sich anhand des Endknotens be­stimmen und wird durch die Funktion GetNextOpposite() ersetzt. Dazu muß eine Routine lediglich den Endknoten gegen den Uhrzeigersinn durchlaufen und die erste gefundene eingehende Kante zurückliefern.

3. Die durch  bestimmte Kante erhält man mittels der Funktion GetSuccessor(), die einer Kombination von  und  entspricht.

4. Zur Ergänzung wird eine Funktion GetPredecessor() eingeführt, die den Vorgänger einer Kante ermittelt und die Umkehrung von GetSuccessor() darstellt.

Schon die beiden Funktionen GetInverse() und GetOpposite() würden ausreichen, den Graphen vollständig zu beschreiben, aber die zusätzlichen Funktionen erleichtern die De­finition von Flächen.

Die Flächen selbst benötigen nur eine beliebige Kante der Umrandung. Die restlichen Segmente lassen sich dann iterativ mit Hilfe der GetSuccessor()-Funktion bestimmen.

7.3.2.3 Die Geo-Objekt-Mengen

Für GIS-Applikationen ist es sinnvoll, mehrere Geo-Objekte zu einer Gruppe zusammen­zufassen und als eine Einheit ansprechen zu können. Dabei sind aber zwei Fälle zu unter­scheiden, die dazu führen, diese Aggregation auf verschiedenen Ebenen eines objekt­orientierten GIS durchzuführen:

1. Leitet man die Zusammenfassung primär aus semantischen Aspekten ab, sollte dies auf der Feature-Ebene durchgeführt werden. Beispielsweise könnte man das Feature “Stadtbezirk” thematisch in die Bestandteile “Straßennetz”, “Baublöcke”, “Park­flächen” usw. zerlegen. Da die einzelnen Bestandteile bereits thematische Einheiten darstellen, die neben den rein räumlichen Eigenschaften weitere beschreibende Attri­bute besitzen, ist es günstiger, diese als Feature-Typen in eine Klasse “Stadtbezirk” zu integrieren.

2. Das Beispiel des Straßennetzes zeigt einen Anwendung, bei der es sinnvoll ist, die Zusammenfassung auf der Ebene der Geo-Objekte durchzuführen, da hier die räum­lichen Eigenschaften im Vordergrund stehen. Applikationen zur Netzwerknavigation benötigen Informationen, welche Netzwerke in einer Datenbank zur Verfügung stehen und wie die einzelnen Elemente darin miteinander verbunden sind. Ein anderes An­wendungsbeispiel sind Geo-Objekte, die das System wegen topologischen Kon­sistenzbedingungen an Kreuzungspunkten segmentiert, wie etwa einzelne Straßen oder Flüsse. Eine Aggregation fügt diese Teilstücke wieder zu einem durchgehenden Strang zusammen, ohne daß die Information über Kreuzungspunkte verdeckt würde.

Abbildung 56: Klassendiagramm für Geo-Objekt-Mengen



Quelle: Eigener Entwurf

Innerhalb der Klassen für Objektmengen erfolgt eine Differenzierung in heterogene und homogene Mengen (Klassen STCollection und STConstrainedSet). Heterogene Mengen können Elemente verschiedener Typen aufnehmen, während homogene Mengen auf eine bestimmte Ableitung von STObject festgelegt sind. Für Objekte von STSet_0D gilt, daß alle Elemente vom Typ STObject_0D sein müssen, womit hier Instanzen der Klassen STPoint sowie STNode zulässig sind. Analog hierzu verhalten sich die Klassen STSet_1D und STSet_2D, die einfache Objektsammlungen für Elemente mit festgelegter Dimension darstellen.

Die Klassen STNetwork und STCoverage bilden im Datenmodell den Ausgangspunkt für wichtige analytische Möglichkeiten eines GIS. Instanzen von STNetwork bilden Netz­werke ab, die in Fom von STEdge-Instanzen gegeben sind. Benutzerdefinierte Ableitungen kann ein Anwendungsprogrammierer um Methoden zur Behandlung typischer Netzwerk-Probleme erweitern, mit denen Aufgaben wie das Handlungsreisenden-Problem, kürzeste Wege in einem Netzwerk oder Erreichbarkeitsanalysen abgedeckt werden können. STCoverage-Objekte nehmen disjunkte STFace-Instanzen auf, die einen Gesamtraum hin­sichtlich eines Merkmales beschreiben.

7.4 Das temporale Modell

7.4.1 Übersicht

Die Klassen zur Repräsentation von Zeit bilden zwei Gruppen:

• Die erste Gruppe umfaßt Klassen, mit deren Hilfe ein temporales Referenzsystem be­schrieben werden kann. Diese Funktion ist vergleichbar mit der eines Kalenders, in­dem hier ein Rahmenwerk gebildet wird, in dessen Kontext einzelne Zeitangaben zu interpretieren sind.

• Die zweite Gruppe umfaßt Klassen, die aufbauend auf einem definierten Referenz­system konkrete Zeiteinheiten abbilden. Hier wird grundsätzlich zwischen Zeitpunkten der Länge 0 und Zeitintervallen, die kontinuierliche Zeitabschnitte abdecken, unter­schieden.

In beiden Gruppen werden Instanzen der Klasse TChronon verwendet, die die kleinsten unteilbaren Zeitabschnitte eines Referenzsystems darstellen.

Abbildung 57: Klassendiagramm zur Verwaltung von Zeitangaben



Quelle: Eigener Entwurf

7.4.2 Das temporale Referenzsystem

Jedes Objekt der Klasse TChronon enthält einen vorzeichenbehafteten Integerwert mit 32 Bit, der in Abhängigkeit des zeitlichen Referenzsystems interpretiert wird. Von dem dar­stellbaren Zahlenbereich werden die 3 niedrigsten Zahlen zur Darstellung dreier Konstan­ten verwendet:

1. LOW_END (= Dezimalwert –2.147.483.648 ): ist ein Zeitpunkt in der Vergangenheit unbestimmt, dann wird diese Konstante eingesetzt.

2. HIGH_END: diese Konstante steht für unbekannte Zeitpunkte in der Zukunft.

3. NOW: diese Konstante steht für die Gegenwart und ist damit solange gleitend, bis ein anderer Wert festgelegt wird. Bei der Verwendung in einem Zeitintervall ist aber dar­auf zu achten, daß diese Konstante logisch korrekt verwendet wird. Ist beispielsweise als Startzeitpunkt NOW angegeben, muß das Ende des Intervalls in der Zukunft liegen.

Damit verbleiben für die Darstellung eines Zeitpunktes 4.294.967.292 (2³² - 3) ver­schiedene Werte. Legt man eine Genauigkeit im Sekundenbereich zugrunde, wie dies bei GPS-Anwendungen der Fall ist, kann man damit eine Zeitspanne von 136 Jahren abdec­ken. Für andere Anwendungzwecke reicht dieser Zeitraum aber bei weitem nicht aus. Durch eine Erweiterung auf einen 64-Bit-Wert könnten zwar 584.942.417.355 Jahre in Sekundenauflösung dargestellt werden, andererseits ”verschenkt” man hier Speicherplatz, da die Sekundengenauigkeit für Zeitpunkte in geologischen Dimensionen nicht erforder­lich ist.

Hier bietet sich eine Lösung in Form von verschiedenen Zeitskalen an, in der jede Skala festlegt , wie der gespeicherte 32-Bit-Integer-Wert eines TChronon-Objektes zu inter­pretieren ist. Im vorgestellten Objektmodell übernehmen Instanzen der Klasse TAbsoluteReference diese Aufgabe. Um die unterschiedlichen Skalen zu synchronisieren und damit die Werte vergleichbar zu machen, sind für jede Skala die dazu notwendigen Parameter anzugeben:

• Eine Zeitbasis definiert einen Zeitpunkt, der den Nullpunkt der eindimensionalen Zeit­achse markiert. Da der Integer-Wert von TChronon mit einem Vorzeichen versehen ist, sind damit Werte im Bereich von –2.147.483.645 bis 2.147.483.647 möglich. Die Angabe erfolgt in Universal Coordinated Time (UTC) im Format Tag – Monat - Jahr. Als Uhrzeit gilt 0 Uhr.

• Mit einem Offset in Sekunden kann eine von Greenwich abweichende Zeitzone mar­kiert werden.

• Die Granularität als Vielfaches einer Sekunde bestimmt das Auflösungsvermögen des Referenzsystems bzw. die Länge eines Chronoms und damit den durch einen 32-Bit-Wert beschreibbaren Zeitraum. Negative Werte werden zu Darstellung von Granu­laritäten unterhalb einer Sekunde verwendet.

Diese drei Parameter reichen aus, um die unterschiedlichsten Anwendungbereiche abzu­decken und um gegebenfalls TChronon-Objekte von verschiedenen Skalen miteinander zu vergleichen. Um beispielsweise eine für Windows-basierte Anwendungen kompatible Zeitskala zu entwickeln, verwendet man als Basis den 1. Januar 1970, 0.00 Uhr mit einer Granularität von einer Sekunde. Für historische Themen kann der Anwender die Granu­larität auf einen Tag festlegen, womit hier 11.767.033 Jahre darzustellen sind.

Anhand der gegebenen Parameter kann für je zwei TValidTime-Objekte ein Vergleich durchgeführt werden, um die in Kapitel 6.4.3 festgelegten temporalen Prädikate anzuwen­den. Dabei wird vereinbart, daß bei unterschiedlichen Granularitäten die gröbere Variante zu verwenden ist und die feinere Angabe entsprechend umgewandelt wird. Beispielsweise führt dabei der Vergleich einer Instanz mit dem Wert “Holozän” einer geologischen Skala mit dem Wert “07.Juni 1999, 20 h 1 min 43 sec bis 07.Juni 1999, 20 h 1 min 50 sec” einer GPS-Skala zu dem Ergebnis, daß sich die Zeitintervalle überdecken. Die Prädikate selbst sind als Methoden in TValidTime mit einem Ergebnis vom Typ “bool” zu implementieren. Damit ist indirekt auch eine Operandenfolge vorgegeben, die für das Ergebnis von “precedes” und “contains” von Bedeutung ist, da diese Prädikate nicht symmetrisch sind. Beispielsweise bewirkt der folgende Methodenaufruf, daß die STObject-Instanz “Geo_Object_1” der erste Operand ist.

bool value = Geo_Object_1->precedes(Geo_Object_2);/* (entspricht Geo_Object_1 precedes Geo_Object_2)*/

Objekte der Klasse TCyclicReference beschreiben temporale Zyklen. Dazu wird das Objekt mit einer Instanz von TAbsoluteReference verknüpft, in dessen Rahmen ein Zyklus definiert ist. Das Attribut ValidFromTo zeigt an, zu welchem Zeitpunkt der Zyklus zum ersten mal startet und wann er das letzte mal abläuft. Die Länge eines einzelnen Durch­laufs ist dem Attribut Duration zu entnehmen. TChronon-Werte, die durch solch ein Referenz­system beschrieben sind, müssen zwischen 0 und Duration liegen, d.h. be­schreibbare Zeitpunkte liegen innerhalb eines einzigen Zyklus. Durch das Referenzsystem wird er aber bis zum Ende der Gesamtlaufzeit des Zyklus im Abstand von Duration wie­derholt.

Zu jeder Instanz, die von TTemporalReference abgeleitet ist, können feste Zeitabschnitte mittels TRefPeriod-Objekten angelegt werden, die für das Referenzsystem eine geordnete Sequenz darstellen. Für ein absolutes Referenzsystem könnten diese beispielsweise in geologischen Applikationen Anwendung finden, um Formationen und Abteilungen als zeitliche Unterdimensionen abzubilden. Damit kann eine fachspezifische Begriffswelt mit zeitlichem Bezug in eine Applikation integriert werden und eine Alternative zu der in die­sem Fall nicht sinnvolle Benutzung des gregorianischen Kalenders anbieten. Für die zyklischen Referenzsysteme gilt, daß hiermit ein Zyklus in mehrere benannte Abschnitte unterteilt werden kann, die sich ständig in gleichem Abstand wiederholen. Ein An­wendungsbeispiel wäre hier die Modellierung von Vegetationszyklen im Jahresablauf, die hier mit zeitlich absolut referenzierten Geo-Objekten, wie beispielsweise dem Parzellenge­füge, kombiniert werden können.

7.4.3 Die Repräsentation von Zeitpunkten und Intervallen

Um Zeitpunkte und Zeitintervalle in einem System alternativ verwenden zu können, wird eine gemeinsame Oberklasse TValidTime eingeführt, die über Funktionen zum Ermitteln von Startzeitpunkt und Dauer bzw. Endzeitpunkt verfügt. Für ein TTimeStamp-Objekt wird vereinbart, daß dieses die Länge 1 besitzt, d.h. ein Chronom, während für Ableitungen von TTimeInterval eine Länge größer 1 anzugeben ist. Die Länge eines Inter­valls berechnet sich aus erstem und letztem Chronom sowie allen dazwischenliegenden. Um die Modellierung von Zeitintervallen zu flexibilisieren, sind hier drei Subklassen definiert, die sich für verschiede Situationen anbieten. Die einfachste Form bildet die Klasse TAbsInterval mit absoluten Angaben zu Start und Ende. Instanzen von TTimePeriod referenzieren einen für ihr Referenzsystem angelegten Zeitabschnitt, während in den Ableitungen von TRelInterval (“relatives Intervall”) Bezug genommen wird auf mindestens eine andere TValidTime-Instanz. Die vier Subklassen unterscheiden sich darin, ob zur Darstellung des Startzeitpunktes oder des Endzeitpunktes bzw. für beide eine externe Referenz notwendig ist. Dabei ist die Art der Interpretation dieser Referenz zu beachten: falls ein Intervall referenziert wird, ist der jeweils nächste Zeitpunkt zu wäh­len, d.h. ein TRelStart-Objekt, das seinen Startzeitpunkt anhand eines anderen Objektes bestimmt, verwendet bei einem Intervall dessen Endzeitpunkt. Analog hierzu erfolgt die Wahl bei Instanzen von TRelEnd und TRelStartEnd. Instanzen von TRelSpan beschreiben Zeitspannen, deren Länge anhand des Attributs Duration festzulegen ist. Der Startzeit­punkt wird wiederum relativ zu einem referenzierten TValidTime-Objekt bestimmt. Die in Kapitel 5.1.3 angesprochenen Zeitelemente, die mehrere nicht notwendigerweise ver­bundenen Zeitabschnitte zu einer Menge kombinieren, können hier nur indirekt abgebildet werden, indem eine Geometrie mit mehreren Instanzen der hier vorgestellten Klassen ver­knüpft wird.

7.5 Die Erweiterung des räumlichen Modells auf temporale Geo-Objekte

Zur Abbildung des zeitlichen Bezugs sind für die STObject-Klassen zwei Assoziationen in dem in Abbildung 53 dargestellten Klassendiagramm relevant. Zunächst ermöglicht es ein Zeiger auf eine andere Instanz vom Typ STObject, eine Versionenkette zu bilden, mit deren Hilfe jedes Objekt die zeitlich vorhergehende und die nachfolgende Version ermit­teln kann. Innerhalb dieser Kette gilt die Integritätsbedingung, daß sich zwei unmittelbar aufeinanderfolgende Versionen zeitlich nicht überlappen dürfen. Um Speicherplatz zu sparen und um den Verwaltungsaufwand zu minimieren, ist diese Kette nur in eine Richtung über Zeiger festgelegt, wobei sie bei der ältesten Version beginnt und immer zum nächsten Nachfolger zeigt. Das letzte Element zeigt dann wiederum auf die erste Ver­sion und anhand des Zeitstempelvergleichs läßt sich feststellen, daß es sich hierbei nicht um einen Nachfolger, sondern um den Ausgangspunkt handelt (vgl. Abbildung 58). Über diesen Ring läßt sich auch der Vorgänger bestimmen, ohne daß ein zusätzlicher Zeiger notwendig ist. Darüberhinaus sind Einfüge- und Löschoperationen in einem solchen Ring einfach zu bewerkstelligen, da jeweils nur ein Pointer im Vorgänger-Objekt korrigiert werden muß.

Abbildung 58: Versionenring zur Abbildung temporaler Vorgänger und Nachfolger



Quelle: Eigener Entwurf

Mit Hilfe der Verknüpfung zu einem TValidTime-Objekt kann für jedes räumliche Objekt eine Festlegung hinsichtlich der temporalen Dimension erfolgen. Für die Klassen der Spaghetti-Ebene bedeutet dies, daß die vollständige geometrische Beschreibung für den durch das TValidTime-Objekt beschriebenen Zeitraum gültig ist. Da sich in diesem Zu­sammenhang die Klasse STObject als eine Assoziation interpretieren läßt, die ein unab­hängiges Geometrie-Objekt mit einer Zeitangabe verknüpft, kann diese Geometrie auch in anderen Zeitabschnitten verwendet werden.

Während sich die Versionierung in den Spaghetti-Klassen unmittelbar immer nur auf eine Objektinstanz auswirkt, sind in den topologisch strukturierten Klassen immer mehrere Instanzen von einer Änderung betroffen. Ergibt sich beispielsweise für eine Kante ein neuer Verlauf, so bedeutet dies für die angrenzende Fläche, daß sich zumindest ihre Geo­metrie geändert hat und damit eine neue Version der Fläche vorliegt, da die Fläche selbst über keine eigene geometrische Beschreibung verfügt, sondern diese anhand der referenzierten Kanten zu ermittlen ist. Einen Sonderfall stellen die Knoten dar: hier ist die Registrierung unterschiedlicher Versionen aufgrund einer geometrischen Veränderung nicht sinnvoll, da die Interpretation, ob ein Knoten der Vorgänger eines anderen ist, oder ob hier zwei völlig voneinander unabhängige Knoten vorliegen, nur schwer zu führen ist. In der Regel führt das Einfügen eines neuen Knotens auch dazu, daß neue Kanten gebildet werden müssen. Deshalb kann man hier von folgenden Regeln ausgehen:

1. Zwei Knoten, die durch unterschiedliche geometrische Punkte festgelegt sind, können dann als zwei zusammengehörige Versionen angesehen werden, wenn sie unmittelbar vor und nach der Änderung identische Kanten verbinden.

2. Zwei Kanten mit unterschiedlichen Verbindungslinien sind dann Versionen von­einander, wenn sie durch identische Anfangs- und Endknoten markiert sind.

3. Referenziert eine neu hinzugefügte Version einer Kante dieselbe rechtsliegende Fläche wie ihre Vorgängerin, dann muß ebenfalls eine neue Version dieser Fläche angelegt werden, die einen Zeiger auf die entsprechende Kante enthält.

Letztendlich muß es dem Anwender überlassen bleiben, hier zwischen den Alternativen zu wählen, da sich die Entscheidung zwischen Versionierung einerseits und Modellierung als völlig unabhängige Geo-Objekte andererseits auf den Anwendungskontext auswirkt. In einem Kanalnetz läßt sich beispielsweise einen bauliche Veränderung sowohl als Ver­schiebung eines bestehenden Schachtes als auch als Erneuerung durch einen neuen Schacht interpretieren, so daß hier die Entscheidung nicht schematisch nach geometrisch-topologischen Kriterien erfolgen kann, sondern einer Überprüfung anhand der Thematik bedarf.

Lediglich die Flächenversionierung für die topologisch strukturierten Klassen läßt sich automatisieren. Sobald eine neue Kante in das System eingefügt wird, kann nach einer Überprüfung, ob für den in der Kante angegebenen Zeitabschnitt eine geschlossene Flä­chenumrandung zur Verfügung steht, eine neue Version der Fläche erzeugt werden. Moderne serverbasierte Datenbanksysteme bieten für diese Automatisierungen sogenannte Trigger-Funktionen an, die durch das Eintreten eines bestimmten Bedingung - hier das Einfügen einer neuen Kante - ausgelöst werden.

Abbildung 59: Versionierung einer Fläche durch hinzugefügte Kanten



Quelle: Eigener Entwurf

Wie aus Abbildung 59 ersichtlich, erzwingt eine neue Kante nicht in allen Fällen eine weitere Flächenversion. Vielmehr kann nur anhand aller Veränderungen seit einem Aus­gangszustand die Anzahl der notwendigen Versionen bestimmt werden. Die Abbildung zeigt in fünf Teilschritten die Auswirkungen, wie sie sich aus dem Einfügen der Kanten k1 bis k5 auf die angrenzende Fläche ergeben, wobei angenommen wird, daß durch die neue Kante bzw. Kantenversion jeweils für die angegebene Zeitspanne eine gültige Flächenum­schreibung entsteht. Anhand der Zeitachse ist ersichtlich, für welchen Zeitraum die Kanten gültig sind, und wie sich analog dazu der durch eine Flächenversion beschriebene Zeitraum verhält. Während die Veränderung durch die Kante k2 zu zwei zusätzlichen Ver­sionen führt, wirkt sich k3 lediglich auf bereits bestehende Versionen aus. Letztendlich erzwingt jeder Start- und Endzeitpunkt in der Gültigkeitsdauer aller Kanten einer Fläche einen Versionsübergang.

Für die Navigation in der durch die topologisch strukturierten Klassen definierten Knoten-Kanten-Struktur bedeutet die Erweiterung auf die temporale Dimension, daß die ent­sprechenden Funktionen jeweils durch eine parametrisierte Version ersetzt werden müs­sen. Der eingeführte Parameter gibt einen Zeitraum bzw. einen Zeitpunkt an, für den die gültige Verbindung gesucht ist. Beispielsweise besitzt die neue Funktion zu GetInverse() dann folgende Signatur:

SEdge* GetInverse(TValidTime* time = 0);

Das Standardargument 0 wird hier so interpretiert, daß ohne die Übergabe eines TValidTime-Objektes der konstante Wert NOW verwendet wird, d.h. das System sucht die für den aktuellen Zeitpunkt gültige Kante.

Für Geo-Objekt-Mengen gilt, daß sich der zeitliche Bezug aus den einzelnen Elementen ergibt, so daß sich eine zusätzliche temporale Referenzierung hier erübrigt.

7.6 Das thematische Modell

Da die vorliegende Arbeit auf die Darstellung eines objektorientierten GIS-Kerns be­schränkt ist, der die wichtigsten Basisdienste für die Verwaltung räumlich-temporaler Daten in Form eines Objektmodells enthält, ist das thematische Modell hier auf eine ein­zige Klasse reduziert, von der die anwendungsspezifischen Klassen abzuleiten sind. Diese Feature-Klasse stellt damit den Ausgangspunkt für die Entwicklung anwendungsab­hängiger Klassenbibliotheken dar, die eine räumliche Thematik abbilden. Beispiele hierfür finden sich in den Standards ATKIS (BORCHERT 1994) und SDTS (ANSI 1997b)

Abbildung 60: Die Feature-Klasse



Quelle: Eigener Entwurf

Das Standardattribut dieser Klasse ist eine Referenz zur Klasse STGeoObject, das die räum­lichen Aspekte eines Anwendungsobjektes darstellt, während alle weiteren Attribute in den Ableitungen definiert werden müssen. Instanzen dieser Assoziation können ein Feature-Objekt mit einzelnen Geo-Objekten (STObject) sowie mit Mengen derselben verknüpfen (STObjectSet). Wie das in Abbildung 60 dargestellte Instanzen­diagramm zeigt, werden über diese Assoziation unter Umständen mehrere Geo-Objekte indirekt referenziert, die die räumliche Ausdehnung für unterschiedliche Zeitab­schnitte repräsentieren. Die indirekte Zuordnung zu einer Feature-Instanz wird über die in Kapitel 7.5 dargestellte Vorgänger-Nachfolger-Struktur vorgenommen. Durch diese Struktur ist es ebenfalls möglich, die Verknüpfung vom Feature-Objekt auf eine beliebige STObject-Instanz einzurichten, da das für einen bestimmten Zeitabschnitt gültige Geo-Objekt problemlos zu ermitteln ist. Abgeleitete Klassen können aber auch mehrere Assoziationen zu diversen STObject-Klassen aufbauen, um beispielsweise ein intelligentes Zoomen zu ermöglichen. Dabei wird auf dem Bildschirm in Abhängigkeit des aktuell verwendeten Maßstabes eine vorher bestimmte Repräsentation des Features angezeigt. Eine Stadt ist für kleine Maßstäbe als ein Punkt generalisiert und wird beim Hinein­zoomen zunächst als einfache Fläche und in weiteren Schritten mit zunehmenden Details wie dem Straßennetz, den Baublöcken oder zusätzlichen touristischen Hinweisen ange­zeigt.

© 2014 Zeit in Geografischen Informationssystemen (GIS), Frank Hellwich