Schnittstellen für eine landesweite 3D-Datenbank

Technische Universitt Bergakademie Freiberg Fakultt fr Geowissenschaften, Geotechnik und Bergbau Institut fr Geophysik und Geoinformatik Lehrstuhl fr Mathematische Geologie und Geoinformatik

DiplomarbeitSchnittstellen fr eine landesweite 3D-DatenbankKonzipierung und Realisierung des Datenexportes fr GOCAD und GEOCANDO Weitergehende Untersuchungen bezglich der Interoperabilitt

Christian BertramDiplom Geoinformatik Matrikel: 47557

1. Prfer: Prof. Dr. Helmut Schaeben 2. Prfer: Dipl. Mathematiker Bernd Torchala

D ANKSAGUNGDiese Arbeit widme ich meinen Eltern fr die Geduld und Untersttzung im Studium, durch die diese Arbeit berhaupt zustande kommen konnte. Fr die Betreuung und Begleitung dieser Arbeit danke ich Prof. Helmut S chaeben und Peggy Hielscher seitens der Universitt und Bernd Torchala fr die Erfllung dieser Aufgabe bei Beak. Besonderer Dank gilt zudem Sven Etzold fr die hervorragende Betreuung und auch der Firma Beak und deren Mitarbeitern fr das gute Arbeitsklima dort, sodass diese Arbeit in einem angenehmen Umfeld entstehen konnte.

i

Z USAMMENFASSUNGDie Visualisierung von Geodaten wird auch heute noch meist ber 2D-Abbildungen realisiert. Abhngig davon, ob damit Fachanwender oder ein breiteres Nutzerspektrum erre icht werden soll, werden die Daten per Webservice oder in verschiedensten Geodatenformaten bereitgestellt. Die 3D-Visualisierung spielt dabei oft nur bei der Konstruktion und Modellierung der Modelle eine Rolle. In dieser Arbeit soll eine Schnittstelle konzipiert und umgesetzt werden, die dem Fachanwender den 3D-Export hydrogeologischer Krper aus einer dreidimensionalen Geodatenbank ermglicht. Die Datenbank selbst wird mit 3D-Daten aus einer Spezialkartierung bestckt und soll bei Fertigstellung ein landesweites hydrogeologisches 3D-Modell Sachsens umfassen. Der Zugriff auf die ExportSchnittstelle wird ber ein Fachinformationssystem erfolgen, integriert in die GIS-Software ArcMap. Die Export-Komponente ermglicht dem Nutzer dabei ein Auswahlgebiet festzulegen,

hydrogeologische Krper in diesem auszuwhlen und diese im SGRID-Format der 3DGeomodellierungssoftware GOCAD zu speichern. Die erzeugten Dateien knnen dann entweder in GOCAD oder im Open-Source Viewer Geocando visualisiert werden. In einem zweiten Teil werden Mglichkeiten zum Austausch der 3D-Daten in interoperablen, auf internationalen Standards basierenden Geodatenformaten aufgezeigt. Verschiedene Abbildungsmodelle werden untersucht und anschlieend Wege aufgezeigt, wie eine Reprsentation in ausgewhlten Formaten erreicht werden kann. Dabei wird auf die Geometriemodelle dieser Formate eingegangen und relevante Spezifikationsbestandteile werden erlutert. Zuallerletzt werden diese Formate verglichen und Vorund Nachteile aufgezeigt.

Christian Bertram Schnittstellen fr eine Landesweite 3D-Datenbank

ii

Inhaltsverzeichnis1. Einleitung ..................................................................................................................... 1 1.1. 1.2. 1.3. 1.4. 2. Ausgangslage.......................................................................................................... 1 Ziele der Arbeit ....................................................................................................... 2 Interoperable Software........................................................................................... 3 Reprsentation von Geodaten ................................................................................ 4

Die 3D-Geodatenbank .................................................................................................. 6 2.1. 2.2. Daten des FIS Hydrogeologie .................................................................................. 6 Datenmodell .......................................................................................................... 7 Sulen ............................................................................................................. 7 Sulenabschnitte ............................................................................................. 9

2.2.1. 2.2.2. 2.3. 3.

Sonderflle und komplexe Krper ......................................................................... 10

GOCAD-SGRIDs ........................................................................................................... 15 3.1. 3.2. 3.3. 3.4. 3.5. 3.6. SGRID-Datenformat .............................................................................................. 15 Flags ..................................................................................................................... 17 Punktattributierung .............................................................................................. 19 Dateiformat und SGRID-Konfiguration .................................................................. 20 Vergleich zu weiteren GOCAD-Formaten............................................................... 22 Geocando- Formatuntersttzung .......................................................................... 24

4.

Vorgehen bei der HGK-Abbildung ............................................................................... 26 4.1. 4.2. Abbildung von senkrechten Kanten....................................................................... 26 Abbildung komplexerer Geometrien ..................................................................... 29

5.

Schnittstellen-Entwurf und Implementierung ............................................................ 32 5.1. 5.2. 5.3. 5.4. 5.5. 5.6. 5.7. 5.8. Funktionsumfang.................................................................................................. 32 Varianten und Zusatzoptionen .............................................................................. 35 Exportdaten ......................................................................................................... 36 Entwicklungsumgebung ........................................................................................ 38 Softwarearchitektur ............................................................................................. 38 Analyse der Gebietsdaten ..................................................................................... 39 Datenbankzugriff .................................................................................................. 40 SGRID-Export ........................................................................................................ 41 Export-Parameter .......................................................................................... 41 SGRID-Datengenerierung ............................................................................... 42

5.8.1. 5.8.2.


Einleitung

iii

5.8.3. 5.9. 6. 7. 8.

Erstellung der SGRID-Dateien......................................................................... 44

Export-Workflow und GUI..................................................................................... 46

Tests und Auswertung ................................................................................................ 50 Ausblick...................................................................................................................... 54 Interoperabilittsuntersuchungen.............................................................................. 55 8.1. 3D-Abbildungsmodelle der HGK ............................................................................ 56 Punktmodell .................................................................................................. 56 Polygonnetz / Drahtmodell ............................................................................ 57 Flchenmodell ............................................................................................... 59 Volumenmodelle ........................................................................................... 63 Keyhole Markup Language ............................................................................. 65 Geometry Markup Language .......................................................................... 69 CityGML ........................................................................................................ 71 Extensible 3D ................................................................................................. 72 Simple Feature Access ................................................................................... 75

8.1.1. 8.1.2. 8.1.3. 8.1.4. 8.2. 8.2.1. 8.2.2. 8.2.3. 8.2.4. 8.2.5. 8.3. 9.

Interoperable Austauschformate .......................................................................... 65

Auswertung .......................................................................................................... 77

Zusammenfassung ..................................................................................................... 80

Tabellenverzeichnis ...............................................................................................................I Abbildungsverzeichnis .......................................................................................................... II Abkrzungsverzeichnis ....................................................................................................... IV Glossar ................................................................................................................................ V Literaturverzeichnis ............................................................................................................ VI Anhang ............................................................................................................................... IX A) B) C) D) Aufgabenstellung der Diplomarbeit ....................................................................... IX Sequenzdiagramm fr den Export eines HGK ......................................................... XI Objektmodell der Geographic Markup Language................................................... XII Objektmodell Simple Feature Access ................................................................... XIII


Einleitung

1

1. Einleitung1.1. Ausgangslage

Im Rahmen einer hydrogeologischen Spezialkartierung werden im Auftrag des Landesamtes fr Umwelt, Landwirtschaft und Geologie (LfULG) derzeit die Raumlagen der relevanten hydrogeologischen Einheiten Sachsens erfasst. Durch das von der Firma Beak Consultants GmbH im Auftrag des LfULG entwickelte Fachinformationssystem (FIS) Hydrogeologie knnen nun diese bei der Kartierung erfassten Daten einheitlich und datenbankbasiert gespeichert werden. Ziel ist die Ablage eines kompletten landesweiten hydrogeologischen Untergrundmodells mit zugehrigen Sachdaten. Das FIS Hydrogeologie stellt den Anwendern dabei eine Oberflche bereit, um fachbezogene Aufgaben, die die Kenntnis des hydrogeologischen Untergrundes erfordern, zu lsen. Das Datenformat der zugehrigen 3DDatenbank wurde dabei an das SGRID-Format von GOCAD angelehnt, da eben dieses durch erste Modellierungen in GOCAD im LfULG erprobt wurde [1]. Es wurde eine ArcMapExtension (FHYG) konzipiert, die dem Anwender eine Nutzerschnittstelle zur Abfrage der hydrogeologischen Entitten in Bezug auf deren Sachdaten, den zugehrigen GIS-Daten und den damit verknpften 3D-Geometriedaten zur Verfgung stellt. Eine 2D-SchnittVisualisierung der 3D-Daten ist bisher die einzige Mglichkeit die 3D-Daten darzustellen. Die ArcMap-Extension fgt sich, zusammen mit der 3D-Datenbank in das

Fachinformationssystem Hydrogeologie ein, dargestellt in Abbildung 1. Vom Bearbeiter durch eine Import-Schnittstelle abgelegt, eingepflegte diese Daten in die werden zunchst in eine des

Arbeitsdatenbank

bevor

Produktionsdatenbank

Informationssystems bernommen werden. Dies ermglicht eine konsistente Datenhaltung. Alle fachlichen Daten zu den 3D-Objekten befinden sich in einer Sachdatenbank, die mit der 3D-Datenbank verknpft ist. Die in der GIS-Datenbank gespeicherten Verbreitungs- und Ausstrichflchen der hydrogeologischen Krper dienen der Navigation in ArcMap.


Einleitung

2

Abbildung 1: FIS Hydrogeologie (Quelle: Beak)

1.2. Ziele der ArbeitIm Moment knnen im FIS Hydrogeologie vom Nutzer achsenparallele Schnitte erzeugt und als 2D-Grafik visualisiert werden. Im Projekt ist jedoch auch eine 3D-Visualisierung der 3DDaten vorgesehen. Diese setzt die Umwandlung der Daten in ein geeignetes Format voraus. Da GOCAD bereits Anwendung im LfULG findet, liegt es nahe, die Daten auch in ein fr GOCAD importfhiges Format zu bringen, um sie so den GOCAD-Anwendern zur Verfgung zu stellen. Im Rahmen dieser Arbeit soll deshalb ein Export-Werkzeug konzipiert und umgesetzt werden, welches hydrogeologische Krper (HGK) aus der 3D-Geodatenbank (3DGDB) in das GOCAD-spezifische SGRID-Format konvertiert. Dieses ermglicht eine rasterbasierte Speicherung von Krpern, hnlich wie sie in der 3DGDB gewhlt wurde. In der zu realisierenden Export-Schnittstelle sollen vom Nutzer ausgewhlte Datenbereiche im GOCAD-Format exportiert und dateibasiert abgelegt werden. Formatspezifische

Abbildungsmglichkeiten mssen dazu auf ihre Tauglichkeit fr die Abbildung untersucht werden. Die SGRID-Modelle sollen die Krper getreu abbilden und mglichst flexibel fr die weitere Verwendung einsetzbar sein. Die Visualisierung dieses Formates ist dann sowohl in GOCAD als auch in dem, an der Technischen Universitt Bergakademie Freiberg entwickelten OpenSource-Viewer Geocando mglich [2]. Einschrnkungen bei der Abbildung auf Seiten


Einleitung

3

der Zielprogramme sind nicht auszuschlieen und sollten bei der Arbeit mit Testdaten aufgedeckt und dokumentiert werden. In Zukunft soll es mglich sein die Daten einem breiten Nutzerkreis zur Verfgung zu stellen. Das Landesamt als Auftraggeber ist deshalb neben einer Exportschnittstelle fr GOCAD auch an interoperablen Exportschnittstellen interessiert. Der heterogene Pool an interoperablen Austauschformaten von Geodaten erfordert eine Analyse dieser Formate auf Tauglichkeit fr den Export aus der Datenbank. Dabei soll abgewogen werden, welches Format eine realisierbare, aber auch zufriedenstellende Lsung fr eine interoperable Exportschnittstelle bietet. Hierfr sollen zunchst, ausgehend vom Modell der Datenbank des FIS Hydrogeologie, denkbare Abbildungen aufgezeigt, gegenbergestellt und anschlieend deren Realisierbarkeit in ausgewhlten Formaten analysiert werden.

1.3. Interoperable SoftwareDie Idee bei der Entwicklung interoperabler Software ist es, die Kommunikation zwischen Programmen, die mit hnlichen fachspezifischen Daten umgehen, zu ermglichen und zu vereinfachen. Wichtig dabei sind offene, an Standards orientierte Schnittstellen. Import und Export der Daten soll ber offene Austauschformate geschehen. Die Bereitstellung von Datenbankinhalten ber Dienste und offene, weit verbreitete Dateiformate zur Weiterverarbeitung, Aufbereitung, Prsentation und Visualisierung bildet einen

Schwerpunkt. Speziell im geowissenschaftlichen Bereich besteht das Bedrfnis groe Mengen ortsbezogener Daten einem groen Nutzerkreis bereit zu stellen. Oft mssen georeferenzierte Daten in einer Software erzeugt, in der nchsten weiterverarbeitet und einer dritten bereitgestellt werden. Die Austauschformate sind jedoch bisher meist herstellerspezifisch, nicht offen oder (bewusst) sprlich dokumentiert. Monopolstellungen fhrender Hersteller ermglichen es ihnen zudem, Standards auer Acht zu lassen und auf eigene proprietre Formate zu setzen. Dies bindet die Nutzer an das Produkt, hemmt aber auch die Umsetzung neuer innovativer Ideen. Lizenzbestimmungen, Kosten fr Clients und fehlende Flexibilitt verschwenden hier Potential. Aus diesen Defiziten heraus entstand im Bereich der Geodaten bei vielen Anwendern, Industrieunternehmen, ffentlichen mtern und Universitten die Motivation die Vorteile


Einleitung

4

von international geltenden Standards zu nutzen und implementierende Schnittstellen und Dienste zu entwerfen und weiter zu entwickeln, um die Interoperabilitt rumlicher Daten zu verbessern. Eine Organisation die sich das zum Ziel gemacht hat, ist das Open Geospatial Consortium (OGC). OGC-standardisierte Formate sind allgemein weit verbreitet und als Standards akzeptiert. Vom OGC entworfene Spezifikationen beschreiben dabei die Struktur der Schnittstellen. Werden diese getreu der Spezifikation vom Softwareentwickler umgesetzt, knnen so entstandene Programme ber diese offenen Schnittstellen Daten austauschen. Bei der Untersuchung interoperabler Formate im Rahmen dieser Arbeit sollten OGC-Standards deshalb eine besondere Rolle spielen. Ein berblick ber internationale Standards im GIS-Bereich findet sich in [3].

1.4. Reprsentation von GeodatenHat man geowissenschaftliche Daten des Untergrundes erfasst, gibt es diverse Anstze, um diese dreidimensional abzubilden. Je nach Anwendungsgebiet muss eine mehr oder weniger abstrakte Art der Reprsentation gefunden werden, die den Anforderungen des Nutzers gengt. [4] beschreibt dabei eines der Grundprobleme, dass bei digitalen Abbildungen auftritt. Die Welt ist unendlich komplex, Rechenleistung und Speicher aber endlich. Reprsentationen mssen die Menge an Details deshalb limitieren. Unterschieden wird in der Literatur meist zwischen vektorbasierten und rasterbasierten Modellen [4], [5], [6]. Als Sonderformen sind zudem hybride Modelle umsetzbar. Whlt man ein Vektormodell enthlt dies diskrete Objekte, die durch ihre Grenzen klar definierte Instanzen einer Kategorie darstellen. In der Thematik der Hydrogeologie sind dies zum Beispiel Krper mit gleichen gesteinsphysikalischen Eigenschaften. Vektorreprsentationen basieren auf Punkten oder Vertices, die durch Linien miteinander verbunden werden und so die Form einer Flche beschreiben. Der Rasteransatz hingegen beruht auf kontinuierlichen Feldern, bestehend aus einer endlichen Anzahl von Variablen, die fr jeden Punkt des Abbildungsgebiets definiert sind. Rasterreprsentationen teilen ein Gebiet in Felder von Zellen auf. Den Zellen knnen dann fachlich relevante Attribute (Durchlssigkeit, Gesteinsdichte, ) zugewiesen werden (vgl. [4]). Reden wir von dreidimensionalen Abbildungen, so werden kontinuierliche Felder oftmals als Voxelmodell realisiert. Voxel sind wrfelfrmige Volumenelemente, die


Einleitung

5

aneinander angrenzen, sich jedoch nicht berschneiden. Man kann jenes Modell als Fortfhrung des Rasteransatzes in den dreidimensionalen Raum ansehen (vgl. [7]). Mchte man ein dreidimensionales Gebiet des Untergrundes abbilden , sollten die Einzelvolumen der Krper ein geschlossenes, topologisch konsistentes Modell ergeben. Die Einhaltung dieser Bedingung ist im Rastermodell einfacher, jedoch knnen komplexe Strukturen leichter als Vektorreprsentation abgebildet werden.


Die 3D-Geodatenbank

6

2. Die 3D-GeodatenbankDie 3DGDB des FIS Hydrogeologie enthlt die 3D-Geometrien, die im Rahmen dieser Arbeit abgebildet werden. Das zugrunde liegende Modell ist es als hybrides Modell einzuordnen, welches sowohl Vektor- als auch Rastereigenschaften aufweist. In den kommenden Abschnitten wird nher auf die Speicherung der Daten eingegangen und wie konkrete 3DObjekte aussehen, die in der Datenbank gehalten werden knnen.

2.1. Daten des FIS HydrogeologieIn Tabelle 1 sind die in der 3D-Datenbank enthaltenen Geometrien aufgelistet. Relevant fr diese Arbeit sind die Daten der hydrogeologischen Krper. Diese sind in einem rasterbasierten und zugleich zellzerlegenden Modell gespeichert. Die Gesamtkrper bestehen dabei aus einzelnen Grundkrpern, die rasterbedingt im Aufriss feste quadratische Formen aufweisen, in der dritten Dimension jedoch Freiformflchen darstellen. Das Modell weist somit auch Eigenschaften vektorbasierter Modelle auf. Dies macht es flexibel bei der Abbildung realer Krper ohne den Vorteil der einfachen Verwaltung von Rasterdaten zu verlieren (vergl. [7] , [6]). Alle zu einem HGK gespeicherten Geodaten knnen ber die HGKID und ber ihre bergeordnete hydrogeologische Einheit (HGE) mit den Sachdaten verknpft werden. Jede HGE ist dort auch ber eine Identifikationsnummer (HYE) oder ber den Einheiten-Namen identifizierbar. Die Geogenen Kommunikationsbereiche stellen die Berhrungsflchen zwischen zwei grundwasserdurchlssigen Schichten dar. Anthropogene Kommunikationsbereiche knnen zum Beispiel Bereiche untertgigen Bergbaus sein. Die Belegbohrungen bilden die Eingangsdaten bei der Konstruktion der HGK und lassen sich ebenfalls in der ArcMapExtension einblenden.Art Gelndeoberkante Hydrogeologische Krper Anthropogene Kommunikationsbereiche Geogene Kommunikationsbereiche 3D-Flchen FHY_3D_GKB_SAEULE Abgebildet als 3D-Flche 3D-Krper 3D-Krper DB-Tabelle FHY_3D_SAEULE FHY_3D_HGK_SAEULE FHY_3D_GKB_SAEULE


Die 3D-Geodatenbank

7

Grundwasserflurabstand Strungen Belegbohrungen

3D-Flchen 3D-Flchen 3D-Linien

FHY_3D_GWFLA_SAEULE FHY_3D_STOERUNG FHY_3D_BP

Tabelle 1: Arten von Geodaten in der 3D-Datenbank

2.2. DatenmodellUm zu erreichen, dass alle Datenpunkte auf festgelegten Gitterkreuzen liegen, wie es bei einem rasterbasierten Format der Fall ist, muss auf das abzubildende Gebiet ein quidistantes Gitter gelegt werden. Aus den Eingangsdaten werden dann Werte auf den Gitterpunkten abgegriffen. Dies bedeutet, dass alle rumlichen Daten, die in die Datenbank eingepflegt werden, in derselben Rasterung vorliegen oder eben auf dieses projiziert werden mssen. Ein quidistantes Gitter erlaubt es die ortsbezogenen Daten in der Datenbank durch Datenbankindizes nach ihren Koordinaten zu ordnen und so zum Beispiel Abfragen mit einer festen Koordinate besonders schnell durchzufhren. Benachbarte Datenpunkte stlich, westlich, nrdlich oder sdlich eines bestimmten Punktes ergeben sich aus dem Raster und mssen nicht aus Distanzberechnungen ermittelt werden. Zur Anwendung kommen diese Vorteile auch bei dem im FHYG integrierten Schnittwerkzeug. Mit dessen Hilfe werden achsenparallele, und somit auf den Gitternetzlinien liegende, Schnittspuren erzeugt . Die Rasterlinienabstnde in der 3D-Datenbank betragen in der Regel 50 Meter, knnen aber auf 25 und 12,5 Meter verfeinert werden. Somit reprsentiert jede Gitterzelle hchstens ein Gebiet von 50 x 50 Metern. Die Koordinaten liegen dabei als Hoch- und Rechtswerte vor und werden ganzzahlig in Millimetern abgespeichert.

2.2.1. Sulen Erweitert man das Rastermodell in die dritte Dimension und mchte nun 3D-Krper in dieser Form speichern, bedeutet dies, dass die Krper in Einzelelemente zerlegt werden, die als Grundflchen die Gitterquadrate erhalten. In der 3D-Datenbank wird deshalb jedes Gitterquadrat, auf dem 3D-Daten liegen, als Sule reprsentiert. Im Datenbank-Schema entspricht jede Sule einem Eintrag in der Tabelle FHY_SYS_3D_SAEULE (Tabelle 2). Eindeutig ist der Eintrag durch die ID und zustzlich durch Kombination der in der Tabelle enthaltenen X- und Y-Koordinaten der Sdostecke der Sule. Die Gelndeoberkante wird fr


Die 3D-Geodatenbank

8

jede Sule durch die vier Hhenwerte an den Sulenecken reprsentiert. Die Sdwest-, Nordwest- und Nordost-Eckkoordinaten ergeben sich aus der Sulenposition und der Kantenlnge der Sule. Da nur quadratische Sulen mglich sind, gilt die Kantenlnge fr die Breite und Lnge der Sule.Spalte in der SulentabelleID_FHY_3D_SAEULE X Y KANTENLAENGE Z_SE Z_NE Z_NW Z_SW

Beschreibung Eindeutige Identifikationsnummer fr die Sule Die X-Koordinate der Sdost-Ecke der Sule Die Y-Koordinate der Sdost-Ecke der Sule Die Kantenlnge der Sule in X- und Y-Richtung Z-Wert der Gelndeoberkante an der Sdost-Ecke Z-Wert der Gelndeoberkante an der Nordost-Ecke Z-Wert der Gelndeoberkante an der Nordwest-Ecke Z-Wert der Gelndeoberkante an der Sdwest-Ecke

Tabelle 2: Tabelle FHY_3D_SAEULE aus der 3D-Datenbank

Eine 50 Meter Sule kann immer nur vollstndig in vier kleinere 25 Meter Sulen aufgeteilt werden. Andernfalls wrden Lcken im Modell entstehen. In Abbildung 2a ist ein inhomogenes Beispielraster abgebildet. Das Gebiet kann eine geologisch heterogene Zone oder ein fachlich interessanter Bereich sein, bei dem eine hhere Auflsung der Daten gewnscht ist. In den Bereichen mit 25 Meter Sulen, liegen dabei nicht zugleich 50 Meter Sulen vor. In Abbildung 2b ist der zugehrige Schnitt entlang der gelben Rasterlinie zu sehen. Da im Gitter ein Gitterpunkt zu bis zu vier Gitterzellen gehrt, kann die markierte Schnittlinie entweder die sdlich oder die nrdlich anliegenden Gitterzellen visualisieren. In der Abbildung wurden diese bereinander gelegt. Dies soll durch die Schraffierung der Sulen angedeutet werden. Weiterhin ist die Gelndeoberkante fr diesen Bereich abgebildet. Sie ergibt sich aus den Hhenwerten der Suleneintrge auf dieser Gitterlinie.


Die 3D-Geodatenbank

9

Abbildung 2: Inhomogenes Sulenraster. a) Aufriss ; b) Schnitt durch das Gebiet

Die Sulentabelle bildet die Grundlage fr die meisten Abfragen aus der Datenbank, da ausgehend von den Suleneintrgen ber die Koordinate verknpfte Teilkrper abgerufen werden. Wie diese in der Datenbank abgelegt werden, wird im nchsten Abschnitt erlutert.

2.2.2. Sulenabschnitte Fr die Speicherung der hydrogeologischen Krper werden die Sulen in Sulenabschnitte aufgeteilt. Die Tabelle 3 listet die Spalten der zugehrigen 3DGDB-Schematabelle auf, die fr die Konstruktion der Krper von Bedeutung sind. Jeder Eintrag in dieser Tabelle reprsentiert einen Sulenabschnitt. Jeder Sulenabschnitt ist durch seine Koordinaten eindeutig einer Sule zugewiesen. Ein Sulenabschnitt ist immer ein Teil einer Sule , der den Verlauf des hydrogeologischen Krpers fr diese Sule beschreibt. Durch

Fremdschlsseleintrge mit HGK- und HGE-ID gehrt jeder Sulenabschnitt zu genau einem HGK und einer HGE.Spalten in HGK-TabelleID_FHY_3D_HGK_SAEULE R_X / R_Y Z_MIN_SE / Z_MIN_NE / Z_MIN_NW / Z_MIN_SW Z_MAX_SE / Z_MAX_NE / Z_MAX_NW / Z_MAX_SW FK_FHY_MT_HGK FK_FHY_MT_HGE R_SYMBOL

Beschreibung Eindeutige Identifikationsnummer fr den Sulenabschnitt Die X und Y-Koordinate der Sdost-Ecke der Sule Z-Werte der Sdost-, Nordost-, Nordwest- und Sdwest-Ecke der Unterkante des Sulenabschnitts jeweils in einer Spalte Z-Werte der Sdost-, Nordost-, Nordwest- und Sdwest-Ecke der Oberkante des Sulenabschnitts jeweils in einer Spalte Fremdschlssel mit der ID des HGK in der Sachdatenbank Fremdschlssel mit der ID der HGE in der Sachdatenbank String fr den oder die RGB-Farbwerte der HGE

Tabelle 3: Spalten aus der Tabelle FHY_3D_HGK_SAEULE der 3D-Datenbank.


Die 3D-Geodatenbank

10

Um die Geometrie eines Sulenabschnitts zu beschreiben sind acht Hhenwerte gespeichert, die die Ecken der Ober- und Unterkante des Krpers fr die jeweilige Sule darstellen. In Abbildung 3 ist ein solcher Sulenabschnitt links im Aufriss und rechts als perspektivische Darstellung abgebildet. Zu sehen ist, dass immer jeweils zwei Ecken des Abschnittes auf der gleichen XY-Koordinate liegen. Krperober- und unterkante besitzen in der Regel pro Ecke unterschiedliche Hhenwerte.

Abbildung 3: Darstellung eines Sulenabschnitts. a) Aufriss b) Perspektive

Die Z-Werte fr bis zu drei Ecken knnen jedoch auch zusammen fallen. Dies ist vor allem an Krperenden der Fall. Verbindet man alle Sulenabschnitte eines HGKs, erhlt man den eigentlichen Krper. Die Auenkanten eines Sulenabschnitts ergeben sich aus der Verbindung der Eckpunkte. Die oberen und unteren Begrenzungsflchen sind dagegen nicht immer eindeutig definiert. ber den Flchenverlauf innerhalb der Begrenzungskanten ist keine Information gespeichert. Dies ist fr die achsenorientierte Schnittdarstellung, wie sie jetzt im FHYG integriert ist, nicht von Relevanz. Bei der 3D-Abbildung der Krper und deren Oberflchen ist dies jedoch zu bercksichtigen.

2.3. Sonderflle und komplexe KrperPro Sule knnen mehrere Eintrge in der Sulenabschnitts-Tabelle zum gleichen HGK gespeichert werden. Wie wir sehen werden, ist das auch notwendig, um komplexere Krper korrekt abbilden zu knnen. Betrachten wir den Standardfall, dann besitzt ein hydrogeologischer Krper eine kontinuierlich verlaufende Ober- und Unterkante. Darzustellen sind diese durch zwei Flchen, die an den Enden zusammenfallen und so den Krper komplett abschlieen. Ob ein Krper an einer Koordinate - und damit innerhalb einesChristian Bertram Schnittstellen fr eine Landesweite 3D-Datenbank

Die 3D-Geodatenbank

11

Sulenquadrats - existiert, uert sich in der Datenbank darin, dass fr die entsprechende Sule auch ein Sulenabschnitt vorhanden ist, der dem Krper zugeordnet ist. Die Mchtigkeit des Krpers in diesem Bereich ergibt sich aus den Minimums- und Maximumshhenwerten des Sulenabschnitts. Der Krper kann dann entweder keilfrmig oder durch eine vertikale Ebene enden, zu sehen in Abbildung 4. Fallen Ober- und Unterkante wie in Sule 1 zusammen, enthlt der entsprechende Sulenabschnitt eine oder mehrere Ecken mit zwei gleichen Hhenwerten. In Sule 6 hingegen endet der Krper nach Osten hin mit einer vertikalen Kante. Dies entspricht einem Sulenabschnitt wie er in Abbildung 3b dargestellt ist.

Abbildung 4: Standardfall hydrogeologischer Krper im Schnitt

Weiterhin gibt es den Sonderfall der Strungen, die die Kontinuitt eines Schichthorizontes stren. Diese knnen in beliebigem Winkel einfallen und eine Schicht so verschieben, dass sie sich in der Krperabfolge wiederholt oder zumindest die beiden Teile links und rechts der Strung voneinander getrennt werden. Die Schichtlagerung kann ebenso durch zeitlich nacheinander stattfindende Verschiebungen geprgt sein. Welche Strukturen dabei entstehen, ist im Detail zum Beispiel in [8] nachzulesen. So rumlich voneinander getrennte Krper werden in der Datenbank dann als zwei unterschiedliche HGKs gelistet, die jedoch zur gleichen Einheit zuzuordnen sind. In Abbildung 5 sehen wir einen durch eine Strungszone zerteilten Krper im Schnitt. Benachbarte Sulenabschnitte gehen im Normalfall, wie zum Beispiel zwischen Sule 5 und Sule 6, ineinander ber. Die Ost-Ecke von Sule 5 liegt auf der gleichen Koordinate wie die West-Ecke der Sule 6. Hhenwerte benachbarter Teilkrper sind also in der Regel redundant gespeichert. Denkt man sich den Krper in die Bildebene


Die 3D-Geodatenbank

12

hinein weiter, so sind die Hhenwerte sogar vierfach vorhanden. Am Rand der Strungszone jedoch zeigt sich, warum jeder Sulenabschnitt acht Hhenwerte besitzen muss. Die stlichen Hhenwerte der Sule 4 unterscheiden sich von den westlichen Hhenwerten der Sule 5 um den Betrag der Verschiebung die durch die Strung hervorgerufen wurde. Zwischen Sule 2 und 3 wurde der Krper sogar aufgetrennt.

Abbildung 5: Schnittdarstellung Sulenabschnitte - Spezialfall Verwerfung

Ein weiterer zu betrachtender Fall sind Krper die innere Aussparung en aufweisen. Neben der ueren Grenze existieren somit eine oder mehrere innere Begrenzungsflchen zu anderen HGKs. Die Krper die diese Lcher ausfllen, werden Linsen genannt. Diese knnen selbst auch wieder kleinere Krper enthalten. Die Hierarchie, also die Beziehung zwischen uerem und innerem Krper, ist in der Datenbank nicht abgelegt und fliet bei der Abbildung eines Einzelkrpers nicht ein. In der 3D-Datenbank werden solche Krper mit Hilfe von mehreren Sulenabschnitten pro Sule gespeichert. In Abbildung 6 ist ein solcher Krper abgebildet. In Sule 4 ist der Krper durch die Linse getrennt, sodass zwei Abschnitte (SA41, SA42) notwendig sind, um ihn in dieser Sule zu beschreiben. In Sule 5 fllt der Krper zusammen und es ist nur ein Sulenabschnitt (SA51) notwendig.


Die 3D-Geodatenbank

13

Abbildung 6: Schnittdarstellung Sulenabschnitte - Spezialfall Linse

In Abbildung 7 ist ein hnlicher Fall dargestellt, der beispielsweise bei einer Intrusion von Magma in darber liegende Schichten auftreten kann. Auch Salzstcke weisen eine hnliche Form auf. Solche Krper sind in flchenbasierten Formaten oftmals nicht abbildbar. Viele Flchenmodelle knnen nicht mehrere Datenpunkte auf einer XY-Koordinate speichern, sodass berhnge nicht dargestellt werden knnen. In der 3D-Datenbank des FIS Hydrogeologie ist dies jedoch mglich. hnlich wie bei der Problematik der Linse, werden bei dem abgebildeten Beispiel fr den Krper 2 in Sule 4 zwei Sulenabschnitte gespeichert (SA41, SA42). In Sule 3 ist der Krper verbunden, sodass dort nur ein Sulenabschnitt (SA31) notwendig ist.

Abbildung 7: Schnittdarstellung Sulenabschnitte - Spezialfall komplexe Krper

Auf diese Art knnen nahezu beliebig geformte Krper in der 3D-Datenbank abgebildet werden. Jedoch mssen diese bei der Modellierung an das Raster und somit an die begrenzte Auflsung angepasst werden. Strungszonen, die eine Breite von 50 Metern


Die 3D-Geodatenbank

14

unterschreiten, knnen nur stark abstrahiert und nicht ohne Verlust von Daten in ein 50 Meter Raster berfhrt werden. Entschrft wird dieses Problem mit der Mglichkeit der Verringerung der Kantenlnge auf 25 und 12,5 Meter in diesen Bereichen. Die Genauigkeit ist also, wie bei allen Rasterdaten, durch die Auflsung des Rasters beschrnkt. Die genannten Sonderflle sollen bei der Entwicklung einer Routine zum Export der Krper korrekt abgebildet werden. Dabei ist festzuhalten, dass die im Rahmen dieser Arbeit abzubildenden Daten selbst schon Abbildungen darstellen.


GOCAD-SGRIDs

15

3. GOCAD-SGRIDsAuf den ersten Blick unterscheidet sich das GOCAD-SGRID-Format nicht sehr von dem der 3D-Datenbank. Beide sind rasterbasiert. Bei beiden ergeben sich die Volumenkrper aus rasterbasierten Teilkrpern. Die Ober- und Unterkanten der Teilkrper mssen zudem keine planaren Flchen sein. In den folgenden Abschnitten sollen Mglichkeiten des SGRIDFormates und Unterschiede zum Datenmodell der 3D-Datenbank des FIS Hydrogeologie aufgezeigt werden. Wichtige SGRID-Merkmale werden dabei nher beleuchtet.

3.1. SGRID-DatenformatDas SGRID-Format ist zwar ein zellbasiertes Format, jedoch knnen die Zellen dabei variable Ober- und Unterkanten besitzen. Die Zellgeometrie ist also, im Gegensatz zu den meisten voxelbasierten Formaten, nicht fr jede Zelle gleich. Grundlage eines jeden SGRIDs ist ein quidistantes Gitter, das die Zellanzahl in X- und Y-Richtung vorgibt. Die Dimension des SGRIDs ergibt sich durch Angabe der Knotenpunkte pro Koordinatenrichtung. Ist k die Anzahl der Knoten, so ergibt sich die Gesamtzahl der SGRID-Zellen aus:

Jeder SGRID-Knotenpunkt ist definiert durch eine X-, Y- und Z-Koordinate und seiner Lokalisierung im Gitter. Hierfr dienen Indexwerte I, J und K fr die drei

Koordinatenrichtungen. Ein Knoten gehrt maximal zu acht Zellen, bei Randknoten sind es weniger. Die Konstruktion der Zellen aus den Knoten leitet sich aus den Knotenindizes ab, denn jeder Knoten wird mit seinen Nachbarknoten (maximal sechs) verbunden. Somit entsteht ein zusammenhngendes Volumen. Bei der Angabe der Knoten muss eine feste Sortierung nach den Gitterindizes eingehalten werden. Der Ursprung des Index Bezugssystems liegt dabei in der oberen Sdost-Ecke, sodass die Koordinaten im SGRIDFormat zunchst nach aufsteigendem Y-Wert und innerhalb einer Y-Zeile nach absteigendem X-Wert angeordnet sein mssen. Weitere XY-Knotenschichten werden darauf folgend angegeben. Nur so knnen die Zellen im Visualisierungsprogramm korrekt generiert werden.


GOCAD-SGRIDs

16

Abbildung 2 zeigt ein aus sechs Zellen aufgebautes SGRID, dargestellt als Kantenmodell. Jede XY-Gitterebene enthlt zwlf Knoten. Der in der Knotenliste zuletzt gelistete Knoten mit den Indizes 2,3,1 ist auch der mit dem grten Y-Wert und dem kleinsten X-Wert.

Abbildung 8: Aufbau eines SGRIDs mit Knotenstruktur.

Die Oberflchen des SGRIDs werden erst bei der Visualisierung festgelegt. Die sechs Begrenzungsflchen einer Zelle werden nach einer GOCAD-internen Vorschrift in Dreiecke zerlegt, welche dann gerendert werden. GOCAD zerteilt jede der sechs Seiten einer Zelle in zwei Dreiecke. An den vier Seitenflchen besitzen die so erzeugten Dreieckspaare dieselbe Normale und bilden eine Ebene. Die Triangulation der SGRID-Zelloberflchen geschieht in GOCAD richtungsabhngig. Die Oberflche wird durch die Verbindungslinie zwischen der Nordost- und der Sdwest-Ecke geteilt. Dies fhrt dazu, dass zwei Zellen mit derselben Geometrie, je nach Ausrichtung im Koordinatensystem, unterschiedlich dargestellt werden. In Abbildung 9 sind diese zwei Flle gegenbergestellt. Nehmen wir an, der Z-Wert der Eckknoten betrgt an drei Sulenecken null und an einer Ecke zehn. In Abbildung 9a wurde der Hhenwert der Nordost-Ecke auf zehn gesetzt, im Fall b der Hhenwert der NordwestEcke. Nun teilt GOCAD zwischen der Nordost- und der Sdwestecke in die zwei Dreiecke, die die Oberflche bilden. Whlt man jetzt die Blickrichtung bei beiden orthogonal zur Verbindungslinie zwischen der Ecke mit Hhenwert zehn und ihrer gegenberliegenden Ecke, so erhlt man zwei voneinander verschiedene Visualisierungen des geometrisch gleichen Modells.


GOCAD-SGRIDs

17

Abbildung 9: Triangulation einer Sulenoberkante in GOCAD. a) Nordost-Ecke Z=10. b) Nordwest-Ecke Z=10.

Berechnet man die Volumen unter den Flchen, ergeben sich ebenso Unterschiede, die je nach Anwendungsfall von Bedeutung sein knnen. Dieser Sachverhalt ist wichtig fr die Konsistenz des Gesamtmodellblocks. Zwei hydrogeologische Krper, die aneinander angrenzen oder aufeinander liegen, sollen im Modell keine berschneidungen und keine Lcken aufweisen. Gewhrleistet ist das nur, falls die Triangulation der Oberkante des unteren Krpers mit der Triangulation der Unterkante des oberen Krpers bereinstimmt. Man sollte hier also festhalten, dass ein im GOCAD-Format gespeichertes Objekt keine eindeutige Reprsentation besitzt. Die Darstellung ist also programmabhngig. Innerhalb von GOCAD ist die topologische Konsistenz jedoch Aufgrund der einheitlichen NordostSdwest Zerlegung gewhrleistet. In Geocando (Abschnitt 3.6) ist die Triangulation ebenfalls einheitlich, jedoch wird hier zwischen der Sdost- und der Nordwestecke geteilt.

3.2. FlagsMchten wir einen Krper abbilden, besitzt dieser in der Regel keine rechteckige, geschlossene Form, so wie sie beim SGRID die Regel ist. Mchten wir aber hydrogeologische Krper abbilden so sind diese im Grundriss durch ihre Verbreitungsflchen definiert. Die Begrenzung einer solchen Verbreitungsflche kann man sich als Stanzform vorstellen. Die Form eines HGK sollte dann das SGRID-Rechteck so ausstanzen, dass es die Form des Krpers abbildet. Zudem kann es Krper geben, die im Inneren Lcher aufweisen oder durch andere Krper durchbrochen werden. In Abschnitt 3.1 wurde jedoch erwhnt, dass ein SGRID immer


GOCAD-SGRIDs

18

ein zusammenhngendes Volumen aus miteinander verbundenen Zellen darstellt. Krper mit Lcken und frei geformten Rndern lassen sich so also nicht abbilden. Diese Regel lsst sich jedoch aufweichen, indem Flags eingesetzt werden. Flags sind zellgebunden und lassen sich als boolesche Werte einer Zelle zuweisen. Eine Zelle kann so zwei verschiedene Zustnde annehmen. Alle auf wahr (true) gesetzten Zellen gehren dann zu einer Menge von Zellen die den SGRID-Krper beschreiben. Auf unwahr (false) gesetzte Zellen bilden die komplementre Menge. GOCAD interpretiert die Flag-Werte, indem auf false gesetzte Zellen bei der Visualisierung und der Weiterverarbeitung ignoriert werden. Abbildung 10 zeigt ein SGRID in GOCAD mit gesetzten Flag-Werten im Aufriss. Der abgebildete Kper besitzt in der Mitte einen Bereich ohne Daten, in dem im Modellblock ein anderer Krper liegen wrde. Diese Zellen sind, in einer zum SGRID gehrenden Flag-Liste, auf false gesetzt. Der Ursprungskrper aus der 3DGDB htte in diesem Beispiel fr die auf false gesetzten Bereiche des SGRIDs keine Sulenabschnitte. Der Krper ist dort nicht vorhanden.

Abbildung 10: SGRID-Grundriss mit gesetzten Flags fr jede Zelle.

Es gibt zwei Spezifizierungen in denen diese Flags im SGRID-Format eingesetzt werden. Dead Cells

Zellen ohne Daten werden in einer separaten Datei als tot gelistet. Auf diese Datei muss dann nur im SGRID-Header verwiesen werden. Auch auf tot gesetzte Knoten sind in der Knotenliste vorhanden und besitzen Koordinaten. Die damit deaktivierten Zellen werden jedoch in GOCAD nicht dargestellt. Alle anderen Zellen mssen auf true gesetzt werden. Alle Flchen zwischen Krperzellen und toten Zellen werden als Dead Cell Faces bezeichnet. Diese knnen visualisiert und zur Weiterverarbeitung des Grids genutzt werden.Christian Bertram Schnittstellen fr eine Landesweite 3D-Datenbank

GOCAD-SGRIDs

19

REGIONS

Die zweite Mglichkeit ist eine Zuordnung der Zellen durch Flag-Werte zu einer Region, die separat eingeblendet und weiterverarbeitet werden kann. Die Speicherung der Zuordnungen erfolgt extern in einer Regionflags-Datei. Regionen sind dabei Teilmengen des gesamten SGRID-Objektes. Viele Mengenoperationen in GOCAD basieren auf der Verwendung von Regionen (Split, Merge, Complement, Substract).

3.3. PunktattributierungEine Alternative fr die Klassifikation von Zellen sind Properties. Mit ihnen kann ebenfalls eine Krper-Zugehrigkeit ausgedrckt werden. Property-Werte eines SGRIDs knnen zelloder eckpunktzentriert anliegen. Bei eckpunktzentrierten Attributen knnen alle acht Knoten einer Zelle unterschiedliche Attributwerte besitzen. Bei zellzentrierten Attributen gilt der Attributwert der oberen Sdost-Ecke einer Zelle. Property-Werte an den anderen Eckpunkten der Zelle werden dann ignoriert. In Abbildung 11 wurden beide Flle als visualisiertes Property gegenbergestellt. In Abbildung 11a gilt der obere Sdostwert fr die gesamte Zelle. Wird der Wert 1 mit der Farbe Grn visualisiert, wird also die gesamte Zelle grn dargestellt. Im eckpunktzentrierten Fall in Abbildung 11b hingegen, liegen die Attribute direkt an den Ecken an und gelten auch nur fr diese. Zwischen den Ecken wird interpoliert, in diesem Fall also zwischen der Farbe Grn fr den Wert 1 und der Farbe Rot fr den Wert 0.

Abbildung 11: SGRID mit Attributwerten fr jeden Knoten a) zellzentriert b) eckpunktzentriert


GOCAD-SGRIDs

20

Werden Properties angelegt, so muss jeder Knoten des SGRIDs auch einen Wert fr dieses Property besitzen. Gespeichert werden die Attributwerte entweder als weitere Spalte innerhalb der Knotenliste oder als externes Array im Binrformat. Attribute mssen mit einer ID und dem Namen deklariert werden. Die Verwendung von Attributen kann man als Alternative zu den Flag-Werten ansehen. Bei der Reprsentation eines Krpers in einem SGRID knnen beispielweise die Attributwerte 0 und 1 analog zur Funktion von Flags eingesetzt werden. Auch knnen dem SGRID so hydrogeologische Parameter wie die Durchlssigkeit zugewiesen werden.

3.4. Dateiformat und SGRID-KonfigurationZiel des FHYG-Exports sollen Dateien in einem fr GOCAD lesbaren SGRID-Format sein. Pro SGRID ist dafr immer eine Datei mit der Endung .sg notwendig. In dieser sind die HeaderInformationen enthalten. Alle weiteren Dateien werden in dieser referenziert. Die KnotenKoordinaten und Indizes fr das Zellgitter sind in einer separaten, endungslosen ASCII- oder Binrdatei gespeichert. Im ASCII-Format wird jeder Knoten in einer Zeile abgespeichert. Die drei Koordinatenwerte, gefolgt von (optionalen) Attributwerten und den Knotenindizes, werden durch Leerzeichen getrennt angeordnet. Die erste Zeile der Knotendatei gibt zudem die enthaltenen Spalten mit Namen an. Gleitkommazahlen werden durch den Punkt als Dezimaltrennzeichen angegeben. Im Binrformat entfllt die Angabe der Knotenindizes. Jeder Knoten wird in zwlf Byte mit jeweils vier Byte fr den X-, Y- und Z-Wert der Koordinate gespeichert. Die Reihenfolge der Knoten ist festgelegt und wurde in Abschnitt 3.1 beschrieben. Eventuelle Attributwerte knnen in einer separaten Binrdatei gespeichert werden. Die in Abschnitt 3.2 erwhnten Flag-Werte werden ebenfalls in einer eigenen Datei gehalten. Jeder boolesche Wert, der fr einen Knoten gilt, muss dabei in einem Bytearray abgelegt werden. Setzt man REGIONS im SGRID ein, knnen die Flag-Werte fr mehrere Regionen in einer einzigen Binrdatei abgelegt werden. Jeder Region-Flag wird in einem Byte, jeder Dead-Cell-Flag wird in vier Byte gespeichert. Die Verknpfung zu den Knoten erfolgt dann ber die Reihenfolge der Bytes in der Datei. Diese muss also zwingend der Sortierung in der Knotendatei entsprechen. Abbildung 12 zeigt die Abhngigkeiten, Kardinalitten und Formate der jeweiligen Dateien.


GOCAD-SGRIDs

21

Abbildung 12: Schematische Darstellung der SGRID-Dateistruktur

Das GOCAD-Format ermglicht und erfordert zudem Angaben zur Visualisierung, den Achsen und den Attributwerten. Folgende Angaben sind dabei von besonderem Interesse (mit den Aufzhlungszeichen aus Tabelle 4 versehen): Mchte man die farbliche Visualisierung des SGRIDs beeinflussen um mehrere gleichzeitig eingeblendete SGRIDs visuell zu unterscheiden, kann die Farbgebung der Flche (a) und die Farbe des SGRID-Gitters (b) angepasst werden. Zudem sind Verweise auf die zum SGRID gehrenden Dateien notwendig. In jedem Falle gehrt hierzu eine Knotendatei (d) und optional eine DeadCell- (e) und/oder eine Regions-Datei (f). Diese mssen dann im selben Verzeichnis wie die Header-Datei liegen. Eine Pflichtangabe ist die Dimension des SGRIDs in X-, Y-, und Z-Richtung (c). Des Weiteren wichtig ist die Festlegung ob die Z-Achse Hhenoder Tiefenwerte darstellt (g) und ob Attributwerte fr den Zellmittelpunkt oder fr jeden Knoten einzeln gelten sollen(h).Schlsselwort (a) (b) (c) (d) (e) (f) (g) *volume*color: # # # # *grid*color: # # # # AXIS_N NX NY NZ ASCII_DATA_FILE Dateiname FLAGS_FILE Dateiname REGION_FLAGS_FILE Dateiname ZPOSITIVE Wert Bedeutung Angabe der SGRID-Farbgestaltung im Format RGBA Angabe der SGRID-Gitter-Farbgestaltung im Format RGBA Angabe der Knotenmenge. NX, NY, NZ sind die Anzahl der Knoten in X-, Y-, und Z-Richtung. Verweis auf die Punktdatei mit den SGRID-Knoten Verweis auf die Flag-Datei, in der die Flag-Werte der Knoten liegen. Verweis auf die REGION-Flagdatei, in der die FlagWerte der SGRID-Regionen stehen. Z-Werte als Hhen- oder Tiefenwerte interpretieren.


GOCAD-SGRIDs

22

(h)

PROP_ALIGNMENT Wert

Die Art wie Property-Werte fr die SGRID-Zellen gelten sollen (CELLS oder POINTS)

Tabelle 4: Header-Angabe zur SGRID-Konfiguration

3.5. Vergleich zu weiteren GOCAD-FormatenBei der Entscheidung welches konkrete Format fr die Bereitstellung der Krper aus der 3D Datenbank verwendet werden soll, fiel die Wahl auf das GOCAD SGRID-Format. Die Nutzung von GOCAD zur Visualisierung der Daten ergab sich bereits aus der Verwendung der Software fr die Modellierung im Landesamt. Warum aber wurden SGRID s zur Abbildung gewhlt? Einfachere Formate beschreiben einen Krper nur indirekt ber seine Oberflche. Die GOCAD-Formate Surface und 2DGrid sind solche Flchenformate und bestehen beide aus miteinander vermaschten Polygonen. Ein Surface-Objekt besteht aus einer irregulren Dreiecksvermaschung (TIN). Da das Surface nicht zwingend eine geschlossene Flche bildet, knnen so bei der Abbildung ungltige Krper mit Lcken entstehen. Das 2DGrid hingegen weit ein regulres Gitter auf, das aufgrund seiner eingeschrnkten Punkteverteilung aber eher fr ein digitales Gelndemodell geeignet ist. Die Ober- oder Unterkante eines HGKs liee sich ebenso in einem 2DGrid beschreiben. Es ist als 2D-Vorstufe des SGRID-Formates anzusehen. Die Vorteile eines Volumenmodells (Volumenberechnung, Mengenoperationen) knnen so jedoch nicht genutzt werden. Beim 2DGrid lsst sich nicht unmittelbar bestimmen, ob ein Punkt auerhalb oder innerhalb des Krpers liegt. Es dient nur als Oberflchenabbildung von Volumenkrpern. Eine Zwischenstufe zwischen Flchen- und Volumenformaten ist das geschlossene Surface. Es besteht aus Dreiecken, die zusammen eine geschlossene Flche bilden mssen1. Mit einem solchen Modell ist dann eine Volumenberechnung mglich. hnlich verhlt es sich mit dem Format Model3D, welches ebenso aus Einzelflchen besteht. Ein Model3D besteht aus Regionen, die sich ihre Begrenzungsflchen teilen. Auf diese Weise knnen ebenso geschlossene Krper modelliert werden. berschneidungen von zwei Krpern sind so nicht mglich, da hinter der Oberkante des unteren Krpers und der Oberkante des unteren Krpers dasselbe Geometrieobjekt steckt.

1

Eine geschlossene Flche ist dann gegeben, wenn jede Dreieckskante auch zu zwei Dreiecken gehrt.


GOCAD-SGRIDs

23

Mchte man ein, aus Teilkrpern bestehendes, Volumenmodell eines Krpers erzeugen, so bietet GOCAD die Formate Solid, Stratigraphic Grid und Voxet. Diese unterscheiden sich in der Geometrie ihrer Teilkrper und der Topologie zwischen ihnen. Im Voxet-Format reduziert man die Geometrie der Teilkrper auf primitive 3D-Basiselemente, sogenannte Voxel. So werden die Algorithmen zur Aufstellung und Verarbeitung eines solchen Modells einfach, und dementsprechend weniger Probleme treten bei der Einhaltung der Konsistenz des Modells auf. Komplexe Geometrien mssen jedoch stark abstrahiert werden. Unregelmig geformte, stetige Krperoberflchen, lassen sich nicht ohne Abstraktion in einem, aus Voxeln bestehenden, Volumenmodell darstellen. Mit dem Voxet-Format wre nur eine treppenartige Struktur der Krperoberflche reprsentierbar, weshalb es fr eine Abbildung weniger geeignet ist. Einen Gegensatz dazu bildet das Solid-Format. Die Teilkrper sind dabei Tetraeder. Ein Tetraeder kann aus vier beliebig im Raum liegenden Punkten konstruiert werden. Es ist also keine homogene Aufteilung des Krpers in Teilelemente mit quadratischer Grundflche notwendig. Das Solid-Format stellt eine direkte Erweiterung der Idee der Dreiecksvermaschung in die dritte Dimension dar. Fr die Sulen in der Datenbank wrde eine Portierung in das Solid-Format eine weitere Zerlegung bedeuten. Jede Sule msste in sechs Tetraeder zerlegt werden. Vergleichen wir dies zum SGRID-Format, so wrde das entstandene 3D-Modell uerlich keine Unterschiede aufweisen. Das Solid-Modell ist jedoch als Vektormodell einzuordnen und besitzt demzufolge auch dessen Vor- und Nachteile. Neben der Zuordnung von Punkten zu Tetraedern sind keine weiteren Topologieinformationen in einem solchen Modell enthalten. Die Ober- und Unterkante lsst sich dagegen im SGRID-Modell aus den Indizes der Knoten rekonstruieren. Im Solid knnen solche Zell-Eigenschaften nur durch zustzliche GOCAD-Plug-Ins hinzugefgt werden, da GOCAD selbst keine Umfangreiche Funktionalitt zur Nutzung von Solids bietet. Das SGRIDFormat ist als hybrides Format zwischen Voxet und Solid anzusehen und weist die grten Gemeinsamkeiten mit dem Datenmodell der 3D-Datenbank auf. Zudem hat sich die Verwendung des Formates bei ersten Modellierungen im LfULG als zufriedenstellend erwiesen. Eine bersicht der Formate ist in Tabelle 5 zu finden. Eine weitergehende Einfhrung findet sich in [9].Format Surface Typ Flchenmodell Besonderheit Irregulres Gitter


GOCAD-SGRIDs

24

2DGrid Geschlossenes Surface Model3D Solid SGRID Voxet

Flchenmodell Flchenmodell Surface-Sammlung Volumenmodell Volumenmodell Volumenmodell

Regulres Gitter Geschlossene Krperoberflche Modell konsistent Tetraeder als Teilkrper Irregulre Oberflchen Voxel als Teilkrper

Tabelle 5: Formate zur Abbildung von Krpern in GOCAD

3.6.

Geocando- Formatuntersttzung

Als alternatives Visualisierungsprogramm soll der, an der TUBAF entwickelte, freie Viewer Geocando Verwendung finden. Geocando bietet die Mglichkeit neben den GOCADFormaten PointsSet, Curve, Surface, Well, Model3d, 2d-Grid, Voxet und Solid auch Dateien im SGRID-Format einzuladen und hnlich wie in GOCAD, diese in einer 3D-Szene zu visualisieren. Der Open Source Viewer wurde unter der GNU General Public Licence verffentlicht und nutzt zur Visualisierung das Visualization Toolkit [10]. Er wird dabei stndig weiter entwickelt und steht zurzeit in der Version 1.1 frei zur Verfgung. Die Untersttzung des SGRID-Formates lag bei der Entwicklung von Geocando nicht an vorderster Stelle, sodass einige Formatfeatures noch nicht untersttzt sind. Da es sich um eine OpenSource-Software handelt, ist jedoch eine Anpassung des Viewers an spezifische Aufgabenstellungen mglich. In der Tabelle 6 sind SGRID-Funktionalitten und ihre Implementierung in Geocando aufgelistet. Es ist zu entnehmen, dass Dead Cells fr die Visualisierung in Geocando nicht verwendet werden knnen. Ein Krper kann so nicht mit der Hilfe von Flags reprsentiert werden. Stattdessen stellt Geocando das gesamte, rechteckige SGRID dar. Ebenso kann der Krper nicht durch die Zuweisung seiner Zellen zu einer Krperregion visualisiert werden. Eine Mglichkeit SGRIDS dennoch in Geocando zu visualisieren sind Attribute (Abschnitt 3.3). Attributwerte knnen farblich aufgeschlsselt in Geocando eingeblendet werden, um so Krperzellen hervorzuheben. Neben den Attributen besteht noch die Mglichkeit tote Zellen dahingehend zu kennzeichnen, dass die Z-Werte dieser auf einen festen Wert gesetzt werden. Die festen Z-Werte gelten dann als NoDataValues, also Werte die keine echten Daten darstellen. Hydrogeologische Krper im SGRID-Format knnen also in Geocando nur bedingt visualisiert werden. Im Rahmen der Entwicklung einer Exportschnittstelle kann deshalb keine volle Funktionalitt der erstellten


GOCAD-SGRIDs

25

Daten fr Geocando gewhrleistet werden. Um eine Darstellung der SGRIDs hnlich der in GOCAD zu erreichen, sollten die in Tabelle 6 gelisteten Merkmale deshalb nachgerstet werden. Weitere Informationen zur Formatuntersttzung von Geocando finden sich in [11].Merkmal Einladen von SGRID-Dateien Visualisierung der SGRID-Sttzpunkte Visualisierung der SGRID-Zelloberflchen Visualisierung von SGRID-Attributwerten Einlesen von Flag-Werten des SGRIDS aus einer Flag-Datei. Untergliederung des SGRIDs in Regionen (Region-Flags) Bereits Implementiert Ja Ja Ja Ja Nein Nein

Tabelle 6: SGRID-Untersttzung im Open Source Viewer Geocando


Vorgehen bei der HGK-Abbildung

26

4. Vorgehen bei der HGK-AbbildungHauptaufgabe bei der Umsetzung des Export-Moduls ist der Entwurf eines Algorithmus zur HGK-Abbildung vom 3DGDB-Modell ins SGRID-Modell. Ausgehend von den Erluterungen des SGRID-Formates wird nachfolgend auf die Verwendung der Format-Features eingegangen, um die in der Datenbank mglichen Krpergeometrien abzubilden.

4.1. Abbildung von senkrechten KantenIn Abschnitt 2.3 wurde erlutert, wie in der Realitt vorkommende hydrogeologische Krper in der 3D-Datenbank abstrahiert werden. Bei dieser sulenbasierten Speicherung liegen fr die Begrenzung eines Krpers bis zu vier Datenpunkte pro XY-Koordinate an. Dies ermglicht senkrechte Kanten zwischen zwei benachbarten Zellen. Damit mssen Krperoberflchen keinen kontinuierlichen Verlauf aufweisen. Im SGRID lsst sich diese Problematik prinzipiell auch lsen, jedoch sind dabei einige Dinge zu beachten.

Abbildung 13: SGRID mit senkrechten Kanten. a) Aufriss; b) perspektivische Darstellung

Betrachten wir einen Ausschnitt eines Krpers mit jeweils zwei Sulen (-abschnitten) in Xund Y-Richtung. Mchten wir diese Daten in ein SGRID transformieren, werden daraus in der XY-Ebene nicht vier, sondern neun Zellen. In Abbildung 13a ist dieser Fall im Aufriss abgebildet. Der gleiche Krper ist in Abbildung 13b als perspektivische Darstellung zu sehen. Die Geometriedaten jedes Sulenabschnitts aus der 3D-Datenbank resultieren im SGRID in acht Knoten mit den Koordinaten der acht Ecken des Sulenabschnitts. Geht man nun alle



27

abzubildenden Sulenabschnitte durch, werden im SGRID Knoten erstellt , die die gleichen Koordinaten besitzen. Betrachten wir den Normalfall, so besitzt der Krper eine kontinuierliche Oberflche und es liegen innerhalb des Grids auf jeder Koordinate vier Knoten, die im SGRID zu einer Zelle ohne Volumen verbunden werden. Dies liegt daran, dass die aufeinander liegenden Punkte miteinander verbunden werden. Solche

Nullvolumenzellen ermglichen letztendlich die Abbildung der senkrechten Kanten und damit Diskontinuitten auf der Krperoberflche. Nachteil ist, dass die mehrfach vorhandenen Knoten im entstehenden SGRID-Modell redundant gespeichert werden mssen. Auf diese Weise wird jedoch eine rechenaufwendige Nachbarschaftsbetrachtung zwischen den Sulenabschnitten vermieden. Alle Datenpunkte knnen eins zu eins in SGRIDKnoten bertragen werden, ohne dabei die Geometrie zwischen benachbarten Sulen betrachten zu mssen. Da dieser Sachverhalt wichtig fr das Verstndnis des gesamten SGRID-Formates ist, betrachten wir die Knotensetzung fr das genannte Beispiel genauer. In Tabelle 7 sind die Knoten des SGRIDS mit ihren Indizes aufgelistet. Zur Vereinfachung wurden die Knoten der Unterkante nicht mit aufgelistet. Welche Knoten zu welchen Zellen verbunden werden, ergibt sich aus der bereits in Abschnitt 3.1 erluterten Vorschrift. Betrachten wir die Knoten der Zelle 1, zeigt sich, dass diese auf vier unterschiedlichen Koordinaten liegen. Sie spannen zusammen ein Rechteck auf und ergeben zusammen mit den Knoten der Unterkante eine Zelle mit Volumen. Zelle 5 hingegen baut sich aus Knoten mit der gleichen Koordinate auf. In Abbildung 13 ist diese Zelle im Zentrum des SGRIDs und ergibt zusammen mit den Unterkantenknoten eine Zelle ohne Volumen in Form einer Linie. hnlich verhlt es sich bei Zelle 6, die nur zwei unterschiedliche XY-Koordinaten besitzt. Wieder wird daraus eine Zelle ohne Volumen generiert. Sie uert sich im SGRID in Form einer Ebene. Das im Beispiel abgebildete SGRID besitzt also nicht vier, sondern neun Zellen. Vier davon sind tatschliche Abbildungen von Sulenabschnitten aus der Datenbank.



28

Knoten(OK)30 10 45 0 0 0 20 10 45 1 0 0 20 10 30 20 20 10 30 20 20 10 30 20 10 10 20 20 20 20 20 20 20 20 30 30 40 30 45 45 37 30 50 50 40 40 50 40 2 3 0 1 2 3 0 1 2 3 0 1 0 0 1 1 1 1 2 2 2 2 3 3 0 0 0 0 0 0 0 0 0 0 0 0

Zugehrigkeit

Zelle

Abbildung (OK+UK)

12 3 4

Zellkrper

5Linie

67 8 9

20 30 40 2 3 0 10 30 43 3 3 0

Ebene

Tabelle 7: SGRID-Knotenaufbau und Zellgenerierung

Das SGRID-Format bietet darber hinaus eine weitere Mglichkeit, Diskontinuitten innerhalb eines Krpers abzubilden. Bei der Einarbeitung von Strungen in ein SGRID, kann dieses Anhand einer Strungsflche zerschnitten werden. Die Beziehung zwischen zwei vorher verbundenen Nachbarzellen kann so aufgelst werden. Hierfr ist es mglich, die Knoten an solchen Stellen durch Split Nodes neu zu definieren. Der folgende Befehl generiert so einen Split Node:SPLIT U V W X Y Z id Cell(u,v,w) Cell(u-1,v,w) Cell(u,v-1,w) Cell(u-1,v-1,w), Cell(u,v,w-1) Cell(u-1,v,w-1) Cell(u,v-1,w-1) Cell(u-1,v-1,w-1)

Dies bedeutet am Knoten mit den Indizes U, V, W wird ein Split Node eingefgt, der die Koordinaten X, Y, Z besitzt. Nachfolgend wird durch boolesche Variablen die Verknpfung dieses Knotens mit den Nachbarzellen festgelegt. Vorteil dieser Methode ist, dass hier Mehrfachknoten pro Koordinate nur auftreten wo dies auch notwendig ist. Ein Problem ist jedoch, dass Verwerfungen innerhalb hydrogeologischer Krper in der 3DGDB nicht direkt erkennbar sind. Der Versatz, der zwischen zwei Sulenabschnitten auftreten kann, lsst sich nur durch Analyse der Nachbarschaft der gerade zu betrachtenden Sule feststellen. Die Hhenwerte mssen fr jede Sule verglichen werden und Split Nodes an den entsprechenden Stellen eingefgt werden. Eine mglichst allgemeingltige Nutzung dieser



29

Split Nodes bei der SGRID-Generierung ist, gerade wenn wir komplexere Krper betrachten, nur schwer umzusetzen. Der Analyseaufwand bei der Generierung der SGRIDs ist aufgrund der Nachbarschaftsbetrachtungen im Vergleich zur Variante mit redundanten Knoten ungleich hher. Eine weitere Mglichkeit wre es, die Eckknoten der Sulenabschnitte nur dort doppelt abzubilden wo es auch ntig ist. hnlich wie bei den Split Nodes mssen dabei die Nachbarsulen untersucht werden und die Hhenwerte mit der gerade abzubildenden Sule verglichen werden. Zudem muss dann fr die gesamte XZ- oder YZ-Ebene eine Knotenschicht eingefgt werden. Die senkrechte Kante (Strung) zieht sich in der Regel jedoch nicht achsenparallel durch den Krper, sodass je nach Durchlauf pro Y-Zeile oder pro X-Zeile die Ebenen mit doppelten Knoten beim Exportvorgang verwaltet werden mssten. Der Vergleich eines Krpers mit senkrechter Kante mit einem darunter liegenden Krper ohne senkrechte Kante ist bei dieser Variante nicht mehr zwingend mglich. Auch bei dieser Mglichkeit wre eine rechenaufwendige Nachbarschaftsanalyse notwendig, die vermieden werden sollte. Da bei der Abbildung die Gre der entstandenen SGRIDs keine besondere Prioritt hat, wurde sich deshalb fr die redundante Abbildung der Knoten entschieden.

4.2. Abbildung komplexerer GeometrienEine weitere Schwierigkeit bilden komplexe Krper mit gestrten Schichtverlufen. Gespeichert werden solche Krper mit Hilfe von mehreren Sulenabschnitten in einer Sule. Es liegt zunchst nahe jeden Sulenabschnitt aus der Datenbank als Zelle im SGRID darzustellen. Problem hierbei ist erstens die feste Verknotung der SGRID -Gitterpunkte, zweitens die feste Anzahl an Knoten pro Knotenebene. Im SGRID mssen bei solchen Krpern weitere horizontale Knotenebenen eingefhrt werden.



30

Abbildung 14: Beispielkrper im Schnitt.

In Abbildung 14 und Abbildung 15 ist der gleiche Krper in der 3D-Datenbank und dessen Abbildung in einem SGRID abgebildet. Der dargestellte Krper wurde aufgetrennt und bereinander geschoben. In Sule 3 berlappt der Krper sich deshalb. In der 3D-Datenbank sind dies zwei Eintrge in der Sulenabschnittstabelle, die zum selben Krper und zur selben Sule gehren. Die Information, dass die Schicht zunchst mit Sulenabschnitt SA1S3 endet und in derselben Sule durch Sulenabschnitt SA2S3 fortgesetzt wird, befindet sich nur indirekt in der Datenbank. Diese Beziehung lsst sich nur durch Koordinatenvergleich ermitteln. Bei der berfhrung des Krpers in das SGRID-Modell muss die Lage einer Zelle im Gesamtgitter jedoch durch Gitterindizes angegeben werden. Durch die Einfhrung zustzlicher Zellschichten kann dieses Problem gelst werden. Abbildung 15 zeigt, dass fr diesen Krper drei SGRID-Zellschichten notwendig sind.

Abbildung 15: Abbildung des Krpers aus Abbildung 14 im SGRID-Format.

Betrachten wir Sule 3 genauer, zeigt sich, dass sich die zwei bereinander liegenden Sulenabschnitte nicht durch zwei Zellen reprsentieren lassen. Der Freiraum zwischenChristian Bertram Schnittstellen fr eine Landesweite 3D-Datenbank


31

beiden tatschlichen Krperteilen muss ebenso durch eine Zelle reprsentiert werden. Die Zelle wird dann durch die Markierung als DeadCell zum Zwischenraum erklrt. Nutzen wir also fr die Abbildung sechs Knotenschichten, lassen sich daraus drei Zellschichten generieren. Setzten wir die Zwischenzelle auf tot, lsst sich so auch ein solcher Krper abbilden. Denken wir weiter, knnen so nahezu beliebig komplexe Krper im SGRID-Format abgebildet werden. Es ist dazu notwendig die maximale Anzahl an Zellschichten vor der Generierung des SGRIDs zu kennen. In den Sulen an denen der Krper normal verluft und nur eine Zelle bentigt, werden die Zellschichten an die Krperunterkante herangelegt. In Abbildung 15 tritt dies in den Sulen eins bis zwei und vier bis sechs auf. Diese Zellen knnen als Dead Cells markiert werden. Sie sind ohne Mchtigkeit und haben auf die SGRIDVolumenberechnung keinen Einfluss.


Schnittstellen-Entwurf und Implementierung

32

5. Schnittstellen-Entwurf und ImplementierungGeht es bei der Entwicklung einer Software primr um die Bereitstellung einer Nutzerschnittstelle, so spielt diese auch beim Entwurf eine zentrale Rolle. [12] hat hierzu ein Interaktionsmodell aufgestellt (vgl. Abbildung 16). Es zeigt, was eine Nutzerschnittstelle leisten soll. Bezogen auf die GOCAD-Schnittstelle, stellt diese die Export-Funktionalitt dem Anwender bereit und ermglicht eine Interaktion durch Beeinflussung der Exportdaten und Parameter. Sie verwaltet Eingabe- und Ausgabedaten und stellt diese dem Nutzer und den anderen Programmteilen zur Verfgung. Eingabedaten (Input) fr die GOCAD-

Exportschnittstelle sind, neben den eigentlichen Geodaten, die Exportkoordinaten und optional Filterkriterien und Exportparameter. Ausgabedaten (Output) sind die generierten 3D-Daten in Form von SGRIDs. Die Aufgaben beim Export teilen sich dabei in die Aktionen des Anwenders und die vom Computer auf Anfrage des Nutzers durchgefhrten Funktionen. Welche konkreten Funktionen in der Schnittstelle implementiert werden mssen, wird im nchsten Abschnitt erlutert.

Abbildung 16: Interaktionsmodell nach Norman

5.1. FunktionsumfangAusgehend von der Aufgabenstellung bereitzustellenden Funktionen (Anhang A), wurden die vom Programm Bei diesem aufgabenorientierten

herausgearbeitet.

Softwareentwurf werden zunchst die gestellten Aufgaben formuliert, die dann die Grundlage der Entscheidung bilden, welche Funktionen die Software erfllen muss (vgl. [13]). Abbildung 17 zeigt die Anwendungsflle die sich daraus ableiten lassen. Ziel des



33

Nutzers bei der Verwendung der GOCAD Exportschnittstelle des FIS Hydrogeologie ist allgemein der 3D-Daten-Export. Hierfr ist immer eine rumliche Einschrnkung des Exportgebietes notwendig, im Diagramm durch den Anwendungsfall Gebietsauswahl enthalten. In der eigentlichen Schnittstelle beinhaltet der Export immer die Gebietsabfrage und optional eine Filterung der HGKs. Ist der Export durchgefhrt, kann darauf die Visualisierung der Export-Daten folgen. Dies geschieht unabhngig von der ExportSchnittstelle, kann aber durch Kopplung von Export und Visualisierung miteinander verzahnt werden.

Abbildung 17: Use-Case-Diagramm fr den 3D-Daten Export aus FHYG

Leiten wir hieraus die Funktionen der Schnittstelle ab, sehen diese aus Anwendersicht wie folgt aus:

Parametrisierter Anwendungsaufruf in ArcMap

Das Exportwerkzeug soll in die FHYG ArcMap-Toolbar integriert werden. ArcMap dient hierbei zur Anzeige der im FIS Hydrogeologie gespeicherten GIS-Daten, die als Layer in ArcMap eingeblendet werden knnen. Die GIS-Daten umfassen unter anderem die Verbreitungs- und Ausstrichflchen der hydrogeologischen Krper als Polygone. Das Exportgebiet wird mit Hilfe der GIS-Daten durch den Nutzer eingeschrnkt. Hierfr ist die Integration eines Werkzeuges zum Aufziehen des Exportgebietes notwendig. Ist das Gebiet festgelegt, werden die Eckkoordinaten an die Nutzeroberflche der Exportschnittstelle bergeben. Hinzu kommen weitere allgemeine Parameter. (Verbindungsinformationen, Version, )



34

Gebietsanalyse

Der Nutzer muss die Mglichkeit haben, Informationen ber die im Gebiet liegenden 3DDaten abfragen zu knnen. Hierzu zhlen vor allem die im Gebiet liegenden hydrogeologischen Krper, die Einheiten, zu denen die Krper gehren und welche und wie viele Daten fr diese Krper im Gebiet vorliegen. Dabei ist auch eine Analyse der Kantenlngen im Gebiet notwendig. Der Nutzer soll anhand dieser Informationen weitere Entscheidungen treffen knnen und kann diese Informationen fr alle im Gebiet liegenden Krper ansehen. Der Nutzer soll gewarnt werden, falls das Auswahlgebiet sehr gro ist oder keine Daten im Auswahlgebiet vorhanden sind. Die kritische Datengre soll ebenfalls konfigurierbar sein. Filterung

Falls der Nutzer es wnscht, soll eine Filterung der im Gebiet liegenden hydrogeologischen Krper mglich sein. Das bedeutet, es kann anhand einer HGK-Auflistung die Selektion und Deselektion der HGKs fr den Export durchgefhrt werden. Der Nutzer kann sich dabei vor der Gebietsabfrage fr die Filterung entscheiden. Die zu exportierenden Krper knnen dann fr den Export ausgewhlt werden. Die Auswahl soll mglichst benutzerfreundlich geschehen. Informationen ber die 3D-Daten im Gebiet sollen dem Nutzer dabei untersttzen. Export-Konfiguration

Der Nutzer kann das Exportverzeichnis selbst whlen. Der Ordnername fr die Exportdateien kann von ihm festgelegt werden. Er kann Konfigurationen vornehmen, die die Struktur der SGRIDs beeinflussen. Die Standard-Einstellungen fr den Export lassen sich ber eine, vom Administrator editierbare Konfigurationsdatei ndern. GOCAD und Geocando-Kopplung

Der bergang von der Generierung der SGRIDS zur Visualisierung in GOCAD soll auf einfache Weise ohne viele Zwischenschritte erfolgen. Beim Export knnen dabei optional GOCAD- und Geocando-Projektdateien erzeugt werden. Die erstellten SGRID-Dateien werden ber Befehlsfolgen in den Projektdateien oder Scripten im entsprechenden Programm eingeladen. Exportoptionen: Gelndeoberkante, SGRID-Schnitte



35

Es soll eine Erzeugung von weiteren SGRIDs mglich sein, die nicht das eigentliche HGKVolumen darstellen. Ist die Option aktiviert, wird ein SGRID mit der Gelndeoberkante erstellt. Des Weiteren kann fr jeden Krper ein Schnitt-SGRID erstellt werden. Dieses hat eine Kreuzform und zeigt so den Mittelpunkt des Auswahlgebietes mit zwei rechtwinklig zueinander liegenden Schnitten.

5.2. Varianten und ZusatzoptionenDie Abbildung der SGRID-Krper wird, wie bereits in Kapitel 3 beschrieben, ber die Zuweisung eines Flag-Wertes zu den Knoten realisiert. Eine solche Flag-Variable kann nur zwei verschiedene Werte annehmen. Der eine Zustand markiert die Zugehrigkeit zum Krper, der andere den Ausschluss. Nun knnen diese Zustnde durch Dead Cells, die Erzeugung einer SGRID-Region, ein Property oder die Manipulation der Hhenwerte des SGRID-Krpers visualisiert werden. Im Programm werden dem Anwender alle vier Mglichkeiten bereitgestellt. Standard soll dabei die Visualisierung durch Dead Cells sein, da diese in GOCAD die optimalste Lsung darstellen. Das SGRID stellt so, ohne die Verwendung anderer SGRID-Features, den eigentlichen Krper dar. Fr den Anwender sind keine weiteren Arbeitsschritte fr die Visualisierung und Weiterverarbeitung notwendig. Werden die Flag-Werte in einer Region gespeichert (zweite Option), wird die SGRID-Konfiguration so angepasst, dass GOCAD nach dem Einladen die Region darstellt. Alle nicht zur Region gehrenden SGRID-Zellen lassen sich ber das SGRID-Volume einblenden. Die Z-Werte dieser Zellen werden auf einen konstanten Wert gesetzt. Wird die Option Property gewhlt, werden die Zustnde als Attributspalte in die Knotendatei geschrieben. Das Property besitzt dann nur die Werte null und eins. Visualisiert man dieses, ist der eigentliche Krper sichtbar. Diese Variante ist vor allem fr Geocando gedacht. Die ersten beiden Varianten bieten zwar bessere Lsungen, werden aber derzeit von Geocando nicht untersttzt (siehe Abschnitt 3.6). Als vierte Mglichkeit bietet sich das Setzen der Hhenwerte von Knoten, die nicht zum Krper gehren, auf einen festen Wert. Dabei ist keine Flag-Datei oder eine zustzliche Attributspalte notwendig. Der Wert liegt standardmig bei -200 Metern, kann aber in einer Konfigurationsdatei angepasst werden. Diese Variante ist ebenso fr die Visualisierung in Geocando entwickelt.



36

Des Weiteren existiert eine Wahlmglichkeit zwischen der Einstellung Visualisierung und Weiterverarbeitung. Die Option ist notwendig, da den in Kapitel 4 beschriebenen Zwischenzellen ohne Volumen korrekte Flag-Werte zugewiesen werden mssen. Diese sind bei der Weiterverarbeitung des SGRID von Bedeutung. Wird die Option Visualisierung gewhlt, werden die Krper zwar korrekt abgebildet, die Flag-Werte sind jedoch teilweise falsch. Fr die Visualisierung spielt dies keine Rolle, die Krper werden alle Korrekt angezeigt. Whlt der Anwender die Option Weiterverarbeitung, werden die Flag-Werte bereinigt und das SGRID kann so auch korrekt weiterverarbeitet werden. Dies erfordert zustzliche Analysen der Sulennachbarschaften und erzeugt bei komplexeren Krpern aufgrund fehlender Information ber die Schichtverlufe teilweise falsche Flags. Deshalb wurde es dem Anwender berlassen, welche Option fr ihn die besseren Ergebnisse liefert. Geht es beim Export lediglich um die Visualisierung, so kann der Export mit der Standardeinstellung Visualisierung durchgefhrt werden. Zur Untersttzung des Anwenders bei der Analyse des Auswahlgebietes wurde zudem die Mglichkeit implementiert, SGRID-Schnittdateien zu erzeugen. Diese werden pro Krper erzeugt und setzen sich aus einem Ost-West und einem Nord-Sd-Schnitt zusammen. Die Schnitte sind senkrecht und kreuzen sich im Mittelpunkt des Auswahlgebietes. Hierfr werden die Flag-Werte so verndert, dass nur die Zellen die auf den Schnitten liegen auf true gesetzt werden. Dies bietet dem Nutzer eine Sicht in das Innere des Auswahlblocks, denn oftmals ist die Schichtung an einer konkreten Koordinate von Interesse. Es kann also sein, dass der Nutzer sich fr den Mittelpunkt des Auswahlgebietes interessiert, weil dieser zum Beispiel fr eine potentielle Bohrung in Frage kommt. Einen hnlichen Weg geht die 3DModellierungssoftware GSI3D, bei der der Nutzer senkrechte Schnitte aus den Eingangsdaten erzeugen und das entstandene Modell in einem sogenannten fence diagram darstellen kann (vgl. [14]).

5.3. ExportdatenAus den Anforderungen heraus ergeben sich die Daten, die bei der Durchfhrung des Exports erzeugt werden. Ziel ist es, Dateien zur erzeugen, die von GOCAD und Geocando



37

genutzt werden knnen. Folgende Daten fallen dabei pro exportiertem Krper pro Kantenlnge an:Datei SGRID-Headerdatei (*.sg) SGRID-Headerdatei Schnitt (*.sg) HGK-Knotendatei (ohne Endung) HGK-Flagdatei (ohne Endung, binr) HGK-Flagdatei Schnitt (ohne Endung, binr) Einschrnkung falls aktiviert bei Option Region oder DeadCell falls aktiviert

Tabelle 8: SGRID-Dateien pro HGK pro Kantenlnge.

Diese Daten fallen bei drei unterschiedlichen Kantenlngen also auch dreimal an. Hinzu kommen die gleichen SGRID-Dateien fr die Gelndeoberkante (ohne Schnittdateien), falls der Export fr diese aktiviert ist. Weitere beim Export optional erstellbaren Dateien sind in Tabelle 9 gelistet.Datei GOCAD-Projektdatei GOCAD-Projektordner Geocando-Projektdatei GOCAD-Ladescript GOCAD-Ladescript - Schnitte Logdatei Typ Xml-basiert, *.gprj - Templateprojekt control, data, projekt Templatedateien XML-basiert, *.gtp Befehlsauflistung, *.gsc Befehlsauflistung, *.gsc ASCII-Datei, *.txt2

Tabelle 9: Optionale Exportdaten

Um eventuelle Fehlermeldungen die beim Export entstehen, zu dokumentieren, wird eine Logdatei angelegt. Diese listet die exportierten Dateien und das Exportgebiet auf. Eine Fehlerbehebung wird so vereinfacht. Fr die lose Kopplung der Export-Schnittstelle an GOCAD und Geocando werden Projektdateien erstellt. Da fr den direkten Aufruf mehrerer SGRID-Dateien in Verbindung mit dem ffnen einer Projektdatei keine direkte Lsung gefunden werden konnte, knnen zustzlich GOCAD-Skripte generiert werden. Listing 1 zeigt ein solches Script. Es enthlt, neben den Befehlen zum Einladen der SGRID -Dateien, auch Befehle zur Konfiguration der Kamera. Fr Geocando hingegen, wird eine Pro jektdatei angelegt, die das ffnen der exportierten SGRID-Dateien impliziert.

2

Diese Dateien sind notwendig fr das Anlegen eines neuen GOCAD-Projektes. Sie befinden sich im

Projektordner, der im selben Verzeichnis wie die Projektdatei liegen muss.



38

gocad load File_names "C:\...\HYE_18050_hgk_2134_KL50.sg" gocad load File_names "C:\...\HYE_20000_hgk_2166_KL50.sg" gocad load File_names "C:\...\HYE_55705_hgk_2178_KL50.sg" gocad load File_names "C:\...\GOK_KL50.sg" gocad on Camera "Camera#0" autosetup gocad on Style Camera3d.Camera#0 gocad update all cameras set attribute "*scaling*z" value "10" gocad on Style Camera3d.Camera#0 update

Listing 1: GOCAD-Script

5.4. EntwicklungsumgebungFolgende Software wurde whrend der Konzeption und Implementierung der

Exportkomponente der ArcMap-Extension herangezogen: Oracle 11g als Datenbank des FIS Hydrogeologie Zugriff auf das FHYG-Datenbankschema ber den SQL Developer (v2.1) von Oracle Microsoft Visual Studio 2008 mit C# als Programmiersprache Das .NET Framework in der Version 3.5 ArcGIS 9.3.1 mit installierter FHYG-Erweiterung zum Testen der Schnittstellenintegration in ArcMap Das FHYG.GIS Projekt fr das Testen der Export Komponente im Debug-Modus Gocad 2009.3 und Geocando 1.1 fr die berprfung der entstandenen Exportdateien

5.5. SoftwarearchitekturDie Architektur der Software besteht aus vier Bestandteilen, die unterschiedliche Aufgaben wahrnehmen (Systembersicht siehe Abbildung 18). Die Subkomponenten sind zudem in einem Paket FHYG.Export zusammengefasst. Das Paket liegt im kompilierten Zustand als Dynamic Link Library (DLL) vor und kann so in das Fachinformationssystem Hydrogeologie integriert werden. Die Kommunikation zwischen der Export-Komponente und dem restlichen System erfolgt einseitig in Richtung der Export-Komponente. Das GUI-Paket enthlt dabei die Nutzeroberflche. Die Nutzereingaben werden dort entgegen genommen. Die Informationen zu den im Gebiet liegenden 3D-Daten werden im Paket HGKDaten gehalten und mit den im Paket DBAdapter enthaltenen Klassen abgefragt. Vorgenommene Export-Einstellungen werden hingegen im GocadExport-Paket gespeichert. Hier befinden sich auch die ExportFunktionen fr die Durchfhrung der SGRID-Abbildung.



39

Abbildung 18: Paketdiagramm fr das Export-Tool

5.6. Analyse der GebietsdatenEin wichtiger Teil fr die Vorbereitung der SGRID-Erstellung ist die Analyse des Auswahlgebietes und der Krperdaten im Exportgebiet. Im Paket HGKDaten werden diese Informationen verwaltet und spter im Exportvorgang bereitgestellt. Die enthaltenen Klassen sind in Abbildung 19 dargestellt.

Abbildung 19: Paket HGKDaten

In jeder Instanz der HGE-Klasse befinden sich Informationen zu einer im Exportgebiet vorkommenden Einheit. Hierzu zhlen die HYE-Nummer, die ID der Einheit in der Datenbank und ihr voller Name. Jede Einheit enthlt eine Liste mit HG K-Objekten mit den Krpern, die zur Einheit gehren. Fr jede Einheit und jeden Krper werden die Koordinaten der umgebenden Bounding Box separat pro vorkommende Kantenlnge gespeichert. Ein Array verwaltet die ntigen Flag-Werte fr die Sulendaten des Krpers in diesem Gebiet. Eine bool-Variable in der HGK-Klasse dient zur Auswahl der Krper fr den Export. Die Daten werden teilweise direkt nach der Gebietsabfrage ermittelt, teilweise erst nach der Filterung. So vermeidet man berflssige Abfragen fr Krper die nicht exportiert werden sollen. Die



40

Abfolge der Gebietsanalyse ist in Abbildung 20 dargestellt. Als Eingangsdaten dienen dabei die Koordinaten der oberen linken und unteren rechten Ecke des Exportgebietes. Sind Exportdaten in dem Gebiet, werden die HGEs im Gebiet abgefragt. Anschlieend wird fr jede HGE die HGK-Liste gefllt und die Verbreitungsgebiete der HGK ermittelt. Die Verbreitungsgebiete werden, bei der Filterung durch den Nutzer, nur fr die ausgew hlten HGK ermittelt. Die Liste der Einheiten wird in einem GocadExportData-Objekt im GocadExport-Paket angelegt.

Abbildung 20: Aktivittsdiagramm fr die Gebietsanalyse.

5.7. DatenbankzugriffFr die Abfrage von Datenbank-Daten ist die Klasse DBAdapterClass im Paket DBAdapter (siehe Abbildung 21) zustndig. Die Klasse ist statisch und ist somit ohne Instanziierung whrend der Laufzeit fr die anderen Pakete verfgbar. Bei Start der FHYG.ExportKomponente wird die Oracle-Datenbankverbindung an diese Klasse bergeben. Aus dieser wird der notwendige OracleCommand fr die Ausfhrung der Select-Anweisungen generiert. Die Select Klasse hilft bei der Aufstellung der Abfrage-Strings, indem dieser die Einzelteile fr die Filterung nach HGK, HGE, Kantenlnge und/oder X-, Y- oder XY-Koordinaten bereitstellt. Die Namen der Datenbank-Tabellen und Spalten sind hartkodiert aber zentral in den Enumerationen FHY3DTbl, HGKSaeule und Saeule gelistet. Dies erleichtert das Warten des Quellcodes ungemein, da Informationen und Befehle im Quellcode voneinander getrennt sind. Die meisten Anpassungen lassen sich so durch die nderung einer Funktion in der Select-Struktur oder in den Enumerationen durchfhren. Fr den Export werden die Tabellen FHY_3D_SAEULE und FHY_3D_HGK_SAEULE verwendet. Die Verknpfung zur Sachdatenbank



41

fr

den

Abruf

der

HGE-Informationen

geschieht

ber

den

Datenbank-View

FHY_VW_MT_HGE. Die drei mglichen Kantenlngen werden der bei den Funktionsaufrufen als Parameter bergebenen Enumeration KL entnommen. Inserts oder Updates sind nicht vorgesehen, die Klasse ist deshalb nur zum Lesen, nicht zum Schreiben in die Datenbank konzipiert.

Abbildung 21: Paket DBAdapter

5.8. SGRID-Export5.8.1. Export-Parameter Die Export-Einstellungen mssen zentral verwaltet werden. Dabei wird zwischen SGRIDspezifischen Exporteinstellungen und der global gltigen Konfiguration unterschieden. Erstere werden fr das SGRID, das gerade generiert werden soll, in einem Objekt der Klasse ExportParams zwischengespeichert (siehe Abbildung 22). Die Klasse enthlt die in Tabelle 10 aufgelisteten Variablen. Sie werden aus den, bei der Gebietsanalyse abgefragten, HGK- und HGE-Daten ermittelt. Volumen- und Gridfarbe ergeben sich aus der Symbol-Spalte aus der Datenbank, welche mindestens einen, maximal zwei RGB-Farbwerte besitzt, die auch bei der Zeichnung des Krpers im Schnitt verwendet werden. Diese Einstellungen sollen dem Nutzer eine Unterscheidung der SGRIDs und eine Zuordnung dieser zu den Krpern und Einheiten im FIS Hydrogeologie erleichtern.



42

Abbildung 22: Paket GocadExportVariable Color Dim3D GridColor Name NumPoints sgridType Bedeutung Farbe des SGRID-Volumens Anzahl der Knoten des SGRIDS in X-,Y-,Z-Richtung Farbe des SGRID-Gitters Name des SGRIDs Gesamtzahl der Knoten SGRIDType des SGRIDs (Enumeration)

Tabelle 10: SGRID-Exportvariablen

Alle brigen vom Nutzer vernderbaren Variablen werden in der statischen Klasse ExportConfig verwaltet. Hierzu zhlen die gesetzten Export-Einstellungen. Die Einstellungen werden dann bei der SGRID-Generierung berprft, sodass nur die Dateien erzeugt werden, die der Anwender wnscht. Die Namensbestandteile fr die Export-Dateien und die Standard-Werte befinden sich in String-Variablen, die aus der XML-Konfigurationsdatei gelesen werden.Typ Export-Einstellungen Variablen ExportCross, ExportGeocandoPrj, ExportGocadPrj, ExportGocadScript, ExportGOK, ExportLog, ExportPath, InstallPath, PostProcessing, SGRIDOption str_cross, str_flags, str_geocandoPrj, str_gocadPrj, str_gok, str_loadScript, str_points, str_region NoDataZValue, PropName, RegionName, StandardColor, StandardGridColor

Dateinamen Standard-Werte

Tabelle 11: Globale Exportvariablen der ExportConfig-Klasse

5.8.2. SGRID-Datengenerierung In Kapitel 4 wurde bereits erlutert, wie die Abbildung der HGKs im SGRID-Format umsetzbar ist. Dafr zustndig ist im Export-Tool die Klasse GOCADExportFunctions. Alle ntigen



43

Funktionen sind in dieser statischen Klasse enthalten. In Abbildung 23 sind die am Exportvorgang beteiligten Klassen mit Navigationsrichtung dargestellt. GOCADExportData ist der Startpunkt fr die Exportprozeduren. Die darin enthaltene Funktion ExportToSGRIDs() wird aus dem GUI-WindowsForm heraus durch den Export-Button aufgerufen. In dieser Funktion werden die HGK-SGRIDs in einer Schleife separat voneinander erzeugt. Fr jeden HGK, der fr den Export ausgewhlt wurde, generiert das Programm pro Kantenlnge ein SGRID mit den zugehrigen Dateien. Dafr wird die Funktion HGKExport() aufgerufen und die HGK-Daten, die Kantenlnge und das Auswahlgebiet werden als Parameter bergeben. Fr die SGRID-Generierung wird eine ExportParams-Instanz angelegt und mit den HGK-Daten gefllt. Die SGRID-Knotengenerierung erfolgt dann durch Aufruf der Funktion

WriteHGKPointFile(). Die Knoten werden als Liste zurckgegeben, da diese fr die Erstellung der Flagdatei bentigt werden. Falls die Option DeadCell oder Region als SGRIDOption gewhlt ist wird anschlieend die Flag-Datei erzeugt. Ist die Schnittgenerierung aktiviert, wird pro HGK ein weiteres SGRID erstellt. Die Punktdaten bleiben dabei gleich, die Flag-Daten werden jedoch neu bestimmt. Der Export-Ablauf ist als bersicht noch einmal in Anhang B als Sequenzdiagramm modelliert.

Abbildung 23: Klassendiagramm - Export

Die eigentliche Knotengenerierung ist in Abbildung 24 detaillierter aufgezeigt. Das Gebiet wird dabei pro Sule durchlaufen. Die Positionen der Knoten des zu erzeugenden SGRIDs lassen sich aus dem HGK-Gebiet und der Kantenlnge ermitteln. Vorher werden die FlagWerte bestimmt. Sie sind fr die berprfung notwendig, ob fr die Koordinaten Sulendaten und speziell Sulenabschnitte fr den Krper existieren. Die Knoten werden dann fr jede Sule zunchst fr jeden X-Wert pro Zeile mit gleichem Y-Wert erzeugt. Der YChristian Bertram Schnittstellen fr eine Landesweite 3D-Datenbank


44

Wert wird dann um die Kantenlnge verringert und die nchste Zeile wird bearbeitet. Das heit, die Sulenabschnitte werden pro Sule (pro XY-Koordinate) abgefragt. Zuvor wurde ermittelt wie viele Sulenabschnitte pro Sule fr diesen Krper in diesem Auswahlgebiet maximal existieren. Dementsprechend viele SGRID-Schichten werden erzeugt. Die abgefragten Sulenabschnitte werden dann von oben nach unten sortiert und in SGRIDKnoten umgewandelt. Diese werden in einer Liste von ASCIIRow-Strukturvariablen angehngt. Die Struktur ist in Abbildung 23 gelistet. Sind alle Koordinaten durchlaufen, werden die Knoten in dieser Liste sortiert und von der Funktion zurckgegeben.

Abbildung 24: Aktivittsdiagramm SGRID-Knotengenerierung

5.8.3. Erstellung der SGRID-Dateien Die bei der Knotengenerierung erzeugten SGRID-Knoten mssen in korrekter Reihenfolge in eine ASCII-Datei geschrieben werden. Da das SGRID-Knotengitter auf Indizes basiert, ist es notwendig diese Indizes korrekt den Knoten zuzuordnen. Dabei ist sowohl die Anordnung der Knoten in der SGRID-Datei wichtig, als auch

Documents

Schnittstellen für eine landesweite 3D-Datenbank