Das Geo-Informationssystem GeoStore bietet die persistente Verwaltung geologischer Schichtflächen (Grenzen zwischen geologischen Schichten mit individuellen Eigenschaften wie mineralische Beschaffenheit, Dichte etc.), Störungsflächen (vertikale Bruchflächen, an deren beider Seiten Schichtflächensysteme vertikal gegeneinander verschoben sind) und Querschnittsprofilen (vertikale Querschnitte durch Mengen von Schicht- und Störungsflächen). Über Objektbrowser, 2D- und 3D-Viewer greift der Benutzer interaktiv auf die Daten zu und wählt gewünschte Ausschnitte zur Weiterverarbeitung aus (z.B. zur Errechnung von Profilen aus Schichten und Störungen). GeoStore wurde zunächst in der Sprache C implementiert, die unterstützten 3D-Objekte wurden für ihre persistente Speicherung jeweils in ihre logischen Bestandteile zerlegt und diese mit dem relationalen DBMS ORACLE verwaltet. Wegen des hohen Grades an Aggregation und der großen Anzahl topologischer Beziehungen der räumlichen Objektklassen untereinander erwies sich dieser Ansatz aber schon bald als ungeeignet. So besteht zum Beispiel ein Dreiecksnetz aus einer beliebigen Anzahl von Dreiecken, die bis zu drei angrenzende Dreiecke als Nachbarn haben und durch je drei Eckpunkte definiert werden. Der zur betreffenden Zeit in Mode gekommene objektorientierte Ansatz bot sich in diesem Zusammenhang geradezu an: räumliche Objekte konnten modelliert werden als das was sie sind - als Objekte, die andere Objekte als Aggregate besitzen oder zu ihnen in festen Beziehungen stehen. Zudem waren die objektorientierten Konzepte mittels der Programmiersprache C++ auch umsetzbar, und mit dem OODBMS ObjectStore bot sich ein flexibles System zur persistenten Organisation von C++-Objekten. Folglich wurde GeoStore auf dieser Basis erstmals reimplementiert.

3D-GUI von GeoStore: grafischer und textueller Zugriff auf räumliche Datenbestände (hier Niederrheinische Bucht) Automatische Berechnung und Visualisierung sekundärer Informationen (hier z.B. vertikale Störungen und Profilschnitte)

Aus der Absicht, unter GeoStore entwickelte Geo - Datenbanktechniken auch anderen GIS verfügbar zu machen, entstand die Idee, die geometrische Schicht der GeoStore - Typen geschlossen als wiederverwendbare C++ - Bibliothek auszulagern. Der GeoToolKit getaufte 3D-DB-Kern bietet - aufbauend auf ObjectStore - persistent speicherbare räumliche 3D- Datentypen und räumliche Indexe an. Die Library enthält ferner eine Menge räumlicher Operationen, Funktionen und Prädikate, die über allen Objektklassen definiert sind und so abgeschlossen auf Objektpaaren jeder beliebigen Typkombination operieren. Dabei berechnen die Prädikate Wahrheitswerte wie "Objekt A enthält Objekt B". Funktionen dagegen bilden einzelne Objekte ("Volumen des Objekts") oder Objektpaare ("kürzeste Distanz zwischen Objekt A und Objekt B") auf einen skalaren Wert ab. Räumliche Operationen schließlich erzeugen aus bestehenden GeoToolKit - Objekten als Resultat ein neues GeoToolKit - Ob- jekt. Dies gilt im unären ("Boundingbox des Objekts") wie im binären Fall ("Schnittmenge von Objekt A und Objekt B"). Die unterstützten 3D-Datentypen umfassen 0D-3D-Simplexe (Punkt, Liniensegment, Dreieck, Tetraeder), 1D-3D-Komplexe (Kurven, Dreiecks- und Tetraedernetze) sowie analytische Objekte (Geraden und Ebenen). Zur Zusammenfassung beliebiger und beliebig vieler dieser Objekte existiert ein besonderes Verbundobjekt, die Gruppe. Neben räumlichen Objekten werden räumliche Zugriffspfade (Indexe) angeboten, die den bei GIS häufig benötigten partiellen Zugriff auf räumliche Komplexe beschleunigen (Beispiel: Selektion eines Dreiecksnetz - Teilbereiches mit Hilfe einer Boundingbox). Besondere Schwerpunkte bei der Konzeption der Bibliothek waren einerseits die Erweiterbarkeit des Systems in der Breite (Hinzufügen neuer geometrischer Datentypen und Zugriffspfade) und der Tiefe (Kreation eigener thematischer Typen auf Basis der schon existierenden geometrischen Klassen).

Architektur (vereinfachte Darstellung) Beispiel 1: Relief als Dreiecksnetz mit Boundingbox Beispiel 2: Horizontaler Schnitt durch das Relief, Schnittergebnis rote Polylinie

Schon Anfang der 90er war die Auffassung verbreitet, räumliche Daten gebe es zur Genüge, es fehle jedoch an Geoinformationssystemen, mit denen diese Rohdaten zu aussagefähigen Modellen verarbeitet werden können. Bezogen auf die Verfügbarkeit von 3D/4D-GIS scheint diese Einschätzung auch heute noch richtig zu sein. Leider entspricht die naheliegende Folgerung, daß einem GIS-Entwickler diese Daten für Praxistests in geeigneter Form und Umfang auch tatsächlich zur Verfügung stehen, nicht unseren Erfahrungen. Die Gründe hierfür sind vielschichtig. Geowissenschaftliche Daten müssen in der Regel unter nicht unerheblichem finanziellen und mitunter politischem Aufwand (z.B. Bohrgenehmigungen) im Feld erfaßt werden. Damit erhalten schon die Rohdaten einen bestimmten wirtschaftlichen und politischen Wert, der die erste Hürde für die freie Verfügbarkeit dieser Daten darstellt. Auch ist oft ein hoher Aufwand damit verbunden, aus Profilschnitten die dazwischenliegenden geologischen Schicht- und Störungsflächen halbautomatisch zu generieren. So bestanden beispielsweise die der Geo-Gruppe der Bonner Informatik zur Verfügung gestellten geologischen Schichtflächen der Niederrheinischen Bucht aus nur wenigen Dreiecksnetzen mit geringen Kardinalitäten (max. 1200 Dreiecke). Für aussagefähige Praxistests sind solche Beispieldaten in Anzahl und Kardinalität völlig unzureichend. Ein weiteres Problem stellt die hohe Homogenität von Testdatensätzen dar, die aus ein- und demselben Forschungsprojekt stammen. Im SFB 350 etwa modellieren alle uns verfügbaren 3D-Flächen Schicht- und Störungsflächen innerhalb der Niederrheinischen Bucht. Die wenigen Schichtflächen davon wurden zudem alle aus den gleichen Bohrungspunkten erstellt. Zwar kann ein solcher Datenbestand zur Prüfung von geometrischen Operationen (z.B. Verschneidungen) genutzt werden, allgemeingültige Vergleiche und Bewertungen konkurrierender Datenstrukturen können auf einer solchen Basis jedoch nicht vorgenommen werden. Zur Entwicklung eines vielseitigen, skalierbaren und robusten GIS-Toolkits müssen seine Methoden und Datenstrukturen also möglichst vielen unterschiedlichen Praxistests ausgesetzt werden. Können die dazu nötigen Testdaten nicht aus dem eigenen Projektumfeld in genügendem Maße rekrutiert werden (das ist im SFB der Fall), so müssen externe Datenquellen herangezogen werden. Dies ist jedoch noch schwieriger als die Akquisition projektinterner Quellen, da einerseits die wirtschaftlich - politische Hürde bei externen Daten noch größer ist und diese nicht unbedingt in einem kompatiblen Format vorliegen. Desweiteren müssen sie nicht notwendigerweise den im GIS-Toolkit vorausgesetzten Konsistenzkriterien genügen, so daß für jedes externe Testobjekt erst eine aufwendige Prüfung nötig wäre. Um allen diesen Problemen zu begegnen, wurde zur besseren Erforschbarkeit skalierbarer GeoToolKit - Datenstrukturen ein Flächengenerator entwickelt, der aufgrund einer einfachen Beschreibungssprache 3D-Flächen beliebiger Größe und Dichte erzeugen kann. Die Geometrie und Topologie der im Hintergrund generierten Flächen können vom Benutzer umfangreich beeinflußt werden. Kurz gesagt bietet GT GeoSurf die nicht- interaktive Generierung von 3D-Testmaterial wie Bergketten oder flache Bodenreliefs, die in beliebiger Größe und Komplexität hergestellt werden können.

Zentrierter Hügel, 1000 Dreiecke Gebirgskette, 75.000 Dreiecke Zentrierter Berg, 75.000 Dreiecke Bodenrelief, 50.000 Dreiecke

Die Verbeitung des Internet weckte den Bedarf, auf räumliche und geowissenschaftliche Datenbestände via Web-Browser zugreifen zu können. Ziel war dabei eine geeignete grafische Darstellung individuell angeforderter Daten mittels eines frei erhältlichen Plug-Ins. Die Wahl fiel auf VRML (Virtual Reality Modeling Language) - das heute als Standard geltende Protokoll zur Übertragung dreidimensionaler Grafik über das World Wide Web. Den Zugang zu den räumlichen Datenbeständen erhält GeoWeb über das Common Gate Interface (CGI), das von jedem Web-Browser als client angesprochen werden kann. Ein CGI script wird von einem HTML-Formular aktiviert und stellt eine formatierte Anfrage an einen permanent laufenden GeoServer. Dessen Aufgabe ist die Überwachung aller GeoToolKit-kompatiblen ObjectStore-Datenbanken innerhalb einer Domain, sowie die Beantwortung räumlicher Anfragen. Hierbei ist durch eine asynchrone Session-Steuerung eine gleichzeitige Verbindung mehrerer Web-Clients mit dem GeoServer gewährleistet. Durch GeoToolKit-internes Caching räumlicher Zugriffspfade wird die Antwortzeit im Laufe mehrerer aufeinanderfolgender Queries auf ein Mindestmaß minimiert. Anfrageergebnisse werden an das CGI script - je nach Anforderung - in Form von HTML oder VRML zurück transportiert. Letzteres wird ermöglicht durch eine obligatorische VRML-Exportmethode jeder implementierten GeoToolKit-Klasse. VRML97 hat sich dabei als sehr gut geeignet herausgestellt zur Visualisierung dreidimensionaler Strukturen und vierdimensionaler Prozesse. Als Freeware-Plugin zur Anzeige der Anfragergebnisse in einem Browser wird der CosmoPlayer eingesetzt (unter SGI und Windows). Die Anfrage selbst wird noch auf eher traditionelle Weise über HMTL-Forms mit grafischer Eingabehilfe gestellt.

Anfrage-Interface GeoWeb Mit CosmoPlayer visualisiertes Anfrageergebnis