02/2011 - Fakultät für Mathematik und Informatik - TU Bergakademie ...

Fakultät für Mathematik und Informatik
Preprint 2011-02
Helmut Schaeben (Hrsg.)
9. Freiberg Forum
Geoinformationstechnologie
ISSN 1433-9307

Helmut Schaeben (Hrsg.)
9. Freiberger Forum Geoinformationstechnologie
TU Bergakademie Freiberg
Fakultät für Mathematik und Informatik
Akademiestr. 6
09596 FREIBERG
http://www.mathe.tu-freiberg.de

ISSN 1433 – 9307
Herausgeber: Dekan der Fakultät für Mathematik und Informatik
Herstellung: Medienzentrum der TU Bergakademie Freiberg

Interoperabilität von Geodaten – ein Gordischer Knoten kann durchtrennt
werden
Dr. Jörg Reichling
Kommission für Geoinformationswirtschaft des Bundesministeriums für Wirtschaft und Technologie
GeoBusiness, das sind Geschäftsmodelle mit ortsgebundenen Informationen der öffentlichen Hand.
Die Kommission für Geoinformationswirtschaft des Bundesministeriums für Wirtschaft und Technologie
(GIW-Kommission) arbeitet seit 2004 daran, die Rahmenbedingungen zur Bereitstellung dieser
Daten an die Wirtschaft zu optimieren. Leitprojekte zeigen was geht und was nicht geht. Studien arbeiten
gesetzliche Grundlagen und marktpotenziale international heraus. TaskForces entwickeln Lösungsmodelle
zur Änderung der Vielfalt an Bereitstellungsbedingungen für staatliche Geoinformationen.
Fazit aller Erfahrungen ist, dass Geschäftsmodelle - also Arbeitsplätze und KnowHow-Vorsprung
in der deutschen Wirtschaft auch in Europa - nur dann entstehen können, wenn Lizenz- und Preismodelle,
Datenschutzbedingungen und technische Standards der öffentlichen Hand bundesweit verwaltungsübergreifend
einheitlich sind. Hier müssen große politische Räder gedreht werden. Initiativen
wie die „open data policy“ bei unseren amerikanischen Freunden, Preissenkungen um mehr als 90%
für öffentliche Geoinformationen in unserem Nachbarland Österreich oder „free data release“ wie in
Großbritannien müssen auch in Deutschland Schule machen. Ein gordischer Knoten im GeoBusiness
in Deutschland muss vom Bund über die Länder bis zu den Kommunen durchtrennt werden.
Die Leitlinie der GIW-Kommission sind zwei Memoranden
Im Frühjahr 2005 entsteht das erste Memorandum der GIW-Kommission (www.GeoBusiness.org).
Das Bundeswirtschaftsministerium, die Wirtschaftsministerkonferenz und 15 Bundesspitzenverbände
legen ein strategisches Papier vor, in dem folgende Eckpfeiler eines aktivierten Geoinformationsmarktes,
des GeoBusiness in Deutschland, benannt werden:
• Geoinformationen sind im Sinne einer volkswirtschaftlich positiv wirksamen Nutzung in Form
einer kostenlosen Grundversorgung oder transparenter und nachvollziehbarer Gebührenmodelle zugänglich
zu machen. Hierbei sind branchenspezifische Bedürfnisse zu berücksichtigen.
• Gebührenmodelle sind marktorientiert zu vereinheitlichen und zu vereinfachen, nutzerorientiert,
internetfähig, flexibel und dynamisch darzustellen. Die enge Verknüpfung mit einer wirtschaftsorientierten
Handhabung von Nutzungsrechten ist offenbar.
• Datenschutzrechtliche Aspekte sind bundeseinheitlich, marktwirtschaftsorientiert und angemessen
zu klären.
Im Mai 2010 entsteht das zweite Memorandum der GIW-Kommission. Die Eckpfeiler sind immer
noch die gleichen. Die Erfahrungen der vergangenen 5 Jahre jedoch lassen vieles deutlicher fassen.
Insbesondere die Werkzeuge, mit denen nun die Lösungen hin zu bundesweit einheitlichen Rahmenbedingungen
geschaffen werden können, haben sich heraus kristallisiert: moderierte thematische
TaskForces zu Lizenzen, Preisen, Datenschutz etc. wurden aus der Taufe gehoben und eine zentrale
Informationsdrehscheibe über WebDienste im Internet für die Unternehmen geschaltet.
Die Werkzeuge zur Änderung der Rahmenbedingungen
• Flexible Managementstrukturen
Die GIW-Kommission besteht aus 18 Bundesspitzenverbänden der Deutschen Wirtschaft und einem
Vertreter der Wirtschaftsministerkonferenz. Sie wird vom BMWi geleitet. An den Sitzungen der
Kommission nimmt darüber hinaus der Vorsitzende des Lenkungsgremiums GDI-DE regelmäßig teil.
Die operative Arbeit in den Projekten, Workshops, Arbeitsgruppen und TaskForces wird häufig durch
Mitgliedsunternehmen der Verbände wahrgenommen. Das BMWi wiederum vertritt die Kommission
im Lenkungsgremium GDI-DE. Über den Austausch der Geschäftsstellen der GIW-Kommission und
von GDI-DE mit wechselseitiger Mitwirkung in Projekten und Arbeitsgruppen wird insgesamt eine

Dr. Jörg Reichling
inhaltliche Ergänzung sicher gestellt. Es gibt drei wesentliche Beteiligte im GeoBusiness in Deutschland,
die Wirtschaft, die Verwaltung und die Politik (Abb. 1). Um die Schwerpunkte in den Rahmenbedingungen
effektiv bearbeiten können, müssen die Aktionsfelder Leitprojekte, Studien, TaskForces
und Kommunikation je nach Bedarf mit den entscheidenden Mitwirkenden besetzt sein.
Der Dreh- und Angelpunkt in den Managementstrukturen dieser Wirtschaftskommission ist die Kooperation
der Wirtschaftsvertreter mit der GIW-Geschäftsstelle. Ein Stabsbereich mit fünf Personalstellen
steht dem BMWi an seiner Bundesoberbehörde unmittelbar zur Verfügung. Diese operative
Einheit der Kommission wurde an der Bundesanstalt für Geowissenschaften und Rohstoffe in Hannover
eingerichtet. Hier laufen die Fäden der Strukturen auf Behördenseite, der Geodateninfrastruktur
Deutschland GDI-DE und der Kommission zusammen. Die Geschäftsstelle bündelt die Bedürfnisse
der Wirtschaft, sorgt für inhaltlichen Abgleich und zielgerichtete Aktivitäten. Studien werden vergeben,
begleitet und Kommunikationsstrategien entwickelt. Insgesamt stellt die Geschäftsstelle die strukturelle
Unterstützung der Kommission sicher. Sie öffnet als Katalysator die Türen zu den Fachverwaltungen,
bereitet die Verabredungen mit den Vertretern der Geodateninfrastruktur in Deutschland vor
und moderiert die Verhandlungsprozesse zwischen Wirtschaft und Verwaltung. Ihre Neutralität als
Schaltstelle zwischen Wirtschaft und Verwaltung an einer Bundesoberbehörde mit traditionell ausgebildeten
Kooperationserfahrungen in unterschiedlichsten Wirtschaftszweigen und großer Offenheit
gegenüber Geschäftsprozessen in der Wirtschaft bietet eine ideale Grundlage für diese Funktion.
• Validierung von Vermutungen durch Leitprojekte
Das integrale Analyse-Instrument der Kommission sind ihre Leitprojekte. Branchenübergreifend werden
hier die aktuellen Bereitstellungsmodalitäten analysiert und gemeinsam mit den Fachverwaltungen
Wege entwickelt, die eine wirtschaftlich nachhaltige Nutzung staatlicher Geoinformationen erlauben.
Das Patentrezept, diese Aktivitäten wirtschaftlich tatsächlich nachhaltig zu platzieren ist, dass für die
Umsetzung dieser Geschäftsmodelle keine Fördergelder des BMWi bereitgestellt werden. Wie im
täglichen Unternehmensgeschäft muss die Geschäftsidee durch die Verbände und Unternehmen selbst
vorfinanziert und gesteuert werden. Das heißt, auch der operative Unterbau zur Umsetzung wird von
der Wirtschaft gestellt. Dies beginnt mit der Identifizierung technischer Hürden und endet mit dem
Austausch von Webdiensten zwischen Wirtschaft und Verwaltung in internetbasierten Applikationen.
Ein Beispiel für eine nur innerhalb von zwei Jahren bundesweit umgesetzten Anwendung ist das
www.georohstoff.org (Abb. 2). Die Verbände der Rohstoffwirtschaft in Deutschland machen hier für
die Betriebsplanung ihrer Unternehmen wichtige Informationen topaktuell, 7 Tage die Woche, verfügbar.
• Die TaskForces als strategisches Instrument
Für diese Wirtschaftskommission stehen in der nächsten Zukunft Rahmenbedingungen wie "Gesetze",
"Lizenzen", "Datenaustausch", "Preismodelle", "Datenschutz" und "Wertschöpfung" im Mittelpunkt.
Seither wurden als Basis für die weiteren Überlegungen Leitprojekte gemeinsam zwischen Wirtschaft
und Verwaltung umgesetzt, Studien erstellt und nun thematische TaskForces eingerichtet, die helfen
sollen, die vielfältigen Probleme zu lösen. Die TaskForces sind interdisziplinär durch Vertreter der
Wirtschaft und Vertretern der Länderministerien und Fachverwaltungen besetzt. Der gemeinsame
Dialog ist der richtige und einzige Weg, für alle Seiten tragfähige Lösungen zu erarbeiten, die auch im
politischen Raum Akzeptanz finden können. Wenig Ziel führend ist es, wenn Wirtschaft und Verwaltung
jeweils für sich über Lösungswege nachdenkt, ohne den Anderen zu hören und sich mit den jeweiligen
Bedürfnissen auseinander zu setzen.
Gesetzliche Grundlagen
Während der Begleitung der GIW-Leitprojekte wurde immer deutlicher, dass die Rechtsunsicherheit
sowohl auf Seiten der Wirtschaft wie auch auf Seiten der Verwaltung sehr hoch ist. Gesetzliche
Grundlagen waren zwar im Grundsatz bekannt, welche EU-Richtlinie sich mit welcher nationalen
Umsetzung in Bundes- oder Ländergesetzen aber mit welchen Effekten auf das deutsche GeoBusiness
auswirkt, war nicht hinreichend erkennbar. Darüber hinaus war ebenfalls unsicher, welchen Einfluss

9. Freiberger Forum Geoinformationstechnologie
die jeweiligen Fachgesetze in welcher Hierarchie haben. Aus diesem Grund hat das Bundeswirtschaftsministerium
im Jahre 2009 die Studie "Die EU-Richtlinien als Motor für das deutsche Geobusiness"
vergeben. In dieser Studie (www.GeoBusinessLaw.org, Abb. 3) wird der Weg durch die Vielfalt
der Gesetze, Verordnungen und Behörden in Europa und Deutschland aufgezeigt, der eingeschlagen
werden muss, wenn ein Geschäftsmodell im Geobusiness aufgesetzt werden soll. Die interdisziplinär
besetzten Workshops zu dieser Studie bildeten die TaskForce GeoBusinessGesetze bildeten. Die Aufgabe
dieser TaskForce ist mit dieser Studie erfüllt.
Lizenzen
Das Thema "Lizenzen" nimmt im GeoBusiness eine zentrale Position ein. In den 16 Ländern, beim
Bund, und den 12.400 Kommunen existiert eine Vielzahl unterschiedlicher Lizenzbedingungen. Dabei
verwenden die jeweiligen Fachbehörden wiederum voneinander abweichende Dokumente. Diese Vielfalt
machen wirtschaftliche Geschäftsmodelle nahezu unmöglich. Ein Unternehmen mit einer bundesweiten
Geschäftsidee müsste Monate bis Jahre zunächst damit verbringen, Datenbereitsteller zu analysieren,
zu finden und jeweils einzelne Verträge zu schließen. dieser Aufwand ist allerdings insbesondere
für KMU viel zu hoch. Mithin werden gute Ideen und innovative Geschäftsideen durch die Rahmenbedingungen
im Keim erstickt, staatliche Daten nicht in Wert gesetzt. Neue Ideen können nicht
umgesetzt werden, potenzielle Arbeitsplätze entstehen nicht und das KnowHow des Standortes
Deutschland kann sich nicht ausreichend entfalten. Es gilt also, ein einheitliches Lizenzmodell für alle
Fachverwaltungen des Bundes, der Länder und auch der Kommune zu erarbeiten, um Geschäftsmodelle
zu ermöglichen. Als Vorlage zur Lösung dieses komplexen Problems dienen nun die Creative
Commons (CC) aus der Medienbranche. Anwendungen z.B. im Bundestag sowie Urteile in den Niederlanden
oder Spanien zeigen, dass diese Art der Lizenzierung durchführbar ist. Die TaskForce Geo-
BusinessLizenz entwickelt nun „GeoCCs“, die in allen Bereichen gleichermaßen Anwendung als
„ClickLicence“ finden können.
Eine Variante der TaskForce GeoBusinessLizenz ist die TaskForce GeoBusinessAustausch. Nicht nur
die Wirtschaft benötigt Informationen des Staates, sondern auch der Staat ist an bestimmten Unternehmensinformationen
interessiert, um beispielsweise seine Landesplanung zu optimieren. Bei den
Informationen, die die Verwaltung gern verarbeiten möchte, handelt es sich häufig um Geschäftsgeheimnisse.
Die sieben regionalen Rohstoffverbände gemeinsam mit den beiden Bundesspitzenverbänden
in der Rohstoffwirtschaft haben in nur eineinhalb Jahre eine einvernehmliche Einigung erzielt, um
ausgewählte Unternehmensdaten unter der Berücksichtigung bestimmter Restriktionen an die öffentliche
Verwaltung bundesweit einheitlich zu übergeben. Die Lizenzbedingungen und Nutzungsarten
unterschieden sich hierbei nicht grundsätzlich von den Entwicklungen in der TaskForce GeoBusiness-
Lizenz, sie haben lediglich eine andere Ausprägung. Dieses „GeoBusiness einmal anders herum“
zeugt außerdem von dem guten Verständnis und Vertrauen, das sich in den vergangenen Jahren im
GeoBusiness zwischen Wirtschaft und Verwaltung entwickelt hat.
Preismodelle
Analysiert man Richtlinien, Verordnungen und Tabellen zu Bepreisungen für die Bereitstellung von
Geoinformationen der öffentlichen Hand, so zeigt sich ein vielfältiges Angebot. Jede Verwaltungseinheit
in jedem Land, aber auch beim Bund und auch in den Kommunen hat seine eigenen Preisstrukturen.
Um allein die gemäß der uns vorliegenden Unterlagen für die Daten in den beiden zentralen Leitprojekten
der Kommission die Preise zu recherchieren, wurden zwei Monate benötigt. Ziel war es, für
die Geschäftsmodelle der Leitprojekte GeoRisiko und Georohstoff die tatsächlich zu bezahlenden
Preise insgesamt zu berechnen. Allein für das Land Baden-Württemberg würden sich demnach bei der
Nutzung durch 300 Unternehmen, also 300 Lizenzen, Preise in Höhe von 540.000 Euro pro Jahr ergeben.
Rabatte, Weiterverwendungszuschläge etc. sind dabei berücksichtigt. Hauskoordinaten für ein
Geschäftsmodell mit bundesweitem Anspruch kosten 100.000 Euro, Luftbilder ebenfalls. Geologische
Daten in Nordrhein-Westfalen sollen bald mehrere Tausend Euro im Jahr kosten. Dies sind Zahlen, die
dazu führen, dass Geschäftsmodelle erst gar nicht entstehen. Kein KMU kann es sich leisten, im Vorfeld
einer Geschäftsidee erst einmal wochenlange Preis- und Lizenzrecherchen zu beauftragen. Investitionen
für Daten in den genannten Größenordnungen sind in der Regel nicht zu finanzieren.

Dr. Jörg Reichling
Die Kommission hat beschlossen vor dem Hintergrund einer volkswirtschaftlichen Gesamtbetrachtung
einen Vorschlag zu entwickeln, der eine Aktivierung des Geoinformationsmarktes erlaubt. In der
TaskForce GeoBusinessPricing werden für die Wirtschaft realistische Szenarien diskutiert. Im Ergebnis
muss für Deutschland für alle Verwaltungseinheiten, Länder übergreifend, im Bund und in den
Kommunen eine einheitliche Flatrate für alle Datengruppen gleichartig angesetzt werden. Jede andere
Lösung ist für die Wirtschaft zu kompliziert, entspricht nicht den Gleichbehandlungsgrundsätzen und
wäre im Aufwand durch die Unternehmen nicht zu bewältigen. Denkbar ist, das diese Flatrate auf
mengen- und lastabhängigen Parametern beruht – ein Vorgehen ähnlich dem der Telekommunikationsbranche.
Datenschutz
Der Datenschutz war die Rahmenbedingung, die in der Kommission mit Hochdruck behandelt wurde.
Im Jahre 2006 war klar, dass das beste Lizenzmodell mit den besten Preisen und der besten Geschäftsidee
so lange in die Leere läuft, wie nicht das Thema Personenbezug und Personenbeziehbarkeit, also
der Datenschutz rechtssicher geklärt ist. Im Jahre 2007 analysierte die erste Datenschutzstudie der
Kommission "Datenschutz und Geoinformation" die allgemeine rechtliche Situation im föderalen
Deutschland. Auf dieser Grundsatzstudie aufbauend wurde 2008 die Studie "Datenschutzrechtliche
Rahmenbedingungen für die Bereitstellung von Geodaten für die Wirtschaft" angefertigt. Diese "Ampelstudie"
zeigt in Tabellenform mit Ampelfarben, welchen Status die gewünschten Datencluster der
Wirtschaft hinsichtlich ihrer datenschutzrechtlichen Einordnung einnehmen. Die dritte Studie zu Geoinformation
und Datenschutz, "Bereitstellung von Geodaten unter Berücksichtigung datenschutzrechtlicher
Aspekte anhand des Datenclusters "Denkmalschutz" der öffentlichen Verwaltung für die Wirtschaft"
ist im Mai 2010 publiziert worden. Hier werden exemplarisch an den Geschäftsprozessen der
Wirtschaft datenschutzrechtliche Mechanismen entwickelt, die die Nutzung auch sensibler Daten am
Ende erlauben. Optionen sind Instrumente wie Verrauschung, Kachelung, Anonymisierung oder vertragliche
Bindung. Mit diesen drei Studien ist der Grundstein gelegt für den länderübergreifenden
Dialog mit den Aufsichtsbehörden für den Datenschutz. Hervorgehend aus der Unterarbeitsgruppe
"Geodaten" des Düsseldorfer Kreises der Datenschutzkonferenz wird im September 2010 die
TaskForce GeoBusinessDatenschutz Ihre Arbeit aufnehmen. Ziel ist es, eine bundesweit einheitliche
Bewertung und Handhabung datenschutzrechtlicher Aspekte bei der Nutzung staatlicher Geoinformationen
einzuleiten.
Wertschöpfung
Im Rahmen der Bereitstellung und Abgabe von Geodaten staatlicher Stellen stellt sich immer häufiger
die Frage, wann die Wertschöpfungskette in der Wirtschaft beginnen kann und bis zu welcher Verarbeitungsstufe
die Verwaltung die Informationen der öffentlichen Hand bereitstellen sollte. Bereits in
der Situationsanalyse des ersten Memorandums der GIW-Kommission aus dem Jahre 2005 wurde
dieses wichtige Themenfeld identifiziert: "Im Grundsatz muss gelten: so viel Wirtschaft wie möglich -
so wenig Staat wie nötig." Dies bedeutet, dass die Branchenverbände der Wirtschaft und die sogenannte
veredelnde Wirtschaft, also die Unternehmen, deren Kernkompetenz die Konfektion spezieller GIS-
Software oder die Integration von GIS-Modulen in bestehende Geschäftsprozesse ausmacht, so früh
wie möglich an dem Wertschöpfungsprozess beteiligt werden sollte. Im Rückschluss ergibt sich wiederum,
dass die Verwaltung ihre Geoinformationen in einem möglichst gering wirtschaftlich veredelten
Zustand und mit wenig Möglichkeit zur Synopse bereit stellen sollte. Aus den Qualitätsansprüchen
der Verwaltung auf der einen Seite und den Wertschöpfungsansprüchen der Wirtschaft auf der anderen
ergibt sich ein natürliches Spannungsfeld. Die "TaskForce GeobusinessWert" widmet sich dem
Ziel, die spezifischen Probleme der Thematik zu analysieren und mögliche Lösungen herauszuarbeiten.

9. Freiberger Forum Geoinformationstechnologie
Das gebündelte Informationsangebot mit Wirtschaftskonfektion
Immer mehr Unternehmen aus den verschiedensten Branchen benötigen eine Vielzahl unterschiedlicher
Internet gestützter Informationen über einen Ort, sogenannte Geoinformationen. Eine solche Geoinformation
kann zum Beispiel die Verbreitung denkmalgeschützter Häuser oder von Feuerwehrstationen
sein. Um die Auffindbarkeit und den Zugang zu diesen öffentlichen Daten als WebDienste zu
bündeln, zu vereinfachen und den Gewohnheiten der normalen Anwender bei der Internetsuche anzupassen,
gibt es unter www.GeoMonitoring.org (Abb. 4) eine zentrale Informationsdrehscheibe. Dabei
spielt es keine Rolle, ob Geodaten der Bundes-, Landes- oder Kommunalverwaltung gesucht werden.
Die Geo-Suchmaschine zeigt, was es wo in Deutschland gibt. Gleichzeitig wird geprüft, wie zuverlässig
der Dienst zur Verfügung steht.
Die großen Vorteile dieser WebDienste liegen auf der Hand: Aktualität und Zugriff rund um die Uhr.
Daneben bietet die neue Plattform weitere Vorteile für den Nutzer von Web-Diensten. Er kann nach
Stichworten, in Themengebieten, nach Postleitzahlen oder Verwaltungseinheiten suchen. Mit geliefert
werden Informationen zu Ansprechpartnern und Lizenzbedingungen. Der Mehrwert besteht im schnellen
Zugriff mit Bildvorschau und Kontaktdaten - eine One-Stop-Info zu Webdiensten der öffentlichen
Hand.
In einem nächsten Schritt ist geplant, dem Datenbereitsteller die Möglichkeit zu geben, selbst eigene
Web-Dienste zu registrieren. So kann er seine Produkte über „www.GeoMonitoring.org“ auf Verfügbarkeit
und Stabilität prüfen und zeitgleich einer breiten Öffentlichkeit mit allen erforderlichen Zusatzinformationen
zugänglich machen. Auch bisher geschützte Dienste mit besonderen Lizenz- oder Datenschutzbedingungen
und Preismodellen sollen dann gefunden werden können. Der Wirtschaft wird
mit dieser Anwendung ein gebündelter, einfacher und verlässlicher Zugang zu Web-Diensten der öffentlichen
Verwaltungen ermöglicht. Die Vereinheitlichung der Rahmenbedingungen in TaskForces
soll im Ergebnis dazu dienen, diesen Angeboten einfache, nachvollziehbare, einheitliche, rechtssichere
und preisgünstige WebDienste über Click-Licenses verfügbar zu machen.
Eine „aktivierende Datenpolitik“ kann den Gordischen Knoten zerschlagen
Die politischen Strukturen für den GDI-Prozess in Deutschland sind insgesamt konstituiert. Hiermit
sind die Bundesverwaltung, die Landesverwaltungen und die Kommunen direkt und aktiv an der Gestaltung
der Rahmenbedingungen beteiligt. Die einheitliche Bereitstellungsbedingungen für staatliche
Geoinformationen als WebDienste an die Wirtschaft können nur dann eine einheitliche Umsetzung
finden, wenn die höchsten politischen Ebenen dieses Thema aufnehmen und als folgerichtigen Weg
für die wirtschaftliche Entwicklung des GeoBusiness in Deutschland annehmen.
Die TaskForces der GIW-Kommission, als operative Organe innerhalb der GDI-Prozesse in Deutschland,
entwickeln wirtschaftsorientierte Vorschläge für harmonisierte Bedingungen zur Bereitstellung
staatlicher Geoinformationen. Das diese modernen Vorschläge für Lizenzen, Preismodelle oder Datenschutz
von den bestehenden Verordnungen, Gesetzen und Richtlinien in den verschiedenen föderalen
Ebenen abweichen müssen, liegt in der Natur der Sache. Bisher wurden sowohl auf Bundesebene, als
auch auf Landesebene und auch auf kommunaler Ebene jeweils Vereinbarungen, AGBs oder Gebührenverordnungen
erlassen, die mit benachbarten, nach- oder übergeordneten Bereichen in der Regel im
Vorfeld nicht vereinheitlicht wurden. Es steht also ein Paradigmenwechsel bevor, der Vorbild für ähnliche
Entwicklungsprozesse in Europa haben kann. Geplant ist es, die Überlegungen zu einheitlichen
Rahmenbedingungen 2011 weitestgehend abzuschließen. Ob dies so aufrecht erhalten werden kann,
richtet sich wesentlich an der Entscheidungsfreude der politisch Verantwortlichen aus.
Aus den Erfahrungen der vergangenen Jahre in den Leitprojekten der GIW-Kommission ist davon
auszugehen, dass die Implementierung einer neuen zukunftsweisenden und aktivierenden Datenpolitik
über die föderalen Strukturen in Deutschland eine gewisse Zeitspanne in Anspruch nehmen wird. Es
ist davon auszugehen, dass die Zeitspanne bis zur vollständigen Umsetzung der INSPIRE-Richtlinie,
also mindestens bis 2019, ausgeschöpft werden muss, bis die einheitlichen Rahmenbedingungen von
der Bundes- bis zur Kommunalebene eingeführt sind. Da weiterhin davon auszugehen ist, dass die

Dr. Jörg Reichling
Datenpolitik im Zuge der politischen sowie der technischen Entwicklung stetig anzupassen ist, wird
ein dauerhafter Steuerungsprozess eingerichtet werden müssen. Diese Steuerungsmechanismen sollen
es erlauben die Lizenz-, Preis- und Datenschutzpolitik kontinuierlich neuen Veränderungsprozessen
anzupassen.
Voraussetzung für eine solche einfache und wirtschaftsorientierte Geodatenwelt in Deutschland ist
jedoch, dass der Gordische Knoten der heterogenen Rahmenbedingungen durch „aktivierende Datenpolitik“
durchtrennt wird. Die letzten fünf Jahre im Rahmen der Geodateninfrastruktur Deutschland
haben die Situation analysiert und Lösungsansätze herausgearbeitet. Jetzt braucht es Mut und Entscheidungsfreude
im politischen Raum, um den Gordischen Knoten bei den Bedingungen zur Bereitstellung
staatlicher Geoinformationen zu durchtrennen: open data policy auch in Deutschland…

Towards Interoperability with GST
Paul Gabriel, Jan Gietzel, Ha Hai Le, Helmut Schaeben
Geoscience Mathematics and Informatics, TU Bergakademie Freiberg, Germany
Abstract
Our communication presents a data model for a network based infrastructure to manage spatially indexed
geological properties assigned to simplicial objects. Finally we strive for a comprehensive
model for spatio temporal geo-data and geo-models towards a geoscience information system.
For the time being, the project includes a first extension of the database system PostgreSQL (pgSQL,
2011) for three dimensional geo-data which we refer to as GST. Analogously to the well known open
source extension for two dimensional geometries PostGIS (PostGIS refractions, 2010), our extension
employs the Simple Feature Standard (OGC 06-104r4) defined by the Open Geospatial Consortium(OGC)
for communication. In order to reduce the amount of data required to be transferred to
clients, extensions have been included to SFS+. Our approach is not restricted to extensions of PostgreSQL
and will soon be applied to other database systems. Future developments of the model will
comprise explicit considerations of topology and time.
To meet the requirements of interoperability, this system shall include a webservice to provide geodata
in a service oriented architecture (SOA). The implementation of a web feature service (WFS)
creates an interface to share geo-data with any other systems via GML (OGC 07-036) and GeoSciML
(GeoSciML, 2010), and more recent markup languages inclined to geosciences.
A client-software is implemented both as gOcad-plugin as well as standalone application. Thus it is
possible to access our GST, installed on a network server, from various clients simultaneously. Complementary
implementing a WFS interface on client side will enable gOcad to retrieve data from any
other web feature service. In general, Postgres Server (and others) and WFS will be implemented in
such a way that they can be accessed via the internet.
1 Introduction
The design of our store is based on WGFS by Jacynthe Pouliot (Pouliot et al., 2009) which in turn is
based on earlier work by Marcus Apel (Apel, 2004). The general idea of our data store is a 3 tier architecture.
Accordingly a system is being developed to store spatial and spatio-temporal geo-data, and a
corresponding client. This architecture enables to store the geo-data on a central server and to retrieve
them from anywhere by many clients simultaneously.
2 GST
GST stands for geoscience data and models in space and time. At this time GST is an extension of the
DBMS PostgreSQL and written in C/C++ to enhance the functionality of the database (Figure 1).
Since PostGIS supports two dimensional data structures (in most of its operations), the actual version
of GST now fully supports three dimensional geometrical data types. To store three dimensional objects
in the database an interface for Simple Feature Standard (OGC 06-104r4) is used.

Paul Gabriel & Jan Gietzel & Ha Hai Le & Helmut Schaeben
Figure 1: The extensions of PostgreSQL are implemented as C/C++ stored procedures using
different libraries like boost (Boost), spirit (de Guzman et al., 2011) for parsing and CGAL
(CGAL) for geometry construction.
1.1 GST for geo-data in spatial domain
GST features a class domain modeling. The first prerequisite of modeling is a generalization of the
objects to be modeled, i.e. the user organizes all geo-data into classes. For example, a typical geomodel
is displayed in Figure 2.
Figure 2: An example for a geological structure modeled with gOcad. There is one fault (red)
crossing two layers (yellow and grey) (_gure from [Apel, 2004]).

9. Freiberger Forum Geoinformationstechnologie
Typically the construction of the model commences with modeling the base horizons as surfaces from
varous data like borehole data, geological sections, seismic data and others. These surfaces are collected
in a class “base horizon”. In this way the user creates a class base_horizon with the property to
which stratigraphic unit a modeled surface of this class belongs, e.g. by storing the stratigraphic shortcut.
The following command will create a table named base_horizon to store the modeled horizons.
CREATE TABLE base_horizon
(
id serial NOT NULL primary key ,
name character varying (100) ,
strat character varying (5)
);
SELECT gst. addgeocolumn (' base_horizon ','shape ', 'TIN ');
The first command creates a table as defined in the SQL-Standard (ISO 9075). The second command
is a GST function, which attaches a virtual geometry column to the table.
Similarly to the horizons the user may model the surfaces representing faults. Analogously a class for
faults is created.
Using base horizons and faults the modeler creates volumetric objects, e.g. tetrahedral meshes, defined
by the bounding surfaces, simply assuming that a specific geological body is bounded at top and bottom
by base horizons and by the faults. A class named “geobodies” is created for these volumetric
objects with a geometry of type “Multipolygon”. Next the user may wish to assign rock properties
from borehole measurements like porosity or storage capacity for pore uids to these volumetric objects.
To this end another class is created as follows.
CREATE TABLE geobody
(
id serial NOT NULL primary key ,
name character varying (100)
);
CREATE TABLE bodyproperty {
effective_porosity double precision ,
total_porosity double precision ,
storage double precision
};
select gst. addgeocolumn ('geobody ', 'shape ', ' MULTIPOLYGON ', -1, 'bodyproperty ',
'VERTEX ');
Thus a second table named bodyproperty was created to store geological properties of the volumetric
objects. Using the addgeocolumn function a property table can be attached to the geometry on the
level of simplices. Then each cell of a tetrahedron mesh can now hold three double values.
The last parameter (in this example VERTEX) defines the cell type of the geometry to which the
property will be actually attached.
VERTEX will attach the property on vertex level. Three property values (effective
porosity, total porosity and storage) are assigned to each of the 4 vertices of
every tetrahedron.
CENTROID will attach the property on cell level. The three property values then are
assigned to each tetrahedron.
Which attachment of the property should be preferred depends on the geometry, on the modeling purpose,
and on the modeling software. The tetrahedral mesh of gOcad (TSolid) supports vertex attachment
of properties. SGrids of gOcad provide both possibilities to attach properties to their elements.

Paul Gabriel & Jan Gietzel & Ha Hai Le & Helmut Schaeben
3 GST and geometry
GST has a Simple Feature Interface [OGC 06-104r4] which enables the user to retrieve geometries
acording to this standard. In the actual version the well known text representation (WKT) is implemented.
WKT encodes geometrical information as strings. The first entry specifies the geometry type,
e.g. Multiline z for a three dimensional segment collection, followed by the coordinates of all points.
Using the select function gst.select_geowithoutpros the user can get SFS expressions.
select gst. select_geowithoutpros (id , type )
--- int id ... the id of the geometry
--- var char type ... the type the geometry is encoded
select gst. select_geowithoutpros (7, 'SFS ')
The actual version of GST supports the geometry types “pointset” (accumulation of isolated points),
“multilineset” (set of segments which are connected), “trianglenet” (triangulated irregular network)
and “tetrahedronnet”. For large TINs the SFS expression may become very large, and network and
parsing may take more time. To avoid these unpleasant shortcomings we have extended SFS to SFS+.
However, the choice is left to the user. It is also possible to retrieve the geometry in GML encoding.
GST fully supports tin z and multipolygon z in SFS, but its text representations are much longer than
in our SFS+. The following Table 1 relates types of geometry and geometry commands of SFS and
SFS+, respectively.
Tabelle 1: Types of geometry and geometry commands of SFS and SFS+, respectively
Geometry SFS SFS+
Pointset multipoint z multipoint z
Multilineset multiline z multiline z
triangle net tin z trianglenet z
tetrahedron net multipolygon z tetrahedronnet z
1.2 Internal structure
All geometry objects stored in the system are partitioned into simplices. For a triangulated irregular
network (TIN) all points are listed in one table. Another table holds the indices of all points which are
connected to one triangle. Finally one table defines which triangles belong to a TIN (see Figure 3).
The SFS interface of GST is realized as stored procedures. When the user requests an object geometry
in SFS representation, a procedure selects all simplices of the requested object, builds the object as
CGAL (CGAL) geometry and encodes it as well known text (WKT). When the user wants to store a
geometry in the database, a procedure parses the WKT, constructs the geometry and enters the simplices
in the related tables.

9. Freiberger Forum Geoinformationstechnologie
Figure 3: The internal structure of a triangulated irregular network (TIN) object in GST v.0.1
4 Client implementation
The development of the client involves an interface to retrieve data via HTTP and direct access (Figure
4). At this time only an interface for PostgreSQL database is included. The graphical user interface
is based on the basic requests defined by the WFS standard (OGC 09-025r1 and ISO/DIS 19142).
Figure 4: Screenshot of the client GUI. The user is asked for server authorization data in order
to connect to a particular server
Thus the user has the possibilities to display general information about the server providing the data
and information about the features themselves (see Figure 5). When the user has chosen a particular

Paul Gabriel & Jan Gietzel & Ha Hai Le & Helmut Schaeben
feature he wants to work on, the client program either can store them locally on hard disk as gOcad
object file or display them directly in the opened gOcad program depending on whether the client program
has been started as standalone application or gOcad plugin, respectively.
Figure 5: Screenshot of the client GUI after retrieving feature information from the server.
5 Outlook
GST will be extended to include several geometrical grid types beyond point, line, triangle net and
tetrahedron net. The major issues to be tackled are implementation of a topological model, generalization
of the data model to consider the time domain, a viewer for the next browser generation (Firefox
4, Google Chrome 10, etc.) supporting WebGL technology, and an approach to manage huge geomodels.
6 Conclusions
A first implementation was successfully tested with Pär Weihed and his group, gOcad partner at Luleå
University of Technology, Sweden, and their gOcad model of the Fennoscandian Shield (Skellefte-
Pyhäsalm).
7 Acknowledgments
This ongoing research project is funded by the European Community's Seventh Framework Programme
(FP7/2007-2013) under grant agreement no 228559. This publication reflects only the authors'
view, exempting the Community from any liability.
The authors gratefully acknowledge that they used the Computational Geometry Algorithms Library
(CGAL, see http://www.cgal.org) for the first prototypical implementation of the model.

9. Freiberger Forum Geoinformationstechnologie
References
APEL, M. (2004): A 3d geoscience information system framework. Cotutelle de thèse, TU Bergakademie
Freiberg, Germany, and ENSG Nancy, France
Boost (2011): Boost C++ libraries. http://www.boost.org/.
GeoSciML (2010): Geoscience Markup Language. Commission for the Management and the Application
of Geoscience Information (CGI). http://www.geosciml.org/.
DE GUZMAN, J., KAISER, H., NUFFER, D. (2011): Boost spirit – LL parser framework represents
parsers directly as EBNF grammars in inlined C++.
http://www.boost.org/doc/libs/1_46_1/libs/spirit/doc/html/index.html.
CGAL (2011): Computational Geometry Algorithms Library. Geometry Factory http://www.cgal.org/.
ISO 9075 (2008): Information technology – Database languages – SQL – Part 1, Framework
(SQL/Framework), http://www.iso.org/iso/catalogue_detail.htm?csnumber=45498
OGC 06-104r4 (2010): OpenGIS Implementation Standard for Geographic information – Simple feature
access – Part 2: SQL option, http://www.opengeospatial.org/standards/sfs.
OGC 07-036 (2010): OpenGIS Geography Markup Language (GML) Encoding Standard,
http://www.opengeospatial.org/standards/gml.
OGC 09-025r1 and ISO/DIS 19142 (2010): OpenGIS Web Feature Service 2.0 Interface Standard,
http://www.opengeospatial.org/standards/wfs.
PostGIS refractions (2010): PostGIS wiki,
http://trac.osgeo.org/postgis/wiki/UsersWikiPostgreSQLPostGIS.
pgSQL (2011): PostgreSQL – the world most advanced open source database. PostgreSQL Global
Development Group, http://www.postgresql.org/.
POULIOT, J., BADARD, T., DESAGNÉ, E., BÉDARD, K., THOMAS, V. (2009): Development of a
Web Geological Feature Server (WGFS) for sharing and querying of 3D objects. In van Oosterom, P.,
Zlatanova, S., Penninga, F., Fendel, E., (eds.), Advances in 3D Geoinformation Systems, Springer,
115–130.

Datenmodelle für boden- und felsmechanische Kennwerte und ihre Umsetzung
J. Engel 1 , G. Gräfe 2 .
Abstract: Zur Bearbeitung geotechnischer Projekte sind unterschiedliche ingenieurtechnische Aufgaben
zu bearbeiten. Dies umfasst u.a. die Ermittlung der Grundlagen, den Entwurf und die Planung der
technischen Lösung. Dabei fallen Informationen in unterschiedlichsten Formaten an. Vielfach stehen
spezielle Programme zur Verfügung, die nur begrenzt untereinander kompatibel sind. Die Daten lassen
sich oft nur durch die Verknüpfung der fertigen Dokumente verwalten. Wegen des geographischen
Bezugs ist die Einbindung in ein GIS wünschenswert. In diesem Artikel werden die Grundzüge eines
Datenmodells vorgestellt, das die Einbindung unterschiedlicher Informationen nach einer erprobten
Systematik erlaubt. Es wird damit möglich, alle Prozesse bei der Bearbeitung geotechnischer Projekte
vollständig in einem Datenmanagementsystem zu verwalten. Durch Berücksichtigung der Schnittstellen
zu verbreiteten GIS ist die Nutzung der Daten für Anwendungen im Bereich Umwelt, Geotechnik,
Wasser- und Verkehrsbau sichergestellt. Erste Umsetzungen des Modells werden zurzeit für bodenmechanische
Untersuchungen und für Projekte des Deponiebaus realisiert.
1 Einführung
1.1 Boden- und felsmechanische Kennwerte bei bautechnischen Projekten
Das Wesen der ingenieurtechnischen Bearbeitung von Bauprojekten besteht u. a. in der Anfertigung
prüfbarer Unterlagen zu den rechnerischen Nachweisen und zu allen Vorgaben die Konstruktion, die
Materialbeschaffenheit, den zeitlichen Ablauf und die Kosten betreffend. Dazu wird u.a. auf naturwissenschaftliche
Arbeitsmittel aber auch in einem erheblichen Maße auf Erfahrungswissen zurückgegriffen.
Abbildung 1: links – physikalisches Modell der trockenen Reibung, rechts – Scherfestigkeit bei Böden
1
Hochschule für Technik und Wirtschaft Dresden, Fak. Bauingenieurwesen/Architektur, Professur Geotechnik
Friedrich-List-Platz 1, D-01069 Dresden, Tel.: ++49 351 4622352, e-mail: engel@htw-dresden.de
2
Hochschule für Technik und Wirtschaft Dresden, Fak. Informatik/Mathematik, Professur DV-Anwendungen/Datenbanksysteme
Friedrich-List-Platz 1, D-01069 Dresden, Tel.: ++49 351 4623432, e-Mail: graefe@informatik.htw-dresden.de

Eine Grundlage für die Aufstellung rechnerischer Nachweise sind Gesetzmäßigkeiten, mit denen die
Reaktion eines Materials auf eine Einwirkung zahlenmäßig beschrieben werden kann. Mit diesen Material-
oder Stoffgesetzen werden Kennwerte definiert, die als Eingangsgrößen bei Berechnungen zu
benutzen sind. Die Festigkeit von Böden wird z. B. durch Bruchbedingungen beschrieben. Sehr verbreitet
ist dabei das Mohr-Coulombsche Bruchkriterium.
τ = σ tan ϕ + c
(1)
N
Diese wurde abgeleitet aus systematischen Materialprüfungen an Festgestein, Beton und später auch
an Böden. Von O. Mohr ist auf Grundlage dieser Prüfungen eine Bruchbedingung formuliert worden,
die durch eine nichtlineare Abhängigkeit der Festigkeit τ von der Normalspannung σN beschrieben
wird. Die lineare Vereinfachung dieses Ansatzes ist das Mohr-Coulombsche Bruchkriterium gemäß
Gl. (1). Die beiden Kennwerte, die für die grundlegenden Standsicherheitsnachweise benötigt werden,
sind der Reibungswinkel ϕ und die Kohäsion c.
Beide Kennwerte sind für einen Boden nicht konstant. Sie werden u. a. von der Dichte und Entstehungsgeschichte
der Ablagerung beeinflusst. Materialprüfungen an ungestörten Probekörpern sind
aufwendig und werden in vielen Fällen nicht durchgeführt. Man hilft sich mit Erfahrungswerten. Wie
diese „Erfahrungswerte“ entstanden sind, ist oft nicht mehr vollständig nachvollziehbar.
Abbildung 2: Triaxialprüfung an einer Bodenprobe, links - Gerät, rechts - Probe nach dem Versuch
Die grundlegende Methode ist die Ermittlung der Kennwerte durch Messungen im Rahmen von Labor-
und Feldversuchen. Versuchstechnik, Durchführung und Auswertung sind durch Normen und
Regelwerke weitestgehend vereinheitlicht und die Anwendung der Verfahren erfolgt routinemäßig.
Bei diesen Messungen wird allerdings nur ein sehr kleiner Ausschnitt des Untergrunds betrachtet. Im
günstigen Fall erfasst man mit einer Untersuchung an einer Probe im Labor etwa den zehnmillionstel
Teil des durch das Bauwerk beanspruchten Volumens. Die Übertagung von fehlerhaften Ergebnissen
auf große Untergrundbereiche kann zu unrealistischen Vorhersagen führen.
Übertragung bedeutet hierbei die Anwendung eines Berechnungsverfahrens, mit dem die Reaktion des
Untergrunds auf die Einwirkungen vorhergesagt werden kann. Bei der Beurteilung der Standsicherheit
von Böschungen nutzt man beispielsweise Gleitkreis- oder Starrkörperverfahren. Es wird ein größerer
Bereich des Untergrunds idealisiert und diesem Bereich müssen charakteristische Kennwerte zugewiesen
werden. Dazu sind bestimmte Annahmen zur Baugrundschichtung und den Einwirkungen erforderlich.
Die Bodenkennwerte werden so lange variiert, bis der beobachtete Zustand mit dem rechneri-

schen in wesentlichen Punkten übereinstimmt. Diese Vorgehensweise wird als „inverse Parameterbestimmung“
bezeichnet und liefert mittlere Parameter für ausgedehnte Bereiche.
Abbildung 3: Versagen einer Böschung, Idealisierung des Untergrunds für das Berechnungsmodell
Bei manchen Projekten beschränkt sich die Untersuchung des Baugrunds auf die Auswertung von geologischen
Karten in Verbindung mit der Bewertung durch „Sachverständige“ oder der Untergrund
wird in situ in Augenschein genommen. Es wird in beiden Fällen die Bodengruppe verbal beschrieben
und daraus auf die Eigenschaften, d. h. die Kennwerte, rückgeschlossen. Eine wichtige Grundlage für
diese Vorgehensweise ist die Vereinheitlichung der verbalen Beschreibung der Bodengruppen. Dafür
sind in den letzten Jahrzehnten Standards entwickelt worden, die z. B. aus petrografischen, stratigraphischen,
bodenmechanischen oder bodenkundlichen Prinzipien abgeleitet worden sind. Die Bezeichnung
des Gesteins oder Bodens soll mit den Eigenschaften korrelieren.
Abbildung 4: Ausschnitt aus einer Tabelle mit Erfahrungswerten für Parameter des Untergrunds
Zur Gewährleistung der Reproduzierbarkeit sind Regeln aufgestellt worden, die den Zusammenhang
zwischen einfach bestimmbaren Parametern wie Korngrößenverteilung oder Konsistenzgrenzen und
der Bezeichnung des Bodens beschreiben. Diese Regeln wurden in Klassifizierungsvorschriften zusammengefasst.
Die Eigenschaften von Boden und Fels lassen sich allerdings nicht allein auf Grundlage
der Locker- oder Festgesteinsart abschätzen. Sie sind in starkem Maße abhängig von der Schichtung,
dem Zustand des Bodens oder der Klüftung des Festgesteins. Außerdem bestimmt auch die Art
und Intensität der Beanspruchung die Größe eines Kennwerts.
1.2 Erfahrungswissen in der Geotechnik – subjektive Einflüsse
Die Bewertung von Untersuchungsergebnissen ist ein wichtiger – in bestimmtem Umfang aber auch
sehr subjektiver – Teil bei der Bearbeitung von umwelt- und geotechnischen Projekten. Das Expertenwissen
kann sehr nützlich sein, in manchen Fällen ersetzt es die experimentellen oder rechnerischen
Untersuchungen auch komplett. Gesammelte Erfahrungen sind die Grundlage für die Ableitung von
verallgemeinerten Regeln. Datensammlungen sind seit vielen Jahrzehnten in unterschiedlichster Form
angelegt worden. Es fehlt ein allgemein akzeptiertes Ablageschema und es fehlt teilweise auch die Bereitschaft,
eigenes Wissen einer breiten Anwendergruppe zur Verfügung zu stellen. Unter anderem aus
diesen Gründen sind die übergreifenden Initiativen zur Entwicklung eines Standards der Datenablage
für boden- und felsmechanische Kennwerte bisher nicht sehr erfolgreich gewesen.

Erfahrungswissen bei geo- und umwelttechnischen Projekten wird auf unterschiedlichen Wegen gewonnen.
Mögliche Quellen für Daten sind u. a:
• Experimentelle Untersuchungen zur Bestimmung eines Kennwerts (Versuche)
• Ableitung von Kennwerten aus Korrelationen zu Klassifikationskennwerten
• Nutzung tabellierter Erfahrungswerte in Abhängigkeit der Bodengruppe
• Sammlung und Interpretation indirekter Hinweise („unscharfe“ Informationen).
Zur Auswertung und Interpretation der Messungen oder anderer Informationen werden unterschiedliche
Hilfsmitteln genutzt, z. B.:
− Mathematische Verfahren zur Bewertung von Versuchsergebnissen (Stichproben)
− sachverständige Bewertung auf Grundlage von Untersuchungsergebnissen
− sachverständige Bewertung auf Grundlage der Begutachtung von Proben
− sachverständige Bewertung allein auf Grundlage von Erfahrungen.
In der ingenieurtechnischen Praxis überwiegt nach wie vor die deterministische Betrachtung. Bei den
Berechnungen werden keine Schwankungsbreiten für einen Parameter angesetzt, sondern es wird mit
charakteristischen Zahlenwerten gerechnet. Deshalb ist das Ergebnis einer sachverständigen Bewertung
von Boden und Fels immer die Zuweisung eines Parameters für einen ausgedehnten Bereich.
Einzelne Prüfergebnisse und Informationen müssen dabei so bewertet werden, dass ein Entwurf des
Bauwerks auf der sicheren Seite gewährleistet wird. Dabei müssen die zur Verfügung stehenden Informationen
gewichtet und bei der Bildung des Schichtenmodells berücksichtigt werden.
Eine Bewertung der Qualität von Kennwerten ist allein auf Grundlage der Art ihrer Entstehung nicht
möglich. Das Ergebnis experimenteller Untersuchungen an Boden oder Fels kann zwischen unterschiedlichen
Laboratorien aber auch zwischen unterschiedlichen Laboranten erheblich streuen. Die
Übertragung eines an einer Stichprobe gewonnenen Parameters auf eine ausgedehnte Schicht kann zu
Fehleinschätzungen führen. Umgekehrt kann ein durch Nachrechnung eines vorhandenen Bauwerks
ermittelter Kennwert so weit von der üblichen Erfahrung abweichen, dass eine unkritische Übernahme
nicht möglich ist. Man benötigt Algorithmen zur Bewertung der Plausibilität und der Zuverlässigkeit.
Abbildung 5: Karteikarte zur Erfassung wichtiger Kennwerte von Proben
1.3 Beispiele für die Sammlung boden- und felsmechanischer Daten
Die Informationen, die bei geo- und umwelttechnischen Projekten anfallen, sind sehr vielfältig. Neben
den inhaltlichen Unterschieden ist auch der räumliche und zeitliche Bezug der Daten zu berücksichtigen.
Viele Informationen lassen sich einer der folgende Bezugsgrößen bzw. Datenarten zuordnen:
− auf einen Punkt bezogene, nicht „sachverständig interpretierte“ Ergebnisse von Versuchen
und Messungen
− punktbezogene Daten aus der Interpretation indirekter Informationen (Korrelationen, Nachrechnungen,
Karten, …)

− auf eine Schicht bezogene Kennwerte, die aus der Bewertung von direkten Messungen abgeleitet
worden sind
− schichtbezogene Kennwerte, die aus der Bewertung von indirekten Informationen abgeleitet
worden sind.
Für die Nutzung innerhalb von Institutionen oder Firmen werden oft Daten mit unterschiedlicher Herkunft
ohne nähere Unterscheidung vermischt. Auswertungen müssen zwangsläufig zu widersprüchlichen
Ergebnissen bzw. großen Streuungen führen.
In Abbildung 5 ist die Vorder- und die Rückseite einer Karteikarte dargestellt, mit der in den 50er und
60er Jahren des letzten Jahrhunderts Ergebnisse von Versuchen an Boden- und Felsproben erfasst
wurden. Die Karteikarte enthält alle wesentlichen Informationen über die Ergebnisse von Laborversuchen.
Jede Karte fasst die an einer Probe im Labor bestimmten Kennwerte zur:
• Klassifizierung und Phasenzusammensetzung
• Scherfestigkeit
• Zusammendrückbarkeit und
• Durchlässigkeit
zusammen. Mit Hilfe solcher Datensammlung können Erfahrungen mit regional anstehenden Böden
leicht für andere Projekte genutzt werden. Sie sind auch die Grundlage für die Entwicklung von Klassifikationskriterien,
mit denen Böden mit ähnlichen Eigenschaften zu Gruppen zusammengefasst werden
sollen.
Ein Vorteil dieser Art der Datensammlung ist die Übersichtlichkeit und die Beschränkung auf wenige,
charakteristische Kennwerte. Nachteilig ist die aus den speziellen Erfahrungen abgeleitete Kennwerteliste.
Eine Übertragung auf andere Stoffgesetze und Kennwertmodelle ist nicht ohne weiteres möglich
und der Einfluss des Untersuchungsverfahrens auf die Größe des Kennwerts lässt sich ebenfalls nicht
mehr nachvollziehen.
2 Entwicklung eines Datenmodells für boden- und felsmechanische
Versuchsergebnisse
2.1 Geotechnische Versuche
Ein Kennwert ist eine Größe, die aus einem Versuch gewonnen wird und dazu dient, das im Experiment
beobachtete Verhalten auf Grundlage eines theoretischen Modells rechnerisch vorherzusagen.
Dafür ist eine Versuchsanordnung mit der erforderlichen Messtechnik notwendig. Die gemessenen
Größen müssen umgerechnet und auf Grundlage einer Theorie ausgewertet werden. Nicht alle Größen,
die das Ergebnis beeinflussen, lassen sich zahlenmäßig erfassen. Deshalb sind bei der Aufstellung des
Datenmodells beschreibende Einteilungen eingeführt worden.
Abbildung 6: Daten und Schritte zur Informationsverarbeitung bei Laborversuchen

Aus dem Ablauf bei Versuchen an Boden und Fels lassen sich verallgemeinerte Kriterien zur Katalogisierung
der Daten ableiten. Ausgangspunkt ist die vollständige Dokumentation aller Vorgänge und
Daten bei Messungen. In Abbildung 6 sind die einzelnen Informationen und die erforderlichen Arbeitsschritte
dargestellt.
Wegen der unterschiedlichen Arten der Daten ist eine Bewertung mittels statistischer Modelle nicht
immer möglich. Die Güte der Informationen, z. B. die Qualität der Versuchsdurchführung, lässt sich
ebenfalls nur schwer objektiv quantifizieren. Deshalb wird für die Bewertung der Kennwerte die Zuordnung
in Zuverlässigkeitsklassen benutzt. Sind für einen Kennwert alle Informationen bis hin zu den
originalen Messprotokollen verfügbar, kann auch nachträglich eine Bewertung der Daten durchgeführt
werden. Sind dagegen nur die Kennwerte als Endergebnis bekannt, ist eine Überprüfung nicht mehr
möglich. Nach der Vollständigkeit der dokumentierten Informationen werden 11 Zuverlässigkeitsklassen
unterschieden.
ZV 1: Alle Arbeitsschritte der Versuche an einer Probe sind mit den Daten vollständig nachvollziehbar.
ZV 2: Die Vorschrift zur Berechnung der Ergebnisse der Versuche an einer Probe ist bekannt, die
Originalmesswerte können aber nicht mehr rekapituliert werden.
ZV 3: Es sind die Ergebnisse der Versuche an einer Probe bekannt.
ZV 4: Die Ergebnisse zur Darstellung von Diagrammen der Versuche an einer Probe sind nicht verfügbar.
Es ist die Vorschrift zur Berechnung der Kennwerteder Versuchsabschnitte (Teilversuche)
bekannt.
ZV 5: Die Kennwerte der Teilversuche an einer Probe sind bekannt. Das Verfahren der Ermittlung
dieser Kennwerte ist nicht abgespeichert.
ZV 6: Es sind die eigentlichen Kennwerte der Versuche an einer Probe und die Vorschrift für deren
Berechnung bekannt.
ZV 7: Nur die Kennwerte der Versuche an einer Probe sind bekannt.
ZV 8: Der Kennwert der Probe und die Vorschrift für dessen Berechnung sind bekannt.
ZV 9: Es ist nur der Kennwert der Probe bekannt.
ZV 10: Für eine Baugrundschicht ist der Kennwert und das Verfahren für dessen Ermittlung bekannt.
ZV 11: Es ist lediglich der Kennwert der Schicht bekannt.
2.2 Datenmodell für Kennwerte von Versuchen
Abbildung 7: Gliederung der Informationen für das Datenmodell für boden- und felsmechanische Kennwerte
Durch die Bundesanstalt für Wasserbau und die Deutsche Gesellschaft für Geotechnik ist eine Initiative
zur Entwicklung einer Datensammlung für Versuchskennwerte gestartet worden. Die Arbeitsgruppe
hat sich mehrfach zu Beratungen getroffen und als Ergebnis eine Gliederung der Daten vorgeschlagen.
Dieser Vorschlag wurde am ZAFT an der HTW Dresden aufgenommen und zu einem Modell
gemäß Abbildung 7 weiterentwickelt. Die Datensammlung dient der Erfassung von Kennwerten, die

durch Laborversuche an Proben gewonnen worden sind. Sie kann ohne weiteres auch auf Schichtdaten
oder Daten aus indirekten Untersuchungen ausgeweitet werden.
Um eine Einbeziehung beliebiger Kennwertansätze zu ermöglichen, werden die Kennwerte in eine
Form transformiert, die unabhängig vom zugrunde liegenden Stoffgesetzt ist und die Rücktransformation
der abgelegten Daten in die vom Anwender gewünschte Form sicher stellt. Die entsprechenden
Algorithmen sind in einer Beispielumsetzung des Datenmodells implementiert.
2.3 Exemplarische Umsetzung des Datenmodells im Projekt Archiv Geotechnik
Am Zentrum für angewandte Forschung und Technologie e.V. (ZAFT) wird seit mehreren Jahren an
der Entwicklung eines Datenverwaltungssystems gearbeitet, mit dem die Informationen zentral abgelegt
werden können, die bei der Bearbeitung geo- und umwelttechnischer Projekte anfallen. Für die
Entwicklung werden ausschließlich frei nutzbare Softwarekomponenten eingesetzt.
Abbildung 8: Internet-Oberfläche von PrAG, Menüaufbau und Zuordnung der Ebenen
Das System ist so aufgebaut, dass Daten unterschiedlicher Herkunft und Zuverlässigkeit berücksichtigt
werden können. Zurzeit wird intensiv an der Fertigstellung der Programmbausteine gearbeitet, die für
die automatische Auswertung von Laborversuchen und die Erstellung der Protokolle erforderlich sind.
Im Rahmen dieser Auswertung werden die Einträge in die Kennwertedatei automatisch oder durch
Nutzereingabe erzeugt.
Der Bezug zu Lagekoordinaten und die Zeit ist im System durch entsprechende Strukturen gesichert.
Damit können die Daten auch für andere Informationssysteme zur Verfügung gestellt werden. Eine
Verbindung zu Bohrungsdatenbanken und anderen Datenerfassungsystemen wäre wünschenswert, um
Parallelentwicklungen zu vermeiden. Ein erster Schritt dazu könnte der Bezug zu den Fremdschlüsseln
der Bohrdaten sein bei der Registrierung von Lage und Herkunft der Proben.
Der Probezugang zu PrAG ist über folgeende Adresse möglich:
https://www.zaft.htw-dresden.de/geotechnik/prag/?lang=de
Firma: gast
Name: gast
Passwort: gast

Bodenaggressivitätskarte für die Stadt Leipzig: Methodik, Ausführung
und Anwendung
Wolfram Heidenfelder & Jochen Rascher
GEOmontan GmbH Freiberg, Am St. Niclas Schacht 13, D-09599 Freiberg, freiberg@geomontan.de
Angesichts zukünftiger Investitionen in ihr Leitungsnetz beauftragten die Kommunalen Wasserwerke
Leipzig GmbH die Erstellung einer Bodenaggressivitätskarte für ihren Versorgungsbereich, um die
Ursachen für Schäden an den Versorgungs- und Entsorgungsleitungen aus Eisen, Stahl und Beton
qualitativ nach DIN 50929 und E DIN 4030 zu beurteilen und für die Rekonstruktion und den Neubauentsprechende
Materialvorgaben leisten zu können. Die GEOmontan GmbH Freiberg erläutert im
Rahmen des 9. Freiberger Forums für Geoinformationstechnologie den methodischen Ansatz von der
Datenerhebung aus verschiedensten Quellen bis zur GIS-gestützten Analyse, Modellierung und Kartenerstellung
unter Beachtung kritischer Aspekte, wie z. B. dem Erhalt von raumbezogenenen Informationen
aus punktuellen Daten, und gibt einen Ausblick zur Anwendung der Bodenaggressivitätskarte.
The Kommunale Wasserwerke Leipzig GmbH commisioned the GEOmontan GmbH Freiberg to create
a map of soil aggressiveness for the area of the city of Leipzig using the German standards of DIN
50929 and E DIN 4030. This map enables the client to judge the impact of the soils on damages on
their water pipelines which are mainly made of iron, steel or concrete. The information of the map
provides the means to optimize material specifications of the water pipelines to be installed in future
reconstruction projects. During the 9 th Freiberg Forum of Geomatics, GEOmontan GmbH Freiberg
will illustrate the methodology of collecting data from various sources, GIS-based analyses and spatial
modelling in order to create the map of soil aggressiveness. Critical aspects such as the conversion of
point data into spatial information will be explained, and last but not least an outlook for the utilization
of the map will be given.
1 Untersuchungsgebiet – Stadt Leipzig
Die Stadt Leipzig mit einer Größe von ca. 298 km² befindet sich in der durch mehrfache Senkungen
während des Tertiärs angelegten Leipziger Tieflandsbucht. Das Stadtgebiet wird von den Flüssen
Weiße Elster, Pleiße und Parthe durchzogen, die einen maßgeblichen Einfluss auf das Grundwasserregime
haben.
Die geologischen Verhältnisse sind durch die Ablagerungen der quartären Eiszeiten bestimmt. Der
Untergrund von Leipzig besteht vornehmlich aus elster- bis weichselkaltzeitlichen sand-, kies- und
schotterführenden Flussterrassen von bis zu mehreren Dekametern Mächtigkeit. Diese sind weitflächig
überdeckt von Geschiebelehmen oder -mergeln bzw. von holozänen Auenlehmen mit mittleren Mächtigkeiten
zwischen 1 und 10 Metern. Die Sedimente der alten Flussterrassen und die tertiären Sande
wirken als Grundwasserleiter. Eine nicht unbedeutende Rolle spielen, besonders im Stadtzentrum,
anthropogene Auffüllen (durch menschliche Tätigkeit umgelagerte Materialien, v. a. Bauschutt) und
die durch Bergbautätigkeit ausgeräumten Areale. Im tieferen Untergrund stehen tertiäre Sande, Schluffe
und Tone sowie prätertiäre Grauwacken- bzw. deren Zersatz an.
2 Untersuchungsansatz und Arbeitsschritte
Für die ArcGIS-basierte Erstellung der Bodenaggressivitätskarten galten folgende Rahmenbedingungen:
• Die Untersuchung zielt auf die hauptsächlich durch die KWL verwendeten Rohrleitungswerkstoffe
Eisen, Stahl und Beton.

Wolfram Heidenfelder & Jochen Rascher
• Die Karten bewerten die mittlere Aggressivität der Böden und Grundwässer gegenüber diesen
Werkstoffen bis 6 m Tiefe.
• Innerhalb dieser Teufenlage werden zwei Hauptleitungsbereiche ausgehalten: 1-3 m (Trinkwasserleitungen)
und 3-6 m (Abwasserleitungen).
• Die Bewertung der Aggressivität der Böden und Grundwässer gegenüber den Zielwerkstoffen
erfolgt nach DIN 50929, Teil 3 für Eisen und Stahl (DIN 1985) sowie nach E DIN 4030, Teil
2 für Beton (DIN 1991).
• Einflüsse des Verfüllmaterials von Leitungsgräben und temporäre sowie lokal eng begrenzte
Boden- und Grundwasserkontaminationen sind nicht berücksichtigt.
Der methodische Grundansatz zur Erstellung der Bodenaggressivitätskarte stellt sich in der Abfolge
der Arbeitsschritte wie folgt dar:
1) Datenrecherche (räumliche Verteilung der geologischen Einheiten, DGM, Grundwasserflurabstand,
Wasserqualität, Bodenqualität)
2) Erhebung fehlender Qualitätsdaten per Feldbeprobung und Laboranalyse
3) Einstufung der Analysenergebnisse in eine Bodenaggressivitätsmatrix (mittlere Aggressivität
der Substrate der geologischen Einheiten gegenüber den Zielwerkstoffen)
4) Verschneidung der verschiedenen Substrateinheiten in den beiden Hauptleitungstiefen (1-3
und 3-6 m) mit der Bodenaggressivitätsmatrix zu einer Bodenaggressivitätskarte ohne Grundwassereinfluss
5) Identifikation von grundwasserbeeinflussten Rohrleitungsbereichen im Stadtgebiet Leipzig
6) Zuweisung von Grundwasseraggressivitäten zu den grundwasserbeeinflussten Bereichen
7) Verschneidung der Aggressivitäten der grundwasserbeeinflussten Bereiche mit der Bodenaggressivitätskarte
aus Schritt 4 zur fertigen Bodenaggressivitätskarte mit Grundwassereinfluss
3 Datengrundlage und Datenaufbreitung
Für die Erstellung der Bodenaggressivitätskarte war die Anschaffung/Erhebung der folgenden Daten
verschiedenster Art und Herkunft und deren Aufbreitung für die GIS-Analysen notwendig.
3.1 Hydrogeologischer Atlas
Für die Untersuchung stand mit dem durch GEOmontan GmbH Freiberg entwickelten Hydrogeologischen
Atlas der Stadt Leipzig (FISCHER et al. 2005) ein ArcGIS-basiertes Kartenwerk in den Maßstäben
1:10.000 bzw. 1:5.000 zur Verfügung, mit dem geometrische, lithologische, stratigraphische und
hydrogeologische Eigenschaften der quartären Grundwasserleiter und der auflagernden Deckschichten
flächendeckend für Leipzig abgebildet werden (Abb. 1).
Abb. 1: Hydrogeologischer Atlas mit Karten zu Verbreitung und Mächtigkeit der Grundwasserleiter
und Deckschichten

9. Freiberger Forum Geoinformationstechnologie
Diese Karte beruht auf ca. 15.000 recherchierten und geologisch (stratigraphisch, hydrogeologisch)
bewerteten Bohrungen als Stützstellen. Das entspricht einer mittleren Bohrungsdichte von etwa 51
Bohrungen pro Quadratkilometer. Konzentrationen im Stadtzentrum und Ausdünnungen in den landwirtschaftlich
geprägten Stadtrandbereichen sind jedoch in Abb. 2 sichtbar.
Abb. 2: Bohrungen als Stützstellen
Das dem Kartenwerk zugrunde liegende und in Abb. 3 dargestellte geologische Modell orientiert sich
an der Gliederung der quartären Sedimente in der Leipziger Tieflandsbucht i. S. v. Eissmann (u. a.
EISSMANN & LITT 1994)
Abb. 3: Geologisches Modell der Stadt Leipzig (nach Eissmann)

Wolfram Heidenfelder & Jochen Rascher
3.2 Digitales Geländemodell (DGM)
Es stand ein DGM des Stadtgebietes von Leipzig zur Verfügung, das um ca. 60.000 KWL-
Vermessungsdaten von Kanaldeckelhöhen mit Höhengenauigkeiten im Zentimeterbereich ergänzt
wurde.
3.3 Grundwasserhöhenmodell
Mit der Grundwasserstichtagsmessung Mai 2007 für den Großraum Leipzig lagen die Hydroisohypsen
des Hauptgrundwasserleiters und des oberen Grundwasserleiters als analoge Karte vor (REGIERUNGS-
PRÄSIDIUM LEIPZIG 2007). Diese wurden manuell vektorisiert und in ein digitales Grundwasserhöhenmodell
umgewandelt.
3.4 Daten zur Grundwasserqualität
Das Sächsische Landesamt für Umwelt, Landwirtschaft und Geologie hat freundlicherweise etwa 1000
digitale Grundwasserqualitätsdaten aus Dauerbeobachtungspegeln zur Verfügung gestellt, von denen
ca. 100 für die vorliegende Aufgabenstellung nutzbar waren und nach DIN 50929 und E DIN 4030
(Abb. 4) in Aggressivitätsklassen eingeordnet werden konnten.
Abb. 4: Parameter zur Berechnung der Grundwasseraggressivität
3.5 Daten zur Bodenqualität
Für die Bewertung der Bodenaggressivität nach DIN 50929 und E DIN 4030 sind Daten zur Bodenqualität
notwendig. Es standen jedoch auch nach ausführlicher Archivrecherche keine homogenisierbaren
Daten zur Verfügung, so dass eine Neubeprobung jeder geologischen Einheit (vgl. Abb. 1) vonnöten
war. Aus den Tagesbaustellen der KWL wurden aus jedem Grundwasserleiter, jeder Deckschicht
und aus den Auffüllen über das Stadtgebiet verteilt je 5-10 Proben genommen (siehe Bsp. in
Abb. 5) und nach DIN 50929 und E DIN 4030 (Abb. 6) hinsichtlich ihrer Aggressivität gegenüber den
Leitungswerkstoffen analysiert.
Anmerkung: Erstaunlicherweise zeigten sich trotz des geringen Probenumfanges zwischen den einzelnen
Proben aus denselben Grundwasserleitern Ähnlichkeiten im Chemismus, obwohl die Probenahmeorte
oft mehrere Kilometer voneinander entfernt lagen.

9. Freiberger Forum Geoinformationstechnologie
Abb. 5: Bodenprobenahme (Beispielaufschluss)
Abb. 6: Parameter zur Berechnung der Bodenaggressivität
4 ArcGIS-Analysen und Modellbildung
Die aus den Analysenergebnissen der Bodenproben berechneten Aggressivitäten wurden für jede geologische
Einheit gemittelt und in einer sogenannten Bodenaggressivitätsmatrix (Abb. 7) zusammengeführt.

Wolfram Heidenfelder & Jochen Rascher
Abb. 7: Bodenaggressivitätsmatrix
Aus den Ergebnissen wurde eine erste Bodenaggressivitätskarte ohne Grundwassereinfluss generiert.
Die dafür notwendigen Verschneidungsprozesse sind vom rechnerischen Ansatz her eher simpel. Da
jedoch zehntausende Polygone aller Größen miteinander verschnitten und die Ergebnisse auf 500 m²-
Polygone bereinigt werden mussten, betrug der Aufwand an Rechenzeit mit einem leistungsstarken PC
pro Zielwerkstoff mehrere Tage.
Im Stadtgebiet von Leipzig treten flächenmäßig bedeutsame Areale auf, in denen Rohrleitungen im
Einflussbereich des Grundwassers liegen. Im Gegensatz zu den Arealen mit meist trockener Bodensubstanz
herrschen in den grundwasserbeeinflussten Arealen im Leitungsbereich (1-3 m und 3-6 m
Teufe) veränderte Bedingungen für die Rohrleitungskorrosion. Um eine aussagekräftige Bodenaggressivitätskarte
zu entwickeln, mussten also Einflüsse des Grundwassers auf die Bodenaggressivität berücksichtigt
werden. Dafür wurde nach folgendem Muster zunächst eine Grundwasserflurabstandskarte
generiert:
(DGM + Kanaldeckelhöhen) – Grundwasserhöhenmodell = Grundwasserflurabstandskarte
Es folgte die Selektion der grundwasserbeeinflussten Leitungsbereiche (1-6m Tiefe, vgl. Abb. 8).
Abb. 8: Im Leitungsbereich grundwasserbeeinflusste Areale
Der Bodenaggressivitätskarte ohne Grundwassereinfluss wurden im letzten Arbeitsschritt die nach
DIN 50929 und E DIN 4030 berechneten Grundwasseraggressivitäten (Parameter lt. Kapitel 3.4) aufgesetzt.
Aufgrund der bisher geringen Probendichte wurde an dieser Stelle keine Interpolation vorge-

9. Freiberger Forum Geoinformationstechnologie
nommen, sondern es wurden um die einzelnen Messstellen 500 m-Pufferzonen gleicher Wertebereiche
gebildet.
5 Ergebnisdarstellung – Bodenaggressivitätskarte Stadt Leipzig
Nachfolgend ist die fertige Bodenaggressivitätskarte am Beispiel des Werkstoffes Eisen dargestellt
(Abb. 9 und 10). Sie wurde als digitales Kartenwerk ausgefertigt und ist bis zu einem Maßstab von
1:200 stufenlos zoombar.
Abb. 9: Bodenaggressivitätskarte Stadt Leipzig für Eisenwerkstoffe, 1-3 m Tiefe
Abb. 10: Bodenaggressivitätskarte Stadt Leipzig für Eisenwerkstoffe, 3-6 m Tiefe

Wolfram Heidenfelder & Jochen Rascher
6 Fazit und Ausblick
Die vorangegangen Ausführungen stellen ein Beispiel dafür dar, wie man ein praxisbezogenes, technisches
Problem mit ArcGis-gestützten Methoden und unter Einbeziehung geowissenschaftlicher
Grundlagenkenntnisse lösen kann. Im vorliegenden Fall wurde gezeigt, wie mit einer Vielzahl geographischer,
geologischer sowie wasser- und bodenchemischer bzw. -physikalischer Daten verschiedensten
Ursprungs eine flächendeckende Bewertung des Untergrundes des Stadtgebietes von Leipzig hinsichtlich
seiner Aggressivität gegenüber den Rohrleitungen des Kommunalen Wasserversorgers, der
KWL GmbH, durchgeführt werden kann.
Dabei wurde auch deutlich, dass die aussagekräftige Projektion punktbezogener Daten in die Fläche
eine besondere Herausforderung darstellt, insbesondere, wenn ein Untersuchungsgebiet geologisch so
heterogen gestaltet ist, wie das Stadtgebiet von Leipzig.
Die vorliegende Bodenaggressivitätskarte soll deshalb nicht als vollendetes Bewertungsinstrument
verstanden werden, sondern als zukünftig fortlaufend zu qualifizierendes. Gegenwärtig findet anhand
zahlreicher Rohrleitungserneuerungen die Prüfung der Bodenaggressivitätskarte auf Plausibilität statt.
Die Baustellen der KWL GmbH werden jedoch auch künftig zur Proben- und Informationsgewinnung
genutzt, um mittelfristig eine umfangreiche, aussagekräftige Datenbank zu entwickeln. Letztlich wird
die Bodenaggressivitätskarte auch eine Neuauflage erfahren.
7 Quellenverzeichnis
DIN DEUTSCHES INSTITUT FÜR NORMUNG E. V. (Ed., 1985): DIN 50929 Teil 3, Korrosionswahrscheinlichkeit
metallischer Werkstoffe bei äußerer Korrosionsbelastung, Rohrleitungen und Bauteile in Böden und Wässern.
– Beuth Verlag GmbH, Berlin.
DIN DEUTSCHES INSTITUT FÜR NORMUNG E. V. (Ed., 1991): E DIN 4030 Teil 2, Beurteilung betonangreifender
Wässer, Böden und Gase – Entnahme und Analyse von Wasser- und Bodenproben. – Beuth Verlag GmbH,
Berlin.
EISSMANN, L. & LITT, T. (1994): Das Quartär Mitteldeutschlands. - Ein Leitfaden und Exkursionsführer. Mit
einer Übersicht über das Präquartär des Saale-Elbe-Gebietes. – Altenburger Naturwiss. Forsch., 7: 1-458; Altenburg.
FISCHER, J.; RASCHER, J.; ESCHER, D.; DUTSCHMANN, U.; KÄSTNER, S. (2005): Hydrogeologischer Atlas Stadt
Leipzig, Quartäre Grundwasserleiter 1:50.000. Amt für Umweltschutz Stadt Leipzig (Ed.).
REGIERUNGSPRÄSIDIUM LEIPZIG (2007): Grundwasserstichtagsmessung Mai 2007 Großraum Leipzig – Hydroisohypsen
des Hauptgrundwasserleiters (HGWL) und des oberen Grundwasserleiters (OGWL). – unveröff.,
Regierungspräsidium Leipzig, Umweltfachbereich.

Topologische Datenbanken – Ein Konzept zur Vereinheitlichung
von Geodaten
Norbert Paul
Geodätisches Institut Karlsruhe, KIT, Engesser Straße 7, 76131 Karlsruhe, norbert.paul@kit.edu
Räumliche Daten sind stets eine Repräsentation einer Zerlegung des euklidischen Raums in endlich
viele Teile und der Information, wie diese untereinander verbunden sind. Eine derartige Zerlegung im
streng mathematischen Sinn erzeugt dann eine Topologie für die räumlichen Komponenten. Diese
kann durch eine Relation repräsentiert und folglich als relationale Datenbank gespeichert werden,
womit die so gespeicherten Daten selbst zu topologischen Räumen werden. Dadurch kann das
relationale Modell unter Zuhilfenahme der Theorie der topologischen Konstruktionen erweitert
werden, und die aus der relationalen Algebra bekannten Abfrageoperationen bekommen jeweils eine
entsprechende räumliche Variante, welche wiederum mit Mitteln der relationalen Algebra berechnet
werden kann. Diese Übertragung des relationalen Datenmodells auf topologische Daten könnte helfen,
räumliche Datenhaltung zu vereinfachen und die bekannten Probleme dateibasierter Datenhaltung –
insbesondere Versionskontrolle und Konvertierung zwischen unterschiedlichen Formaten –
vermeiden.
Spatial data is always some representation of a partitioning of the Euclidean space into a finite number
of parts together with connectivity information among these parts. Such a partitioning in the strict
mathematical sense then yields a topology for its components. This topology can be represented by a
relation and, hence, can be stored into a relational database—thus turning spatial data itself into a
topological space. Then by application of the theory of topological constructions the relational model
can be extended, and each query operator from relational algebra gets its spatial counterpart which
itself can be computed using relational queries. This transferring the relational model into a
topological model should help to simplify spatial data storage and avoid the well-known problems of
file-based data storage—in particular ease problems with version control and conversion between
different formats.
1 Einleitung
Jedes Modell für räumliche Daten umfasst Datentypen für elementare räumliche Objekte wie Punkt,
Linie, Fläche und eine Methode, die topologischen Beziehungen unter diesen elementaren Objekten zu
speichern. Zudem muss stets die Geometrie dieser Objekte modelliert werden, und es ist erforderlich
den Objekten weitere fachspezifische Daten, wie z.B. Materialeigenschaften, zuzuordnen. Wir wollen
hier geometrische Informationen zunächst vereinfachend als weitere fachspezifische Daten auffassen
und uns hier auf den topologischen Aspekt der Modellierung beschränken. Nun gibt es eine Vielzahl
von Ansätzen, topologische Informationen zu speichern. So gibt es z.B. Winged-Edge, DIME,
G-Maps, die topology-resources in ISO-STEP 10303-42 oder das Topologie-Schema von GML. Diese
Heterogenität der Ansätze erschwert den Austausch von Daten zwischen raumbezogenen
Anwendungsprogrammen (PAUL 2008).
Es kann jedoch gezeigt werden, dass der sehr einfache Inzidenzgraph als topologisches Datenmodell
vollständig ausreicht. Von diesem sind zwei Varianten möglich: Ein einfacher Inzidenzgraph, der
topologische Beziehungen von Elementen modelliert und eine erweiterte Variante mit der die
Orientierung dieser Elemente wie etwa „Vorderseite“ und „Rückseite“ ausgedrückt werden kann. Die
eine Variante entspricht der mengentheoretischen Topologie während die Variante mit den
Orientierungen zur algebraischen Topologie gehört. Den mengentheoretischen Inzidenzgraphen
zusammen mit den noch zu definierenden Morphismen bezeichnen wir als Topologischen Datentyp,

9. Freiberger Forum Geoinformationstechnologie
die algebraische Variante hingegen als Relationalen Komplex. Die Einfachheit der Modelle erlaubt es
wiederum, komplexe Operationen durchzuführen, da die Sicht auf diese nicht durch eine unnötige
Komplexität des Modells selbst verstellt wird. Insbesondere werden wir hier eine topologische
Variante der relationalen Algebra für topologische Datentypen vorstellen.
2 Grundlagen
Ein topologischer Raum ist eine Menge von Punkten zusammen mit derjenigen Menge von besonders
ausgezeichneten Teilmengen, die jeden ihrer Punkte „vollständig umgeben“. Diese Teilmengen
definieren (bzw. sind) die topologische Struktur des Raums.
Definition (Topologischer Raum) Sein X eine Menge und TX eine Menge von Teilmengen von X. Dann
bezeichnet man TX als eine Topologie für X, wenn TX folgende Eigenschaften hat:
(1) Die Vereinigung jeder Teilmenge von TX ist Element von TX.
(2) Der Schnitt jeder endlichen Teilmenge von TX ist Element von TX.
Das Paar X = (X, TX) heißt dann topologischer Raum. Eine Menge A ∈ TX bezeichnet man als offen in
(X, TX).
Man beachte, dass die leere Menge als Vereinigung der leeren Menge und die Menge X als Schnitt der
leeren Menge jeweils Element von TX und somit beides offene Mengen in X sind. Ein Beispiel für
topologische Räume ist das Paar (X, 2 X ), wobei 2 X die Potenzmenge von X bezeichnet. Jede andere
Topologie für X ist eine Teilmenge von 2 X . Umgekehrt ist auch die Menge {Ø, X} eine Topologie für
X und diese ist wiederum selbst Teilmenge jeder Topologie für X. Jede andere Topologie für X liegt
also zwischen den beiden Extremfällen 2 X , der diskreten Topologie, und {Ø, X}, der indiskreten
Topologie.
Der topologische Raum, der aller räumlichen Datenmodellierung zugrunde liegt, ist der euklidische
Raum: Der drei- (bzw. n-) dimensionale reelle Vektorraum mit der euklidischen Abstandsfunktion
d(( x,
y,
z),
( u,
v,
w))
− w
2
2 2
= ( x − u)
+ ( y − v)
( z )
(1)
Seine Topologie ist durch diese Abstandsfunktion wie folgt definiert:
Definition (metrische Topologie) Sei X eine Menge mit einer Abstandsfunktion (Metrik) d:X²→IR. Sei
x ∈ X und r>0 eine reelle Zahl. Dann heißt die Menge K(x, r) = { k ∈ X | d(x, k) < r } die offene
Kugel um x∈ X mit Radius r. Sei nun K = { K(x,r) | x ∈ X, r > 0 } die Menge aller offenen Kugeln in
X. Dann ist Td, die Schnittmenge aller Topologien für X, welche K als Teilmenge enthalten, die von d
induzierte Topologie für X.
Man kann sich leicht überlegen, dass Td in der Tat eine Topologie ist oder dies in (HERRLICH 1986)
nachlesen. Es werden hier generell keine mathematischen Aussagen bewiesen sondern jeweils auf
Fundstellen für Beweise verwiesen.
Man beachte nun die auffällige Asymmetrie der zwei Bedingungen für Topologien: Es wird (1)
gefordert, dass die Vereinigung beliebiger Teilmengen von TX Element von TX ist während (2)
ähnliches nur beim Schnitt endlich großer Teilmengen von TX fordert. Wenn wir nun bei Eigenschaft
(2) verstärken, erhalten wir eine für die Datenmodellierung interessante Klasse topologischer Räume:
Definition (Alexandroff-Raum) Sei (X, TX) ein topologischer Raum. Dann heißt TX Alexandroff-
Topologie und (X, TX) Alexandroff-Raum, wenn gilt:
(2’) Der Schnitt jeder Teilmenge von TX ist Element von TX.
Alexandroff-Räume haben zwei bemerkenswerte Eigenschaften: Erstens ist eine Alexandroff-
Topologie durch eine Relation R⊆X×X eindeutig bestimmt und kann damit leicht als Beziehungstyp in
einer relationalen Datenbank gespeichert werden. Zweitens ist die Eigenschaft (2') für endliche
Mengen X stets erfüllt. Sobald wir also endliche Datenmengen speichern, haben wir auch sofort ein
Verfahren, jede beliebige Topologie dazu in Form einer weiteren Relation abzuspeichern.

Norbert Paul
Ein wichtiges Instrument topologischer Räume untereinander zu vergleichen sind die stetigen
Abbildungen:
Definition (stetige Abbildung) Seien (X, TX) und (Y, TY) zwei topologische Räume und sei f:X→Y eine
Abbildung (oder Funktion). Dann heißt f stetig, wenn das Urbild f –1 (B) jeder (offenen) Menge B ∈ TY
eine (offene) Menge in TX ist. Stetige Abbildungen notiert man f:(X, TX)→(Y, TY).
Unter Urbild einer Menge B⊆Y bezüglich einer Abbildung f:X→Y versteht man die Menge aller
Elemente x ∈ X, deren Bild f(x) Element von Y ist: f –1 (B) = { x ∈ X | f(x) ∈ Y }.
Ein wichtiges Beispiel für stetige Abbildungen ist die identische Abbildung idX:X→X, die jedes
Element in X auf sich selbst abbildet: idX(a) := a. Sie ist stets stetig – also idX : (X, TX)→(X, TX) – von
einem topologischen Raum (X, TX) zu sich selbst. Dabei müssen die Topologien im Definitions- und
im Wertebereich übereinstimmen.
Stetige Abbildungen haben nun folgende Eigenschaften:
Satz (Stetige Abbildungen sind Morphismen) Seien W, X, Y und Z topologische Räume und f:W→X,
g:X→Y und h:Y→Z stetige Abbildungen. Dann ist die Abbildungskomposition g○f:W→Y mit
g○f(x) = g(f(x)) ebenfalls eine stetige Abbildung, und es gilt h○(g○f) = (h○g)○f und idX○f = f = f○idW.
Damit lassen sich nun topologische Räume vergleichen und der Begriff „topologische Eigenschaft“
definieren:
Definition (Homöomorphismus) Seien X und Y zwei topologische Räume und sei f:X→Y eine stetige
Abbildung. Dann heißt f Homöomorphismus, falls es eine stetige Abbildung g:Y→X zurück gibt, so
dass gilt g○f = idX und f○g = idY. Zwei topologische Räume heißen homöomorph, falls ein
Homöomorphismus zwischen ihnen existiert.
Jede Eigenschaft, die zwei topologische Räume soweit unterscheidet, dass sie nicht homöomorph
zueinander sind, ist eine topologische Eigenschaft.
Wir haben also einerseits den unendlichen euklidischen Raum mit seiner Topologie und andererseits
wollen (und können) wir endliche topologische Räume speichern. In welcher Beziehung stehen nun
diese beiden Räume? Zunächst beobachten wir, dass beim räumlichen Modellieren der euklidische
Raum in endlich viele Teile zerlegt wird:
Definition (Zerlegung) Sei X eine Menge und Q eine Menge von Teilmengen von X. Dann heißt Q
Zerlegung von X, falls je zwei Mengen in Q entweder gleich oder disjunkt sind und die Vereinigung
von Q gleich X ist.
Dann gibt es zu jedem Punkt a in X eine eindeutig bestimmte Teilmenge [a] ∈ Q, die a enthält, also
eine Abbildung π:X→Q, π(a)=[a]. Wir haben nun also eine Abbildung, die von einem topologischen
Raum X in eine Menge Q geht, aber wir haben keine Topologie für Q. Nun suchen wir eine solche
Topologie, die möglichst mit der Topologie von X übereinstimmt und π stetig macht:
Definition (Finaltopologie) Sei X = (X, TX) ein topologischer Raum, Y eine Menge und f:X→Y eine
Abbildung. Dann ist Tf = { B×Y | f - –1 (B) ∈ TX } eine Topologie für Y, die Finaltopologie bezüglich X
und f.
Die Finaltopologie einer Zerlegung heißt auch Quotiententopologie. Es gibt auch noch die duale
Situation der initialen Topologie und die Verallgemeinerung für mehrere Räume und Abbildungen die
simultan auf eine Menge einwirken. Dies ist Grundlage der Theorie der topologischen Konstruktionen
(HERRLICH 1986. S. 87ff) und wird später benutzt, um die Operatoren der relationale Algebra auf
topologische Räume zu erweitern.
Beispiel (Kanten und Knoten) Wir zerlegen die reelle Gerade IR in drei offene Intervalle und zwei
Punkte
a = ]-∞,-1[ , b = ]-1,+1[, c = ]+1,+∞[
p = {-1}, q = {+1}.

9. Freiberger Forum Geoinformationstechnologie
Wir haben also die Abbildung
⎧ a : x < −1
⎪
{ x}
π ( x)
= ⎨
⎪ c
⎪
⎩ b
:
:
:
| x | = 1
x > + 1
sonst
(2)
Man beachte, dass stets gilt: x ∈ π(x). Dann entsteht folgende Topologie Tπ für {a,b,c,p,q}:
Tπ = {{}, a, b, c, apb, bqc, ab, ac, abqc, bc, apbc, abc, apbqc}, wobei ein Wort wie z.B. apb für die
Menge {a, p, b} steht. Man beachte, dass z.B. jede offene Menge, die den Punkt p enthält auch den
Punkt b enthält. Dies drückt aus, dass die Kante b von p begrenzt wird. Analoges gilt für die
Beziehung von Punkt q zu den Kanten b und c.
3 Topologische Datentypen und -banken
Wir werden zunächst etwas alten Wein in neue Schläuche füllen und später dann sehen, dass dabei in
der Tat etwas Neues herauskommt:
Definition (Topologische Datenbank) Sei X eine Menge und R⊆X×X eine Relation auf X. Dann
bezeichnen wir das Paar (X, R) als topologischen Datentyp. Eine Familie {(X1, R1), … , (Xn, Rn)} von
topologischen Datentypen bezeichnen wir als topologische Datenbank.
Dies ist bisher nur eine neuer Namen für „einfacher gerichteter Graph“, hier aber interpretiert als
topologischer Raum. Die Menge X entspricht dabei der Punktmenge und die Topologie wird durch die
Relation R wie folgt definiert:
Definition (Von Relation erzeugte Topologie) Sei X eine Menge und R⊆X×X eine Relation auf X.
Dann ist die Menge TR = { A ⊆ X | x R a und a ∈ A ⇒ x ∈ A } eine Topologie für X, die wir als die
von R erzeugte Topologie bezeichnen.
Dies ist in der Tat eine Topologie und umgekehrt wird jede Alexandroff-Topologie T von einer
derartigen Relation erzeugt (PAUL 2010). Eine weitere Rechtfertigung für das „Umbenennen“ der
simplen gerichteten Graphen in „topologische Datentypen“ ist die relationale Entsprechung der
stetigen Abbildungen, die wir hier als stetige Datenbankabbildungen bezeichnen.
Definition (stetige Datenbankabbildung) Seien (X, R) und (Y, S) zwei topologische Datentypen und sei
f:X→Y eine Abbildung. Dann heißt f stetige Datenbankabbildung, wenn gilt: a R b ⇒ f(a) S * f(b).
Analog zur Konvention bei den stetigen Abbildungen notieren wir stetige Datenbankabbildungen mit
f:(X, R)→(Y, S).
Dabei ist S * die transitive und reflexive Hülle von S: Zwei Punkte a und b stehen in dieser Relation
a S * b, wenn es einen gerichteten Pfad a = y1 S … S yn = b von a nach b in S gibt, insbesondere gilt
a S * a für jeden Punkt a. Man kann zeigen, dass (1) die stetigen Datenbankabbildungen genau die
stetigen Abbildungen zwischen Alexandroff-Räumen sind und dass (2) Stetigkeit im Allgemeinen das
Berechnen der transitiven Hülle (manchmal auch „rekursiver Verbund“ genannt) erfordert. Mit
„Datenbankabbildung“ meinen wir jede Art von Beziehung zwischen Relationen einer relationalen
Datenbank, die eine Abbildungen bilden, also etwa 1:n Fremdschlüsselbeziehungen oder – ganz
wichtig – die Beziehung zwischen den Eingaberelationen und der Ausgaberelation einer
Datenbankabfrage.
4 Topologische relationale Algebra
Man kann durch eine Abbildung nicht nur die Topologie des Definitionsbereichs auf den Wertebereich
als Finaltopologie übertragen sondern auch in umgekehrter Richtung die Topologie aus den
Wertebereich rückwärts in den Definitionsbereich „ziehen“. Beides wird nun verwendet, um die
Grundoperatoren der relationalen Algebra in topologische Konstruktionen zu überführen. Als derartige
Grundoperatoren betrachtet man üblicherweise (CODD 1990):
• Selektion: Auswahl gewisser Datensätze (Zeilen einer Tabelle)

Norbert Paul
• Projektion: Auswahl von Attributen (Spalten einer Tabelle)
• Umbenennung: Änderung von Attribut- oder Tabellennamen
• Kartesisches Produkt: Alle Kombinationen aller Datensätze aus mehreren Tabellen
• Vereinigung: Zusammenfassen von Tabellen deren Schemata kompatibel sind
• Schnittmenge von Tabellen mit kompatiblen Schemata
• Mengendifferenz von Tabellen mit kompatiblen Schemata
Zu jeder dieser Grundoperationen gibt es eine oder mehrere Abbildungen zwischen den
Eingaberelationen und der Ausgaberelation. Handelt es sich bei den Eingabedaten um topologische
Datentypen, haben wir also stets die Möglichkeit, eine Topologie für die Ausgaberelation zu
berechnen. Wir werden hier nun für jede der obigen Grundoperation aus der relationalen Algebra eine
Relation angeben, welch die Topologie für das Abfrageergebnis definiert. Wir notieren diese
topologische Variante eines Operators durch Unterstreichung.
Definition (topologische Selektion) Sei (X, R) ein topologischer Datentyp und P ein Prädikat für die
Elemente (Datensätze) in X. Dann bezeichnet σP(X) die Menge (Tabelle) der Datensätze von X, die das
Prädikat P erfüllen, also σP(X) = { x ∈ X | x erfüllt P }. Ohne Einschränkung sei R eine Tabelle in der
jeder Datensatz r = (x1, x2) in R aus zwei Kopien von Datensätzen x1, x2 in X besteht. Dann ist die
topologische Selektion definiert als
σP(X, R) = ( σP(X), R + ∩ σP(X)×σP(X) ).
Die obige Annahme für R wäre natürlich ein grober Verstoß gegen die Prinzipien des
Datenbankentwurfs, würde R in der Tat in dieser Form abgespeichert werden. Sie dient nur dazu, die
Definition zu vereinfachen und auf die Angabe der sonst zusätzlich notwendigen Verbundoperationen
verzichten zu können.
Die Inzidenzrelation der Selektion ist initial bezüglich der Inklusionsabbildung
iP:σP(X) → X; iP (x) := x,
die jeden Datensatz in der Ergebnistabelle auf sein Original in der Eingabetabelle abbildet. Die
entsprechende Topologie heißt auch Spurtopologie oder Teilraumtopologie. Sie kann im Allgemeinen
nicht ohne Verwendung der transitiven Hülle berechnet werden (BRADLEY & PAUL 2010).
Widmen wir uns der nächsten Operation:
Definition (topologische Projektion) Sei (X, R) ein topologischer Datentyp und A eine Teilmenge der
Attribute von X. Dann ist πA(X) die Menge der Datensätze πA(x), die aus x ∈ X entstehen, wenn man
nur Attributwerte für Attribute, die in A vorkommen, verwendet. Wir unterstellen wieder, R bestünde
aus Paaren von Datensätzen in X, und definieren die topologische Projektion
πA(X, R) = ( πA(X), πA×πA(R) ),
mit πA×πA(R) := { (πA(a), πA(b)) | a R b }.
Diese Operation kommt ohne transitive Hülle aus, da sie eine Finaltopologie für πA(X) berechnet.
Die Umbenennung können wir übergehen, da in einem realistischen Datenbankentwurf die
Inzidenzrelation der Eingaberelation für das Ergebnis einfach mitverwendet werden kann.
Das kartesische Produkt ist ein interessanter Sonderfall einer Initialtopologie.
Definition (relationaler Produktraum) Seien (X, R) und (Y, S) topologische Datentypen (mit disjunkten
Attributmengen). Dann ist X×Y das kartesische Produkt der Mengen X und Y, die Tabelle, die entsteht,
wenn wir je einen Datensatz x in X mit je einem Datensatz y in Y zu einem großen Datensatz xy
zusammenhängen. Dann ist der relationale Produktraum definiert durch
(X, R)×(Y, S) = ( X×Y, ∆X⊗S ∪ R⊗∆Y).
Hier ist ∆X⊗S die Relation {((x,a) (x,b)) | x ∈ X, a S b} und analog ist R⊗∆Y die Relation
{((a,y), (b,y)) | a R b, y ∈ Y}.

9. Freiberger Forum Geoinformationstechnologie
Die Inzidenzrelation des Produktraums erzeugt die Produkttopologie. Sie ist die Initialtopologie der
zwei Projektionsabbildungen π1(x,y) = x und π2(x,y) = y, kann jedoch ohne transitive Hülle berechnet
werden.
Kommen wir nun zu den mengentheoretischen Operationen Vereinigung und Schnitt. Zwei Relationen
sind vereinigungskompatibel, wenn sie das gleiche Relationenschema haben.
Definition (Vereinigung und Schnitt topologischer Datentypen) Seien (X, R) und (Y, S) zwei
vereinigungskompatible topologische Datentypen. Dann sind deren Vereinigung und Schnitt definiert
durch
(X, R)∪(Y, S) = (X∪Y, R∪S) und (X, R)∩(Y, S) = (X∩Y, R + ∩S + ).
Bei der Vereinigung können wir also die Inzidenzrelationen ebenfalls einfach vereinigen, während wir
beim Schnitt zuvor noch deren transitive Hüllen berechnen müssen.
Da uns so alle Grundoperatoren der relationalen Algebra für die topologischen Datenbanken zur
Verfügung stehen, haben wir ein relational vollständiges Abfragesystem.
5 Dimension
Es gibt keine allgemein verbindliche Definition von „topologischer Dimension“ sondern eine eigene
Dimensionstheorie mit mehreren alternativen Definitionen für „Dimension“ (ENGELKING 1995). Für
die topologischen Datenbanken schlagen wir folgenden Dimensionsbegriff vor:
Definition (Dimension Topologischer Datentypen) Sei (X, R) ein topologischer Datentyp. Ohne
Einschränkung sein R irreflexiv. Falls R azyklisch ist, dann ist dim(X, R) wie folgt rekursiv definiert:
dim ∅ = –1
dim(X, ∅) = 0
dim(X, R) = 1 + dim(X, {(b,c) ∈ R | Es gibt ein (a,b) ∈ R}) .
Diese Dimension entspricht der maximalen Länge eines gerichteten Pfades im Graph (X, R), und sie
entspräche auch genau der sogenannten kleinen induktiven Dimension (ENGELKING 1995), wenn man
deren Definition auf die Alexandroff-Räume ausweitete. Sie deckt sich auch mit dem, was durch
räumliche Datenmodellierung beabsichtigt ist. Zur Modellierung von 3D-Modellen benötigt man
topologische Datentypen von Dimension 3, bei 4D Raum-Zeit-Modellen ist deren Dimension 4.
6 Komplexe
Mit topologischen Datentypen allein wird keine Information über eine Orientierung ihrer Elemente
gespeichert. So hat z.B. eine Kante e, die von zwei Punkten a und b begrenzt ist, als topologischer
Datentyp zunächst keine Richtung. Um eine Orientierung festzulegen, etwa „e verläuft von a nach b“,
können wir die Inzidenzrelation um ein Vorzeichen erweitern, hier z.B. zu {(e,a,–1), (e,b,+1)}:
Definition(Relationaler Komplex) Eine Folge Xn, … X0 von Mengen und eine Folge Rn, … R1 von
partiellen Abbildungen Ri :⊆ Xi×Xi–1 → ZZ, aufgefasst als partielle Xi×Xi–1 -Ganzzahlmatrizen, heißt
relationaler Komplex von Dimension n, wenn für alle i = 2 … n das partielle Matrixprodukt Ri·Ri–1
nur Nullwerte enthält.
Das partielle Matrixprodukt Ri·Ri–1 :⊆ Xi×Xi–2 → ZZ ist dabei definiert durch
( x, z)
= R ( x, y)
⋅ R ( y, z)
Ri ⋅ Ri−1
∑ i
i−1
für alle (x,z) in Xi×Xi–2.
y∈Xi
−1
Es wird dabei nur über die y-Werte in Xi–1 aufsummiert, für die es einen (x,y)-Eintrag in Ri und einen
(y,z)-Eintrag in Ri–1 gibt. Anstelle der sonst üblichen Festlegung ∑x ∈ ∅ = 0 legen wir hier fest, dass die
Summe über die leere Menge nicht definiert ist.
Die Forderung, dass diese Matrixprodukte nur Nullwerte enthalten dürfen, entspricht der
fundamentalen Eigenschaft von Komplexen in der Algebraischen Topologie: Der Rand des Randes ist
null (HATCHER 2002), denn „läuft“ zyklisch um das Element „herum“ und hat somit selbst keinen
Rand, wie etwa die Randlinie um eine Fläche oder die Oberfläche um ein Volumen.

Norbert Paul
Damit können topologische Komplexe ebenfalls als relationalen Datenbanken modelliert werden. Es
ist dabei möglich, die Mengen Xi in einer einzigen Relation zu speichern und die Dimension i der
Elemente durch ein Dimensionsattribut zu kennzeichnen. Die Dimension des modellierten Raums
ändert sich dann dynamisch mit den Daten. Die Alternative, jeweils eine Tabelle pro Dimension, ist
auch möglich, fixiert dann eine obere statische (wenn auch beliebig große) Dimensionsgrenze und
entspricht im Wesentlichen den klassischen Vertex–Edge–Face–Volume Schemata in 3D-Modellen.
Die höhere Flexibilität beim Modellieren spricht für die dynamische Variante, insbesondere bei der
Raum-Zeit-Modellierung. Außerdem ist es bei nur einem Entitätstyp leichter, stetige Abbildungen
zwischen Räumen zu modellieren um z.B. Objektreferenzen zwischen verschiedenen
Verfeinerungsstufen (LOD, Levels of Detail) darzustellen.
7 Anwendungsskizze
Wir wollen hier nun ein einfaches topologisches Datenbankschema für geologische Daten skizzieren,
weniger um einen konkreten Vorschlag für ein derartiges Schema zu machen sondern vielmehr als
Illustration der Möglichkeiten des topologischen Modells. Dieses Schema ist generisch gehalten und
könnte in ähnlicher Form auch für andere raumspezifische Anwendungen Verwendung finden. Wir
werden hier ein relationales Schema angeben – dessen Implementierung als objektorientiertes
Datenbankschema steht natürlich nichts entgegen.
Zunächst ist die Menge der Räume zu spezifizieren:
Raum(id, name, …, projekt, …)
Jeder Raum hat eine id, einen Namen und weitere Attribute wie etwa die Zuordnung zu einem Projekt,
etc. Wir kennzeichnen Primärschlüssel (hier Raum.id) durch Unterstreichung.
Ein wichtiges Attribut ist etwa, ob der Raum durch tatsächliche Erhebung (Sample, z.B. Bohrung,
Seismik) oder durch Modellierung („Geofantasie“) entstanden ist.
Für die nun folgende Modellierung sollte ein räumliches DBMS (DatenBankManagementSystem)
Standardkonstrukte und -abfragen anbieten und einige der hier dargestellten Aspekte verbergen:
Jeder Raum unterliegt einer Versionsgeschichte. Dies ist nichts anderes als ein gerichteter Graph bzw.
eine Familie von gerichteten Graphen, indiziert durch Raum-Objekte.
Version(raum:Raum.id, nr, … , datum, bearbeiter, …)
VersionsHistorie(raum, von, nach)
VersionsHistorie hat Fremdschlüssel (raum, von) → Version(raun, nr) und (raum, nach) →
Version(raum, nr).
Die Notation attribut:Tabelle.att kennzeichnet, dass attribut an einer Fremdschlüsselbeziehung zum
Attribut att der Tabelle Tabelle teilnimmt. Wir werden von nun an Fremdschlüsselbeziehungen
andeuten, indem Attributnamen dem Namen der referenzierten Relation gleichen. Wir schreiben also
kurz „raum“ statt „raum:Raum.id“
Zunächst ermöglichen wir mehrere Detaillierungsstufen (Levels Of Detail) für einen Raum:
LOD(raum, id, verfeinert:LOD, maszstab, … )
mit Fremdschlüssel (raum, verfeinert) -> LOD(raum, id)
Kommen wir zum eigentlichen topologischen Modell: der topologische Datentyp 〈Objekt, Rand〉 für
die Ausprägung der Räume. Diesen bauen wir hier schrittweise als Relationalen Komplex mit
dynamischer Dimension auf:
Objekt0(id, dim, … ),
Rand0(zelle:Object, rand:Object, seite:Integer).
Wenn wir für jedes Objekt den zugeordneten Raum, das LOD und die Version zuordnen, erhalten wir
Objekt1(raum, lod, version, id, dim,… ),
Rand1(raum, lod, zver, zelle, frver, rand, seite).

9. Freiberger Forum Geoinformationstechnologie
Wobei mit den Attributen „Rand.raum“ und „Rand.lod“ über die Fremdschlüsselbeziehungen
(raum,lod,zver,zelle)→Objekt und (raum,lod,frver,rand)→Objekt (jeweils auf den Primärschlüssel
von Objekt) die Inzidenzrelation realisiert wird. Damit haben wir eine Familie von disjunkten
topologischen Räumen, mit Raum×LOD als Indexmenge. Die Inzidenzrelation ist
versionsübergreifend, um bei lokalen Änderungen nicht große unveränderte Bereiche redundant
kopieren zu müssen. Dies erfordert aber, zu definieren, welches Objekt durch ein neueres Objekt
ersetzt wird. Eine der Möglichkeiten ist, Objekten mit einem Attribut maxver:Version, eine Art
Verfallsdatum, zuzuordnen:
Objekt2(raum,lod,version,maxver,id, dim,… ).
Um die Detaillierungsstufen untereinander in Beziehung zu setzen, werden Attribute „spezialisiert“,
„version“ und „grLOD“ („gröberer LOD“) definiert und das endgültige Objektschema ist:
Objekt(raum,lod,version,maxver,id, dim, spezialisiert, grLOD, version, … )
Dabei ist die Beziehung zwischen zwei Detaillierungsstufen ein stetiger und monotoner (siehe
KURATOWSKI 1968) Fremdschlüssel vom feineren zum gröberen Raum. Es ist auch möglich, ein
Schema zu definieren, anhand dessen lokale Verfeinerungen möglich sind, etwa durch eine LODübergreifende
Inzidenzrelation analog zu den Versionen.
Schließlich unterstellen wir vereinfachend eine polyedrische (bzw. polytope) Struktur und speichern
nur die Punktkoordinaten als Entitätstyp Vertices(id, x,y,z,t). Dieser steht mit Objekten von Dimension
0 in einer 1:1 Beziehung. Das t-Attribut steht für den Zeitpunkt des Vertex im Falle einer 4D
Modellierung. Es kann bei 3D-Modellen entfallen.
8 Zusammenfassung
Die topologischen Datentypen sind eine sehr einfache Struktur und in jedem räumlichen Datenmodell
implizit vorhanden, oft jedoch durch weitere, häufig sehr komplexe, Strukturen verdeckt. Die
Einfachheit der topologischen Datentypen kann helfen, die Gesamtkomplexität eines räumlichen
Domänenmodells ohne Funktionsverlust zu reduzieren bzw. bei gleichbleibender oder sogar
geringerer Komplexität mehr Funktionalität, wie etwa räumliche Versionierung, raumzeitliche und
höherdimensionale Modellierung und eine Hierarchie von Detaillierungsgraden, in das Modell zu
integrieren. Die formale Spezifikation einer räumlichen Abfragesprache würde zudem ermöglichen,
viele Funktionen als Standard an ein künftiges räumliches bzw. raumzeitliches DBMS zu delegieren
und die Anwendungsprogramme von diesen Aufgaben zu entlasten. Insbesondere können dann
mehrere unterschiedliche Anwendungen auf einen gemeinsamen Datenbestand zugreifen – die Daten
wären also von den Anwendungsprogrammen entkoppelt.
9 Literatur
BRADLEY, P. E. & PAUL, N. (2010): Using the Relational Model to Capture Topological Information of Spaces –
The Computer Journal 53: 69 — 89.
CODD, E. F. (1990): The Relational Model for Database Management – Addison-Wesley.
ENGELKING, R. (1995): Theory of Dimensions, Finite and Infinite – Heldermann, Lemgo.
HATCHER, A. (2002): Algebraic Topology – Cambridge University Press.
HERRLICH, H. (1986): Topologie 1 : Topologische Räume – Heldermann, Berlin.
KURATOWSKI, K. (1968): Topology, Band II – Acad.Pr., 1968.
PAUL, N. (2010): Basic Topological Notions and their Relation to BIM – In: UNDERWOOD, J.& ISIKDAG, U. (Hg):
Handbook of Research on Building Information Modeling and Construction Informatics – Information Science
Reference.

Einarbeitung neuer Informationen in das 3D-Modell des
Geotektonischen Atlas für den deutschen Nordsee-Sektor
C. Schmidt, K. Lademann
Landesamt für Bergbau, Energie und Geologie, Hannover
Kurzfassung
Am Landesamt für Bergbau, Energie und Geologie (LBEG) wird derzeit ein geologisches 3D-Modell
aus den Daten des Geotektonischen Atlas von Nordwestdeutschland und dem deutschen Nordsee-
Sektor (Kockel et al. 1995, Baldschuhn et. al. 2001) flächendeckend für Niedersachsen und die
Deutsche Nordsee erstellt.
Der Geotektonische Atlas (GTA) entstand auf der Grundlage von Seismik- und Bohrungsdaten der
Erdöl- und Erdgasindustrie. Er beschreibt ausgewählte Horizonte des tieferen Untergrundes in
zweidimensionalen Isolinienplänen, Karten und Profilschnitten.
Für den Bereich der Deutschen Nordsee wird der Geotektonische Atlas durch das LBEG im Rahmen
des Gemeinschaftsprojektes "Geopotenzial Deutsche Nordsee" (GPDN), an dem die Bundesanstalt für
Geowissenschaften und Rohstoffe (BGR), das LBEG sowie das Bundesamt für Seeschifffahrt und
Hydrographie (BSH) beteiligt sind, seit Mai 2009 dreidimensional modelliert. Der Bereich des
sogenannten Entenschnabels, für den keine Informationen im GTA vorliegen, wird auf Basis neuerer
Daten in enger Zusammenarbeit mit der BGR im Projekt GPDN neu bearbeitet.
In dem Vortrag wird die bereits abgeschlossene Umsetzung des GTA für den Bereich der Deutschen
Nordsee vorgestellt. Der Geotektonische Atlas wurde möglichst eins zu eins umgesetzt. Dabei wurden
topologische Fehler, wie zum Beispiel Flächendurchdringungen, mit abgebildet. Die Rekonstruktion
der Raumlage, der zu den Störungsspuren gehörigen Störungsflächen, war auf Grundlage der Daten
des GTA nicht möglich. Mit Hilfe neuer Daten sollen Fehler beseitigt und die Störungsflächen
modelliert werden, wenn die dafür notwendige 3D-Seismik vorliegt (Abb. 1).
Abb.1: Ausschnitt aus einer 3D-Seismik mit interpretierten Störungen und einem interpretierten Horizont.
Des Weiteren wird gezeigt wie neu interpretierte Daten (3D- und 2D Seismik sowie Bohrungen) zur
Modellierung der geologischen Horizonte im Entenschnabel genutzt werden. Besonders in diesem

C. Schmidt + K. Lademann
Bereich liegt eine große Dichte von 3D-Surveys vor, was eine schlüssige Störungsflächen- und
Horizontmodellierung ermöglicht.
Referenzen
BALDSCHUHN, R., BINOT, F., FLEIG, S. & KOCKEL, F. (2001): Geotektonischer Atlas von
Nordwestdeutschland und dem deutschen Nordsee-Sektor: Strukturen, Strukturentwicklung,
Paläogeographie. - Geol. Jb., A153: 88 S.; Stuttgart (Schweizerbart).
KOCKEL, F., BALDSCHUHN, R., BEST, G., BINOT, F., FRISCH, U., GROSS, U., JÜRGENS, U., RÖHLING,
H.-G., SATTLER-KOSINOWSKI, S. (1995): Structural and palaeogeographical development of the
german north sea sector. - Beiträge zur Regionalen Geologie der Erde, 96 S.; Berlin - Stuttgart
(Gebrüder Bornträger)

Landesweite hydrogeologische 3D-Datenbank Sachsens
B. Torchala 1 , S. Etzold 1 , C. Block 2 , J. Richter 2
Beak Consultants GmbH, Am St. Niclas Schacht 13, 09599 Freiberg 1 (bernd.torchala@beak.de, 03731
781 358)
Sächsisches Landesamt für Umwelt, Landwirtschaft und Geologie, Halsbrücker Str. 31a, 09599 Freiberg
2
Im Rahmen mehrerer Projekte wurde eine 3D-Datenbank des hydrogeologischen Aufbaus des Landes
Sachsen realisiert. Dieses Projekt verfolgt im Wesentlichen zwei Ziele:
Praktikable und konsistente („wasserdichte“) Speicherung der Geometrien hydrogeologischer Körper
als landesweiter Bestand in einer Datenbank sowie schnelle Visualisierung durch Schnittgenerierung.
Ziel 1 wird unter anderem durch die Implementierung des kompletten Workflows realisiert. Für Ziel 2
gibt es eine ArcGIS-Erweiterung, welche sehr umfangreiche Funktionen bereitstellt.
Mit dem implementierten Datenmodell wird das Erreichen beider Ziele, topologische Konsistenz und
Performance, ermöglicht. Es ist darüber hinaus sehr einfach und offen. Hydrogeologische Körper,
Störungen usw. treten dem Anwender als Einheit von 3D-Daten, GIS-Daten und Sachdaten entgegen.
Derzeit wird unter anderem an Schnittstellen für die 3D-Visualisierung mit GOCAD und GEOCAN-
DO sowie an einer interoperablen Exportschnittstelle gearbeitet.
Design and Development of the Countrywide Hydrogeological 3D Database of Saxony:
In the scope of several projects, a 3D database was realised. The two main targets of the projects are:
consistent storage of 3D-geometry and attributes of all hydrogeological bodies of the whole
federal state of Saxony, Germany as well as
fast visualisation by creating cross sections.
Target 1 was succeeded by implementing a complex workflow. To succeed target 2, an ArcGIS-
Extension for visualization of 3D data and factual data was created.
The implemented data model allows the topological correct storage and best performance to construct
cross sections. Furthermore it is quite simple and open for further interfaces.
Especially the links between 3D, GIS and factual data assures the consistent data storage.
Further functions and modules are currently being developed, e.g. an interface to 3D modelling systems
(here: GOCAD) and 3D visualisation software (here: GEOCANDO).
1 Umfeld des Projektes und Aufgabenstellung
Das Sächsische Landesamt für Umwelt, Landwirtschaft und Geologie (LfULG) hat die Aufgabe, für
ein Fachinformationssystem Hydrogeologie (FIS HyG) ein hydrogeologisches 3D-Modell für Sachsen
zu erstellen. Maß für die geforderte Detailliertheit ist eine Rasterweite von 50m.
Mit der Modellierung werden blattschnittweise Ingenieurbüros beauftragt.
In der Vergangenheit wurden die Modellierungsergebnisse in Form von ESRI-GRIDs abgespeichert.
Die Generallegende besteht aus einer MS Access-Datenbank.
Ziel des aktuellen Projektes ist eine datenbankbasierte Speicherung des 3D-Modells. Neben der Verwaltung
der Körper und 3D-Flächen in einer Datenbank sind auch die technische Modernisierung der

9. Freiberger Forum Geoinformationstechnologie
hydrogeologischen Legende sowie die Speicherung von 2D-Daten wie Verbreitung und Ausstrich in
einer GIS-Datenbank Inhalt des Projektes.
Hieraus ergeben sich die folgenden Schwerpunktanforderungen des Projektes:
1. Datenbankbasierte Speicherung von hydrogeologischen Körpern, so dass eine möglichst
schnelle und unkomplizierte Visualisierung z. B. in achsenparallelen Schnitten möglich ist.
2. Gewährleistung der topologischen Korrektheit der hydrogeologischen Körper, d. h. keine Lücken
und keine Überschneidungen.
3. Ermöglichen einer gebietsweisen Überarbeitung / Fortführung der Daten (vor allem der 3Dund
der GIS-Daten)
4. Schaffung der technischen Mittel zur Speicherung und fachlichen Administration einer sauber
hierarchisch gegliederten hydrogeologischen Legende.
Die Lösung der gestellten Aufgaben beruht auf:
1. Einem einfachen und offenen relationalen Datenmodell mit den Teilen Sachdaten, GIS-Daten
(2D) und 3D-Daten.
2. Einem Workflow für die Pflege und Verbreitung der Legende sowie aller weiteren Schlüsseltabellen
und vor allem für die Modellierung, die Prüfung und den Import der Modellierungsergebnisse
3. Eine erweiterbare Reihe von Werkzeugen vor allem für die Auswertung/Visualisierung der
3D-Datenbank und für den Export für 3D-Viewer usw.
2 3D-Datenbank
Anfangs wurde die geforderte sekundenschnelle Darstellung achsenparalleler Schnitte aus einer landesweiten
Datenbank von bis zu 0,5 TerraByte als Herausforderung angesehen.
Aus verschiedenen denkbaren Varianten für ein Datenmodell der 3D-Daten wurde eine Variante kreiert,
die ein Rasterdatenmodell in der Lage (2D) mit der Speicherung der realen Höhe verbindet – es
wurden sogenannte virtuelle oder Modellbohrungsstäbchen gespeichert, deren Schichten durch Modellierung
entstehen und die Körper in der 3D-Datenbank repräsentieren. Diese Modellbohrungen sind in
einem achsenparallelen Raster von 50 m x 50 m angeordnet. Das Raster kann im Bedarfsfall regional
halbiert (25 m x 25 m) bzw. geviertelt (12,5 m x 12,5 m) werden.
Auf Grund der Achsenparallelität des Rasters können die Koordinaten der Bohrungen (X, Y) als DB-
Indizes genutzt werden, so dass ein Zugriff auf die Daten eines Gebietes sehr schnell erfolgt.
Auf Grund der Unabhängigkeit der Bohrungen ist es sehr einfach möglich, die Modellbohrungen eines
Gebietes einfach durch überarbeitete Modellbohrungen zu ersetzen.
Vom Projektpartner TU Chemnitz, Professur Datenverwaltungssysteme, wurden verschiedene
Zugriffsmethoden verglichen, darunter das an der TU Chemnitz entwickelte Produkt ICIx, das in der
Lage ist, basierend auf Verfahren der künstlichen Intelligenz, auf mehrdimensionale Daten sehr
schnell zuzugreifen.
ORACLE ohne Index: 5:18 Minuten
ORACLE Spatial: 0,1493 Sekunden
ORACLE mit Index (Composit Key): 0,0013 Sekunden
ICIx: 0,0005 Sekunden
ICIx hat seine Stärken bei Systemen mit sehr vielen Dimensionen. Bei dem 2-dimesionalen Index (X
und Y) fällt der Zeitgewinn des Datenzugriffs im Gesamtprozess nicht ins Gewicht.
Der Raumindex bei ORACLE Spatial oder ERSI SDE wurde entwickelt, um auf Polygone oder Linien
effektiv zugreifen zu können. Für Punkte ist dieser Raumindex auf Grund des Overheads uneffektiv.

B. Torchala & S. Etzold & C. Block & J. Richter
Auf Grund dieses Ergebnisses wurde eine sehr einfach strukturierte 3D-Datenbank aufgebaut:
X, Y, Z-Oberkante, Z-Unterkante, Fremdschlüssel zum Objekt in der Sachdatenbank, Farbcode, Beschriftung
Aus Performance-Gründen wurde die 3D-Datenbank physisch von der GIS- und der Sachdatenbank
getrennt.
irregulär verteilte
echte Bohrungen
mit {x, y, z 1...n )
punktbezogene Information
als Ableitung aus dem 3D -
Modell („virtuelle Bohrung“)
mit {x, y, z 1...n)
Abb. 1: Veranschaulichung des Datenmodells der in einem Raster angeordneten Modellbohrungen
Dieses Datenmodell besticht durch seine Einfachheit. Es stellte sich jedoch heraus, dass im Fall komplexerer
geologischer Lagerungsverhältnissen die Interpretation (d. h. die Visualisierung) der Daten
sehr häufig nicht eindeutig möglich ist. Dies machte sich bei der Konstruktion von Schnittdarstellungen
und beim Export der Daten in ein für das 3D-Werkzeug GOCAD sehr nachteilig bemerkbar.
Das Datenmodell der Modellbohrungen wurde deshalb zum Säulenmodell weiterentwickelt, das sich
an das SGRID-Format von GOCAD anlehnt. Die Modellbohrungen fungieren nun als Eckpunkte von
Säulen. In den Säulen sind Nachbarschaftsbeziehungen der Schichten abgebildet. Die so modellierten
Daten können wesentlich einfacher und vor allem eindeutig zu Schnittdarstellungen verarbeitet bzw.
nach GOCAD exportiert werden.
Die folgenden Abbildungen zeigen, wie senkrechte Abstürze, Linsen oder komplexere Überfaltungen
mit diesen Säulen abgebildet werden.
Abb. 2: Veranschaulichung der Abbildung von senkrechten Abstürzen, Linsen und Überfaltungen mit
dem Säulenmodell

9. Freiberger Forum Geoinformationstechnologie
Auch die regionale Verfeinerung der Daten in ein 25- und ein 12,5-m-Raster ist vorgesehen.
Abb. 3: Veranschaulichung der Halbierung der Rasterweite mit dem Säulenmodell
3 Die hydrogeologische Legende und weitere Objektarten der
Datenbank
Die Hydrogeologische Legende wurde bisher in einer Access-Datenbank gepflegt. Das Datenmodell
der neuen ORACLE-Datenbank bildet die Hierarchie der Legende in einem Selbstverweis auf eine
sehr einfache Tabelle ab. Die Eigenschaften der Hydrogeologischen Einheiten (HGE), dies sind vor
allem qualitative und quantitative Parameter wie Durchlässigkeit, Hohlraumtyp, Gesteinstyp, Stratigraphie
und viele mehr, werden in der Haupttabelle der Legende gespeichert. Die Datenbank bildet
zusätzlich einige Besonderheiten, wie z. B. aggregierte Einheiten, ab.
Diese Legendendatenbank kann einfach mittels SQL-Anweisungen ausgewertet werden. Eine Benutzeroberfläche
ermöglicht es einem Fachadministrator, die Legende zu pflegen. Ein berechtigter Anwender
kann sehr einfach neue HGE erfassen und in die Hierarchie einordnen. Eigenschaften von
HGE können geändert werden, die Hierarchie kann mittels Drag und Drop sehr einfach umgebaut
werden und es können einzelne HGE zu sogen. aggregierten HGE zusammengefasst werden.
Ein wichtiges Instrument der Administration und der Nutzung der Legende ist der Treeview, der die
Hierarchie visualisiert.
Es wurde berücksichtigt, dass die Legende jederzeit an verschiedenen Stellen extern offline im Einsatz
sein kann. Der konzipierte Workflow gewähreistet, dass die verschiedenen Versionen der Legende
nicht inkonsistent werden.
Weitere Objektarten der Datenbank des FIS HyG sind:
• Hydrogeologische Körper (HGK), die eine HGE lokal repräsentieren, jedoch zusätzlich spezielle
lokale Eigenschaften (quantitative und qualitative Parameter) besitzen und damit rückwirkend
auch die Festlegung der HGE beeinflussen.
• Störungen, die als 3D-Flächen abgebildet sind und ebenfalls quantitative und qualitative Parameter
haben können.
• Anthropogene Kommunikationsbereiche, d. h. vor allem vom untertägigen Bergbau beeinflusste
Bereiche, die als 3D-Körper abgebildet sind und die HGK überlagern.
• Geogene Kommunikationsbereiche zwischen Grundwasserleitern, die als 3D-Flächen abgebildet
sind und topologisch korrekt an den Grenzen zwischen zwei GW-Leitern liegen
• Weitere Objektarten wie Grundwasserflurabstand, Hydrogeochemische Körper (HGCK) und
Belegbohrungen

B. Torchala & S. Etzold & C. Block & J. Richter
Alle diese Objekte treten dem Anwender als Einheit von 3D-, Sach- und GIS-Daten entgegen. D. h.,
sie lassen sich mit einer Kombination der Eigenschaften (Geometrie- und Sachdaten) filtern und es
können alle Eigenschaften eines Objektes, z. B. eines oder mehrerer HGK, visualisiert werden: die
3D-Daten in einem Schnitt, die GIS-Daten in einer Karte und die Sachdaten in einem entsprechenden
Formular bzw. in einer Tabelle.
Abb. 4: Treeview im Formular der HGE
4 Workflow beim Aufbau und bei der Fortführung der landesweiten
3D-Datenbank
Wirklich teuer an einem Fachinformationssystem wie dem FIS HyG sind die Daten. Schritt für Schritt
werden seit einigen Jahren von beauftragten Ingenieurbüros einzelne Kartenblätter kartiert. Bei der
Konzipierung des FIS HyG wurde ein besonderes Augenmerk auf die Sicherung der Qualität der Daten
gelegt.
Der Workflow der Datenerfassung beginnt mit einem Check-Out-Prozess, bei dem vorhandene Daten,
die Legende sowie alle weiteren Schlüsseltabellen exportiert und an ein Ingenieurbüro gegeben werden.
Für die Modellierung der HGK sowie der anderen 3D-Objekte (Störungen, Kommunikationsbereiche..)
setzt das Ingenieurbüro ein geeignetes Werkzeug ein. Welches Werkzeug dies ist, bleibt weitgehend
dem Ingenieurbüro überlassen. Wichtig ist lediglich, dass die Modellierung von vornherein die
Eigenschaften der Datenbank berücksichtigt, wie z. B. die Speicherung in einem Raster (50x50m).
Für die Erfassung der Sachdaten wird ein externes Erfassungsprogramm mit dem Namen UFHYG
ausgeliefert. Dieses enthält eine interne Datenbank und neben der hydrogeologischen Legende alle
weiteren für die Erfassung erforderlichen Schlüsseltabellen (Durchlässigkeit, Gesteinstyp…). Mit dem
Import der modellierten 3D-Daten (HGK, Störungen…) über eine einfache ASCII-Schnittstelle werden
in diesem Programm die einzelnen Objekte kreiert, die anschließend mit der Legendenzuordnung
und mit allen anderen Sachdaten ergänzt werden.

9. Freiberger Forum Geoinformationstechnologie
LfULG
GEOCANDO
3D-Daten
GOCAD
FIS Hydrogeologie
CITRIX-Server
Datenbankserver
Client-PC
Arbeitsdatenbank
Sachdaten
3D-Daten
GIS-Daten
FHYG
(Import/Export)
FHYG
(Admin.)
Externes Kartierungsbüros
FHYG UFHYG
Produktionsdatenbank
Sachdaten
3D-Daten
GIS-Daten
Sachdaten
3D-Daten
GIS-Daten
Client-PC
Sachdaten
3D-Daten
GIS-Daten
3D-Daten
Umwandeln in FHYG-
Austauschformat
Externes
Modellierungsprogramm
3D-Daten
Abb. 5: Schaubild des kompletten Workflows zum Füllen und Auswerten der Hydrogeologischen 3D-
Datenbank
Die extern erfassten Daten werden in eine zentrale Arbeitsdatenbank importiert und dort abschließend
geprüft. Diese Prüfung umfasst eine Reihe automatisch ablaufender teilweise komplexer Konsistenzprüfungen
sowie die Sichtprüfung mit verschiedenen Visualisierungsmitteln. Ein wichtiges Prüfkriterium
ist die geometrische Konsistenz zu den ggf. bereits vorhandenen Daten in der Produktions-
Datenbank.
Nach erfolgreicher Prüfung werden die Daten in die Produktionsdatenbank übernommen. Dieser
Schritt ist durch das gewählte 3D-Datenmodell einfach. Die 3D-Konsistenz sowie die 3D-Topologie
(überschneidungsfrei und lückenlos) der Produktionsdatenbank wird nicht gefährdet. Dies wird erreicht,
indem prinzipiell jedes Rasterelement (Modellbohrung bzw. Modellsäule) komplett, d. h. von
der Erdoberfläche bis zum untersten modellierten Horizont in der Produktions-DB ersetzt wird.
Die eigentliche Anwendung funktioniert sowohl mit der Arbeits- als auch mit der Produktionsdatenbank.
Ein wichtiges Instrument des gesamten Workflows ist die sogen. Bearbeitungshistorie. Dieses Datenbankobjekt
gibt nicht nur darüber Auskunft, wann in welchem Gebiet welche Kartierungsprojekte von
wem ausgeführt wurden, es verhindert auch, dass sich versehentlich parallele Kartierungen räumlich
überlappen.
5 Funktionen
Neben den Programmen, die für die Realisierung des Workflows erforderlich sind (Export von Daten
zur Kartierung, externe Datenerfassung, Importschnittstellen) und den Administrationsprogrammen
(Prüfung, fachliche Administration der Hydrogeologischen Legende, Administration der Nutzergruppen
und deren Rechte…) wurde in Form einer ArcGIS-Extension das Programm FHYG entwickelt,
das der Auswertung der Datenbank des FIS HyG dient.
Dieses Programm verbindet die 3D-Geometrie, die GIS-Daten und die Sachattribute zu einer Einheit.
Die folgende Abbildung veranschaulicht, wie ein Nutzer zwischen 3D-Daten (Schnittdarstellung),
GIS- und der Sachdatendarstellung navigieren kann.

B. Torchala & S. Etzold & C. Block & J. Richter
Sachdatenanwendung
Start
Anzeige Sachdaten
Anzeige GIS-Daten
GIS
Anzeige Sachdaten
Anzeige GIS-Daten
Anzeige für
ausgewähltes Gebiet
Schnitt
Abb. 6: Darstellung der Navigationsmöglichkeiten zwischen Schnittdarstellung, GIS und Sachdaten
Das Datenmodell ist für die Darstellung von achsenparallelen (West-Ost oder Süd-Nord) Schnitten
optimiert, so dass diese Schnitte in Sekundenschnelle erzeugt werden können. Ein Anwender definiert
die Schnittdarstellungen mit dem Aufziehen eines Auswertegebietes auf einer GIS-Karte sowie einiger
weniger Einstellungen für den Schnitt (z. B. Maßstab, WE- oder SN-Ausrichtung…). Danach erzeugt
er auf Mausklick in 50m- (in Detailbereichen auch in 25m- oder 12,5m-) Vorwärts oder Rückwärts-
Schritten Schnittgraphiken, die neben den HGK auch Störungen, Geogene und Anthropogene Kommunikationsbereiche,
Grundwasserflurabstand und Belegbohrungen darstellen.
Die Schnittdarstellung bietet eine Reihe von Funktionen zur Auswertung der Sachdaten der dargestellten
Objekte (z. B. das aus ArcGIS bekannte Info-Tool, Beschriftung, Legenden usw.). Die wichtigsten
Funktionen sind das Navigieren zur GIS-Darstellung (Ausstrich- und Verbreitungsflächen) sowie zu
den Sachdatenformularen. Auch die aktuelle Schnittposition kann im GIS verfolgt werden.
Abb. 7: Veranschaulichung der Benutzeroberfläche zum Visualisieren der verschiedenen Daten

9. Freiberger Forum Geoinformationstechnologie
6 Ausblick
Derzeit werden im Rahmen einer Diplomarbeit Schnittstellen nach GOCAD und GEOCANDO programmiert.
Es soll möglich sein, eine Auswahl der in einem Gebiet vorgefundenen Objekte nicht nur
im Schnitt darzustellen, sondern auch in einer 3D-Software zu visualisieren und ggf. weitere 3D-
Auswertungen auszuführen. Die folgende Abbildung zeigt ein erstes Ergebnis.
Abb. 8: 3D-Darstellung der HGK eines Gebietes mittels GOCAD
Aufgabe dieser Diplomarbeit ist es auch, die Voraussetzungen für die Realisierung interoperabler
Schnittstellen zu schaffen. Dadurch soll es künftig möglich sein, den Inhalt der 3D-Datenbank für die
Nutzung mit weiteren Softwareprodukten verfügbar zu machen.

Integration von GOCAD in den Arbeitsablauf von der Modellierung
über die Simulation zur Visualisierung
Björn Zehner
Department für Umweltinformatik, UFZ – Helmholtz Zentrum für Umweltforschung, Permoserstrasse
15, D – 04318 Leipzig; e-mail: bjoern.zehner@ufz.de, bzehner@gmx.de
Um die Prozesse im Untergrund besser zu verstehen werden häufig Simulationsrechnungen durchgeführt.
Innerhalb des gesamten Arbeitsablaufes, von der Erstellung des geometrischen Modells über die
Simulation von Prozessen bis hin zur gemeinsamen Darstellung des Modells und der Simulationsergebnisse
in einer virtuellen Umgebung, kommen eine Vielzahl verschiedener Softwarekomponenten
zum Einsatz, welche jeweils für eine bestimmte Aufgabe optimiert sind. Um einen möglichst schnellen
und einfachen Arbeitsablauf zu gewährleisten, kommt es darauf an, diese verschiedenen Komponenten
möglichst eng miteinander zu integrieren, um einen reibungsfreien Datenfluss zu ermöglichen.
Daher wurde die Software GOCAD, welche vielfach für die geometrische Modellierung eingesetzt
wird, zusätzlich als zentrales Werkzeug für die Datenverwaltung und das Preprozessing benutzt und
mit Hilfe von Plugins erweitert, um einen schnellen Austausch der Daten mit den anderen beteiligten
Programmen zu garantieren.
Numerical Simulation is often used in order to gain a better understanding of the processes in the subsurface.
Within the overall workflow, from geometrical modelling through the process simulation to
the synoptic visualization of the model and the simulation results in a Virtual Environment, numerous
different software packages are used that are each specialized to correspond with one step of the workflow.
In order to ensure an easy and rapid workflow, the different software components should be well
integrated or connected with each other. For this reason the software GOCAD that is used for geometrical
modelling is also used as a tool for data integration and preprocessing and has been extended
using its plugin mechanism in order to ensure the easy and rapid exchange of data with the other software
programs used.
1 Einführung
Die Arbeitsgruppe für Umweltinformatik am Helmholtzzentrum für Umweltforschung beschäftigt sich
mit der Simulation von Prozessen wie Grundwasserfluss und CO2 Verpressung im Untergrund, wobei
die Methode der Finiten Elemente mit dem Softwarepaket OpenGeoSys (WANG ET AL., 2009), welches
von der Arbeitsgruppe entwickelt wird, zum Einsatz kommt. Sowohl für den Aufbau von Modellen
als auch für den Austausch solcher Modelle mit externen Projektpartnern und für deren Nachbearbeitung
bietet sich die Software GOCAD an. Die geometrischen Modelle kommen hierbei zum einen
für die Erstellung der Simulationsgitter zum Einsatz, zum anderen für die Definition der Randbedingungen
und die Parametrisierung der Modelle. Anschließend sollen die Simulationsergebnisse zusammen
mit den Ausgangsmodellen visualisiert werden, wofür am UFZ eine Virtual Reality Umgebung
zur Verfügung steht. Abbildung 1 soll verdeutlichen welche verschiedenen Arbeitsschritte insgesamt
notwendig sind und welche verschiedenen Formen von Modellen bzw. Repräsentationen hierbei
auftreten.
Für diesen mehrstufigen Arbeitsablauf kommen verschiedene Softwarepackete zum Einsatz, welche
jeweils einen der Schritte besonders gut beherrschen. So ist zum Beispiel die Software GOCAD gut
dafür geeignet, um anhand von verschiedenen im Gelände aufgenommen Daten ein Model des Untergrundes
zu konstruieren. Da GOCAD des weiteren über diverse Importfunktionen verfügt, z.B. um
Shape-Dateien von ArcGIS oder Eingabedaten der für die Reservoirsimulation weit verbreiteten EC-
LIPSE Software zu lesen, eignet es sich auch gut zum Austausch von Daten mit unseren Partnern und
somit als zentrale Software für die Verwaltung des Untergrundmodells. Die Möglichkeiten aus einem

9. Freiberger Forum Geoinformationstechnologie
konstruierten geologischen Modell ein 3D Gitter zu generieren, das als Grundlage für eine Finite Element
Simulation genommen werden kann, sind in GOCAD jedoch eher beschränkt. Diese Gittergenerierung
anhand des Oberflächenmodells lässt sich besser mit Software durchführen, die direkt für diesen
Zweck geschrieben worden ist. Als Beispiel sei hier die Software TetGen (SI, 2011)genannt die
für wissenschaftliche Zwecke frei verfügbar ist. Im Fall der Visualisierung verfügt GOCAD über
Möglichkeiten das geologische Modell zusammen mit 3D Gittern darzustellen, hat aber kaum Möglichkeiten
Simulationsergebnisse wie z.B. Isoflächen für skalare Felder oder Vektorglyphen und
Ströhmungslinien für Vektorfelder zu berechnen und zu visualisieren. Hierfür hat die frei verfügbare
Software Paraview (www.paraview.org) weit bessere Möglichkeiten.
Abb. 1: Genereller Überblick über den Arbeitsablauf und die verschiedenen Arten von Modellen die
während des gesamten Arbeitsablaufes auftreten.
Um GOCAD für die geometrische Modellierung und als zentrale Software für die Verwaltung des
Modells zu verwenden, wurde es mit Hilfe von in C++ implementierten Plugins möglichst eng mit den
anderen beteiligten Softwarekomponenten integriert. Zusätzliche Funktionalität beim Modellieren
erlaubt es geometrische Modelle zu erstellen, welche sich für eine Vernetzung mit Tetraedern eignen.
Ferner unterstützen zusätzliche Schnittstellen zu externen und frei verfügbaren Gittergeneratoren die
Erstellung der Simulationsgitter und das Laden der resultierenden Gitter in Gocad. Diese Gitter können
dann direkt im OGS Format geschrieben werden, so dass sie direkt für die Simulation eingesetzt
werden können. Weitere Geometrien wie Bohrungsverläufe, Schichtgrenzen oder Verwerfungen können
genutzt werden, um die Randbedingungen für die Simulation zu definieren. Für die anschließende
Visualisierung wurden Plugins implementiert, welche es erlauben das Modell direkt im VTK Format
zu exportieren, um so die freie Software Paraview für die Analyse der Simulationsergebnisse zusammen
mit dem geometrischen Eingabemodell verwenden zu können. Ferner wurde ein Export in den
open source Szenengraphen OpenSG bereitgestellt, welcher es erlaubt, das geometrische Modell sehr
einfach und schnell in einer virtuellen Umgebung darzustellen.
2 Verwendete Software-Werkzeuge
Um einen einfachen Datenaustausch zwischen GOCAD und den anderen Programmen bereitzustellen,
wurde GOCAD mit Plugins erweitert, um die entsprechenden Export- und Importfunktionen zu erstel-

Björn Zehner
len. Gegenüber der oft verwendeten Methodik Datenkonverter zu schreiben, welche direkt die Dateien
im GOCAD Format einlesen und dann im gewünschten Format schreiben, hat dies den Vorteil, dass
zum einen die gesamten topologischen Informationen der einzelnen Objekte bei der Konvertierung zur
Verfügung stehen und zum anderen auch Zusatzinformationen verwendet werden können, wie die
Farbe der Objekte oder die Liniendicke. Im Folgenden sollen kurz die verwendeten Komponenten und
ihr Zusammenhang vorgestellt werden.
Geometrische Modellierung und Gridding – Gmsh / TetGen
Um ein Tetraeder-Gitter für Finite-Element Simulationen zu erstellen, benötigt man ein Oberflächen-
Modell, welches das Volumen des Modells lückenfrei abgrenzt und in einzelne Subvolumen (die verschiedenen
Schichten) aufteilt. Dort wo verschiedene Flächen in Kontakt stehen, z.B. wo eine stratigrafische
Grenzfläche an eine Verwerfung grenzt, müssen die beiden Flächen die gleichen Punkte
und Segmente aufweisen. Dies soll in der Abbildung 2 illustriert werden, welche auf der linken Seite
ein 3D Modell zeigt, das nicht ohne weitere Nachbearbeitung für die Generierung eines 3D Gitters
geeignet wäre und auf der rechten Seite das korrespondierende Modell, welches die notwendigen Eigenschaften
besitzt.
Abb. 2: Ausschnitt eines Modells bei dem zwei Schichtgrenzen (dunkelgrau und Vernetzung mit
schwarzen Linien) gegen eine Verwerfung laufen (hellgrau, Vernetzung mit weißen Linien).
Links stimmen die Punkte und Segmente der Schichtgrenzen am Kontakt nicht mit denen der
Verwerfung überein. Anhand dieses Modells kann kein konsistentes 3D Gitter, das aus Tetraedern
besteht, erstellt werden. Rechts ein korrespondierendes Modell bei dem die Segmente und
Punkte am Kontakt übereinstimmen und welches sich daher für die 3D Gittergenerierung eignet.
Ein solches Modell lässt sich am besten konstruieren indem man die Kontaktlinien berechnet und anschließend
die einzelnen Flächen mit einem Constrained-Delaunay Algorithmus vernetzt, so dass die
Kontaktlinien jeweils Bestandteil von beiden Flächen sind. Ein Datenaustausch mit der Software
Gmsh (GEUZAINE & REMACLE, 2009) ermöglicht es die Constrained Delaunay Algorithmen von
Gmsh zu verwenden. In ZEHNER (2011) wird genauer beschrieben wie auch komplizierte Störungssysteme
so modelliert werden könnten, dass sie sich für eine anschließende 3D Gittergenerierung eignen.
Hierbei kommen sowohl die Software Gmsh zum Einsatz, als auch weitere einfache Werkzeuge
die mittels Plugins in GOCAD integriert wurden.
Um aus einem so erstellten Oberflächenmodell ein 3D-Gitter zu erzeugen, kann man sehr gut die
Software TetGen (SI, 2011) verwenden. Ein Gocad Plugin ermöglicht es alle im Objekt-Browser als
sichtbar eingestellten Flächen in einer TetGen Eingabedatei zu speichern, wobei die Punkte von den
verschiedenen Flächen, die sich an den Kontakten zwischen ihnen und somit an derselben Position
befinden, zu einem (globalen) Punkt zusammengefasst werden. TetGen erkennt beim Vernetzen die

9. Freiberger Forum Geoinformationstechnologie
verschiedenen Subvolumina automatisch und ordnet den Tetraedern eine entsprechende Identifikationsnummer
zu. Die Ausgabedatei von TetGen kann danach als „Solid“ in GOCAD eingelesen werden,
wobei die verschiedenen Subvolumina verschiedenen „Parts“, also verschiedenen Untereinheiten des
Solids, zugeordnet werden.
Austausch zur Simulationssoftware - OpenGeoSys
Die Simulationssoftware OpenGeoSys (OGS, WANG ET AL., 2009) ist eine Finite-Elemente Software,
welche am UFZ im Department für Umweltinformatik entwickelt wird. Sie wird von der Kommandozeile
aus bedient und liest ihre Konfiguration aus einer Reihe von Eingabedateien. An Geometrien
benötigt OGS zum einen das Simulationsgitter selbst, zum anderen können Geometrien benutzt werden,
um für die Simulation die Randbedingungen zu definieren. Es könnte beispielsweise auf alle
Punkte entlang einer Bohrung ein bestimmter Fluss festgelegt werden oder für alle Punkte die auf einer
Fläche liegen wird der Druck festgehalten. Diese Geometrien für die Randbedingungen lassen sich
auch sehr gut und schnell in GOCAD definieren. Um einen einfachen Austausch zu gewährleisten,
wurden die notwendigen Exportfunktionen direkt in GOCAD integriert um SGrids und Solids unmittelbar
im OGS eigenen Format für Simulationsgitter zu schreiben. Ferner lassen sich die Geometrien
aus GOCAD, also Punkte, Linien und Flächen direkt in einem XML Format abspeichern, das von
OGS gelesen werden kann, so dass die Geometrien für die Definition der Randbedingungen genutzt
werden können. Durch diese Erweiterung lässt sich GOCAD effizient als Preprozessor für die Simulationssoftware
einsetzten. Allerdings müssen viele Eigentschaften, wie z.B. die Definition und Zuordnung
von Materialien für die einzelnen stratigrafischen Einheiten, nach wie vor von Hand definiert
werden. Hierbei ist ein speziell für OpenGeoSys entwickelter 3D-Datenmanger (RINK ET AL., 2011)
sehr hilfreich.
Visualisierung am Bildschirm – Paraview / VTK
Nach erfolgter Simulation sollen die Ergebnisse in der Regel im Kontext des geologischen Modells
visualisiert werden. Wie bereits erwähnt, eignet sich GOCAD zur Visualisierung des geologischen
Modells und der Simulationsgitter. Für die Extraktion und Visualisierung von Informationen aus wissenschaftlichen
Datensätzen und aus Simulationsergebnissen eignet sich die frei verfügbare Software
Paraview (www.paraview.org) jedoch besser. Diese baut auf eine ebenfalls frei verfügbare C++ Bibliothek
auf, die sich Visualization Toolkit nennt (VTK, SCHROEDER ET AL., 1996, www.vtk.org).
VTK stellt eine große Anzahl an Filtern zur Verfügung, welche jeweils Informationen aus dem Datensatz
extrahieren, also z.B. Strömungslinien für ein Vektorfeld berechnen oder Isoflächen für ein skalares
Feld. Diese Filter können dann zu komplexen Pipelines zusammengesetzt werden, so dass eine
Vielzahl an Analysemöglichkeiten entsteht. Ferner stellt VTK auch Methoden bereit, um die Ergebnisse
zu visualisieren wobei die graphische Darstellung und ihre Qualität sowie die Optimierung des Szenengraphen
nicht der Schwerpunkt ist. Paraview stellt einen großen Teil der Funktionalität von VTK
in Form einer graphischen Benutzeroberfläche zur Verfügung und wird von vielen Forschungsgruppen
aus dem Simulationsbereich für das Postprocessing verwendet, weswegen auch die Simulationssoftware
OpenGeoSys den Export von VTK-Dateien unterstützt. Um auch die Eingabedaten, also Geometrien
wie Verwerfungen und Stratigraphie bzw. die Reservoir-Gitter inklusive ihrer Parametrisierung
in Paraview übernehmen zu können, wurde die VTK Bibliothek zu GOCAD hinzugelinkt und auf
diese Weise über GOCAD’s Plugin-Mechanismus Export-Funktionen bereitgestellt, so dass SGrids als
strukturiertes Gitter (vtkStructuredGrid), Solids als unstrukturiertes Gitter (vtkUnstructuredGrid) und
Punkte, Linien und Flächen als Polygone (vtkPolyData) direkt im VTK Format abgespeichert werden
können. In diesem Format können sie dann in Paraview eingelesen werden, so dass eine gemeinsame
Darstellung von Eingabedaten und Simulationsergebnissen in Paraview erfolgen kann.
Visualisierung in einer VR Umgebung – OpenSG / VRED
OpenSG (REINERS ET AL., 2002) ist ein frei verfügbarer Szenengraph, welcher direkt für die graphische
Darstellung optimiert ist. Gegenüber der Darstellung mit VTK hat man viel mehr Einfluss auf die
graphische Repräsentation, so dass sich die Visualisierung für sehr große Modelle besser optimieren
lässt. Eine realistische Visualisierung von Landschaften, wie sie z.B. in ZEHNER (2008) beschrieben
wurde, lässt sich mit VTK sicher nicht erstellen. Somit bietet OpenSG die Möglichkeit sehr komplexe
Szenen zusammenzubauen und die Visualisierung von wissenschaftlichen Sachverhalten und Daten

Björn Zehner
mit einer Darstellung der Umgebung (z.B. der Landschaft) zu verbinden, so dass die Betrachter einen
besseren Eindruck vom gesamten Kontext bekommen und sich besser orientieren können.
Abb. 3: Datenfluss bei der Abfolge von Modellierung, Simulation und Visualisierung unter Einbindung
der Software GOCAD. Der Austausch von Daten mit der Software Gmsh hilft bei der Erstellung
eines konsistenten Oberflächenmodells und der Austausch von Daten mit der Software
Tetgen erlaubt die Generierung eines Tetraedergitters (TSolids) welches für Finite Element Simulationen
eingesetzt werden kann. Der Export im Dateiformat von OpenGeoSys erlaubt ein
einfaches und schnelles Simulieren des Modells und der Export von Gittern im VTK Format
und von Geometrien im OpenSG Format erlaubt eine einfache und schnelle synoptische Visualisierung
der Daten und der Simulationsergebnisse in der virtuellen Umgebung des UFZ.

9. Freiberger Forum Geoinformationstechnologie
Ein weiterer Vorteil von OpenSG ist, dass es die Verteilung des Szenengrafen implementiert, so dass
damit auch Visualisierungs- und Virtual Reality Anlagen betrieben werden können, welche gleichzeitig
mehrere Projektoren verwenden. Das UFZ verfügt z.B. über ein solches System, das mit insgesamt
13 Projektoren angetrieben wird. Das System ist so aufgebaut, dass es sowohl komplett als eine Art
virtueller Raum genutzt werden kann als auch um gleichzeitig 3D Informationen gekoppelt mit 2D
Informationen anzuzeigen (ZEHNER 2009, ZEHNER 2010). Das System wird überwiegend mit der
kommerziellen Software VRED von der PI-VR GmbH betrieben, welche auf OpenSG basiert und
darum mit Hilfe dieses Szenengrafen und von C++ erweitert werden kann.
OpenSG verfügt über ein eigenes Binärformat, das sehr gut für den Datenaustausch mit VRED verwendet
werden kann. Aus diesem Grund wurden die OpenSG Bibliotheken mit GOCAD gelinkt. Die
Geometrischen Objekte wie Linien und Flächen werden direkt in entsprechende OpenSG-Objekte
umgewandelt; Punkte (VSets) werden hierbei als Rhomben dargestellt. Graphische Parameter wie
Farben oder Liniendicke werden von GOCAD übernommen. Der Export von GOCAD direkt in das
Virtual Reality Display wurde bereits mit sehr umfangreichen Datensätzen getestet und funktioniert
problemlos. Für Solids und SGrids muss ein Umweg über VTK genommen werden. Diese können in
der Regel nicht einfach als Geometrien exportiert werden, weil man die Möglichkeit haben will diese
interaktiv zu explorieren. Daher wurden für diese Daten Standardpipelines im VTK Format implementiert
und ein vtkToOpenSG Filter, der am Ende der Pipeline steht und die aus den Daten extrahierten
Geometrien (Schnitte durch den Datensatz, Isoflächen, Ströhmungslinien) direkt in das OpenSG-
Format umwandelt. Mit Hilfe dieses Filters wurden die VTK Pipelines in VRED integriert. Insgesamt
kann mit Hilfe von OpenSG also nicht nur das geologische Modell in einer CAVE dargestellt werden
sondern es besteht auch die Möglichkeit dieses mit Simulationsergebnissen zu ergänzen und den Betrachtern
mit Hilfe von einem Landschaftsmodell die Orientierung zu erleichtern.
Die Abbildung 3 fasst noch einmal den gesamten Datenfluss zusammen wie er bei dem vorgeschlagenen
Arbeitsablauf von der Modellierung über die Simulation bis hin zur Visualisierung des geometrischen
Modells und der Simulationsergebnisse im Visualisierungszentrum des UFZ auftritt.
3 Verwendung des Arbeitsablaufes
Der hier vorgestellte Arbeitsablauf und die zugehörigen Schnittstellen wurden bereits erfolgreich für
verschiedene Projekte verwendet. Zum Beispiel wurde er im Rahmen des INFLUINS-Projektes, welches
sich mit der Fluiddynamik in Sedimentbecken anhand des Thüringer Beckens als Beispiel beschäftigt,
angewendet. Ein erstes Oberflächenmodell der Trias im Thüringer Becken wurde erstellt,
wobei das geometrische Modell auf den Ausbisslinien und Tiefenpunkten der stratigrafischen Schichtgrenzen
einer Diplomarbeit an der Universität Jena (Kober, 2009) beruht. Das Modell unterteilt die
Trias in Buntsandstein, Muschelkalk und Keuper. Die Seitenlängen bei der Triangulierung schwanken
zwischen wenigen hundert Metern in Regionen wo viel Information vorlag und ca 1000-1500 Metern
wo die Informationen eher knapp waren. Die Verwerfungen im Thüringer Becken sollen im Rahmen
des Projektes erst noch genauer untersucht und modelliert werden, so dass sie bei diesem Modell ignoriert
wurden. Auf Dauer ist es aber geplant, auch die Verwerfungen in das Modell mit einzubeziehen.
Bei der Erstellung des Oberflächenmodells fielen immer wieder kleine Fehler auf, die korrigiert werden
mussten. Diese beruhten hauptsächlich darauf, dass bei der Anwendung des Triangulierungs-
Algorithmus von Gmsh teilweise die Randbedingungen nicht ausreichend eingehalten wurden. Diese
Fehler in der Triangulierung ließen sich jedoch mit Hilfe der in GOCAD vorhandenen Standardwerkzeuge
korrigieren. Für die nachfolgende Neugenerierung des Modells war die Möglichkeit diese mit
Scripting zu automatisieren sehr hilfreich.
Anhand des Oberflächenmodells vom Thüringer Becken wurde ein Tetraedergitter erstellt, das aus ca.
600.000 Elementen besteht und bei dem die verschiedenen abgeschlossenen Einheiten in GOCAD
durch verschiedene Untergruppen (Parts) des Solids repräsentiert wurden. Dieses Gitter wurde dann
als Finite Elemente Gitter in OpenGeoSys importiert und dort für eine erste Grundwassersimulation
verwendet. Im Rahmen eines Treffens mit Projektpartnern von der Universität Jena wurde der O-

Björn Zehner
penSG Export genutzt um das Modell im Visualisierungszentrum des UFZ zu präsentieren (siehe Abbildung
4).
Abb. 4: Mitarbeiter des INFLUINS Projektes bei der Betrachtung eine GOCAD Modells vom Thüringer
Becken im Visualisierungszentrum des UFZ.
Im Rahmen des Projektes CO2MAN, welches sich mit der Verpressung von CO2 am Pilotstandort
Ketzin beschäftigt, soll die Ausbreitung des CO2 im Untergrund mit verschiedenen Software-Packeten
simuliert werden. Der Austausch der Daten zwischen den verschiedenen Partnern findet hierbei im
Format der ECLIPSE Software von Schlumberger statt. GOCAD wird in diesem Fall also zum einen
als Konverter vom ECLIPSE-Format in das OpenGeoSys-Format eingesetzt, zum anderen aber auch
um die notwendigen Geometrien zu generieren, welche für die Definition der Randbedingungen benötigt
werden. Es dient also auch hier als Preprozessor für die Simulation.
Unabhängig von dem hier vorgestellten Arbeitsablauf kann der OpenSG Export auch dazu benutzt
werden, um die 3D-Modelle von Partnern und Besuchern, welche diese mit GOCAD generiert haben,
sehr schnell in unser Virtual Reality Display zu exportieren. Dies wurde zum Beispiel mit einem umfangreichen
Modell der Geologie von Schleswig Holstein durchgeführt und war völlig problemlos.
4 Literatur
GEUZAINE, C., REMACLE, J.-F. (2009): Gmsh: a Three-Dimensional Finite Element Mesh Generator with Built-in
Pre- and Post-Processing Facilities. International Journal for Numerical Methods in Engineering 79, Wiley:
1309 – 1331.
KOBER, M. (2009): Erstellung eines ArcGIS- und Petrel-basierten digitalen Untergrundmodells der Thüringer
Mulde. Diplomarbeit, Friedrich-Schiller-Universität Jena, Germany.
REINERS, D., VOSS, G., BEHR, J. (2002): OpenSG: Basic Concepts. OpenSG Symposium 2002
RINK, K., KALBACHER, T., KOLDITZ, O. (2011): Visual data management for hydrological analysis. Environmental
Earth Sciences, accepted.
SCHROEDER, W., MARTIN, K., LORENSEN, B. (2006): The Visualization Toolkit, an Object-Oriented Approach to
3D Graphics. Prentice Hall, Upper Saddle River, USA.
SI, H. (2011): TetGen, A Quality Tetrahedral Mesh Generator and a 3D Delaunay Triangulator,
http://tetgen.berlios.de/, last visited April 2011.

9. Freiberger Forum Geoinformationstechnologie
WANG, W., KOSAKOWSKI, G., KOLDITZ, O. (2009): A Parallel Finite Element Scheme for Thermo-Hydro-
Mechanical (THM) Coupled Problems in Porous Media. Computers and Geosciences 35, Elsevier: 1631-1641.
ZEHNER, B. (2008): Landscape Visualization in High Resolution Stereoscopic Visualization Environments. In:
Buhmann, E., Pietsch, M., Heins, M. (Eds.), Proceedings of Digital Design in Landscape Architecture, 2008,
Wichmann Verlag: 224-231.
ZEHNER, B. (2009): Nutzung von Virtual Reality Anlagen als visuelle Informationssysteme für geowissenschaftliche
Daten. In: Boogaart, R.v.d., Schaeben, H. (2009), GIS-Geowissenschaftliche Anwendungen und Entwicklungen,
Proceedings zum 8. GIS Kolloquium, Wissenschaftliche Mitteilungen des Institutes für Geologie,
Technische Universität Bergakademie Freiberg: 53-58.
ZEHNER, B. (2010): Mixing Virtual Reality and 2D Visualization - Using Virtual Environments as Visual 3D
Information Systems for Discussion of Data from Geo- and Environmental Sciences. In: Proceedings of the
International Conference on Computer Graphics Theory and Applications (GRAPP2010), p. 364-369. Available
from: http://www.ufz.de/index.php?en=19329, last visited May 2011.
ZEHNER, B. (2011): Constructing Models for Finite Element Simulation Using GOCAD, Proceedings of the 31 st
GOCAD meeting in Nancy, France, June 2011, accepted.

Länderübergreifende Datenharmonisierung und geologische 3D-
Modellierung im EU-Projekt „Geopotenziale des tieferen Untergrundes
im Oberrheingraben (GeORG)“
Heiko Zumsprekel 1 & GeORG INTERREG Projektteam 2
1 Regierungspräsidium Freiburg - Abt.9 Landesamt für Geologie, Rohstoffe und Bergbau, Freiburg i.
Br.
2 E. Nitsch, G. Sokol (Koordinatoren), B. Anders, D. Ellwanger, M. Franz, R. Prestel, I. Rupf, U. Wielandt-Schuster,
G. Wirsing, (Regierungspräsidium Freiburg, Abt. 9 Landesamt für Geologie, Rohstoffe
und Bergbau, Deutschland); T. Kärcher, J. Haneke, J. Krzyanowski, R. Storz, J. Tesch, M. Weidenfeller
(Landesamt für Geologie und Bergbau Rheinland-Pfalz, Deutschland); L. Capar, L. Beccaletto, D.
Cruz-Mermy, P. Elsass, S. Urban (BRGM Orléans, Frankreich); P. Huggenberger, H. Dresmann (Departement
Umweltwissenschaften Universität Basel, Abteilung Angewandte und Umweltgeologie,
Schweiz) Kontakt: c/o G. Sokol, Regierungspräsidium Freiburg - Abt.9 Landesamt für Geologie, Rohstoffe
und Bergbau, Albertstr. 5, 79104 Freiburg i. Br., abteilung9@rpf.bwl.de
Zusammenfassung: In dem von der EU kofinanzierten INTERREG IV A Projekt GeORG erarbeiten Partner aus
Frankreich, Deutschland und der Schweiz eine länderübergreifend harmonisierte Datenbank und ein geologisches
3D-Modell, um Geopotenziale des tieferen Untergrundes im Oberrheingraben (z.B. tiefe Geothermie, CO2-
Sequestrierung, Mineral-/Thermalwasser) bewerten zu können. Die Herstellung von geometrischer, technischer
und semantischer Interoperabilität der Eingangsdaten wie auch die Bereitstellung von Schnittstellen und einer
Serverplattform zum Austausch der Arbeitsdaten zwischen den Projektpartnern ist erforderlich, um die 3D-
Modellierung auf der Grundlage homogener Daten realisieren zu können. Die Veröffentlichung der Projektergebnisse
in Form von Geodaten und Geodatendiensten im Internet lehnt sich eng an die Vorgaben und bestehenden
bzw. derzeit entwickelten Spezifikationen der EU-Richtlinie INSPIRE an. Dies gewährleistet, dass die Produkte
des GeORG-Projekts in interoperabler, standardisierter, dienste- und browserorientierter Form der Öffentlichkeit
und Fachwelt zur Verfügung gestellt werden. Die technische Umsetzung des Geoportals GeORG stützt
sich dabei vor allem auf Softwareentwicklungen aus dem Open Source-Bereich.
Summary: Within the INTERREG IV A project GeORG partners from France, Germany and Switzerland aim at
a transnationally harmonized databasis and a 3D model of the deep Upper Rhine Graben for the assessment of
geopotentials (deep geothermal energy, storage of CO2, use of mineral and thermal waters). The establishment of
geometric, technical and semantic interoperability of input data as well as interfaces and server platforms for the
exchange of working data between project partners play a central role for the 3D modelling based on homogenized
data. Project results of GeORG will be published in the internet in terms of geodata and geodata services.
For a straightforward, service- and browser-based public access of interoperable and standardized geodata from
the GeORG project, the publication in the Internet will be closely connected to the directives and specifications
of the EU INSPIRE process. The technical implementation of the Geoportal GeORG will be primarily based on
Open Source software developments.
Résumé: Dans le projet GeORG INTERREG IV A, qui est soutenu financièrement par l'Union Européenne, les
partenaires français, allemands et suisses élaborent une banque de données adaptée aux trois pays et un modèle
tri-dimensionnel géologique pour pouvoir évaluer le potentiel géologique profond du Fossé Rhénan Supérieur
(par exemple la géothermie de profondeur, le séquestre du CO2 (dioxyde de carbone), les eaux minérales/thermales).
La production de l'intercompatibilité géométrique, technique et sémantique des données d'entrée
ainsi que la mise à disposition des interfaces et d'une plateforme de serveur pour échanger les données de travail
entre les partenaires sont nécessaires pour pouvoir réaliser le modelage tri-dimensionnel sur la base des données
homogènes. La publication des résultats du projet sous forme de données et de services scientifiques de la Terre
sur internet est conforme aux indications et aux spécifications, déjà existantes et en élaboration actuellement, du
réglement de l'UE INSPIRE. Ceci garantit que les produits du projet GeORG sont mis à la disposition du grand
public et des spécialistes sous forme inter-compatible, standardisée et adaptée aux services électroniques et aux
logiciels. La réalisation technique du portail géoscientifique de GeORG se base essentiellement sur les développements
du logiciel provenant du domaine "Open Source".

9. Freiberger Forum Geoinformationstechnologie
1 Einleitung
Mit dem Projekt „Geopotenziale des tieferen Untergrundes im Oberrheingraben“ (GeORG) haben sich
die Staatlichen Geologischen Dienste von Baden-Württemberg und Rheinland-Pfalz zusammen mit
Partnern aus Frankreich und der Schweiz zum Ziel gesetzt, eine länderübergreifend harmonisierte
Datenbasis und ein dreidimensionales Computermodell des tieferen Untergrundes im Oberrheingraben
zu erarbeiten. Zunehmend wichtige Geopotenziale des Oberrheingrabens, z.B. tiefe Geothermie, CO2und
Druckluftspeicherung oder Vorkommen von Mineral-/Thermalwasser sollen auf diese Weise mit
aktuellen Maßstäben bewertet und zukünftig noch besser genutzt werden können. GeORG wird seit
Oktober 2008 durch den Europäischen Fonds für regionale Entwicklung (EFRE) im Rahmen des Projekts
INTERREG IV A Oberrhein kofinanziert. Die Projektträgerschaft liegt beim Landesamt für Geologie,
Rohstoffe und Bergbau Baden-Württemberg. Zu den fachlich beteiligten Projektpartnern gehören
das Landesamt für Geologie und Bergbau Rheinland-Pfalz, das Bureau de Recherches Géologiques
et Minières Orléans (BRGM) und die Abteilung Angewandte und Umweltgeologie der Universität
Basel. Weitere Informationen zum Projekt finden sich im Internet unter
http://www.geopotenziale.org bzw. http://www.geopotenziale.eu.
Das Untersuchungsgebiet in GeORG liegt in der Dreiländerregion Frankreichs, Deutschlands und der
Schweiz (Abb.1). Die Datenaufarbeitung und 3D-Modellierung konzentriert sich auf ein inneres Modellgebiet
mit einer N-S- bzw. E-W-Ausdehnung von ca. 250 km x 30-50 km. Damit wird der zentrale
Grabenbereich erfasst, in dem seit dem Beginn der Grabenentwicklung im Eozän bis zu 3000 m mächtige
Sedimentgesteine abgelagert wurden. Die Grabenbildung wurde lokal von vulkanischen Aktivitäten
(z.B. im Kaiserstuhl) begleitet. Mehrfache Änderungen im regionalen Spannungsfeld haben zu
einem tektonisch komplexen Gesamtbild des Oberrheingrabens mit z.T. mehrfach überprägten Störungen
geführt, das im südlichen Gebiet durch den diapirartigen Aufstieg von Salzen entlang von Störungszonen
weiter kompliziert wird [1, Kap. 4.5].
Abb.1: Modellgebiete des GeORG-Projekts.

Heiko Zumsprekel & GeORG INTERREG Projektteam
Aufgrund der lang zurückreichenden wissenschaftlichen Forschungsarbeiten und intensiven Explorationstätigkeiten
im Oberrheingraben kann im Projekt GeORG auf eine Fülle von geologischen Informationen
aus Bohrungen, reflexionsseismischen Messungen, hydrogeologischen Parametern und Ergebnissen
aus vorherigen Arbeiten zurückgegriffen werden. Die Originaldaten liegen allerdings in mehrfacher
Hinsicht heterogen vor. Im Workflow des Projekts (Abb.2) stellt daher die Harmonisierung
aller Eingangsdaten nach technischen, geometrischen und inhaltlichen Kriterien vor der seismischen
Interpretation und dreidimensionalen Modellierung einen wesentlichen Arbeitsschritt dar. Im weiteren
Arbeitsablauf werden nach der 3D-Modellierung und Parametrisierung der modellierten geologischen
Körper mit hydrogeologischen Eigenschaften Informationen über Geopotenziale abgeleitet und in
Form von thematischen Karten und Profilschnitten über Webdienste und Internet-Kartenanwendungen
veröffentlicht.
Die Anforderungen von Interoperabilität im Sinne einer Fähigkeit zur Zusammenarbeit ursprünglich
autonomer Systeme müssen im Projekt GeORG sowohl auf der Arbeitsebene wie auf der Ergebnisebene
realisiert werden: Für die Erstellung des 3D-Modells als zentralen Baustein muss auf der Arbeitsebene
allen Bearbeitern im Projekt über eindeutig spezifizierte Schnittstellen der Zugriff auf geometrisch,
semantisch und technisch harmonisierte Eingangsdaten möglich sein (s. Abschnitt 2). Für
den vereinfachten, standardisierten und browserorientierten öffentlichen Zugriff auf die Projektergebnisse
über moderne Internettechnologien wird eine Interoperabilität nach den Kriterien und Anforderungen
der EU-Richtlinie INSPIRE angestrebt (s. Abschnitt 3).
Abb.2: Workflow im Projekt GeORG.
2 Interoperabilität im GeORG-Projekt
2.1 Geometrische Interoperabilität
Aufgrund der länderübergreifenden Lage des Untersuchungsgebietes liegen die Eingangsdaten in unterschiedlichen,
jeweils landesüblichen Koordinatenreferenzsystemen bei den Projektpartnern vor:

9. Freiberger Forum Geoinformationstechnologie
(1) DHDN Gauß-Krüger Zone 3 in Baden-Württemberg und Rheinland-Pfalz), (2) Schweizer Militärkoordinaten
und (3) Lambert II étendu in Frankreich.
Als einheitliches räumliches Bezugssystem für die 3D-Modellierung in GoCAD wurde nach Absprache
unter den Projektpartnern das System DHDN Gauß-Krüger Zone 3 gewählt, sodass Eingangsdaten
und Arbeitsdaten der seismischen Interpretation aus der Schweiz und Frankreich transformiert werden
müssen. Da die Koordinatenreferenzsysteme auf unterschiedlichen Ellipsoiden beruhen und daher
spannungsbeladen sind, werden die Daten in einer Zwei-Schritt-Transformation zunächst vom originären
Koordinatenreferenzsystem (z.B. Lambert II étendu) in das globale Referenzsystem GCS WGS84
und anschließend von GCS WGS84 in das erforderliche Koordinatenreferenzsystem (DHDN Gauß-
Krüger Zone 3) transformiert. Mit Hilfe der in ArcGIS implementierten Transformationsmethoden
kann eine im Hinblick auf den angestrebten Modellierungsmaßstab hinreichende Genauigkeit erreicht
werden.
Nach Abschluss der Modellierung soll das 3D-Modell nicht nur in DHDN Gauß-Krüger Zone 3, sondern
auch in den beiden anderen Koordinatensystemen vorgehalten bzw. den Projektpartnern zur Verfügung
gestellt werden. Einfache GoCAD-Objekte können prinzipiell auch im ASCII-Format in Arc-
GIS importiert, transformiert und aus ArcGIS wieder exportiert werden. Dies ist jedoch - auch angesichts
der zu prozessierenden Datenmengen - mit einem hohen Zeit- und Bearbeitungsaufwand verbunden.
Daher wurde im Rahmen einer BSc-Arbeit an der TU Freiberg das Standalone-Programm
KoordTrans zur Transformation einfacher GoCAD-Objekte entwickelt [2]. KoordTrans nutzt dabei die
offene Programmbibliothek PROJ.4 zur direkten Umrechnung zwischen geographischen Koordinatensystemen
und ermöglicht zudem die Transformation in das System ETRS 1989 UTM, welches die
länderspezifischen Koordinatenreferenzsysteme in Europa zukünftig ablösen wird.
2.2 Technische Interoperabilität
2.2.1 Aufbereitung der Seismikdaten
Ein wichtiger Arbeitsschritt zur Herstellung einer technischen Interoperabilität ist die Aufbereitung
der 2D-reflexionsseismischen Messungen. Die Daten stammen vorwiegend aus den Explorationskampagnen
der Erdölfirmen seit den 1970er Jahren. Die teils digitalen Messdaten, teils gescannten Seismikprofile
liegen in unterschiedlichen Prozessierungen vor (gestapelt bzw. migriert) und variieren
hinsichtlich ihres Bezugsniveaus.
Die Neuprozessierung von insgesamt ca. 5400 km reflexionsseismischer 2D-Profile wurde von den
französischen Partnern übernommen und umfasst: (1) die Zuweisung eines einheitlichen Bezugsniveaus
(2) die Prozessierung mit modernen Algorithmen zur Verbesserung des Signal/Noise-Ratios und
zum Amplitudenabgleich (3) die Migration von gestapelten Seismikdaten und (4) die Umwandlung
aller Daten in ein standardisiertes digitales SEGY-Format, das direkt in die im Projekt verwendeten
Softwareprodukte zur seismischen Interpretation und Modellierung eingelesen werden kann. Durch
die Neuprozessierung konnte auch eine deutliche Qualitätsverbesserung im Vergleich mit älteren
Seismikdarstellungen erreicht werden. Die neu prozessierten Profile zeigen eine höhere Kontinuität
und Auflösung von seismischen Horizonten oder Gruppen von Horizonten und erlauben eine genauere
geometrische Charakterisierung von Störungszonen.
2.2.2 Aufbereitung weiterer Eingangsdaten
Schichtbeschreibungen und stratigraphische Abgrenzungen in Bohrdaten wurden nach ihrer Harmonisierung
(s. Abschnitt 2.3) tabellarisch zusammengefasst bzw. über Skriptanwendungen gezielt aus den
Datenbanken ausgelesen und als ASCII-Format in die Software zur seismischen Interpretation und
Modellierung importiert. Ergebnisdaten aus vorherigen Projekten wie geologischen Kartierungen,
Strukturkarten und Tiefenlinienpläne wurden bei Bedarf digitalisiert und im Shapefile-Format abgelegt,
das in alle gängigen GIS-Programme sowie in die Modellierungssoftware der Partner problemlos
eingelesen werden kann. Für die Zusammenstellung hydrogeologisch und geothermisch relevanter
Parameter wie Temperaturmessungen, hydrochemische Daten und Wärmeleitfähigkeitsmessungen
wurde ein Datenbankmodell in Access entwickelt. Die meist tabellarisch vorliegenden Daten werden
vor dem Datenbankimport auf Redundanz geprüft und die Messeinheiten und Korrekturverfahren ver-

Heiko Zumsprekel & GeORG INTERREG Projektteam
einheitlicht. Für die weitere Verwendung können diese Daten in unterschiedlichen Formaten (*.csv,
PostgreSQL, Excel sheets) ausgeliefert werden.
2.2.3 Datenserver im Projekt
Neben der Aufbereitung der Eingangsdaten hinsichtlich ihrer Formate ist auch die Bereitstellung einer
geeigneten Plattform für den Datenaustausch zwischen den Projektpartnern zur Umsetzung der technischen
Interoperabilität auf Arbeitsebene erforderlich. Mit Hilfe des webbasierten Dateimanagers
eXtplorer können die Projektmitglieder auch größere Mengen an Arbeitsdaten auf dem Server des
Projekts hoch- bzw. herunterladen und so auf einfache Weise austauschen. Vertrauliche Daten werden
durch sichere Authentifizierungsmethoden und eine flexible Benutzerverwaltung geschützt.
2.3 Semantische Interoperabilität
Zusätzlich zur geometrischen und technischen Interoperabilität muss im Projekt sichergestellt werden,
dass zwischen den Bearbeitern dieselbe Interpretation der Daten - also dieselbe Semantik - ausgetauscht
wird.
Zur Herstellung einer semantischen Interoperabilität müssen in GeORG insbesondere Bohrdaten hinsichtlich
einheitlicher stratigraphischer Bezeichnungen und Abgrenzungen überprüft und harmonisiert
werden. In den Originalunterlagen der Bohrungen variieren aufgrund der lange zurückreichenden Forschungsgeschichte
und Explorationstätigkeit die stratigraphischen Bezeichnungen und Abgrenzungen
für die tertiären und quartären Grabensedimente nicht nur mit dem Aufnahmedatum bzw. dem damaligen
Forschungsstand, sondern auch mit dem Bearbeiter und hinsichtlich regionaler fazieller Verhältnisse.
Zwar wurden von Bearbeitern dieselben Bezeichnungen wie „Niederröderner Schichten“, Cerithienschichten“,
„Corbiculaschichten“ oder „Hydrobienschichten“ verwendet, jedoch mit z.T. völlig
verschiedener Bedeutung. Vor allem bei den älteren Grabensedimenten fanden „auch verschiedene
regionale Namenssysteme für dieselben Schichtenfolgen Anwendung, in denen aber ebenfalls bestimmte
Bezeichnungen für unterschiedliche Schichten mehrfach verwendet wurden“ [1, S. 344].
Auf der Basis der bis dahin veröffentlichten Vorschläge der Subkommission Tertiär der Deutschen
Stratigraphischen Kommission 2009 einigten sich daher Vertreter der am GeORG-Projekt beteiligten
geologischen Dienste auf eine einheitliche Nomenklatur für die stratigraphischen Einheiten im Tertiär
des Oberrheingrabens im Projektgebiet (Abb.3). Die neue Nomenklatur wurde bei der Überprüfung
und Bearbeitung von über 2000 Bohrungen im Projektgebiet angewendet. Sie ist inzwischen auch in
die stratigraphische Systematik der beteiligten Landesdienste und in den bundesweiten Symbolschlüssel
eingearbeitet.

9. Freiberger Forum Geoinformationstechnologie
Abb.3: In GeORG neu entwickelte stratigraphische Nomenklatur der tertiären Grabenfüllung.
Weiterhin wurde zur Herstellung der semantischen Interoperabilität auf der Arbeitsebene eine sprachunabhängige
Nomenklatur für geologische Grenzflächen definiert, die seismisch interpretiert und
modelliert werden (Tab. 1).
Geologische Grenzflächen innerhalb der Grabensedimente, Vorkommen von Vulkaniten und Salzstrukturen
sowie in der Seismik erkennbare mesozoische Grenzflächen werden durch die Interpretation
der Seismikprofile und Bohrungen in der Zeitdomäne erfasst. Zusätzliche mesozoische und paläozoische
Horizonte werden nach der Konvertierung in die Tiefendomäne in das 3D-Modell integriert,
wobei als Grundlagendaten Mächtigkeitsverteilungen aus Bohrungen und bestehenden Projektergebnissen
verwendet werden.
Tab. 1: Nomenklatur und Interpretationsansatz der geologischen Grenzflächen im Projekt GeORG.
Geologische
Grenzfläche
Bezeichnung
in
GeORG
Seismische
Interpretation
(Zeitdomäne)
Interpretation
über Mächtigkeitsverteilungen
(Tiefendomäne)
Bemerkungen
Junge Magmatite 999_jm x - zumeist tertiäre Magmatite
(z.B. Kaiserstuhl)
Salzstrukturen 998_salt x - diapirartige Körper bzw.
Salzmauern entlang von
Störungszonen;
nur südlicher Grabenbereich
Basis Lockergesteine 010_blg (x) (x) z.T. als Erosionsdiskordanz in
der Seismik zu erkennen;
ggf. Modellierung über

Heiko Zumsprekel & GeORG INTERREG Projektteam
Mächtigkeitsverteilungen
Basis Landau-Formation 020_bhy x - z.T. als Reflektor in der
Seismik zu erkennen;
nur nördlicher Grabenbereich
Basis Froidefontaine-
Formation
040_bff x - gut erkennbarer seismischer
Reflektor
Basis Tertiär 050_bt x - als Erosionsdiskordanz oder
Obergrenze mesozoischer
Störungen erkennbar
Basis Oberjura 060_bjo - x Modellierung über
Mächtigkeitsverteilungen
Top Hauptrogenstein 070_thr x - mesozoischer Referenzhorizont
für Modellierung in
Tiefendomäne im südlichen
und zentralen Grabenbereich
Basis Keuper 100_bku x - mesozoischer Referenzhorizont
für Modellierung in der
Tiefendomäne
Top Salinargesteine des
Mittleren Muschelkalks
110_tms - x Modellierung über
Mächtigkeitsverteilungen
Basis Muschelkalk 120_bmu - x Modellierung über
Mächtigkeitsverteilungen
Basis Trias 130_btr - x Modellierung über
Mächtigkeitsverteilungen
Top Kristallines
Grundgebirge
170_tkr - x Modellierung über
Mächtigkeitsverteilungen
3 Interoperabilität nach den Anforderungen von INSPIRE
Produkte des Projekts GeORG werden neben Projektberichten, fachlichen Publikationen und technischen
Dokumentationen vor allem aus dem 3D-Modell abgeleitete thematische Karten und Profilschnitte
sein. Sie werden sowohl in Druckform als auch über ein Geoportal im Internet in Form von
Kartenanwendungen und Webdiensten zur Verfügung gestellt.
Die Bereitstellung der Projektergebnisse wird sich dabei möglichst eng an die Vorgaben aus der IN-
SPIRE-Richtlinie zum Aufbau einer europäischen Geodateninfrastruktur anlehnen. Die mit INSPIRE
angestrebte Interoperabilität, die einen institutionsübergreifenden, grenzüberschreitenden und vereinfachten
Zugriff auf Geodaten, Geometadaten und Geodatendienste ermöglichen wird, birgt sowohl für
die Anbieter von Geodaten und Geodatendiensten als auch für deren Nutzer ein großes Potenzial [3].
Durch den Aufbau eines interoperablen, hierarchisch strukturierten europäischen GDI-Netzwerkes,
das z.B. die Suche nach Geodaten und Geodatendiensten kleiner Anbieter auch auf übergeordneten
Geoportalen erlaubt, wird eine dezentrale Haltung und Pflege der Geodaten und Geodatendienste bei
den Behörden des Landes und der Kommunen vor Ort ausdrücklich gefördert und gestärkt.
Die Richtlinien und technischen Spezifikationen sind im Falle von Metadatenbeschreibungen sowie
für den Aufbau von Diensten zur Suche, Darstellung und zum Download von Geodaten bereits weit
fortgeschritten [4]. Spezifikationen der Datenmodelle für geologische Daten wie Bohrdaten, geologische
und geomorphologische Einheiten, geophysikalische Modelle und Messungen oder Grundwasserkörper
werden im Themenbereich Annex II von INSPIRE behandelt und derzeit erarbeitet. GeORG
ist hierbei als Use Case für die Implementierung des INSPIRE Annex II Geologie gemeldet.

9. Freiberger Forum Geoinformationstechnologie
Bei der konkreten Umsetzung zur Bereitstellung INSPIRE-konformer Dienste für die Suche, Darstellung
und den Download von Geodaten werden im GeORG-Projekt vorwiegend Open Source-
Softwareprodukte eingesetzt: Mit dem Programm GeoNetwork [5] sollen ein INSPIRE-konfomer
CSW-Dienst für die Suche nach Geodaten bereitgestellt und Metadatenprofile nach den Anforderungen
von INSPIRE und den Geodateninfrastrukturen Baden-Württembergs und der Schweiz erstellt
werden. GeoNetwork erlaubt zudem eine Validierung der Schemata von Metadatenprofilen und verfügt
über eine Harvesting-Funktion, mit der Metadaten automatisiert in andere Suchportale transferiert
werden können. Die Umsetzung von Darstellungsdiensten nach INSPIRE wird mit den Open Source
Softwarepaketen GeoServer [6] und UMN Mapserver [7] getestet.
4 Schlussfolgerungen und Ausblick
Interoperabilität wurde in dem länderübergreifenden Projekt GeORG als eine unabdingbare Voraussetzung
erkannt, um die Erarbeitung einer vereinheitlichten geologischen Datenbasis und eines konsistenten
3D-Modells über den tieferen Untergrund des Oberrheingrabens realisieren zu können. Die
Herstellung von Interoperabilität auf der Arbeitsebene des Projekts erfordert insbesondere (1) die Festlegung
von Methoden der technischen Prozessierung und geometrischen Transformation von Daten,
(2) die Harmonisierung der sehr heterogen vorliegenden Originaldaten (3) die Umwandlung der Eingangsdaten
in gängige Datenformate zum problemlosen Import in spezielle Software, (3) eine klare
Begriffsdefinition und Nomenklatur bei der Interpretation der Daten und (4) die Bereitstellung geeigneter
Schnittstellen und einer Serverplattform für den Arbeitszugriff auf Eingangsdaten und den Austausch
von Arbeitsdaten bei gleichzeitiger Berücksichtigung von Sicherheitsaspekten. Die Interoperabilität
auf der Arbeitsebene ist in GeORG weitgehend erreicht, sodass sich die derzeitigen fachlichen
Arbeiten vorwiegend auf die Erstellung des geologischen 3D-Modells konzentrieren.
Durch die Einbindung in den INSPIRE-Prozess können die Ergebnisse des Projekts in standardisierter,
dienste- und browserorienterter Form veröffentlicht werden. Bei der prototypischen Entwicklung des
Geoportals in GeORG werden vorwiegend Open Source-Programme für die Bereitstellung der Geodaten
und Geodatendienste verwendet, da OGC- und ISO-Standardisierungen und INSPIRE-
Spezifikationen in diesen Programmen oftmals schneller implementiert werden als in vergleichbaren
proprietären Softwarelösungen.
Auch die webbasierte 3D-Darstellung von ausgewählten Teilbereichen des geologischen Modells wäre
hinsichtlich der Veröffentlichung von Ergebnissen des GeORG-Projekts wünschenswert. Für 3D-
Geowebdienste sind bisher Vorschläge für zukünftige OGC-Standards eingeführt worden. Die angenommenen
Entwürfe für diesen Standard liegen in Form des WVS und des W3DS vor [8, 9]. In IN-
SPIRE werden Spezifikationen für das Datenmodell und die webbasierte Darstellung von geologischen
3D-Daten hingegen nicht berücksichtigt.
5 Danksagungen
Das Projekt GeORG wird durch den Europäischen Fonds für regionale Entwicklung (EFRE) im Rahmen
des Projekts INTERREG IV A Oberrhein (Projekt C3) gefördert. Partner im Projekt sind das
Regierungspräsidium Freiburg - Abt. 9 Landesamt für Geologie, Rohstoffe und Bergbau Baden-
Württemberg, das Landesamt für Geologie und Bergbau Rheinland-Pfalz, das Bureau de Recherches
Géologiques et Minières Orléans (BRGM), die Abteilung Angewandte und Umweltgeologie der Universität
Basel, das Amt für Umwelt und Energie des Kantons Basel-Stadt, das Amt für Militär und
Bevölkerungsschutz und das Amt für Umweltschutz und Energie des Kantons Basel-Landschaft, die
Schweizerische Eidgenossenschaft, die Région Alsace, die Conseil Général Bas-Rhin (CG 67) und
Haut-Rhin (CG 68), die Agence de l'Environnement et de la Maîtrise de l'Energie (ADEME) und die
Kommission Klimaschutz der Oberrheinkonferenz Frankreich, Schweiz, Deutschland. Unser Dank gilt
allen Partnern für die Förderung des Projekts und die gute Zusammenarbeit.
Der Wirtschaftsverband Erdöl und Erdgasgewinnung (WEG) unterstützt die Nutzung von Daten aus
der Erdöl- und Erdgasexploration. Ein besonderer Dank gilt daher dem WEG und den Firmen
ExxonMobil Production Deutschland GmbH, Gaz de France Produktion Exploration Deutschland
GmbH, RWE Dea AG und Wintershall Holding AG Erdölwerke.

Heiko Zumsprekel & GeORG INTERREG Projektteam
6 Literatur
[1] GEYER, O.F. & GWINNER, M.P (2011): Geologie von Baden-Württemberg. - 5. völlig neu bearbeitete Auflage
von GEYER, M., NITSCH, E. & SIMON, T., 627 S., Schweizerbart'sche Verlagsbuchhandlung.
[2] KARICH, F. (2010): Erstellung eines Standalone-Programms zur Koordinatentransformation von GoCAD-
Objekten im Projekt GeORG. - BSc-Arbeit, 30 S., Technische Universität Bergakademie Freiberg.
[3] RUNDER TISCH GIS e.V. (2010): INSPIRE - Grundlagen, Beispiele, Testergebnisse. - 5. vollständig überarbeitete
und erweiterte Auflage, URL http://www.rundertischgis.de/infobroschuere (16.05.2011).
[4] EUROPEAN COMMISSION INSPIRE: http://inspire.jrc.ec.europa.eu/ (16.05.2011).
[5] GEONETWORK: http://www.geonetwork-opensource.org/ (16.05.2011).
[6] GEOSERVER: http://geoserver.org/ (16.05.2011).
[7] UMN MAPSERVER: http://mapserver.org/ (16.05.2011).
[8] OPEN GEOSPATIAL CONSORTIUM: OGC's Purpose and Structure, http://www.opengeospatial.org/ogc/faq,
(23.09.2010).
[9] SCHILLING, A., OVER, M. & ZIPF A. (2010): Offene Standards für 3D-Anwendungen. - GIS Business 3/2010,
S. 44-47.