Zeit in Geografischen Informations-Systemen

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.).