MRDB - Fachgebiet Datenbanken und Informationssysteme ...

Fakultät
Fakultät
für
für
Elektrotechnik
Elektrotechnik und
und
Informatik
Informatik
Institut für Praktische Informatik
Fachgebiet Fachgebiet Datenbanken Software undEngineering Informationssysteme
Entwicklung von AAA/NAS-basierten
Strukturen und XML-Schnittstellen für
eine Multi-Repräsentations-Datenbank
Kritiksystem für ein
erfahrungsbasiertes
Bachelorarbeit
im Studiengang Informatik
Anforderungswerkzeug
Michael Schäfers
Matrikelnummer: 2296620
Prüfer: Prof. Dr. Udo Lipeck
Zweitprüfer: Dr. Hans Hermann Brüggemann
Betreuer: Dipl.-Math. Michael Tiedge
Bachelorarbeit
im Studiengang Informatik
von
11. September 2007
Ingo Kitzmann

Zusammenfassung
Raumbezogene Daten ( ” Geodaten“) werden in der heutigen Zeit fast ausschließlich digital
verwaltet. Das AAA-Modell (AFIS-ALKIS-ATKIS) stellt ein einheitliches Datenmodell
für geographische Daten der zuvor getrennt geführten Fachinformationssysteme AFIS,
ALKIS und ATKIS zur Verfügung. Hierzu gehört auch ein Modell für den externen Datenaustausch,
welches in der Normbasierten Austauschschnittstelle (NAS) verwirklicht
ist.
In dieser Arbeit wird ein umfassender Überblick über das AAA-Modell gegeben. Anschließend
wird ein zum AAA-Modell konformes ATKIS-Datenmodell in Form eines relationalen
Datenbankschemas entwickelt, das in eine Multi-Repräsentations-Datenbank
(MRDB) integriert werden soll. In einer MRDB werden geographische Datenbestände
integriert, die denselben geographischen Raum beschreiben, sich aber bezüglich der Auflösung,
dargestellter Informationen, Aktualität, Genauigkeit usw. unterscheiden können.
Des Weiteren wird in der Programmiersprache JAVA ein NAS-Importer implementiert,
der NAS-Dateien verarbeiten und in das zuvor erstellte Datenbankschema einlesen kann.
Änderungen am Datenbestand in Form von NAS-Fortführungsaufträgen sollen hierbei
sowohl lokal verarbeitet als auch anderen Anwendungen der MRDB zur Verfügung gestellt
werden.

Inhaltsverzeichnis
1 Einleitung 5
2 XML-Grundlagen 8
2.1 Extensible Markup Language (XML) . . . . . . . . . . . . . . . . . . . . 8
2.1.1 Document Object Model (DOM) . . . . . . . . . . . . . . . . . . 9
2.1.2 Simple API for XML (SAX) . . . . . . . . . . . . . . . . . . . . . 10
2.1.3 Streaming API for XML (StAX) . . . . . . . . . . . . . . . . . . . 10
2.2 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Geography Markup Language (GML) . . . . . . . . . . . . . . . . . . . . 13
2.4 Filter Encoding Specification (FES) . . . . . . . . . . . . . . . . . . . . . 16
2.5 Web Feature Service (WFS) . . . . . . . . . . . . . . . . . . . . . . . . . 17
3 Das AAA-Modell 20
3.1 Das AAA-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2 Amtliches Topographisch-Kartographisches Informationssystem (ATKIS) 30
3.3 Amtliches Liegenschaftskatasterinformationssystem (ALKIS) . . . . . . . 33
3.4 Amtliches Festpunktinformationssystem (AFIS) . . . . . . . . . . . . . . 33
3.5 Normbasierte Austauschschnittstelle (NAS) . . . . . . . . . . . . . . . . . 34
4 ATKIS Datenmodell 39
4.1 Konzeptioneller Entwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2 Relationales Datenbankschema . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3 Implementierung in Oracle 10g . . . . . . . . . . . . . . . . . . . . . . . 44
4.4 Integration in die Multi-Repräsentations-Datenbank . . . . . . . . . . . . 49
4.5 Realisierung von Fortführungsaufträgen . . . . . . . . . . . . . . . . . . . 52
5 NAS-Import 54
5.1 Konzeptioneller Entwurf des Importers . . . . . . . . . . . . . . . . . . . 54
5.2 Implementierung des Importers in Java . . . . . . . . . . . . . . . . . . . 59
5.3 Behandlung der GML-Geometrien . . . . . . . . . . . . . . . . . . . . . . 65
5.4 Vergleich der Parser-Engines . . . . . . . . . . . . . . . . . . . . . . . . . 70
3

6 Fazit und Ausblick 74
6.1 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.3 Motivation zur Implementierung eines NAS-Exporters . . . . . . . . . . . 78
6.4 Entwurf und Ideen zur Implementierung . . . . . . . . . . . . . . . . . . 79
A Objektartenübersicht ATKIS-OK BASIS-DLM 83
B Übersicht über das relationale Datenbankschema 87
C Einheitswürfel dargestellt durch gml:Surface 89
D Abkürzungsverzeichnis 91
4

Kapitel 1
Einleitung
Die Vermessungs- und Katasterverwaltungen der Bundesländer haben die Aufgabe, raumbezogene
Daten für Verwaltung, Wirtschaft und private Nutzer zu liefern. Diese Daten
werden seit den 1970er Jahren zunehmend digital bereitgestellt; viele Datenmodelle und
Standards stammen ebenfalls aus dieser Zeit.
Um diese Systeme an die veränderte Technologie der heutigen Zeit anzupassen und die
im Laufe der Zeit gesammelten Erfahrungen umzusetzen, wird von der Arbeitsgemeinschaft
der Vermessungsverwaltungen der Länder der Bundesrepublik Deutschland (AdV)
seit Mitte der 1990er Jahre das AAA-Modell (AFIS-ALKIS-ATKIS) entwickelt. Es beschreibt
die drei ebenfalls von der AdV entwickelten Informationssysteme AFIS, ALKIS
und ATKIS, zeigt Zusammenhänge zwischen den Systemen auf und stellt somit ein bundesweit
einheitliches konzeptionelles Modell für räumliche Daten bereit.
In dieser Arbeit soll der ATKIS-Teil (Amtliches Topographisch-Kartographisches Informationssystem)
des AAA-Modells betrachtet werden, dessen Daten die Oberfläche der
Erde mit Digitalen Landschaftsmodellen (DLM) und Digitalen Geländemodellen (DGM)
beschreiben. Hierzu soll für die DLM ein Datenbankschema entwickelt werden, das in
eine Multi-Repräsentations-Datenbank (MRDB) integriert werden soll.
In einer MRDB werden Geodaten gespeichert, die denselben Kartenausschnitt darstellen,
jedoch beispielsweise in unterschiedlichen Maßstäben, verschiedenem Informationsgehalt,
ungleicher Aktualität etc. vorliegen. Dies kann z.B. in ATKIS die Darstellung
desselben geographischen Raumes im BASIS-DLM, DLM50 und DLM1000 sein.
Ein bestimmtes Objekt der realen Welt kann somit durch mehrere Repräsentationen in
der Datenbank in den verschiedenen Datenbeständen vorhanden sein. Um diese Repräsentationen,
die alle das gleiche Phänomen der Realität beschreiben, einander zuordnen
zu können, werden Verknüpfungen, die so genannten Links, zwischen ihnen gebildet.
Dies geschieht über komplexe Matchingverfahren, die für größere Kartenausschnitte sehr
zeitaufwändige Berechnungen durchführen müssen.
5

Die maßstabsübergreifende Modellierung, Verwaltung, Speicherung und Aktualisierung
raumbezogener Daten in einer MRDB ist ein Teilprojekt im Rahmen des Projekts Wissensbasierter
Photogrammetrisch-Kartographischer Arbeitsplatz (WIPKA), das an der
Leibniz Universität Hannover durch das Fachgebiet Datenbanken und Informationssysteme
1 in Zusammenarbeit mit dem Bundesamt für Kartographie und Geodäsie 2 und
weiteren Fachbereichen der Leibniz Universität Hannover durchgeführt wird.
Neben den drei bereits genannten Fachinformationssystemen AFIS, ALKIS und AT-
KIS ist im AAA-Modell auch ein Modell für den externen Datenaustausch festgelegt.
Die Normbasierte Austauschschnittstelle (NAS) ermöglicht den Austausch von Geodaten
zwischen verschiedenen auf dem AAA-Modell basierenden Systemen. Dies betrifft
sowohl kleinere Fortführungsaufträge (Update-Aufträge) als auch komplette Einrichtungsaufträge,
die schnell große Datenmengen verursachen können.
Unter Berücksichtigung dieser Aspekte soll ein NAS-konformer Importer für raumbezogene
Daten entworfen und implementiert werden, der ATKIS-Daten aus einer NAS-
XML-Datei einliest und in die MRDB und das im ersten Teil dieser Arbeit erstellte
Schema importiert.
Die durch die NAS gelieferten Fortführungsaufträge betreffen meist nur einige Objekte
und somit nur jeweils kleine Ausschnitte des gesamten Kartenausschnitts. In dieser Situation
ist ein komplettes Matching zu aufwändig und insofern unnötig, da stets auch
die unveränderten Daten neu gematcht werden würden. Für diese Daten bestehen jedoch
bereits alle Links, die auch weiterhin ihre Gültigkeit behalten. Daher wird parallel zu
dieser Arbeit an der Leibniz Universität Hannover ein Verfahren zum lokalen Matching
entwickelt [Nie07].
Mit diesem Ansatz ist es möglich, nur die Gebiete neu zu matchen, in denen auch wirklich
Änderungen stattgefunden haben. Die bereits vorhandenen Verknüpfungen der Gebiete,
deren Daten unverändert geblieben sind, werden ohne erneute Überprüfung übernommen.
So wird bei einem Update nur ein Bruchteil der Rechenzeit im Gegensatz zum
Komplettmatching benötigt.
Um die durch NAS-Fortführungsaufträge gelieferten Aktualisierungen des Datenbestandes
für das lokale Matching zur Verfügung zu stellen, wird das oben beschriebene Datenbankschema
um drei Tabellen erweitert, welche die Updateoperationen (insert, delete
und replace) speichern und somit die Grundlage für die Verarbeitung der Updates
durch das lokale Matching darstellen.
Das AAA-Modell wird in der ” GeoInfoDok“ [AdV06] beschrieben, die aktuell in Version
5.1 vom 31.03.2006 vorliegt. Diese Version bildet auch die Grundlage für diese Arbeit.
1 http://www.dbs.uni-hannover.de
2 http://www.bkg.bund.de
6

Die verwendete Version der NAS ist 5.1.1 vom 15.02.2007 [AdV07].
Die vorliegende Arbeit ist in sechs Kapitel gegliedert und behandelt dort die folgenden
Themen:
Kapitel 2 führt zunächst in für diese Arbeit wichtige XML-Technologien ein. Neben
allgemeinen Grundlagen zum Aufbau und zur Verarbeitung von XML-Dokumenten werden
die in der NAS verwendeten Standards WFS, GML und FES erläutert.
In Kapitel 3 wird in das AAA-Modell der AdV eingeführt. Hierbei liegt der Schwerpunkt
neben allgemein gültigen Konzepten auf dem ATKIS-Ausschnitt und dem Modell
für den externen Datenaustausch, NAS.
Das 4. Kapitel beschreibt die Entwicklung eines relationalen Datenbankschemas für
ATKIS-Daten, auf dessen Implementierung in Oracle 10g hier ebenfalls eingegangen
wird. Auch die Integration in die MRDB und die spezielle Behandlung der Fortführungsaufträge
werden in diesem Kapitel beschrieben.
Die Implementierung eines NAS-Importers wird in Kapitel 5 beschrieben. Neben einem
ausführlichen konzeptionellen Entwurf und der anschließenden Implementierung in
der Programmiersprache JAVA werden auch die JAVA-Implementierungen der beiden
XML-Parser SAX und StAX anhand dieses Projekts betrachtet und bewertet. Zudem
wird auf die Behandlung der GML-Geometrien eingegangen, die in der NAS verwendet
werden.
Im 6. Kapitel findet sich in Form eines Fazits eine Zusammenfassung der wichtigsten
Aspekte dieser Arbeit. Des Weiteren werden Vorschläge zur Fortführung und Erweiterung
der zuvor vorgestellten Ansätze gemacht. Außerdem gibt dieses Kapitel einen Ausblick
auf die Implementierung eines Exporters für NAS-Dateien und beschreibt mögliche
Ansätze hierfür. Dies umfasst auch die konzeptionelle Vorbereitung auf den Export und
es wird dargelegt, wie bei der Implementierung des Importers der Export berücksichtigt
wurde.
7

Kapitel 2
XML-Grundlagen
2.1 Extensible Markup Language (XML)
Die Extensible Markup Language (XML) des World Wide Web Consortium (W3C)
[W3C06a] ist aus der heutigen Zeit kaum mehr wegzudenken. Von einfachen Strukturen
für Konfigurationsdateien über den Austausch von Daten zwischen Softwaresystemen
oder -komponenten bis hin zu Dateiformaten für Office-Software ist das Stichwort ” XMLbasiert“
überall zu finden.
Ein XML-Dokument setzt sich stets durch Kombinationen von Elementen und Attributen
zusammen. Im folgenden Beispiel sieht man ein Element stadt mit einem Attribut
name und einem Attributwert Hannover. Darin befinden sich weitere Elemente vom
Typ stadtteil mit jeweils einem Attribut einwohner und dem zum Element gehörigen
Inhalt Bemerode bzw. Wülferode.
Bemerode
Wülferode
XML-Namensräume (Namespaces) [W3C06b] ermöglichen die Nutzung verschiedener
XML-Sprachen in einem einzigen Dokument. Die verschiedenen Namensräume müssen
explizit in einem Element im Dokument angegeben werden und sind dann für alle Kindelemente
gültig. Ein Beispiel für die Einbindung eines Namensraums ist der auch in der
NAS verwendete GML-Namensraum:
xmlns:gml="http://www.opengis.net/gml"
Nun können Elemente eindeutig durch Angabe des Präfix gml: dem GML-Namensraum
zugeordnet werden. So wäre es z.B. möglich, zwei Elemente mit dem identischen Namen
Feature zu verwenden, einmal aus dem GML-Namensraum und ein zweites mit
verschiedener Bedeutung aus dem AdV-Namensraum.
8

Ein XML-Dokument ist wohlgeformt (well-formed), wenn seine Syntax korrekt ist. Dies
beinhaltet beispielsweise das Vorhandensein von Start- und Endtags für jedes Element
oder die korrekte Verschachtelung der Elemente ineinander. Außerdem muss das Dokument
in einer Baumstruktur darstellbar sein; dies schließt auch das Vorhandensein genau
eines Wurzelelements mit ein.
Von einem validen (valid) XML-Dokument spricht man hingegen, wenn das Dokument
den Vorgaben durch eine Document Type Definition (DTD) oder eine XML Schema
Definition (XSD) (siehe Abschnitt 2.2) entspricht. So müssen alle Elemente und ihre
Attribute durch die Schemasprache definiert sein. Oft muss auch eine bestimmte Reihenfolge
oder Anzahl der Elemente eingehalten werden.
Um XML-Daten in einer Anwendung zu verarbeiten, wird ein XML-Prozessor eingesetzt.
Notwendige Komponente eines jeden XML-Prozessors ist ein so genannter XML-Parser,
der ein XML-Dokument einliest und einzelne Bestandteile wie Elemente und Attribute
erkennt. Um diese erkannten Daten in einer Anwendung zu verarbeiten, gibt es verschiedene
Methoden zum Zugriff auf die Dokumente. Die populärsten Ansätze werden
nachfolgend erläutert.
2.1.1 Document Object Model (DOM)
Das vom W3C entwickelte Document Object Model (DOM) beschreibt ein XML-Dokument
in einer Baumstruktur. Abbildung 2.1 zeigt das im vorigen Abschnitt genannte
Beispiel als DOM-Baum.
Stadt
Stadtteil Stadtteil
Bemerode Wülferode
Abbildung 2.1: Darstellung eines XML-Dokuments in einer Baumstruktur.
Ein auf dem DOM basierender Parser liest zunächst das komplette Dokument in den
Hauptspeicher ein. Daraufhin wird eine Baumstruktur aufgebaut, die das eingelesene
Dokument repräsentiert. Nun ist es einer Anwendung möglich, über einheitliche Schnittstellen
auf das Dokument bzw. einzelne Elemente davon zuzugreifen. So ist ein gezielter
lesender und auch schreibender Zugriff möglich und auch das Einfügen neuer Elemente
9

an beliebigen Stellen kann so einfach realisiert werden.
Der Kern der Implementierung findet sich in der Klasse Node. Hier finden sich die meisten
Methoden, die aus der Verwendung von Bäumen als Datenstrukturen bekannt sind. Mit
getParentNode() kann beispielsweise der Zugriff auf Knoten und ihre Beziehungen zueinander
realisiert werden, durch appendChild(newchild) oder removeChild(oldchild)
ist es möglich, den Baum und somit das XML-Dokument zu verändern. Die Klasse
Element steuert den direkten Zugriff auf einzelne Elemente. So können beispielsweise
mit getElementsByTagName(name) alle Elemente mit dem angegebenen Namen zurückgegeben
werden. Für Attribute und Textanteile stehen ähnliche Zugriffsmethoden zur
Verfügung.
Den oben genannten Vorteilen (direkter Zugriff und Manipulation von Elementen sind
möglich) steht ein großer Nachteil des DOM gegenüber: der hohe Ressourcenverbrauch.
Da das komplette Dokument in den Hauptspeicher eingelesen wird, stößt die Technik hier
schnell an ihre Grenzen. Deshalb ist eine Verarbeitung von großen XML-Dokumenten
fast unmöglich zu realisieren.
2.1.2 Simple API for XML (SAX)
Die Simple API for XML (SAX) wählt einen ereignisgesteuerten Ansatz zum Einlesen
von XML-Dokumenten. Hierbei wird das zu parsende XML-Dokument sequentiell abgearbeitet,
wobei das Vorkommen bestimmter Bestandteile jeweils eine passende Aktion
bzw. eine Methode aufruft, die für die Anwendung entsprechend implementiert werden
muss.
Beispielsweise startDocument() und endDocument() werden aufgerufen, wenn am Anfang
des Dokuments das Einlesen begonnen wird bzw. das Ende des Dokuments erreicht
wurde und es somit komplett eingelesen ist. Ähnlich verhalten sich die Methoden
startElement(Name, Attributes) und endElement(Name); hier werden zusätzlich der
Elementname und etwaige Attribute als Parameter an die Methode übergeben. So ist es
möglich, auf die unterschiedlichen Elemente und Attribute verschieden zu reagieren.
Da SAX stets nur einen kleinen Teil eines Dokuments bearbeitet, eignet sich das Parsen
mit SAX auch für sehr große XML-Dokumente. Die Daten sollten möglichst als Sequenz
von Elementen mit einer einfachen Struktur vorliegen. Zu den größten Nachteilen von
SAX zählen die fehlende Möglichkeit der Manipulation von Dokumenten und der fehlende
Direktzugriff auf einzelne Elemente.
2.1.3 Streaming API for XML (StAX)
Auch die Streaming API for XML (StAX) gehört zur Familie der ereignisorientierten
XML-Parser und ist sehr stark an SAX orientiert. Der große Unterschied besteht in
der Kommunikation zwischen einem Anwendungsprogramm und dem Parser: bei SAX
10

spricht man hier von einer push-API, während StAX eine pull-API ist. SAX ” drückt“
(to push) die gelesenen Daten in das Anwendungsprogramm hinein, ohne auf eine Rückmeldung
zu warten. Das Anwendungsprogramm hat keinen Einfluss darauf, wann die
nächsten Daten geliefert werden.
Dem entgegen greift eine pull-API das Konzept eines Iterators auf. Die Daten werden
erst zur Anwendung ” gezogen“ (to pull), wenn sie auch wirklich benötigt werden.
Der Parser bewegt einen Cursor durch das zu lesende XML-Dokument, der durch Aufruf
der next()-Methode zum jeweils nächsten Element springt und das entsprechende
Ereignis auslöst. Das folgende Codebeispiel illustriert einen Durchlauf durch ein komplettes
XML-Dokument, wobei jeweils die Namen der gelesenen Startelemente ausgegeben
werden:
while (parser.hasNext()) {
int ereignis = parser.next();
if (ereignis == XMLStreamConstants.START_ELEMENT) {
System.out.println("Gelesenes Element: " + parser.getLocalName());
}
}
2.2 XML Schema
Um die Struktur und den Aufbau eines XML-Dokuments, ein XML-Schema 1 , zu beschreiben
und eindeutig festzulegen, bedient man sich einer so genannten Schemasprache.
Das W3C schuf bei der Entwicklung von XML die Document Type Definition (DTD) als
solch eine Schemasprache. Sie ist im XML 1.0 Standard [W3C06a] verankert und genießt
daher eine weite Verbreitung in Anwendungsprogrammen, gilt aber heutzutage bereits
als veraltet (siehe [Bri05]). Die größten Kritikpunkte sind zu geringe Darstellungsmöglichkeiten
und die Tatsache, dass die DTD selbst kein XML-Dokument ist. Deswegen
wird seit 2001 vom W3C der Nachfolger, XML Schema ([W3C04a] und [W3C04b]), entwickelt.
Eine XML Schema Definition (XSD) ist eine Instanz eines in XML Schema verfassten
XML-Schemas. Diese wird gewöhnlich in einer .xsd-Datei abgespeichert und kann dann
in ein XML-Dokument eingebunden werden. Es wird festgelegt, welche Elemente und
Attribute vorkommen dürfen, in welcher Beziehung sie zueinander stehen und welche
Datentypen sie beinhalten.
In XML Schema wird zwischen zwei Arten von Typen unterschieden:
1. Einfache Typen (simpleType) dürfen weder Kindelemente noch Attribute besitzen.
Ein Beispiel für einen einfachen Typen ist folgendes:
1 Im Rahmen dieser Arbeit bezeichnet XML-Schema (mit Bindestrich) stets ein Schema, nach dem
ein XML-Dokument aufgebaut ist, XML Schema (ohne Bindestrich) bezeichnet die Schemasprache.
11

mit einer dazugehörigen Instanz
Hannover
2. Komplexe Typen (complexType) können sowohl Kindelemente als auch Attribute
besitzen. Sie können sich auch aus einfachen Typen zusammensetzen, wie folgendes
Beispiel zeigt:
mit einer dazugehörigen Instanz
Hannover
7996942
XML Schema stellt eine Vielzahl von Standardtypen bereit. Hierbei handelt es sich
hauptsächlich um die auch aus Programmiersprachen bekannten primitiven Datentypen
wie String, Integer oder Date. Eine Einschränkung eines selbst definierten oder
Standarddatentyps ist durch das Element möglich. So kann beispielsweise
ein String auf 10 Zeichen begrenzt werden oder der Integer-Zahlenbereich für ein
Schulnoten-Element auf 1 bis 6 eingeschränkt werden. Ebenso ist eine Erweiterung von
(komplexen) Datentypen über das Element möglich. Im Zusammenspiel
mit der Vererbung lassen sich so bereits vorhandene Typen (base) leicht um zusätzliche
Attribute oder Kinderelemente erweitern.
Im Rahmen dieser Arbeit wird XML Schema als Beschreibungssprache für das AAA-
Modell in den GML-Anwendungsschemata (siehe folgenden Abschnitt) verwendet, die
eine wichtige Grundlage der NAS sind.
12

2.3 Geography Markup Language (GML)
Wie in den vorigen Kapiteln bereits angedeutet, ist es ein wesentlicher Bestandteil von
verteilten Geoinformationssystemen, Daten zwischen verschiedenen Systemen auszutauschen.
Außerdem ist es teilweise nötig, Daten in eine Datei zu speichern bzw. zu exportieren.
Um diesen Daten eine einheitliche Form zu geben, wurde vom Open Geospatial
Consortium (OGC) die Geography Markup Language (GML) entworfen. Zunächst als
OGC 02-023r4
OGC-Standard veröffentlicht durchläuft GML zur Zeit als Version 3.1 die Prüfung zum
Standard 19136 der International Organization for Standardization (ISO) [ISO07] und
basiert The auch types selbst and elements auf zahlreichen required for OGC- backwards und ISO-Spezifikationen. compatibility with GML Seit2 Version are part of 2 ist
GML
geometryBasic0d1d.xsd,
komplett in der Beschreibungssprache
geometryBasic2d.xsd
XML
and
Schema
geometryAggregates.xsd.
verfasst.
geometryPrimitives.xsd and geometryComplex.xsd are comprised of entirely new
types and elements.
Die hier betrachtete, da in der NAS verwendete, Version 3.0 von GML [OGC02] definiert
Class - diagrams im Vergleich of an mit UML der Model Vorgängerversion are added for illustration. GML 2 - eine These wesentlich diagrams größere are Menge
aninformative, Geometrietypen not normative. [LBTR04]. Figure Die7.5-1 Beschreibungssprache shows an overview deckt of the nun type beispielsweise hierarchy of the auch
dreidimensionale GML geometry types. Objekte und Topologie ab. Abbildung 2.2 zeigt die Typenhierarchie
der in GML 3.0 möglichen Geometrietypen. An dieser Stelle wird jedoch im Wesentlichen
der
NOTE:
für diese
The diagrams
Arbeit relevante
represent
Teil
an implementation
der GML-Geometrien
model derived
betrachtet,
from the
der sich an das
Simple
conceptual
Features
UML
Profile
model
[OGC06a]
specified
des
in
OGC
Topic
hält.
1 of OGC’s Abstract Specification (ISO
DIS 19107).
LineString
_CoordinateReferenceSystem
(from CoordinateReferenceSystems)
Curve
i
+segments 1
_CurveSegment
Point
OrientableCurve
Polygon
+interior +exterior
0..n
0..1
_Ring
+srsName
0..1
_GeometricPrimitive
_Curve
CompositeCurve
Surface
i
+patches 1
_SurfacePatch
_GML
(from gmlBase)
+ description [0..1] : CharacterString
+ name [0..*] : CharacterString
+ id [0..1] : ID
_Geometry
+ gid [0..1] : CharacterString
_Surface
OrientableSurface
GeometricComplex
_Solid
Solid CompositeSolid
CompositeSurface
MultiGeometry
_GeometricAggregate
MultiPoint
MultiCurve MultiSolid
MultiSurface
Abbildung 2.2: UML-Klassendiagramm Figure 7.5-1 – Type Hierarchy der Geometrietypen of the GML geometry von GML types 3.0 aus [OGC02].
Any geometry element that inherits the semantics of AbstractGeometryType can be
viewed as a set of direct positions.
All of the classes in the inheritance tree of AbstractGeometryType 13
inherit an optional
association to a coordinate reference system. All direct positions shall directly or
indirectly be associated with a coordinate reference system. When geometry elements are
aggregated in another geometry element (such as a MultiGeometry or

Die in GML 3 zur Verfügung stehenden Geometrischen Primitiven (Geometric-
Primitives) sind:
1. Point für einfache Punkte.
2. Curve, d.h. Kurven bzw. Linien, zur Modellierung aller linienförmigen Geometrien.
Eine Curve besteht immer aus einem oder mehreren segments 2 (Segmenten).
Diese Segmente können einfache linear interpolierte Kurvensegmente sein
(LineStringSegment), aber auch Kreisbögen (z.B. Arc) oder weitere durch verschiedene
Interpolationsverfahren gewonnene Liniengeometrien (z.B. CubicSpline).
3. Surface zur Darstellung von Flächengeometrien. Ähnlich zu den Kurven werden
auch Flächen aus mehreren Teilen zusammengesetzt. Hier spricht man von patches
bzw. genauer von surface patches (nach [BT07] in etwa ” Flächenstück“). Diese
Teilstücke werden in den meisten Fällen Polygone (PolygonPatch) sein. Es sind
aber z.B. auch Dreiecke (Triangle) oder Rechtecke (Rectangle) möglich.
4. Solid (nach [BT07] in etwa ” Festkörper“) ist speziell für dreidimensionale Geometrien
entwickelt worden. Diese Geometrien spielen im Rahmen dieser Arbeit jedoch
keine Rolle, da nur zweidimensionale Geometrien verwendet werden.
Bei der Benennung der Kurvensegmente fällt auf, dass z.B. LineStringSegment nicht
zur weiteren Systematik der Benennung passt. Dies liegt daran, dass LineString bereits
eine GML 2-Geometrie ist und hier zur klaren Unterscheidung ein neuer Name gewählt
werden musste. Gleiches gilt für PolygonPatch in GML 3 und Polygon bei GML 2.
Neben den oben genannten GeometricPrimitives stellt GML 3 auch komplexe Geometrien
(GeometricComplex) zur Verfügung. Diese sind aus den einfachen Geometrietypen
zusammengesetzt. Die einzelnen Komponenten einer komplexen Geometrie müssen dabei
zusammenhängend sein, dürfen sich aber nicht überschneiden. Eine CompositeCurve beispielsweise
kann aus zwei oder mehr aneinandergrenzenden Geometrien vom Typ Curve
zusammengesetzt sein. Der Startpunkt der zweiten Curve ist dabei der Endpunkt der
ersten Curve und so weiter.
Die Bedingung des Zusammenhangs entfällt bei den GeometricAggregates. Dies sind
einfache Sammlungen von gleichartigen Geometrien, die nicht zusammenhängen müssen.
Beispielsweise könnte eine MultiCurve zur Darstellung mehrerer unverbundener Straßen
(modelliert durch je eine Curve) innerhalb eines Gebietes verwendet werden.
Das folgende Beispiel einer GML 3-Geometrie stellt eine Curve dar, also eine Linie,
die in diesem einfachen Fall nur aus einem Segment besteht. Dieses LineStringSegment
setzt sich wiederum aus zwei Koordinatenpaaren zusammen, zwischen denen das Liniensegment
interpoliert wird.
2 Die Kleinschreibung wurde hier und im Folgenden aus der GML-Spezifikation übernommen.
14

3463335.510 5528724.660
3463421.850 5528759.060
Die in der NAS für ein Raumbezogenes Elementarobjekt (REO) zu verwendende Geometrie
wird in einer Anlage zur GeoInfoDok [AdV06] festgelegt. Hier wird die Verwendung
der GML-Geometrien auf folgende Geometrien eingeschränkt:
• gml:Surface und gml:MultiSurface
• gml:Curve, gml:MultiCurve und gml:CompositeCurve
• gml:Point und gml:MultiPoint
Ein GML-Feature ist ein Objekt der realen Welt, welches in GML modelliert werden
kann. Mit GML lassen sich sowohl die räumlichen als auch die thematischen Eigenschaften
von Features modellieren. Der Zusatz Simple schränkt die zu einem Feature
gehörende Geometrie auf den zweidimensionalen Raum ein. Es lassen sich also im Wesentlichen
Geometrien aus Punkten, Linien und Polygonen realisieren.
Da eine bestimmte Anwendung selten auf den gesamten Funktionsumfang von GML
zugreifen wird, gibt es die so genannten GML-Profile. Ein Profil definiert den für eine
Anwendung relevanten Teil, stellt also eine Auswahl und Einschränkung des Funktionsumfangs
dar. Wendet man ein Profil an, so hat man weiterhin nur die Basisdatentypen
aus der GML-Spezifikation zur Verfügung. Eigene Typen (s.u.) sind hier noch nicht eingeplant.
Ein weit verbreitetes Profil ist beispielsweise das GML Simple Features Profile
([OGC06a], s.o.), das nur lineare Geometrien beinhaltet, dreidimensionale Geometrien
oder Topologie hingegen ganz außen vor lässt. Es bietet so ausreichend Möglichkeiten zur
Modellierung der realen Welt und blendet komplexere Möglichkeiten von GML zunächst
aus. Noch restriktiver ist beispielsweise das Point Profile [OGC05a], das nur Punkt-
Geometrien zulässt. Auch in der NAS wird der Umfang der erlaubten GML-Elemente
und -Typen durch ein GML-Profil (gml3nas.xsd) 3 reduziert.
Ein GML-Anwendungsschema hingegen ist zur Erweiterung des Sprachumfangs gedacht.
Hierbei ist es möglich, den vollen GML-Sprachumfang zu nutzen, oder einen zuvor durch
ein Profil eingegrenzten. Durch ein Anwendungsschema ist es möglich, dem Basisschema
von GML eigene Typen hinzuzufügen. Ein Anwendungsschema deckt meist einen speziellen
Themenbereich ab und stellt neue Objekttypen zu diesem Thema bereit. So kann ein
3 Diese Datei befindet sich im Unterordner NAS5.1.1/gml/3.0.0/base der unter [AdV07] erhältlichen
ZIP-Datei.
15

Anwendungsschema zum Thema ” Stadt“ die neuen Objekttypen Straße oder Marktplatz
mit sich bringen, die wiederum aus den in GML spezifizierten Primitiven zusammengesetzt
sind. Ein Anwendungsschema wird in XML Schema verfasst und kann auf anderen
Anwendungsschemata aufbauen oder diese einbinden. In der NAS finden sich u.a.
GML-Anwendungsschemata für das AAA-Basisschema (AAA-Basisschema.xsd) und das
AAA-Fachschema (AAA-Fachschema.xsd) 4 . Eine Übersicht über die in der NAS verwendeten
GML-Anwendungsschemata findet sich in Abschnitt 3.5.
2.4 Filter Encoding Specification (FES)
Die Filter Encoding Specification (FES) wurde vom OGC ursprünglich im Rahmen des
Web Feature Service (WFS) entwickelt, um Filterausdrücke in Anfragen (Queries) an
den Server zu ermöglichen. Mittlerweile wurde die Spezifikation jedoch in einen eigenen
Standard ausgelagert [OGC05b], da sie heute in zahlreichen weiteren OGC-Standards
Verwendung findet. Ziel der Filter Encoding Specification ist es, bestimmte Objektinstanzen
aufgrund ihrer Eigenschaften (Attribute, Typ, Beziehungen) aus einer großen
Menge von Objektinstanzen herauszufiltern, d.h. anzufragen. Diese Filterausdrücke werden
in XML verfasst und können mit der WHERE-Klausel einer SQL-Anfrage verglichen
werden. Auch in der NAS wird die FES als Anfragesprache zum Identifizieren einzelner
Objektinstanzen benutzt.
Die Filter Encoding Specification kennt drei verschiedene Klassen von Operatoren:
1. Vergleichsoperatoren, die im Wesentlichen aus SQL bekannt sind. Dies sind beispielsweise
für =“, für
”
”

20
Eine dazu passende Objektinstanz könnte folgendermaßen aussehen:
[..]
15
Um auch Anfragen an komplexe Objekteigenschaften zu ermöglichen, kann innerhalb eines
Filter-Ausdrucks die XML-Anfragesprache XPath [W3C07] verwendet werden. Das
folgende Beispiel zeigt die Eigenschaft lebenszeitintervall als komplexe Objekteigenschaft.
Im Gegensatz zu der oben genannten einfachen Eigenschaft breiteDesGewaessers
hat diese Eigenschaft selbst wieder Kindelemente (siehe Abschnitt 2.1):
[..]
2007-07-20T14:30:00Z
Ein dazu passender Filterausdruck, der diese komplexe Eigenschaft überprüft, ist im
Folgenden angegeben:
lebenszeitintervall/AA_Lebenzeitintervall/beginnt
2007-07-15T10:00:00
2.5 Web Feature Service (WFS)
Der Web Feature Service (WFS) wurde vom Open Geospatial Consortium (OGC) spezifiziert
[OGC05c], um einen plattformunabhängigen Zugriff auf verteilte vektorielle Geodaten
zu ermöglichen. Die Methode zur Speicherung der Daten auf dem Server (Datenbank,
Dateisystem) und ihr Format spielt hierbei keine Rolle, da die Clients nur
17

auf fest definierte Schnittstellen der Server zugreifen. Der Datenaustausch erfolgt über
das Hypertext Transfer Protocol (HTTP) bzw. HTTPS für verschlüsselte Verbindungen.
Die von einem Web Feature Server angebotenen Dienste können variieren. Man unterscheidet
zwischen:
1. Basic WFS mit den Schnittstellen
• GetCapabilities() zur Beschreibung der vom Server angebotenen Operationen
und der auf dem Server verfügbaren FeatureTypes, wiederum mit ihren
Operationen. Dies stellt in der Regel die erste Anfrage des Clients dar.
• DescribeFeatureType(typename) zur Beschreibung eines auf dem Server
verfügbaren FeatureType. Als Antwort wird eine XML-Schema-Datei zurückgegeben.
• GetFeature(filter) für Anfragen des Clients nach bestimmten Feature-
Instanzen. Eine Einschränkung der Ergebnismenge ist durch den Parameter
filter möglich, der nach der OGC Filter Encoding Specification eine detaillierte
Selektion der zu holenden Features ermöglicht.
2. Transaction WFS mit den Schnittstellen
• Insert(features) zum Einfügen neuer Feature-Instanzen. Diese werden in
GML an den WFS übergeben, wobei sie der durch DescribeFeatureType
(typename) festgelegten Schemadefinition entsprechen müssen.
• Delete(filter) zum Löschen vorhandener Feature-Instanzen. Auch hier kann
wieder ein OGC-Filter verwendetet werden.
• Update(filter, propertyname, propertyvalue) zum Aktualisieren oder
Ändern vorhandener Feature-Instanzen. Die Auswahl einer Instanz erfolgt
wiederum durch einen OGC-Filter, außerdem wird der Name des zu aktualisierenden
Feature-Attributs und dessen neuer Wert als Parameter übergeben.
Ein OGC-konformer Web Feature Server muss mindestens die Basisschnittstelle (nur
lesender Zugriff) zur Verfügung stellen, die schreibenden Zugriffe des Transaction WFS
sind optional. Alle Schnittstellen sind in XML Schema verfasst und frei verfügbar.
Will ein Client einen Server kontaktieren, so sendet er einen Request (Anfrage) an diesen.
Der Server muss laut Spezifikation jede Anfrage mit einer Response (Antwort) beantworten.
Im Fall eines validen Requests ist das Format der Antwort genau spezifiziert, im
Fehlerfall ist eine Service Exception an den Client zu senden.
Die Antworten des Servers sind allesamt XML-Dokumente. Im Falle von GetCapabilities()
und den Methoden des Transaction WFS handelt es sich um ” reines XML“,
DescribeFeatureType() liefert ein GML-Anwendungsschema in XML Schema zurück.
18

Ein zu diesem Schema konformes GML-Dokument (siehe Abschnitt 2.3) wird letztendlich
von GetFeature() generiert und an den Client gesendet.
In der NAS werden die Methoden des WFS als Steuerinformationen innerhalb einer
NAS-konformen XML-Datei verwendet. So wird festgelegt, welche Daten eingefügt, gelöscht
oder aktualisiert werden müssen. Die WFS-Spezifikation wurde von der AdV um
einige AdV-spezifische Funktionen ergänzt. Besonders ist zu beachten, dass in der NAS
statt update eine neue Funktion replace eingeführt wird. Bei einem replace sind stets
alle Eigenschaften des Objekts anzugeben, die Verwendung von update würde hingegen
nur die geänderten Eigenschaften benötigen.
Der WFS entstammt einer ganzen ” Familie“ von OGC-Standards (WFS, WCS und
WMS), die sich in ihrem Aufbau sehr ähnlich sind. So muss beispielsweise die Basisfunktion
GetCapabilities() in allen drei Spezifikationen implementiert werden. Ergänzend
seien deshalb hier noch die beiden anderen durch das OGC spezifizierten Webservices
erwähnt:
• Der Web Coverage Service (WCS) [OGC06c] ist komplett analog zum WFS aufgebaut,
liefert jedoch Geodaten in Form von Coverages an den Client. Coverage
steht nach ISO- und OGC-Definition eigentlich für kontinuierliche flächenhafte
Phänomene, der WCS-Standard interpretiert diesen Begriff jedoch ausschließlich
als Rasterdaten. Sie werden mit detaillierten Beschreibungen und ihrer ursprünglichen
Semantik bereitgestellt.
• Der Web Map Service (WMS) [OGC06b], der aus Raster- oder Vektordaten auf
dem Server ein Kartenbild in Form einer Bilddatei erzeugt und diese als Rastergrafik
(z.B. JPG) oder Vektorgrafik (z.B. SVG) an den Server zurückschickt. Im
Gegensatz zu beiden zuvor betrachteten Services liefert ein WMS stets nur eine
Visualisierung zurück, nicht aber die zu Grunde liegenden Daten und deren Semantik.
19

Kapitel 3
Das AAA-Modell
3.1 Das AAA-Modell
Das AAA-Modell wird von der AdV entwickelt, um die zuvor getrennt geführten Datenbestände
der Informationssysteme AFIS, ALKIS und ATKIS in einem gemeinsamen
Referenzmodell in Beziehung zu bringen. Eine standardisierte Beschreibung in UML,
ein gemeinsames Objektmodell und harmonisierte Objektartenkataloge stellen hierbei
die konzeptionelle Ebene dar, die Normbasierte Austauschschnittstelle (NAS) legt eine
einheitliche externe Sicht auf die Daten fest und definiert somit auch die Datenaustauschschnittstelle.
Die gesamte Spezifikation ist in Form der ” GeoInfoDok“ [AdV06] frei
verfügbar.
AAA-Anwendungsschema
Internationale Normen
(ISO, OGC)
AAA-Basisschema
ATKIS ALKIS AFIS
AAA-Fachschema
NAS
Abbildung 3.1: Das AAA-Anwendungsschema.
Die Umsetzung dieses Referenzmodells wird im gemeinsamen AAA-Anwendungsschema
beschrieben (Abbildung 3.1). Ein Anwendungsschema entsteht durch Abstraktion der
realen Welt und definiert formale Strukturen für Daten und Inhalte. Alle in der realen
20

Welt erfassten Daten müssen dann nach diesem festgelegten Modell in den Datenbestand
der Anwendung aufgenommen werden. Das AAA-Anwendungsschema unterteilt
sich wiederum in
1. das AAA-Basisschema und
2. ein Fachschema, beispielsweise das AAA-Fachschema, das sich aus AFIS, ATKIS
und ALKIS zusammensetzt.
AAA_Operationen
AA_Auftrag
AA_Ergebnis
AA_Instanzenthemen
AA_Themendefinition
AA_Art_Themendefinition
AA_Themendimension
AA_Empfaenger
AA_NAS_Ausgabeform
AA_Benutzungsauftrag
AA_Anlassart_Benutzungsauftrag
AA_Bestandsdatenauszug
AA_Koordinatenreferenzsystemangaben
AA_Objektliste
AA_Fortfuehrungsauftrag
AA_Fortfuehrungsergebnis
GetCapabilities
ServiceMetadata
DataContents
DCP
ExceptionFortfuehrung
Operation
NAS_Filter_Capabilities
AAA_Praesentationsobjekte
AP_TPO
AP_PPO
AP_LPO
AP_FPO
AP_GPO
AP_HorizontaleAusrichtung
AP_PTO
AP_LTO
AP_VertikaleAusrichtung
AP_Darstellung
AAA_GemeinsameGeometrie
AG_Punktobjekt
AG_Linienobjekt
AG_Flaechenobjekt
AG_Geometrie
AG_Objekt
AAA_Katalog
AC_FeatureType
AC_ObjektTypenBezeichnung
AC_Objektartengruppe
AC_Thema
AC_Themenart
AC_Objektartenbereich
AC_FeatureCatalogue
AC_FeatureAttribute
AC_AssociationRole
AC_FeatureOperation
AC_Typensammlung
AC_Erfassungskriterium
AC_DataType
AC_DataTypeKategorie
AC_Profil
AC_CommonElements
AC_LetzteAenderung
AC_ListedValue
AC_Konsistenzbedingung
AC_Bildungsregel
AAA_Spatial Schema
AG_ObjektMitGemeinsamerGeometrie
AA_PunktLinienThema
AA_Flaechengeometrie
AA_Liniengeometrie
TA_SurfaceComponent
TA_CurveComponent
TA_PointComponent
TA_MultiSurfaceComponent
AU_ObjektMitUnabhaengigerGeometrie
AAA_Punktmengenobjekte
AD_PunktCoverage
AD_GitterCoverage
AD_ReferenzierbaresGitter
AD_Wertematrix
AAA_Projektsteuerung
AA_Antrag
AA_Projektsteuerung
AA_Meilenstein
AA_Vorgang
AA_Projektsteuerungsart
AA_Vorgangsart
AA_VorgangInProzess
AA_Dokumentationsbedarf
AA_Gebuehrenparameter
AA_Projektsteuerungskatalog
AA_Antragsart
AA_BesondereMeilensteinkategorie
AA_Aktivitaet
AA_Aktivitaetsart
AA_AktivitaetInVorgang
AA_DurchfuehrungAktivitaet
AA_ProzesszuordnungAktivitaet
AA_Antragsgebiet
AAA_Nutzerprofile
AA_Benutzer
AA_Benutzergruppe
AAA_Unabhaengige Geometrie
AU_Punktobjekt
AU_Linienobjekt
AU_Flaechenobjekt
AU_KontinuierlichesLinienobjekt
AU_Geometrie
AU_Objekt
AA_Punktgeometrie
AU_Punkthaufenobjekt
AAA_Basisklassen
AA_ZUSO
AA_REO
AA_NREO
AA_Objekt
AA_Fachdatenverbindung
AA_Lebenszeitintervall
AA_UUID
AA_ObjektOhneRaumbezug
AA_Fachdatenobjekt
AA_Modellart
AA_AdVStandardModell
URI
AA_PMO
AA_Anlassart
AA_WeitereModellart
Abbildung 3.2: Pakete des AAA-Basisschemas. Eigene Darstellung nach [AdV06].
Das AAA-Basisschema stellt hierbei die Grundlage für beliebige Fachschemata dar, ist
also nicht auf das AAA-Fachschema beschränkt. Es werden dort in 10 Paketen die
grundlegenden Klassen definiert, die eine Modellierung der Fachobjekte in einem Fachschema
ermöglichen (siehe Abbildung 3.2). Hierzu zählt beispielsweise ein Paket, welches
Basisklassen für Objekte mit unabhängiger Geometrie enthält (AAA_Unabhaengige
21

Geometrie). Ein weiteres Paket stellt Basisklassen für Präsentationsobjekte zur Verfügung
(AAA_Praesentationsobjekte). Das AAA-Basisschema implementiert zahlreiche
Normen der ISO 191XX -Familie des technischen Komitees 211 1 ( ” Geographic information“);
diese werden teilweise jedoch angepasst bzw. erweitert.
Die Zugehörigkeit zu einem Paket bzw. der Ursprung einer Klasse ist als Präfix dem
Klassennamen vorangestellt. Die Benennung erfolgt nach folgender Systematik (gekürzt
übernommen aus [AdV07] und mit eigenen Anmerkungen ergänzt):
• Genormte Klassen (z.B. durch ISO oder OGC) behalten das jeweilige genormte
Präfix im Klassennamen (z.B. FC für ” Feature Catalogue“, MD für ” Metadata“).
• Klassen mit grundsätzlicher Bedeutung für AFIS, ALKIS und ATKIS erhalten das
Präfix AA. Dies betrifft viele Klassen des Basisschemas.
• Klassen, die aus den ISO TS *Component - Klassen ( ” simple topology“) abgeleitet
wurden, erhalten das Präfix TA.
• Klassen mit gemeinsam genutzter Geometrie erhalten das Präfix AG.
• Klassen der unabhängigen Geometrie erhalten das Präfix AU.
• Klassen der Präsentationsobjekte erhalten das Präfix AP.
• Die instanziierbaren Klassen der Fachobjekte und ihre Bezeichnung in der NAS
haben das Präfix AX (z.B. AX_Wald).
Die Klassen des AAA-Anwendungsschemas folgen einer strengen Klassenhierarchie. Das
Prinzip der Vererbung wird konsequent eingesetzt. Grundlage aller Klassen zur Darstellung
von Fachobjekten ist die abstrakte Klasse AA_Objekt aus dem Paket AAA_Basisklassen.
Alle Fachobjekte erben von dieser Klasse somit die folgenden fünf Eigenschaften:
1. Den Identifikator, der ein Fachobjekt eindeutig bestimmt.
2. Das Lebenszeitintervall zur Versionierung.
3. Den Anlass für die Entstehung, Änderung oder Löschung des Objekts.
4. Die Modellart, bei ATKIS z.B. Basis-DLM.
5. Die Beziehung zeigtAufExternes, um einen Verweis auf externe Fachinformationssysteme
zu ermöglichen.
1 http://www.iso.org/iso/en/stdsdevelopment/tc/tclist/TechnicalCommitteeDetailPage. Technical-
CommitteeDetail?COMMID=4637
22

Um ein Objekt innerhalb eines Systems (z.B. auch bundesweit) eindeutig zu repräsentieren,
wird jedes Objekt im AAA-Modell mit einem Identifikator versehen. Dieser Identifikator
wird festgelegt, wenn das Objekt entsteht und bleibt bis zum Löschen der letzten
Version des Objekts unverändert. Eine Versionierung ist im AAA-Modell durch das Lebenszeitintervall
eines Objekts möglich. Die Lebenszeit der ersten Version eines Objektes
beginnt stets mit dem Einfügen in den Datenbestand. Hierfür wird die Transaktionszeit
betrachtet, es wird also die Systemzeit des Systems betrachtet, auf dem das Objekt
in den Datenbestand eingepflegt wird. Bei Änderung eines Objekts wird zwischen zwei
Fällen unterschieden:
1. Änderung von objektbildenden Eigenschaften bewirken das Löschen des zu ändernden
Objekts (d.h. das Lebenszeitintervall der letzten Version bekommt ein Enddatum)
und ein neues Objekt mit einem neuen Identifikator wird in den Datenbestand
eingefügt (delete mit anschließendem insert). Die Änderung der Objektart oder
der Geometrie eines Objekts erzeugt beispielsweise immer ein neues Objekt.
2. Änderung von nicht-objektbildenden Eigenschaften bewirken die Schaffung einer
neuen Version des Objekts (mit identischem Identifikator). Das Anfangsdatum des
Lebenszeitintervalls der neuen Version entspricht hierbei dem Enddatum der alten
Version (replace). Beispielsweise die Änderung eines Attributwertes bringt die
Erschaffung einer neuen Version eines bestehenden Objektes mit sich.
Die Regeln zur Objektbildung werden durch Kennzeichnung von objektbildenden Eigenschaften
einerseits verbindlich im Objektartenkatalog (z.B. ATKIS) festgelegt, können
aber andererseits auch ” länderspezifisch erweitert werden“ [AdV07]. Die Bundesländer
können also weitere Eigenschaften eines Fachobjekts als objektbildend festlegen.
Die historischen Informationen bleiben durch diese Art der Versionierung komplett im
Datenbestand erhalten.
Der Aufbau des 16-stelligen Identifikators ist in der GeoInfoDok genau festgelegt und enthält
Informationen zur Nationalität (DE), eine Kennung der ausstellenden Implementierungsstelle,
beginnend mit dem ISO-Code des Bundeslandes bzw. der -behörde (NI1234),
und eine laufende eindeutige Nummer: DENI123412345678. Um verschiedene Versionen
eines Objekts unterscheiden zu können, wird der Identifikator um die Zeitangabe der
Entstehung der Version des Objektes ergänzt. Eine so zusammengesetzte Kennung hat
folgende Form:
DENI12341234567820070501T132500Z
Sie verweist also auf die Version des oben angegebenen Objektes, deren Lebenszeitintervall
am 1. Mai 2007 um 13:25:00 Uhr der Zeitzone Z 2 begann. Durch diese Kennzeichnung
werden sichere Lösch- und Updatevorgänge garantiert, auch eindeutige Verweise auf Objektversionen
sind so möglich.
2 Universal Time Coordinated (UTC), Greenwich Mean Time
23

Neben den hier genannten Attributen, die für alle Fachobjekte gültig sind, können im
AAA-Modell für jedes Fachobjekt weitere thematische Attribute festgelegt werden. In
den jeweiligen Objektartenkatalogen des Fachschemas wird für jedes Fachobjekt festgelegt,
welche Atttribute für eben dies Objekt möglich sind. Hierbei werden die Attributtypen
wie folgt beschrieben:
• Jedes Attribut hat eine eindeutige Kennung. Dies ist z.B. NAM für ein thematisches
Attribut, das einen Namen - beispielsweise einen Straßennamen - angibt.
• Der Datentyp des Attributwertes wird festgelegt. In diesem Fall ist der Name vom
Typ String.
• Es wird eine Kardinalität vorgegeben und somit auch festgelegt, welche Attribute
zwingend angegeben werden müssen. So kann z.B. ein Name für eine Straße
als zwingend notwendig definiert werden, während ein Friedhof auch ohne einen
Namen auskommt.
Auch die Einschränkung eines Attributtyps auf eine bestimmte Menge vordefinierter
Werte ist im AAA-Modell vorgesehen. Dies geschieht durch die so genannten Codelisten.
Sie bestehen aus einer Aufzählung von Zuordnungen zwischen Kennungen und Werten.
Die Kennungen sind hierbei in Form von Nummern gegeben, die innerhalb einer Codeliste
eindeutig sein müssen. Die Werte stellen Beschreibungen dar, welche die Bedeutung
je einer Nummer erläutern.
Codelisten werden im AAA-Modell als Datentypen in eigenen Klassen modelliert. Das
nachfolgende Beispiel (in XML Schema verfasst; aus dem GML-Anwendungsschema des
AAA-Fachschema) legt die möglichen Werte für die Vegetation eines Waldes fest. Es handelt
sich um den Datentyp AX_Vegetationsmerkmal_Wald, der unter dieser Bezeichnung
auch einem Fachobjekt als Attributtyp zugeordnet werden kann.
Dieser neu erstellte Datentyp kann dann in der Definition der Attribute eines Fachobjekts
verwendet werden (hier für das Fachobjekt AX_Wald):
24

Als Attributwert wird in der NAS dann stets nur die Nummer des referenzierten Wertes
angegeben, also beispielsweise
1100.
Auf der nächsten Stufe der Klassenhierarchie definiert das AAA-Basisschema vier weitere
abstrakte Basisklassen für Objekte, die im Vergleich zu AA_Objekt jedoch bereits
weiter spezialisiert sind. Diese sind im Paket ebenfalls im Paket AAA_Basisklassen enthalten
und werden in Abbildung 3.3 und nachfolgend erläutert:
• Raumbezogene Elementarobjekte (Klasse AA_REO) sind die kleinste mögliche Einheit,
lassen sich also nicht in weitere Objekte zerlegen und haben neben thematischen
Eigenschaften einen Raumbezug in Form von geometrischen oder topologischen
Eigenschaften. Dies ist z.B. bei einem Flurstück der Fall und es wird somit
im AAA-Modell als REO angesehen.
AA_PMO
+name [0..1]: CharacterString
+beschreibung [0..1]: CharacterString
+ausdehnung: GM_Envelope
AA_Objekt
+ identifikator: AA_UUID
+lebenszeitintervall: AA_Lebenszeitintervall
+modellart: Set
+anlass [0..1]: Sequence
+zeigtAufExternes [0..1]: Set
+hatDirektUnten
0..*
Unterführung
AA_REO
0..*
+istAbgeleitetAus
0..*
+traegtBeiZu
0..1
Kartengeometrie
+bestehtAus
1..*
AA_NREO
AA_ZUSO
Zusammensetzung
+istTeilVon
0..*
Abbildung 3.3: Die vier Basisklassen für Objekte im Zusammenhang. Eigene Darstellung
nach [AdV06].
• Nicht raumbezogene Elementarobjekte (Klasse AA_NREO) gehören ebenfalls zu den
Elementarobjekten, haben im Unterschied zu REOs aber keinen Raumbezug und
somit nur thematische Eigenschaften. Personen sind im Sinne des AAA-Modells
NREOs, da sie z.B. einen Namen als thematische Eigenschaft, jedoch keine Geometrie
besitzen.
• Zusammengesetzte Objekte (Klasse AA_ZUSO) werden aus beliebig vielen semantisch
zusammengehörigen Objekten (REOs, NREOs und auch ZUSOs) gebildet,
müssen aber mindestens aus einem Elementarobjekt (REO oder NREO) bestehen.
Das Konzept der ZUSOs ermöglicht hierarchische Zusammenhänge zwischen
25

Objekten gleicher oder verschiedener Objektarten. Ein Beispiel für ein ZUSO
aus dem ATKIS-Objektartenkatalog ist in Abbildung 3.4 dargestellt: das ZUSO
AX_Strasse besteht aus den drei Elementarobjekten AX_Fahrbahnachse 3 (zweimal)
und AX_Strassenachse. Die angrenzenden Flächen der Objektart AX_Landwirtschaft
sind nicht Teil des ZUSO und dienen nur zur Veranschaulichung der
Umgebung.
AX_Fahrbahnachse
AX_Strasse
bestehtAus
AX_Strassenachse AX_Fahrbahnachse
AX_Landwirtschaft
Abbildung 3.4: Aufbau eines ZUSOs am Beispiel einer Straße. Eigene Darstellung nach
[AdV06].
• Punktmengenobjekte (Klasse AA_PMO) beschreiben große Ansammlungen von unterschiedlichen
geometrischen Orten mit gleichen Attributarten. Diese Basisklasse
spielt im Wesentlichen für ein Digitales Geländemodell (DGM) eine Rolle, genauer
für die Punkte des DGM-Gitters. Im Kontext dieser Arbeit, die sich hauptsächlich
mit den ATKIS-DLM beschäftigt, spielt diese Klasse von Objekten keine Rolle.
3 AX_Fahrbahnachse ist im AAA-Modell als linienförmige Geometrie (als Mittelachse der Fahrbahn)
modelliert. Die Zuweisung einer Breite erfolgt durch das Attribut breiteDerFahrbahn. In Abbildung
3.4 wurde die intuitivere flächenförmige Visualisierung einer Fahrbahn gewählt.
26

Auf diesen vier Basisklassen aufbauend definiert das AAA-Basisschema in den in Abbildung
3.2 dargestellten Paketen zahlreiche abstrakte Objektklassen, von denen die Fachschemata
durch Vererbung konkrete Klassen ableiten können. Dies sind bei den Fachobjekten
beispielsweise AA_ZUSO und AA_REO selbst, AG_Linienobjekt, AU_Flaechenobjekt
usw. Eine komplette Klassenhierarchie für ein Fachobjekt wird in Abbildung 3.5 für die
Objektarten AX_Friedhof, AX_Strasse und AX_Strassenachse dargestellt.
AA_REO
AA_Objekt
+identifikator
+lebenszeitintervall
+modellart
+anlass
+zeigtAufExternes
AG_ObjektMitGemeinsamerGeometrie
TA_SurfaceComponent
AX_TatsaechlicheNutzung
AX_Friedhof
+name
TA_CurveComponent
AX_Strassenachse
+breiteDerFahrbahn
+funktion
+[...]
AA_ZUSO
AX_Strasse
+name
+widmung
+[...]
Abbildung 3.5: Darstellung der Klassenhierarchie im AAA-Anwendungsschema anhand
der Fachobjekte AX Friedhof, AX Strasse und AX Strassenachse.
27

Diese Vorgaben durch das Basisschema finden sich auch bei den Beziehungstypen, die
die Objekte untereinander eingehen können. Die Zusammenhangsrelation bestehtAus
und istTeilVon ermöglicht Objekte der Basisklasse ZUSO, die durch das Zusammenfügen
mehrerer Objekte entstehen. Die Unterführungsrelation hatDirektUnten kennzeichnet
die relative vertikale Lage zweier Objekte zueinander. Diese Beziehung ist auch
transitiv möglich, das heißt ein Objekt kann beliebige unter sich befindliche Objekte
referenzieren. Für Objekte mit generalisierter Geometrie ist die Relation zu den zugehörigen
Basisobjekten wichtig. Dies stellt der Beziehungstyp Kartengeometrie mit
istAbgeleitetAus und traegtBeiZu dar. Ähnliches leistet die Präsentationsbeziehung
mit dientZurDarstellungVon, die einem Objekt der Bestandsdaten ein Präsentationsobjekt
zuordnet. Auch ein Verweis auf ein fremdes Fachinformationssystem ist möglich,
dies leistet zeigtAufExternes.
Einige Beziehungen zwischen Fachobjekten des AAA-Anwendungsschemas sind von der
AdV für ” beide Richtungen“ modelliert, das heißt, es gibt zu jeder Beziehung eine inverse
Beziehung, die von dem referenzierten Fachobjekt wieder auf das ursprüngliche Fachobjekt
verweist. Diese Modellierung der Beziehungen ist in den UML-Modellen und auch in
den XML Schema-Dateien vorgesehen, um auch Gegenrelationen in Abfragen mit Hilfe
der OGC Filter (siehe Abschnitt 2.4) zu ermöglichen. Es handelt sich somit um eine
AdV-spezifische Festlegung, die im Gegensatz zum Typ (gml:ReferenceType), der im
Namespace der GML-Spezifikation enthalten ist, nur im Namespace der AdV zu finden
ist (adv:InverseReferenceType). Beispielhaft wird in Abbildung 3.6 die Zusammenhangsrelation
mit den beiden Beziehungstypen bestehtAus und istTeilVon dargestellt:
bestehtAus bestehtAus
REO1 ZUSO REO2
istTeilVon istTeilVon
Abbildung 3.6: Beziehungen zwischen einem ZUSO und zwei REOs, die Bestandteil des
ZUSOs sind.
Bei der Beschreibung des Raumbezugs und der Geometrie hält sich das AAA-Basisschema
stark an die ISO-Norm 19107 ” Spatial schema“ [ISO03]. Diese führt den Begriff des
geographischen Features ein und legt ein Referenzmodell zum Umgang mit räumlichen
Eigenschaften fest. Es werden drei Arten von Raumbezugsgrundformen im AAA-Modell
verwendet:
• Objekte mit einfacher Topologie, die einen topologischen Raumbezug haben, der
durch geometrische Eigenschaften ausgedrückt wird. Die Oberklassen dieser Objekte
haben das Präfix TA_ und befinden sich in dem Paket AAA_Spatial Schema.
Mit Hilfe dieser Klassen wird beispielsweise bei ATKIS die komplette Überdeckung
der Erdoberfläche erreicht. Durch Linien- (z.B. Straßen) und Flächenobjekte (z.B.
28

Siedlungsfläche) wird die Erdoberfläche scheinbar topologisch in Maschen aufgeteilt;
das zu Grunde liegende Datenmodell setzt sich jedoch aus Objekten mit
einfachen Geometrien zusammen.
• Objekte mit unabhängiger Geometrie mit Geometrien aus unabhängigen Punkten,
Linien oder Flächen. Diese Klassen befinden sich im Paket AAA_Unabhaengige
Geometrie und erben von der Oberklasse AU_ObjektMitUnabhaengigerGeometrie
aus dem Paket AAA_Spatial Schema.
• Objekte mit gemeinsam genutzter Geometrie, die ebenfalls Punkt-, Linien- oder
Flächengeometrien nutzen, hier aber als Besonderheit Punkt- und Liniengeometrien
gemeinsam von mehreren Fachobjekten genutzt werden können. Diese Geometrien
werden dabei nur einmal definiert und können von mehreren Fachobjekten
referenziert werden. Analog zu den Objekten mit unabhängiger Geometrie gibt es
auch für diese Klassen ein eigenes Paket im AAA-Basisschema (AAA_Gemeinsame-
Geometrie) und eine Oberklasse AG_ObjektMitGemeinsamerGeometrie im Paket
AAA_Spatial Schema.
Für Geometrien kann ein Koordinatenreferenzsystem (CRS) festgelegt werden. Somit
wird auch die Anzahl und Art der Koordinatenwerte bestimmt. Eine detaillierte Übersicht
der verfügbaren Systeme findet sich in [AdV06], Kapitel 11.
Präsentationsobjekte sind Texte und Signaturen, die zur Darstellung eines Fachobjekts
benötigt werden und über eine Relation fest an dieses gebunden sind. Die Festlegungen
zum Umgang mit Präsentationsobjekten sind im AAA-Basisschema bewusst allgemein
gehalten und sehen eine spätere Konkretisierung in einem Fachschema vor. Dennoch
stellt das AAA-Basisschema bereits konkrete Klassen für Präsentationsobjekte im Paket
AAA_Praesentationsobjekte bereit. Dies sind beispielsweise AP_FPO, flächenförmiges
Präsentationsobjekt; AP_LPO, linienförmiges Präsentationsobjekt usw., die allesamt als
REOs modelliert sind. So ist für ein neues Fachschema bereits eine Grundmenge von
Präsentationsobjekten direkt verfügbar. Wenn möglich sollten Präsentationsobjekte automatisch
beim Erzeugen einer Ausgabe nach festen Ableitungsregeln erstellt werden.
Daneben gibt es die Möglichkeit, beim Erfassen automatisch erstellte Präsentationsobjekte
im Bestand zu speichern, um die Geschwindigkeit beim Erzeugen der Ausgabe zu
steigern. Als dritte Möglichkeit bietet die komplett manuelle Erzeugung der Präsentationsobjekte
den größten Gestaltungsspielraum im Hinblick auf beispielsweise Größe und
Position der Objekte.
Das AAA-Fachschema setzt sich aus den einzelnen Fachschemata zu AFIS, ALKIS und
ATKIS zusammen. Diese konkretisieren die Festlegungen des AAA-Basisschema für das
jeweilige Fachinformationssystem. In den Objektartenkatalogen werden die fachlichen
Inhalte (Fachobjekte) festgelegt, die von den Basisklassen des Basisschemas erben. Im
Rahmen dieser Arbeit soll besonders das ATKIS-Fachschema vorgestellt werden.
29

3.2 Amtliches Topographisch-Kartographisches
Informationssystem (ATKIS)
Das Amtliche Topographisch-Kartographische Informationssystem (ATKIS) wurde mit
dem Ziel geschaffen, die Oberfläche der Erde in digitalen Modellen zu beschreiben und
zu speichern. Die reale Welt wird hierfür nach topographischen Gesichtspunkten erfasst
und u.a. in den so genannten Digitalen Landschaftsmodellen (DLM) in Form von Objekten
mit punkt-, linien- und flächenförmigen Geometrien gespeichert. Bereits seit 1989
wird ATKIS von den Vermessungsverwaltungen in Deutschland eingesetzt und ist somit
der älteste Teil des AAA-Modells.
Der ATKIS-Teil des AAA-Modells umfasst vier Komponenten:
1. Digitale Landschaftsmodelle (DLM) stellen die Erdoberfläche nach topographischen
Gesichtspunkten objektstrukturiert dar.
2. Digitale Geländemodelle (DGM) zur Darstellung der Geländehöhe und -form und
somit Strukturinformationen zur Erdoberfläche.
3. Digitale Topographische Karten (DTK), die durch Ableitung aus den DLM und
DGM entstehen.
4. Digitale Orthophotos (DOP) als Grundlage der Datenerfassung für die DLM.
Die dazugehörigen ATKIS-Katalogwerke gliedern sich in
• die ATKIS-Objektartenkataloge,
– ATKIS-Objektartenkatalog für das Digitale Basis Landschaftsmodell
(ATKIS-OK Basis-DLM)
– ATKIS-Objektartenkatalog für das Digitale Landschaftsmodell 50
(ATKIS-OK50)
– ATKIS-Objektartenkatalog für das Digitale Landschaftsmodell 250
(ATKIS-OK250)
– ATKIS-Objektartenkatalog für das Digitale Landschaftsmodell 1000
(ATKIS-OK1000)
• die ATKIS-Objektartenkataloge für das Digitale Geländemodell,
– ATKIS-Objektartenkatalog für das Digitale Geländemodell 2
(ATKIS-OK DGM2)
– ATKIS-Objektartenkatalog für das Digitale Geländemodell 5
(ATKIS-OK DGM5)
– ATKIS-Objektartenkatalog für das Digitale Geländemodell 25
(ATKIS-OK DGM25)
30

– ATKIS-Objektartenkatalog für das Digitale Geländemodell 50
(ATKIS-OK DGM50)
• die ATKIS-Signaturenkataloge.
Diese Kataloge sind alle im Rahmen der GeoInfoDok [AdV06] frei verfügbar. Die ATKIS-
Signaturenkataloge befinden sich jedoch zur Zeit (Stand: September 2007) noch in der
Entwicklung und stehen nur in einer Vorabversion für die kommende GeoInfoDok 6.0
zum Download bereit. Sie sind ausdrücklich nicht Bestandteil der GeoInfoDok 5.1
Für diese Arbeit werden nur die Digitalen Landschaftsmodelle (DLM) betrachtet. Sie
liegen in ATKIS in mehreren Maßstäben vor. Dabei hat das DLM50 einen Maßstab von
1:50.000 das DLM250 1:250.000 usw. Das BASIS-DLM liegt im Maßstab 1:25.000 vor
und besitzt somit die höchste Auflösung und den größten Detailreichtum. Die Digitalen
Landschaftsmodelle mit kleineren Maßstäben als das Basis-DLM (DLM50, DLM250,
DLM1000) können durch Generalisierung aus diesem gewonnen werden. Sie bieten aufgrund
der niedrigeren Auflösung einen geringeren Detail- und einen höheren Generalisierungsgrad
als das BASIS-DLM.
Abbildung 3.7: Kartenausschnitt eines ATKIS-NAS-Testdatensatzes im BASIS-DLM.
Visualisiert mit GML Viewer von Snowflake Software [Sno06]
31

Im ATKIS Basis-DLM wird die Landschaft zunächst in topologische Strukturen eingeteilt,
die objektbasiert dargestellt werden. Durch Straßen, Gewässer und ähnliche im
topologischen Modell linienförmige Erscheinungen wird ein Netz von Maschen auf der
Erdoberfläche gebildet. Deren Kanten und Innenflächen werden als (flächenförmige) Objekte
aus dem Objektbereich (s.u.) Tatsächliche Nutzung mit den Objektartengruppen
(Siedlung, Verkehr, Vegetation, Gewässer) dargestellt. Somit ist für eine lückenlose
und überschneidungsfreie Überdeckung der Oberfläche gesorgt. Der Objektbereich
Tatsächliche Nutzung wird als Folge der Harmonisierung zwischen beiden Systemen
analog in ALKIS verwendet. Als Beispiel für die in ATKIS dargestellten Daten ist in
Abbildung 3.7 ein Ausschnitt einer ATKIS-Karte im BASIS-DLM visualisiert. Die dort
mit der Software GML Viewer von Snowflake Software ([Sno06]) dargestellten Daten
entstammen direkt einer der NAS-Dateien des Testdatensatzes.
Objekte, die direkt überhalb der Erdoberfläche liegen (wie z.B. Brücken) werden ohne
spezielle Relation zur Erdoberfläche direkt darauf platziert. Überlagern sich diese
Objekte wiederum, so werden sie durch die Unterführungsrelation (hatDirektUnten)
vom oberen Objekt aus mit den darunter liegenden in Beziehung gebracht. Folgendes
Beispiel zeigt eine Straße, die auf einer Brücke platziert ist: 42003 AX Strassenachse
hatDirektUnten 53001 AX BauwerkImVerkehrsbereich mit der Attributart BWF und
dem Wert 1800 ( ” Brücke“).
Die zur Verfügung stehenden Objektarten werden im Objektartenkatalog (OK) mit sämtlichen
Attributen und Relationen genau definiert. Alle Fachobjekte des ATKIS-OK erben
von den im AAA-Basisschema festgelegten abstrakten Oberklassen (siehe Beispiel in Abbildung
3.5). Eine Übersicht über den Aufbau des ATKIS-OK des BASIS-DLM findet
sich in Anhang A.
Die Fachobjekte sind im Objektartenkatalog in Objektbereiche (z.B. Objektbereich AAA-
Basisschema oder Objektbereich Tatsächliche Nutzung) eingeteilt, diese wiederum in
Objektartengruppen (z.B. Siedlung oder Verkehr). Nachfolgend soll beispielhaft der Objektartenkatalogeintrag
des Fachobjekts AX_Friedhof (Tabelle 3.1) aus der Objektartengruppe
Siedlung erläutert werden: Neben der Objektart in textueller Form (AX_Friedhof)
besitzt jede Objektart eine eindeutige fünfstellige Kennung (41009). Die darunter folgende
Definition legt genau fest, welche Realweltobjekte diese Objektart zugeordnet bekommen
können. ” Abgeleitet aus“ benennt die Oberklasse, der Objekttyp entspricht einem
der im AAA-Basisschema definierten Basisobjektklassen. Die Modellart ist Basis-DLM,
da dieses Beispiel dem ATKIS-Objektartenkatalog für das Digitale Basis Landschaftsmodell
entnommen ist. Regeln zur Erfassung eines Realweltobjekts können ebenfalls im
OK festgelegt werden.
Das einzige Attribut des Fachobjekts AX_Friedhof ist vom Attributtyp Name, der die
eindeutige Kennung NAM besitzt. Es ist vom Datentyp String und kann null- oder einmal
vorkommen. Neben einer Definition des Attributs findet sich auch hier wieder eine
Angabe, für welches Modell das Attribut spezifiziert ist.
32

Objektart: AX Friedhof
Kennung: 41009
Definition: [E] ’Friedhof’ ist eine Fläche, auf der Tote bestattet sind.
Abgeleitet aus: AX TatsaechlicheNutzung
Objekttyp: REO
Modellart: Basis-DLM
Grunddatenbestand: Basis-DLM
Erfassungskriterien: Fläche >= 0,5 ha
Attributart: Bezeichnung: Name
Kennung: NAM
Datentyp: CharacterString
Kardinalität: 0..1
Modellart: Basis-DLM
Grunddatenb.: Basis-DLM
Definition: ’Name’ ist der Eigenname von ’Friedhof’.
Tabelle 3.1: Objektartenkatalogeintrag AX Friedhof aus dem ATKIS-OK Basis-DLM
3.3 Amtliches Liegenschaftskatasterinformationssystem
(ALKIS)
Ein (Liegenschafts)Kataster verzeichnet Flurstücke und Gebäude mit Informationen zu
Nutzungsart, Größe, Lage (Adresse) und Eigentümer. Zudem wird eine kartographische
Darstellung dieser Informationen geführt. Das Amtliche Liegenschaftskatasterinformationssystem
(ALKIS) ist aus den Informationssystemen Automatisierte Liegenschaftskarte
(ALK) und Automatisiertes Liegenschaftsbuch (ALB) hervorgegangen, in denen die Daten
zum Liegenschaftskataster bereits digital geführt wurden. Das Liegenschaftsbuch
enthält alle textlichen Daten, während die Liegenschaftskarte den Raumbezug in graphischer
Form herstellt.
Für die Modellierung des Liegenschaftskatasters im ALKIS-Teil des AAA-Modells werden
diese beiden Systeme zusammengelegt und an die übrigen AAA-Komponenten angeglichen,
um dem Ziel eines einheitlichen Datenmodells gerecht zu werden. Insbesondere
wurde eine Harmonisierung mit ATKIS angestrebt, was hauptsächlich den Objektartenkatalog
betrifft. Hier gibt es bei vielen Objekten Gemeinsamkeiten in Semantik und
Geometrie, so dass beispielsweise die Semantik der Objektarten der Grundflächen (Objektartenbereich
” Tatsächliche Nutzung“) nur einmal in einem gemeinsamen Katalog
beschrieben werden kann.
3.4 Amtliches Festpunktinformationssystem (AFIS)
Die zeitlich als letzte entwickelte Komponente des AAA-Modells ist das Amtliche Festpunktinformationssystem
(AFIS). Die Einführung eines weiteren Fachinformationssy-
33

stems war notwendig, da die noch zu modellierenden Festpunkte weder in ALKIS, noch
in ATKIS integriert werden konnten.
Ein geodätischer Festpunkt ist ein eindeutig in der Natur gekennzeichneter (Vermarkung)
Vermessungspunkt, dessen Koordinaten aus einer Vermessung eindeutig bestimmt sind.
Man unterscheidet zwischen Lagefestpunkten, Höhenfestpunkten und Festpunkten, die
beide Koordinatenangaben enthalten.
Die zentrale Speicherung aller Festpunkte erfolgt in einer Festpunktdatei, die im AAA-
Modell durch AFIS modelliert wird. Da die Festpunktdatei bisher in der Automatisierte
Liegenschaftskarte (ALK) geführt wurde, ist AFIS stark an ALKIS angelehnt. Der
Grunddatenbestand (die zwingend zu implementierenden Elemente) ist jedoch sehr klein
gehalten, damit die Umsetzung dieses Modells möglichst einfach bleibt.
3.5 Normbasierte Austauschschnittstelle (NAS)
Die Normbasierte Austauschschnittstelle (NAS) stellt im AAA-Modell das externe Modell
dar. Es wird festgelegt, in welcher Form Daten für den Import in bzw. den Export aus
einem nach dem AAA-Modell aufgebauten System strukturiert sein müssen. Die NAS
legt diese Struktur eindeutig fest, indem sie internationale Standards um AdV-spezifische
Erweiterungen ergänzt: in GML beschriebene Daten werden mit Hilfe der Methoden der
WFS-Spezifikation und der FES als Anfragesprache um Steuerinformationen ergänzt.
Bei der Entwicklung der NAS hat sich die AdV streng an die ISO-Norm 19118 ” Encoding“
[ISO06] gehalten. Diese gibt genaue Regeln für die Kodierung von Geodaten
aus einem gegebenen Anwendungsschema vor, unter anderem für einen XML-basierten
Datenaustausch. So wird auch bei der NAS die Schnittstelle als in XML Schema verfasstes
GML 3.0-Anwendungsschema automatisch aus dem in UML verfassten AAA-
Anwendungsschema (Basis- und Fachschema) erstellt. Dies geschieht unter Verwendung
der Software Rational Rose 4 . Die für die automatische Erzeugung verwendeten Steuerparameter
(Encoding Rules) wurden von der AdV manuell angepasst und sind unter
[AdV07] einsehbar.
Abbildung 3.8: Kodierung des UML-Anwendungsschemas nach XML Schema.
4 http://www-306.ibm.com/software/awdtools/developer/rose/index.html
34

Es ergeben sich folgende XML-Schema-Dateien, die unter [AdV07] frei verfügbar sind:
• AAA-Basisschema.xsd und AAA-Fachschema.xsd, die das GML-Anwendungsschema
des AAA-Modells enthalten.
• ISO19100.xsd mit den direkt aus der ISO-Familie 191XX übernommenen Klassen,
z.B. die Möglichkeit zur Angabe von Koordinatenreferenzsystemen (CRS).
• WFS-Erweiterungen.xsd, die AdV-spezifische Erweiterungen des WFS enthält
(z.B. die Verwendung von replace statt update).
• NAS-Operationen.xsd, die die in der NAS möglichen Operationen festlegt. Dazu
zählen z.B. der Einrichtungsauftrag oder der Fortführungsauftrag (s.u.).
• AAA-Katalog.xsd und ISO-Katalog.xsd, die es ermöglichen, Objektartenkataloge
in XML zu beschreiben.
Beziehungen zwischen Objekten werden in der NAS mit XLink [W3C01] realisiert. Mit
dieser W3C-Spezifikation ist es möglich, Hyperlinks in XML-Elemente einzubinden. Das
Ziel eines XLinks kann innerhalb des XML-Dokuments liegen oder auf ein externes
Dokument verweisen. Von der AdV wird die Verwendung von XLink jedoch auf einfache
Verweise (xlink:type="simple", d.h. nur unidirektional) eingeschränkt. Es ist in der
NAS vorgesehen, ein Objekt durch die Angabe eines Uniform Resource Name (URN) zu
referenzieren. Folgendes Beispiel 5 illustriert, wie ein Flurstück einer Buchungsstelle über
deren Identifikator zugeordnet werden kann:
[...]
[...]
Die Betrachtung der in der NAS möglichen Operationen sollen für diese Arbeit auf
Einrichtungs- und Fortführungsaufträge eingeschränkt werden. Daneben sind beispielsweise
auch Bestandsdatenauszüge und das Sperren und Entsperren von Objekten möglich.
Die NAS-Operationen bestehen analog zur WFS-Spezifikation grundsätzlich aus
einem Request (z.B. Fortführungsauftrag) und einer Response (z.B. Fortführungsprotokoll).
Das nachfolgende Beispiel 6 stellt einen kompletten Fortführungsauftrag dar, also eine
Aktualisierung eines vorhandenen Datenbestands. Neben einer Benennung aller benötigten
XML-Namensräume im Wurzelelement (Zeile 2-6) des Dokuments finden sich danach
5 aus [AdV06], Seite 89f.
6 Basierend auf einem der GeoInfoDok [AdV06] entnommenem Beispiel; eigenständig ergänzt und
vervollständigt.
35

weitere organisatorische Angaben. Diese enthalten unter anderem eine Empfängerangabe
(Zeile 10-15), die Auftragsnummer (Zeile 17) und eine Angabe des verwendeten Koordinatenreferenzsystems
(CRS, Zeile 18-24). In einer WFS-Transaction werden dann die
eigentlichen Änderungen am Datenbestand vorgenommen: zwei Feature-Instanzen werden
eingefügt (Zeile 27-34), ein Feature wird in einem Attribut aktualisiert (Zeile 36-42)
und zwei Feature-Instanzen werden gelöscht (Zeile 44-49).
01
02
07
08 MS
09 Test
10
11
12 mailto:info@auftragsempfaenger.de
13 true
14
15
16 application/xml
17 Test_001
18
19
20 urn:adv:crs:DE_DHDN_3GK3
21 3
22 true
23
24
25
26
27
28
29 [...]
30
31
32 [...]
33
34
35
36
37 amtlicheFlaeche
36

38 287
39
40
41
42
43
44
45
46
47
48
49
50
51
Bei den neu hinzuzufügenden Objekten handelt es sich um ein Flurstück (Zeile 28-30)
und ein Gebäude (Zeile 31-33), jeweils mit ihrem eindeutigen Identifikator. Weitere Attribute
sind zur Vereinfachung weggelassen worden.
Die von der Aktualisierung in diesem Beispiel betroffene Feature-Instanz wird durch
den OGC-Filter (siehe Abschnitt 2.4) unter Angabe von Identifikator und Version
DEBY0000F000000220010101T000000Z
(Konkatenation von Identifikator und Beginn des Lebenszeitintervalls des Objekts) eindeutig
bestimmt (Zeile 39-41). Bei dieser Instanz erhält das Attribut amtlicheFlaeche
den neuen Wert 287 (Zeile 38).
Die beiden zu löschenden Objekte werden ebenfalls durch einen OGC-Filter und der
Kombination aus Identifikator und Versionsdatum eindeutig identifiziert (Zeile 45-48).
Neben den hier vorgestellten expliziten Funktionen müssen Systeme, welche die NAS
implementieren, auch einige implizite Funktionen bieten, die den Datenbestand auf Konsistenz
prüfen. Man unterscheidet zwischen zwei Arten von Systemen:
1. Systeme für den Primärnachweis, den amtlichen, zentral geführten Geodatenbestand.
Zu den impliziten Aufgaben dieser Systeme gehört beispielsweise, das Entstehungsdatum
eines Objekts oder einer Version aus der Systemzeit beim Einfügen
abzuleiten, eindeutige Identifikatoren zu vergeben, wenn diese noch nicht existieren
oder Referenzen auf ein nach dem Löschen nicht mehr vorhandenes Objekt zu
entfernen, damit diese nicht ins Leere zeigen.
2. Systeme für den Sekundärnachweis, der eine Kopie des Primärnachweises für ein
bestimmtes Fachinformationssystem darstellt und auf ein bestimmtes Interessengebiet
eingegrenzt werden kann (z.B. nur Daten, die den Niedersächsischen Raum
37

etreffen). Diese Systeme müssen bei einem Replace nicht vorhandene Elemente
durch ein Insert implizit einfügen.
Ein Beispiel hierzu ist, dass ein Flurstück, das im Interessenbereich (Niedersachsen)
liegt, einen neuen Besitzer erhält. Diese Person ist im gesamtdeutschen Datenbestand
bereits vorhanden; da sie aber nur Flurstücken in Bayern zugeordnet war, ist
sie dem auf Niedersachsen eingegrenzten System unbekannt und muss hinzugefügt
werden.
38

Kapitel 4
ATKIS Datenmodell
4.1 Konzeptioneller Entwurf
In diesem Abschnitt wird ein konzeptioneller Entwurf für ein Datenmodell für ATKIS-
Daten vorgestellt. Zu diesem Thema wurde an der Leibniz Universität Hannover bereits
im Jahr 2003 eine Studienarbeit angefertigt [Opi03]. Diese orientiert sich jedoch an der
” GeoInfoDok“ in der Version 1.0 und einem ATKIS-Schema, welches nach dem ” alten“
ATKIS-Modell (vor den Anpassungen im Rahmen des AAA-Modells) aufgebaut war.
Da auch Daten aus dem vorhandenen ATKIS-Schema migriert werden sollten, flossen
teilweise Konzepte aus diesem Schema in das neu erstellte ein. In dieser Arbeit wird
ein komplett neues Schema entwickelt, welches sich streng an den Konzepten des AAA-
Modells orientiert.
Das hier vorgestellte und in Abbildung 4.1 dargestellte Schema greift die objektorientierte
Herangehensweise des AAA-Modells auf. Zudem wurde die Trennung des AAA-
Anwendungsschemas in AAA-Basisschema und AAA-Fachschema beibehalten, indem
die Fachspezifischen Besonderheiten wie z.B. Objektarten und Attribute nach Vorbild
eines Objektartenkatalogs von den im gesamten AAA-Anwendungsschema gültigen Konzepten
getrennt wurden. Somit könnte dieses Schema mit minimalen Änderungen (z.B.
Kardinalitäten der Präsentationsobjekte) auch Grundlage für ein ALKIS-Fachdatenschema
oder ähnliche Fachinformationssysteme sein.
Ausgangspunkt des Schemas ist - wie auch im AAA-Anwendungsschema - die allgemeine
Basisklasse Objekt. Sie legt die folgenden für alle Objekte gültigen Attribute
fest und ist die Oberklasse der drei weiter spezialisierten Klassen Zusammengesetztes
Objekt (ZUSO), Raumbezogenes Elementarobjekt (REO) und Nicht-raumbezogenes
Elementarobjekt (NREO) (siehe Abbildung 3.3):
• Der Identifikator, der ein Fachobjekt eindeutig bestimmt.
• Das Lebenszeitintervall zur Versionierung, das hier in Anfang und Ende aufgeteilt
wurde.
39

• Der Anlass für das Einfügen, Ändern oder Löschen dieser Objektversion.
• Die Modellart, die das Modell (z.B. BASIS-DLM, DLM50) angibt, dem das Fachobjekt
zugeordnet ist.
ObjektartNr Bezeichnung Kennung Bezeichnung
Objektart
(0,n)
istVonTyp
(1,1)
Präsentationsobjekt
(0,n)
Geometrie
(0,n)
kannHaben
Attributwert
Modellart
Identifikator
(0,n)
dZDV*
(0,n)
Datentyp
(0,n)
Objekt
REO ZUSO NREO
hatDirektUnten
(0,n)
Attribut
(0,n)
besitzt
(0,n)
(0,n) (0,n)
möglicheWerteIn
(1,n)
istVersionVon
(0,n)
bestehtAus
(1,n)
(1,1)
Name
Nummer
Codeliste
Bezeichnung
LebenszeitintervallEnde
Objektversion
Anlass
LebenszeitintervallAnfang
*dientZurDarstellungVon
Abbildung 4.1: Entity-Relationship-Diagramm für das ATKIS-Datenmodell
Um die im AAA-Modell vorgesehene Versionierung umzusetzen, wurde die Klasse Objekt
in die beiden Entities Objekt und Objektversion aufgeteilt. Es gibt spezielle Attribute
(objektbildende Eigenschaften), wie z.B. die Objektart, die für alle Objektversionen
gleich bleiben müssen. Werden diese Eigenschaften verändert, so wird ein neues Objekt
in den Datenbestand eingefügt und das alte Objekt muss gelöscht werden. Hierzu zählen
40

auch die Geometrie oder die Beziehungen, die ein Objekt mit anderen Objekten eingehen
kann. Daher beziehen sich all diese Eigenschaften auf ein Objekt, nicht auf dessen
Versionen.
Außer den genannten ” speziellen“ Attributen kann jede Objektversion durch weitere
Attribute (nicht-objektbildende Eigenschaften) näher beschrieben werden. Die zu einem
bestimmten Fachobjekt gehörenden Attribute werden durch das Fachschema im
Objektartenkatalog definiert. Sie sind von einem festgelegten Attributtyp, der durch
seine eindeutige Kennung bestimmt wird. Die Bezeichnung beschreibt den Attributtyp.
Außerdem ist für jeden Attributtyp ein Datentyp festgelegt. Dieser bestimmt auch die
Form der zugelassenen Werte (Integer-Zahlen, Strings usw.). Bei der Zuweisung eines
Attributtyps zu einer Objektversion muss immer ein Attributwert angegeben werden.
Beispielsweise kann einem Fachobjekt ein Name (Kennung: NAM, Bezeichnung: name) mit
dem Attributwert Rathausplatz vom Datentyp String zugewiesen werden.
Um Attributen, deren Attributwert einen Eintrag in einer Codeliste (siehe Abschnitt 3.1)
referenziert, die dahinter stehende Bedeutung zuzuordnen, werden auch die Codelisten in
das Datenmodell mit aufgenommen. Ein Beispiel für eine Codeliste ist AX_Vegetationsmerkmal_Wald,
die unter anderem die folgenden beiden Nummer-Bezeichnung-Paare enthält:
1100-Laubholz, 1200-Nadelholz. Jede Codeliste hat einen Namen (der dem Namen
des Attributtyps entspricht) und besteht aus mehreren Zuordnungen aus Nummern und
Bezeichnungen.
Ein besonderes Attribut ist die Objektart. Um das Konzept des Objektartenkatalogs
weiterzuführen und die Klassenhierarchie des AAA-Modells nachzubilden, wird sie als
eigenes Entity modelliert. Analog zu den Attributen gibt es auch hier eine eindeutige
Kennung (ObjektartNr) und eine Beschreibung (Bezeichnung) der Objektart.
Eine Beziehung zwischen Objektart und Attribut legt fest, welche Attribute einer bestimmten
Objektart zugeordnet werden dürfen. Dies ist ebenfalls im Objektartenkatalog
festgelegt.
Ein NREO hat im Vergleich zur Oberklasse Objekt keine weiteren Attribute.
Ein ZUSO kann durch die Zusammensetzungsrelation mit weiteren Objekten die Beziehung
bestehtAus eingehen. Dies können beliebig viele Objekte sein, es muss sich aber
mindestens ein Elementarobjekt (REO, NREO) darunter befinden. Eine Selbstreferenz ist
nicht zulässig (auch nicht indirekt).
Ein REO besitzt eine fest zugeordnete Geometrie, die den Raumbezug herstellt. Des Weiteren
kann die vertikale Lage je zweier REOs durch die Unterführungsrelation hatDirektUnten
dargestellt werden.
Präsentationsobjekte (siehe Abschnitt 3.1) sind spezielle REOs. Sie erben sämtliche
41

Attribute der Oberklasse REO und werden beliebigen Objekten durch die Präsentationsrelation
dientZurDarstellungVon zugewiesen.
4.2 Relationales Datenbankschema
Aus dem im vorigen Abschnitt vorgestellten konzeptionellen Entwurf wird im Folgenden
ein relationales Datenbankschema erstellt. Eine besondere Herausforderung bei der
Entwicklung war die Umsetzung der objektorientierten Modellierung des AAA-Modells
in ein rein relationales Schema. Hierfür wurde nach den gängigen Methoden zur Transformation
eines ER-Schemas in ein relationales Datenbankschema 1 vorgegangen (z.B.
[Lip06]):
Das Entity Objekt wird mit dem Attribut Identifikator die Tabelle Objekt übernommen.
Das Attribut Modellart fehlt an dieser Stelle in der Tabelle Objekt, da es
bei der Implementierung anderweitig umgesetzt wird (siehe 4.3). Die Zuordnung eines
Objekts zu einer Objektart wird direkt mit in die Tabelle Objekt aufgenommen, da es
sich um eine rein funktionale Beziehung handelt.
Objekt(Identifikator, Objektart → Objektartenkatalog)
Die im AAA-Modell vorgesehene Versionierung (siehe Abschnitt 3.1) wird in der Tabelle
Objekt noch nicht berücksichtigt. Wie im konzeptionellen Entwurf vorgegeben, gibt
es im relationalen Datenbankschema daher eine Trennung von Objekt und Objektversion.
Eine eindeutige Identifizierung einer Objektversion ausschließlich über den Identifikator
ist aufgrund mehrerer Versionen mit demselben Identifikator nicht mehr möglich.
Es müssen also Identifikator und der Beginn des Lebenszeitintervalls zur eindeutigen
Bestimmung herangezogen werden.
Um nicht immer zwei Werte angeben oder bei jeder Anfrage mit Konkatenation von
Strings arbeiten zu müssen, wird eine (nur interne!) ObjektID vergeben, die dann immer
direkt eine Version eines Objektes bezeichnet. Diese wird - in Anlehnung an die
OGC-Filter-Anfragen im AAA-Modell - einmalig beim Einfügen eines neuen Objekts
durch Konkatenation von Identifikator und LebenszeitintervallAnfang gebildet.
Die ObjektID ist somit ein Surrogatschlüssel 2 , d.h. ein künstlich erzeugter Schlüssel für
diese Tabelle.
Neben dem Beginn und Ende des Lebenszeitintervalls wird zu einer Objektversion auch
stets ein Anlass gespeichert. Hier wird in Form der Auftragskennung des NAS-Auftrags
der Anlass für die Erschaffung dieser Objektversion erfasst. So kann stets nachvollzogen
werden, durch welchen NAS-Auftrag eine Objektversion eingefügt oder verändert wurde.
1Eine Abweichung vom rein relationalen Schema stellt die Geometrie dar, die als Objekt gespeichert
wird.
2http://de.wikipedia.org/wiki/Surrogatschl%C3%BCssel 42

Objektversion(ObjektID, Identifikator → Objekt, LebenszeitintervallAnfang,
LebenszeitintervallEnde NULL , Anlass) 3
Die Tabelle REO verknüpft Objekte mit ihrem Raumbezug, also mit einer Geometrie.
Gemäß der Klassenhierarchie im AAA-Modell ist die Klasse REO eine Unterklasse von
Objekt und erhält als Spezialisierung einen Raumbezug. Durch die Modellierung der
REOs in einer eigenen Tabelle wird beispielsweise auch sichergestellt, dass die Unterführungsrelation
nur von zwei REOs eingegangen werden kann.
REO(ReoID → Objekt, Geometrie)
Die Tabelle NREO erfüllt lediglich den Zweck, alle NREOs in einer zentralen Stelle zu sammeln.
Dies könnte z.B. nützlich sein, wenn eine Anfrage an die Datenbank nur NREOs
betreffen soll.
NREO(NReoID → Objekt)
Die Tabelle ZUSO modelliert die Zusammenhangsrelation bestehtAus. Analog zu REO
und NREO wird sie jedoch ZUSO benannt, denn eben diese Beziehung ist charakteristisch
für ZUSOs.
ZUSO(ZusoID → Objekt, Teil → Objekt)
Präsentationsobjekte erben von der Klasse REO die Geometrie. Des Weiteren sind in der
Tabelle verschiedene Angaben zur Schriftformatierung und zur Darstellung gespeichert.
Praesentationsobjekt(PraesentationsobjektID → Objekt, Schriftinhalt,
Fontsperrung, Skalierung, HorizontaleAusrichtung, VertikaleAusrichtung,
Geometrie)
Die Tabelle hatDirektUnten stellt die Umsetzung der Unterführungsrelation zwischen
je genau zwei REOs dar.
hatDirektUnten(Oben → Objekt, Unten → Objekt)
In der Tabelle dientZurDarstellungVon wird die Präsentationsrelation realisiert. Sie
ordnet einem Präsentationsobjekt eindeutig das Fachobjekt zu, welches es (re)präsentiert.
dientZurDarstellungVon(Objekt → Objekt, Praesentationsobjekt → Praesentationsobjekt)
Kartengeometrieobjekte sind Objekte mit eventuell veränderter Lage und Geometrie,
die durch Generalisierung aus einem Fachobjekt für einen anderen Maßstab gewonnen
werden. Sie erhalten durch die Beziehung istAbgeleitetAus einen Verweis auf das
zugehörige Fachobjekt.
3 Ist ein Attribut durch NULL gekennzeichnet, so kann dieses Attribut auch den Nullwert annehmen,
ist also optional anzugeben.
43

istAbgeleitetAus(Kartengeometrieobjekt → Objekt, Basisobjekt → Objekt)
Objektarten und Attributarten sind durch den Objektartenkatalog festgelegt. Alle dort
entnommenen Werte sind in den Tabellen ObjektArtenKatalog bzw. AttributArten-
Katalog gespeichert. Da Attributkennungen bzw. Objektartennummern in der NAS in
anderer Form gespeichert werden als im Objektartenkatalog, wird zusätzlich eine Spalte
aufgenommen, die diese Bezeichnung in der NAS enthält (NASBezeichnung). So ist eine
Zuordnung in beide Richtungen möglich. Bei Attributen ist zusätzlich noch der Datentyp
der Attributwerte gespeichert, damit die aus der NAS stets als Strings eingelesenen (und
auch als Strings in der Datenbank gespeicherten) Werte von einer Anwendung korrekt
weiter verarbeitet werden können. Optional kann eine Beschreibung (beispielsweise eine
Definition) der Objektart bzw. des Attributtyps angegeben werden.
ObjektArtenKatalog(ObjektartNr, NASBezeichnung, Beschreibung NULL )
AttributArtenKatalog(Kennung, NASBezeichnung, Beschreibung NULL ,
Datentyp)
Auch die aus dem Objektartenkatalog übernommenen Codelisten werden nach dem Vorbild
eines Kataloges, ähnlich wie die Attribute, in einer Tabelle gespeichert. Der Name
der Codeliste (z.B. AX_Vegetationsmerkmal_Wald) muss mit einer Spalte des zugehörigen
Attributtyps aus dem Attributartenkatalog übereinstimmen, damit hierüber später
eine Zuordnung möglich ist. Hierfür wird die NAS-Bezeichnung gewählt, da die Namen
der Codelisten ebenfalls aus den NAS-Schemata ausgelesen werden. Beispiele für eine
Zuordnung einer Nummer zu einer Bezeichnung ist aus der o.g. genannten Codeliste
1100-Laubholz und 1200-Nadelholz.
Codelisten(Name → AttributArtenKatalog, Nummer, Bezeichnung)
Die folgende Tabelle bildet die Zuordnung von Attributen zu Objekten ab. An dieser
Stelle wird auch der Attributwert zugewiesen.
AttributZuweisung(ObjektID → Objektversion, Kennung → AttributArtenKatalog,
AttributWert)
Eine Übersicht über das relationale Datenbankschema findet sich in Anhang B.
4.3 Implementierung in Oracle 10g
Bei der Implementierung des zuvor entwickelten relationalen Datenbankschemas wurde
zunächst betrachtet, welche Art von Daten in einem Schema gemeinsam gespeichert
werden sollten. Hierbei ging es um eine Unterscheidung nach
1. dem betrachteten Kartenausschnitt (z.B. Hannover, Hildesheim, Niedersachsen
usw.) und
44

2. dem betrachteten Maßstab bzw. die Modellbezeichnung in ATKIS (z.B. BASIS-
DLM oder DLM50).
Um eine bessere Übersicht zu wahren, gibt es für jede Kombination von Kartenausschnitt
und Modellart eine eigene Schemainstanz. Die Tabellen dieser Schemata erhalten eine
Benennung in der Form Kartenausschnitt_Tabellenname_Modellart. Beispiele hierfür
sind Hannover_REO_DLM50 oder Hildesheim_ZUSO_DLM250.
Der Objektartenkatalog, der Attributartenkatalog und die AAA-Codelisten sind unabhängig
vom betrachteten Kartenausschnitt. Nach dem ATKIS-Teil des AAA-Modells
gibt es je einen Objektartenkatalog pro Modellart. Zur Vereinfachung des hier beschriebenen
Datenbankschemas wird jedoch nur ein Objektartenkatalog für alle Modellarten
verwendet. Der Objektartenkatalog wird im Rahmen des Importer-Programms nur dazu
verwendet, die in der NAS verwendeten Bezeichnungen der Objektart einer Objektartennummer
des ATKIS-OK zuzuordnen. Diese ist in allen Modellarten einheitlich. Spezielle
Angaben, z.B. zur Datenerfassung, die im AAA-Modell das Vorhandensein verschiedener
Objektartenkataloge rechtfertigen, können im Rahmen dieser Arbeit vernachlässigt
werden. Es wird davon ausgegangen, dass die zum Import gelieferten Daten stets korrekt
und konsistent vorliegen.
Um eine Schemainstanz jederzeit einfach erzeugen zu können, wurden die SQL-Anweisungen
zum Anlegen der Tabellen in PL/SQL-Prozeduren auf dem Datenbankserver
gespeichert. Die folgenden Prozeduren finden sich im Package INIT:
• setup() erstellt die gemeinsam genutzten Objekt- und Attributartenkataloge und
das Verzeichnis der Codelisten für eine Modellart.
• erstelleSchema(gebiet, modell) erstellt das spezifische Schema für einen Kartenausschnitt
(gebiet) und eine Modellart (modell).
• loescheSchema(gebiet, modell) löscht ein bereits bestehendes Schema, welches
den beiden o.g. Parametern entspricht.
• erstelleSchemaNeu(gebiet, modell) führt das Löschen und (Neu-) Anlegen eines
Schemas hintereinander aus. Diese Prozedur kann somit auch zum Entleeren
eines vorhandenen Schemas genutzt werden, da dieses erst gelöscht und dann ohne
Inhalte neu angelegt wird.
• entleereSchema(gebiet, modell) wird für die Integration in die MRDB benötigt,
da diese Prozedur in jeder Komponentendatenbank vorhanden sein muss. Die
Prozedur ruft erstelleSchemaNeu(gebiet, modell) auf (s.o.).
• kopiereSchema(gebiet_alt, modell_alt, gebiet_neu, modell_neu) kopiert
die Daten aus dem ersten angegebenen Schema in das als zweites angegebene
Schema. Dies wird bei Bedarf erstellt.
45

• erstelleViews(gebiet, modell) legt die zur MRDB-Integration benötigten Sichten
an. Diese Prozedur wird in Abschnitt 4.4 beschrieben.
Als Beispiel wird im Folgenden der PL/SQL-Code zum Erstellen der Tabelle Objekt
aus der Prozedur erstelleSchema dargestellt. Der komplette Quellcode ist mit dieser
Arbeit erhältlich. Die Variablen praefix und suffix enthalten die Bezeichnungen von
Gebiet und Modellart, um einen Tabellennamen nach dem oben entwickeltem Schema
zu erreichen.
EXECUTE IMMEDIATE ’CREATE TABLE ’ || praefix || ’Objekt’ || suffix || ’(
ObjektID VARCHAR2(32),
ObjektartNr NUMBER(5),
Identifikator VARCHAR2(16),
Lebenszeitintervallanfang DATE,
Lebenszeitinervallende DATE,
Anlass VARCHAR2(100),
PRIMARY KEY (ObjektID),
UNIQUE (Identifikator, Lebenszeitintervallanfang),
FOREIGN KEY (Identifikator) REFERENCES
’ || praefix || ’Ids’ || suffix || ’(Identifikator),
FOREIGN KEY (ObjektartNr) REFERENCES
ObjektArtenKatalog(ObjektartNr))’;
Des Weiteren finden sich im Package UTIL zwei Hilfsfunktionen, die von den Prozeduren
des Package INIT verwendet werden können:
• dropTableIfExists, die eine Tabelle löscht, falls sie existiert und im anderen Fall
die Fehlermeldung des DBMS abfängt. Dies erleichtert zum Beispiel das Löschen
eines unvollständigen Schemas - eine Situation, die hauptsächlich während der
Entwicklung des Schemas zu berücksichtigen ist.
• tableExists liefert true zurück, wenn eine Tabelle existiert, false, wenn sie auf
dem Server nicht vorhanden ist. Dies wird benötigt, um beim Anlegen einer neuen
Schemainstanz zu prüfen, ob die gemeinsam genutzten Kataloge bereits vorhanden
sind, oder ob sie durch Aufruf der Prozedur setup(modell) zuvor eingerichtet
werden müssen.
Das dritte Package mit PL/SQL-Prozeduren für das AAA-konforme Datenbankschema
und den NAS-Importer ist das Package OK. In diesem Package sind Funktionen zur
manuellen Erzeugung des Objektartenkatalogs (inklusive Attributartenkatalog und Codelisten)
enthalten. Dies ist notwendig, da durch das Bundesamt für Kartographie und
Geodäsie (BKG) kein vollständig elektronisch lesbarer Objektartenkatalog (OK) zur Verfügung
gestellt werden konnte. U.a. stand zur Bearbeitungszeit dieser Arbeit die genaue
Zusammensetzung des OK noch nicht fest.
46

Für den Betrieb des Importers ist ein OK zwingend erforderlich, da z.B. für eine in
der NAS verwendete Objektbezeichnung die ObjektartNr aus dem OK gelesen werden
muss. Auch im Datenbankschema vorgesehene Fremdschlüssel, beispielsweise von der
Tabelle Attributzuweisung zu der Tabelle des Attributartenkatalogs, können ohne vorhandenen
OK nie erfüllt werden.
Die manuelle Erzeugung des OK erfolgt durch die folgenden drei PL/SQL-Prozeduren
des Package OK. Die Prozeduren arbeiten nacheinander zahlreiche SQL-INSERTs in die
jeweilige Tabelle ab. Zu jeder Prozedur ist ein Beispiel hierfür angegeben:
• fillOK() fügt in die Tabelle Objektartenkatalog zu einem Objekt die NASBezeichnung
und die dazugehörige ObjektartenNr ein. Die zu einer Objektart zugehörige
Beschreibung bzw. Definition (zu dem unten angegebenen Beispiel wäre
dies ” ’Bauwerk im Verkehrsbereich’ ist ein Bauwerk, das dem Verkehr dient.“) ist
in der Datenbank vorgesehen, jedoch als optionale Angabe. Um den Aufwand der
manuellen Erstellung des OK zu minimieren, wurde die Beschreibung nicht mit
aufgenommen.
INSERT INTO Objektartenkatalog(Objektartnr, NASBezeichnung)
VALUES(53001, ’AX_BauwerkImVerkehrsbereich’);
• fillAK() füllt analog zu fillOK() den Attributartenkatalog. Dieser ist normalerweise
implizit in den Objektartenkatalog integriert, indem zu jeder Objektart die
möglichen Attribute festgelegt werden. Da bei den zu importierenden Daten diese
Bedingungen jedoch als erfüllt vorausgesetzt werden, dient der Attributartenkatalog
in diesem Kontext wie der Objektartenkatalog hauptsächlich der Zuordnung
von der im OK verwendeten Kennung zur NASBezeichnung. Für den Attributartenkatalog
ist als zusätzliche Angabe der Datentyp eines Attributs unbedingt
notwendig. Auf die Beschreibung wurde jedoch auch hier verzichtet.
INSERT INTO Attributartenkatalog(Kennung, NASBezeichnung, Datentyp)
VALUES(’NAM’, ’name’, ’String’);
• fillCodelisten() speichert die Einträge der Codelisten ab, die für Fachobjekte
als Attributart angegeben werden können.
INSERT INTO Codelisten(Name, Nummer, Bezeichnung)
VALUES(’AX_VerkehrsbedeutungUeberoertlich’, 1001, ’Fernverkehr’);
Die Namen der Tabellen des Datenbankschemas mussten bei der Implementierung teilweise
im Vergleich zum Entwurf des relationalen Schemas gekürzt werden. Oracle beschränkt
die Länge des Tabellennamens im Normalfall auf 30 Zeichen. Diese Grenze ist
bei langen Tabellennamen wie ” dientZurDarstellungVon“ in Kombination mit Präfix und
Suffix schnell erreicht. Daher in diesem Beispiel die Abkürzung ” dZDV“.
47

Bei der Implementierung der Tabelle AttributZuweisung stellte die Umsetzung des
Attributwertes eine Herausforderung dar. Laut Objektartenkatalog sind die folgenden
einfachen Datentypen für Attributwerte im AAA-Modell möglich 4 :
• NUMBER
• REAL
• INTEGER
• BOOLEAN
• STRING
Zudem besteht die Möglichkeit, auch Werte aus den im AAA-Modell definierten Codelisten
(Zuordnungen von möglichen Bezeichnern zu Kennungen) als Attributwerte zu
verwenden.
Um das Datenbankschema in diesem Punkt möglichst einfach implementieren zu können,
musste ein gemeinsamer Datentyp gefunden werden. All diese Datentypen lassen sich relativ
einfach durch Strings ausdrücken. Zudem werden die Daten in einer NAS-Datei
bereits als ” Text“ geliefert und durch den Parser als Strings eingelesen. Für die einfachen
Datentypen stehen in vielen Programmiersprachen Funktionen zum Konvertieren in
und aus Strings bereit, so dass sich die in der Datenbank als Strings gespeicherten Werte
leicht in z.B. Integer-Zahlen umwandeln lassen. Des Weiteren ist durch die Aufnahme des
Datentyps eines Attributtyps in dem Attributartenkatalog jederzeit eine Rekonstruktion
des ursprünglichen Datentyps aus den gespeicherten Strings möglich.
Codelisten können ebenfalls einfach durch Strings dargestellt werden, da als Attributwert
nur jeweils eine Kennung eingesetzt werden kann. Die Zuordnung zur dahinter
stehenden Bedeutung ist über die Tabelle Codelisten möglich. Bei dem schon zuvor
verwendeten Beispiel der Codeliste AX_Vegetationsmerkmal_Wald, die unter anderem
die beiden Nummer-Bezeichnung-Paare 1100-Laubholz und 1200-Nadelholz enthält,
würde als Attributwert 1100 bzw. 1200 in die Tabelle AttributZuweisung eingetragen
werden.
Diesen Vorteilen gegenüber steht der große Nachteil, dass Operationen, die direkt in
der Datenbank ausgeführt werden, nicht mehr unmittelbar möglich sind. SQL-Abfragen
à la WHERE strassenBreite > 10 oder die effizientere Trennung von Indexen nach Zahlenwerten
und Strings entfallen.
Die Verwendung eines Index zur Optimierung der Zugriffsgeschwindigkeiten bietet sich
für den Objektarten- und den Attributartenkatalog an. In der NAS wird die Objektart
durch den Namen des Start-Elements eines neuen Fachobjekts festgelegt (beispielsweise
4 Es werden nur Datentypen angegeben, die bisher im ATKIS-Objektartenkatalog verwendet werden.
48

). Da jedoch in der Datenbank die Objektartennummer
(in diesem Fall 53001) verwendet werden soll, muss bei jedem Einfügen eines
neuen Objekts die passende Objektartennummer zu einer gelesenen NAS-Bezeichnung
ermittelt werden (diese Funktionalität ist im NAS-Importer in JAVA implementiert). Da
sich die Daten des Objektartenkatalogs selten ändern und nahezu ausschließlich lesende
Zugriffe auf diese Tabelle stattfinden, kann ein Index auf die Spalte der NAS-Bezeichnung
hier die Zugriffe optimieren. Analog dazu kann auch der Zugriff auf den Attributartenkatalog
optimiert werden - auch hier werden in der NAS andere Kennungen verwendet
als im Objektartenkatalog.
4.4 Integration in die Multi-Repräsentations-Datenbank
Eine Multi-Repräsentations-Datenbank (MRDB) ist nach dem Konzept eines föderierten
Datenbanksystems [Con97] aufgebaut. Die Daten in einem solchen System sind in
mehreren verteilten autonomen Datenbanksystemen gespeichert. Diese Komponentendatenbanken
können beispielsweise auf verschiedene Standorte eines Unternehmens verteilt
sein und werden für sich alleine zunächst von einem ” normalen“ Datenbankmanagementsystem
verwaltet. Insbesondere bleiben die lokalen Schemata erhalten und können durch
lokale Anwendungen (siehe Abbildung 4.2) ohne Beeinflussung genutzt werden. Die Integration
in das föderierte Datenbanksystem erfolgt durch Sichtenbildung (Exportsicht).
Um diese Daten in Beziehung zu bringen, und um einen einheitlichen globalen Zugriff
auf die verteilten Datenbestände zu ermöglichen, wird an einer zentralen Stelle eine Integrationsdatenbank
geführt. Hier finden sich Informationen darüber, wie die Daten der
Komponentendatenbanken in Beziehung gebracht werden können. Es sind Verküpfungen
zwischen den Datenbeständen hinterlegt.
Ein gemeinsamer Zugriff auf das föderierte System findet ebenfalls an zentraler Stelle
über den Föderierungsdienst statt. Dies ist der Einstiegspunkt für sämtliche globale
Anwendungen.
Bezogen auf die im Rahmen des Wissensbasierter Photogrammetrisch-Kartographischer
Arbeitsplatz (WIPKA)-Projekts an der Leibniz Universität Hannover entwickelte und
verwendete MRDB (siehe [Man02]) stellen die Datenbestände in den verschiedenen Auflösungen
oder zu unterschiedlichen Thematiken die Komponentendatenbanken dar. So
kann es beispielsweise je ein DBMS für die Verwaltung räumlicher Daten des ATKIS-
BASIS-DLM, ATKIS-DLM50 und einer Straßenkarte geben. Die Verknüpfung dieser
Datenbestände erfolgt über die durch Matchingverfahren berechneten Links, die somit
die Integrationsdatenbank darstellen. Der Aufbau der MRDB ist in Abbildung 4.2 dargestellt.
49

Integrations-DB
(Links)
DBMS 1 DBMS 2
BASIS DLM DLM50
Komponenten-DBS 1
MRDB
Föderierungsdienst
Komponenten-DBS 2
Globale Anwendung
(z.B. GISVisual)
Lokale Anwendung
(z.B. NAS-Importer)
Abbildung 4.2: Aufbau der MRDB nach [Con97] und [Man02].
Das in den vorigen Abschnitten entwickelte Datenbankschema für ATKIS-Daten nach
dem AAA-Modell soll nachfolgend in die MRDB integriert werden. Eine Komponentendatenbank
muss nach folgendem Schema aufgebaut sein, damit die Integration in das
GeoFoed-Datenbankschema der MRDB möglich ist:
In der Sicht Objektview werden die Objekte mitsamt ihrer Geometrie (objektgeometrie)
dargestellt. Neben der ObjektID wird die Zuweisung der Objektart zu einem
Objekt gespeichert. Hier sollen nur Objekte angezeigt werden, die nicht als gelöscht
markiert sind (das Lebenszeitintervallende darf also keinen von NULL verschiedenen
Wert haben).
Objektview(ObjektID, Objektgeometrie, Objektart)
Die Speicherung der Attribute eines Objekts erfolgt in Form eines Kennung-Wert-Paares,
das über die objektid einem Objekt zugewiesen wird.
Attributview(ObjektID, Kennung, Wert)
Der Name eines Objekts wird als spezielles Attribut in einer eigenen Tabelle gepeichert.
Namenview(ObjektID, Name)
Das in der MRDB verwendete Schema sieht bisher kein Versionierungssystem wie das
des AAA-Modells vor. Daher wird bei der Integration des AAA-konformen Schemas in
die MRDB stets nur die aktuellste Objektversion (mit dem zeitlich spätesten Lebenszeitintervallanfang)
zur Verfügung gestellt.
50

Das oben vorgestellte Datenbankschema einer Komponentendatenbank der MRDB wird
durch Sichtenbildung (views) auf das zuvor entwickelte AAA-ATKIS-Datenbankschema
gebildet:
Erstellen des Objektview:
CREATE VIEW Objektview AS
SELECT Identifikator "ObjektID",
Geometrie "Objektgeometrie", ObjektartNr "Objektart"
FROM Gebiet_Objekt_Modellart JOIN Gebiet_REO_Modellart
ON (REOID = Identifikator)
WHERE NOT EXISTS
(SELECT *
FROM Gebiet_Objektversion_Modellart ov1
WHERE ov1.Identifikator = out.Identifikator
AND Lebenszeitintervallanfang =
(SELECT max(Lebenszeitintervallanfang)
FROM Gebiet_Objektversion_Modellart ov2
WHERE ov2.Identifikator = out.Identifikator)
AND
ov1.Lebenszeitintervallende != NULL)
Erstellen des Attributview:
CREATE VIEW Attributview AS
SELECT ObjektID "ObjektID", Kennung "Kennung", Attributwert "Wert"
FROM Gebiet_Objektversion_Modellart out JOIN Gebiet_Attrzuweisung_Modellart
ON (ObjektID = Objekt)
WHERE LOWER(Kennung) != ’nam’
AND Lebenszeitintervallanfang =
(SELECT max(Lebenszeitintervallanfang)
FROM Gebiet_Objektversion_Modellart ov
WHERE ov.Identifikator = out.Identifikator)’;
Erstellen des Namenview:
CREATE VIEW Namenview AS
SELECT ObjektID "ObjektID", Attributwert "Name"
FROM Gebiet_Objektversion_Modellart out JOIN Gebiet_Attrzuweisung_Modellart
ON (ObjektID = Objekt)
WHERE LOWER(Kennung) = ’nam’
AND Lebenszeitintervallanfang =
(SELECT max(Lebenszeitintervallanfang)
FROM Gebiet_Objektversion_Modellart ov
WHERE ov.Identifikator = out.Identifikator)’;
51

Die PL/SQL-Prozedur erstelleViews(gebiet, modell) zum Erstellen der Sichten findet
sich im Paket INIT. Diese Prozedur wird auch während der Erstellung des AAA-
ATKIS-Datenbankschemas aufgerufen. Somit sind die Sichten zur MRDB-Integration
für ein neu angelegtes Schema sofort verfügbar.
Durch die Registrierung der hier vorgestellten Tabellen bzw. Sichten in der MRDB ist
es auch für die dort verwendeten Anwendungen möglich, auf den Datenbestand des
AAA-ATKIS-Datenbankschemas zuzugreifen. Dies ist z.B. für das parallel zu dieser Arbeit
entwickelte lokale Matching ([Nie07]) im Zusammenhang mit den zu verarbeitenden
Fortführungsaufträgen (Updates) wichtig, wenn die in der NAS-Datei gelieferten Daten
zur Verarbeitung des Fortführungsauftrags nicht ausreichend sind. Dies ist z.B. beim Löschen
eines Objekts der Fall, da für das lokale Matching die Geometrie des zu löschenden
Objekts benötigt wird. In einem NAS-Fortführungsauftrag findet sich in einer delete-
Anweisung jedoch nur ein Verweis auf die zu löschende Objektversion durch deren ObjektID.
Die zusätzlich benötigte Geometrie muss also zuvor aus der Sicht Objektview
ausgelesen werden, damit das lokale Matching die Löschoperation korrekt verarbeiten
kann.
4.5 Realisierung von Fortführungsaufträgen
Das in den vorigen Abschnitten entworfene Datenmodell und das im Rahmen dieser
Arbeit implementierte Datenbankschema ist primär für einen kontinuierlich gepflegten
Bestandsdatensatz entworfen worden. Ziel dieser Arbeit ist es jedoch auch, Aktualisierungen
(Updates) für beliebige Datenbestände entgegen zu nehmen und innerhalb der
MRDB dem lokalen Matching (siehe [Nie07]) zur Verfügung zu stellen. Hierfür muss das
verwendete Datenbankschema erweitert werden.
Wie bereits zuvor erwähnt, können in NAS-Dateien verschiedene Auftragsarten enthalten
sein. Die beiden für diese Arbeit relevanten Auftragsarten sind der Einrichtungsauftrag
und der Fortführungsauftrag. In ihrer Schemabeschreibung 5 ist jeweils ein Element
spezifiziert, welches Änderungen des Datenbestands erlaubt. Bei der Definition des Einrichtungsauftrag
wird dieses Element mit neueObjekte betitelt, bei einem Fortführungsauftrag
hingegen mit geaenderteObjekte. Dies bedeutet, dass bei einem Einrichtungsauftrag
nur neue Objekte eingefügt werden können (insert), bei einem Fortführungsauftrag
ist hingegen zusätzlich das Löschen (delete) und Ändern (replace) von Objekten
möglich.
Vereinfacht könnte man einen Einrichtungsauftrag also als ” Fortführungsauftrag ohne
delete und replace“ bezeichnen, weswegen im Folgenden nur Fortführungsaufträge behandelt
werden.
5 NAS-Operationen.xsd im Unterordner NAS5.1.1 der unter [AdV07] erhältlichen ZIP-Datei.
52

Die folgenden Tabellen werden einmal je Schemainstanz angelegt und gepflegt:
Die Tabelle insert dokumentiert alle durch den NAS-Auftrag neu in den Datenbestand
eingefügten Fachobjekte. Die Fachobjekte werden durch den Importer mit sämtlichen
Attributen in das ATKIS-Datenbankschema geschrieben. Daher ist es an dieser Stelle
ausreichend, eine ObjektID anzugeben. Weitere Attribute, die für das lokale Matching
von Interesse sind, können bei Bedarf aus den weiteren Tabellen ausgelesen werden.
Zur Dokumentation des Kontextes, aus dem das Objekt in den Datenbestand eingefügt
wurde, ist der Anlass anzugeben. Dieser wird als eindeutige Kennung für einen NAS-
Auftrag vergeben. Außerdem kann optional das Datum der Operation - in diesem Fall
die Systemzeit des importierenden Rechners - angegeben werden.
insert(Anlass, ObjektID, Datum NULL )
In der Tabelle delete werden alle Löschoperationen gespeichert. Hierfür ist es ebenfalls
ausreichend, den Anlass, die ObjektID und das Datum der Operation zu kennen.
delete(Anlass, ObjektID, Datum NULL )
Bei einer replace-Operation können einzelne Attribute eines Fachobjekts verändert werden.
Dies ist für Attribute mit nicht-objektbildender Eigenschaft möglich (vergleiche
Abschnitt 3.1). Neben den drei zuvor benannten Daten muss hier zusätzlich das zu ändernde
Attribut durch seine Kennung benannt werden und dazu der neue Attributwert
angegeben werden.
replace(Anlass, ObjektID, Attributkennung, Attributwert, Datum NULL )
Da der NAS-Importer im Kontext der MRDB als lokale Anwendung läuft, werden
die eingelesenen Fortführungsaufträge auch auf den lokalen Datenbestand angewendet.
Wird beispielsweise im Rahmen eines Fortführungsauftrag ein Fachobjekt gelöscht
(), so werden die folgenden beiden Schritte durchgeführt:
1. Es wird ein neuer Eintrag in die Tabelle delete nach oben genanntem Muster
geschrieben.
2. Das Fachobjekt wird aus dem lokalen Datenbestand gelöscht, indem das Lebenszeitintervallende
der letzten Objektversion gesetzt wird (ALTER TABLE ...).
Die Historie des Fachobjekts bleibt durch diese Vorgehensweise erhalten und es ist für die
globalen Anwendungen der MRDB auch weiterhin möglich, beispielsweise die Geometrie
eines gelöschten Objekts auszulesen, wie es für das lokale Matching notwendig ist.
53

Kapitel 5
NAS-Import
5.1 Konzeptioneller Entwurf des Importers
In diesem Kapitel werden grundlegende Konzepte vorgestellt, die bei der Implementierung
des NAS-Importers verwendet wurden. Die Beschreibung wird in diesem Kapitel
bewusst allgemein gehalten und erst im folgenden Abschnitt anhand der Umsetzung in
JAVA konkretisiert.
Die Implementierung des Importers in Java folgt dem Entwurfsmuster (Design Pattern)
Model View Controller (MVC). Hierbei wird ein Softwaresystem in die drei Komponenten
Modell (model), Steuerung (controller) und Ansicht bzw. Präsentation (view)
aufgeteilt (siehe Abbildung 5.1). Das Modell repräsentiert hierbei das Datenmodell und
die Steuerung nimmt Benutzereingaben entgegen und verarbeitet diese. Die Darstellung
für den Nutzer erfolgt letztendlich durch die Benutzeroberfläche. Durch die strikte
Trennung der Komponenten ist es möglich, z.B. Änderungen an der Benutzeroberfläche
durchzuführen, ohne dass die übrigen Komponenten geändert werden müssen.
model
view
controller
Abbildung 5.1: Aufbau des MVC-Entwurfsmusters.
54

Des Weiteren begünstigt das MVC-Entwurfsmuster auch die Nutzung unterschiedlicher
Oberflächen des Programms. Der NAS-Importer soll mit den folgenden Präsentationsformen
realisiert werden:
1. Eine grafische Oberfläche, die mit JAVA Swing realisiert werden soll. Dies ist auf
Systemen mit grafischer Benutzerschnittstelle sicher die erste, da komfortabelste
Wahl.
2. Eine reine Textversion, die über die Konsole und somit beispielsweise auch über
eine Remoteverbindung per Secure Shell (SSH) benutzt werden kann, wenn keine
grafische Benutzerschnittstelle zur Verfügung steht.
Ein weiteres verwendetes Entwurfsmuster ist das Verhaltensmuster Beobachter (Observer).
Es wird dazu eingesetzt, den Fortschritt des Importvorgangs zu überwachen und
darzustellen. Die Rolle des beobachteten Objekts (Observable) übernimmt hierbei eine
Klasse aus dem Modell-Paket, die den aktuellen Zustand (verarbeitete Zeilen, Gesamtanzahl
der Zeilen im NAS-Dokument) repräsentiert. Die Beobachter (Observer) sind die
Klassen des Präsentationspaket des MVC-Patterns: auf der grafischen Oberfläche soll
der Fortschritt durch einen Fortschrittsbalken (Progressbar) dargestellt werden, auf der
Konsole soll eine Prozentzahl ausgegeben werden, die den aktuellen Fortschritt anzeigt.
beobachtetes Objekt
+meldeAn(Beobachter)
+benachrichtige()
Fortschrittsklasse
+Fortschritt
+gibFortschritt()
Beobachter
+aktualisiere()
ProgrammOberfläche
+aktualisiere()
Abbildung 5.2: Verwendung des Observer-Patterns im Kontext des NAS-Importers.
Die Controller-Klassen, also der allgemeine Importer-Controller, der Fortschrittsmanager
(zur Verwaltung des Observer-Patterns) und der Datenbankmanager (in dieser
Klasse wird die Kommunikation mit der Datenbank realisiert) werden jeweils nach dem
Einzelstück-Entwurfsmuster (Singleton-Pattern) umgesetzt. Von diesen Klassen sollte es
nur eine Instanz geben, da sie zentrale Klassen zur Steuerung sind und beispielsweise
nur ein einziger lokaler Zwischenspeicher für Beziehungen (wird durch den Importer-
Controller verwaltet) existieren sollte.
55

Neben der Möglichkeit, zwischen mehreren Benutzeroberflächen zu wählen, soll der erstellte
NAS-Importer auch in der Wahl des Parsers möglichst flexibel sein. Dies ist auch
für einen Vergleich der Geschwindigkeit und Zuverlässigkeit der verschiedenen Ansätze
(SAX vs. StAX) und ihren unterschiedlichen Implementierungen (beide Ansätze geben
nur eine API vor und sind daher in vielen verschiedenen Implementierungen erhältlich)
wichtig. Um dieses Ziel zu erreichen, wird eine Architektur nach dem Vorbild des
Adapter-Entwurfsmusters eingesetzt. Dieses Entwurfsmuster wird eingesetzt, wenn zwei
Klassen mit zueinander inkompatiblen Schnittstellen kommunizieren müssen. Es stellt
die Kompatibilität zwischen den Klassen durch Übersetzen der Schnittstelle auf eine
gemeinsam nutzbare Form her.
SAX-Parser
+...()
+characters(c:char[])
+...()
Controller
+starteParsing(Parsertyp)
Common_Handler
+...()
+characters(c:String)
+...()
StAX-Parser
+...()
+characters(c:String)
+...()
Abbildung 5.3: Verwendung des Adapter-Patterns im Kontext des NAS-Importers.
Abblidung 5.3 zeigt einen Ausschnitt des prinzipiellen Ablaufs eines Importvorgangs:
der Controller ruft den vom Benutzer gewählten Parser auf und startet das Parsing. Da
die beiden hier dargestellten Parser beide einem ereignisgesteuerten Prinzip folgen, sind
die Implementierungen ähnlich, aber im Detail doch verschieden. So werden bei SAX
durch das Ereignis characters erkannte Zeichen als char-Array gelesen, der StAX-
Parser erhält diese Zeichen als String. In diesem Fall muss also im SAX-Parser eine
Umwandlung des char-Arrays in einen String erfolgen, bevor die Daten an die Klasse
Common_Handler weitergeleitet werden können. Diese Klasse realisiert dann - unabhängig
vom gewählten Parser - die weitere Verarbeitung der Daten.
Die Umwandlung geschieht hier direkt in der jeweiligen Parserklasse. Es gibt keine extra
Adapterklasse, was eine Abweichung zum ” original“ Adapter-Entwurfsmuster darstellt.
56

Weitere Informationen zu den hier verwendeten Entwurfsmustern finden sich in [GHJV95],
dem Standardwerk zu diesem Thema.
Der Ablauf des Parsingvorgangs kann anhand eines deterministischen endlichen Automaten
(DEA) dargestellt werden. Der Common_Handler zur Behandlung der Parser-
Ereignisse empfängt diese Ereignisse von der jeweiligen Parser-Implementierung und verarbeitet
sie. Hierbei kann sich der Common_Handler in verschiedenen Zuständen befinden.
Abbildung 5.4 zeigt eine Teilmenge möglicher Zustände und soll die Funktionsweise anhand
eines Beispiels erläutern:
Start
isInsert
isDelete
isFeature
[...]
sonst
isLZI
isAnlass
isAttribute
[...]
[...]
isLZIA
Wert
isLZIE [...]
Abbildung 5.4: DEA zur Darstellung der Funktionsweise des Importers.
Dieser Ausschnit des DEA zeigt im Wesentlichen die Zustände, die beim Einfügen (insert)
eines neuen Fachobjekts erreicht werden können. Der besseren Übersicht halber
wurde nicht jeder erreichbare Zustand des Common_Handlers aufgenommen. Die Verwendung
von [...] deutet an, dass hier die Verarbeitung der Daten innerhalb weiterer
Zustände fortgeführt wird.
Zu Beginn befindet sich der Common_Handler im Zustand Start, nachdem durch den
Parser das Ereignis startDocument() gesendet wurde. In diesem Zustand sind in Abbildung
5.4 nur zwei Möglichkeiten gegeben. Es werden also alle Ereignisse ignoriert ( ” überlesen“),
bis entweder ein oder ein durch den Parser erkannt
wurde. Der Parser wechselt bei gelesenem in den Zustand isInsert. Bei
einem wohlgeformten und nach den NAS-Schemata validen XML-Dokument kann nun
als nächstes gelesenes Element nur das Startelement eines neuen Fachobjekts gelesen
57

werden. Der Common_Handler wechselt also bei jedem nun durch den Parser ausgelösten
Ereignis in den Zustand isFeature, was u.a. mit der Erzeugung einer neuen Feature-
Instanz verbunden ist.
Dies stellt eine erhebliche Vereinfachung der AAA-Klassenhierarchie dar, indem letztendlich
alle Fachobjektklassen wieder auf ihre Oberklasse Objekt zurückgeführt werden.
Alternativ hätte hier jedes im Objektartenkatalog spezifizierte Fachobjekt explizit
benannt werden müssen. Die Folge wäre ein Zustand für AX_Platz, ein weiterer für
AX_Straße, für AX_Wald etc., was natürlich eine große Menge an Zuständen und somit
einen unübersichtlichen Code mit sich gebracht hätte. Da alle diese Fachobjekte von der
Klasse Objekt eine gleichartige Struktur erben, ist diese Vereinfachung möglich.
In diesem Zustand isFeature - und nur in diesem Zustand - erwartet der Parser das Auftreten
von Attributen, die dann eingelesen und der zuvor erstellten Feature-Instanz zugeordnet
werden können. Die beiden speziellen Attribute
und werden gesondert behandelt und ihr Auftreten lässt den Common_Handler
erneut in je einen anderen Zustand wechseln, in dem diese Attribute weiter verarbeitet
werden. Für die übrigen Attribute, die keine besondere Weiterverarbeitung benötigen,
erfolgt eine ähnliche Vereinfachung wie die bereits oben erwähnte. Es wird auf die durch
den OK festgelegte Unterscheidung zwischen verschiedenen Attributarten verzichtet und
es bleibt nur ein allgemeiner Typ Attribut.
Meldet der Parser, dass zu der aktuell verarbeiteten Feature-Instanz ein passendes Endelement
im XML-Dokument erkannt wurde, so wird diese Instanz durch die Methode
Feature.write() in die Datenbank geschrieben. Der Common_Handler wechselt aus
dem Zustand isFeature wieder nach isInsert und wartet dort entweder auf das Startelement
der nächsten Feature-Instanz oder verlässt bei erkanntem auch
den Zustand isInsert wieder. Der Startzustand ist auch gleichzeitig der einzige Endzustand
des Automaten. Bricht das Parsing in einem anderen Zustand ab, gab es entweder
einen unvorhergesehenen Fehler oder das zu importierende NAS-Dokument war nicht
valide.
Der Übersicht halber wurde bei den Zuständen ” nach“ isFeature auf eine weitere Darstellung
der Rückwege verzichtet. Generell geht der Common_Handler in den vorigen
Zustand zurück, wenn
• entweder das zu einem Zustand gehörende Endelement gelesen wurde,
• oder sobald der zwischen Start- und Endelement eines Zustands stehende Wert
eingelesen wurde.
Der Datenfluss innerhalb des NAS-Importers ist in Abbildung 5.5 dargestellt. Die jeweilige
Parserklasse (SAX oder StAX) liest die NAS-Datei ein und gibt die ausgelösten
Ereignisse mitsamt der gelesenen Werte an den Commom_Handler weiter. Dieser entscheidet,
wie die ankommenden Daten weiterverarbeitet werden. Wird eine Beziehung gelesen,
58

findet die weitere Verarbeitung in der Klasse Relations statt.
Ein Fachobjekt wird intern in der Klasse Feature verwaltet. Geometrien werden zunächst
durch den Common_Handler and eine Klasse GMLReader weitergereicht, die nach
der Umwandlung der GML-Geometrie in ein internes Datenformat dieses an die zugehörige
Feature-Instanz weiterleitet. Zentraler Verbindungspunkt zwischen dem internen
Datenmodell und dem Datenbankserver ist die Klasse DB_Manager, welche die internen
Strukturen in SQL-Statements überführt und die Kommunikation mit dem DB-Server
steuert.
NAS-
Datei
Relations
Parser Common_Handler Feature DB_Manager
GMLReader
DB-Server
Abbildung 5.5: Datenfluss im Ablauf des NAS-Importers von der NAS-Datei bis in die
Datenbank.
5.2 Implementierung des Importers in Java
Bei der Entwicklung des NAS-Importers wurde die frei verfügbare Entwicklungsumgebung
Eclipse 1 eingesetzt. Die grafische Oberfläche wurde mit dem komfortablen GUI-
Designer Matisse der ebenfalls frei verfügbaren Entwicklungsumgebung NetBeans 2 erstellt.
Im Quellcode wurden Funktionen verwendet, die seit JAVA 6 (teilweise auch als Version
1.6 bezeichnet) zum Umfang der Sprache gehören. Dies sind beispielsweise die Funktionen
zur Darstellung der grafischen Oberfläche. Auch die StAX-Implementierung ist erst
sei JAVA 6 Bestandteil der JAVA API. Daher ist die JAVA-Version 6 Voraussetzung für
den Betrieb der Software.
Der NAS-Importer besteht aus vier Packages. Dies sind die drei Pakete model, view und
controller des MVC-Patterns sowie ein Paket util, das ein einfaches Logging-System
1 http://www.eclipse.org/
2 http://www.netbeans.org/
59

enthält. Der Inhalt der Packages mit ihren wichtigsten Klassen und deren Funktionen
wird nachfolgend dargestellt:
Das Package view beinhaltet alle Komponenten zur Präsentation des Programms gegenüber
dem Benutzer. Die Klasse Main_Importer ist der Haupteinstiegspunkt in das
Programm. Je nach Aufrufparameter wird entweder die grafische Oberfläche (Abbildung
5.9) oder die Konsolenversion (Abbildung 5.10) gestartet. Die grafische Oberfläche ist in
der Klasse GUI_Importer realisiert. Die Klasse MessageBox stellt eine einfache grafische
Textbox zur Ausgabe von Hilfetexten und Fehlermeldungen zur Verfügung. Die Konsolenversion
ist in der Klasse Console_Importer umgesetzt.
Beide Oberflächen implementieren die update()-Methode des Observer-Interface. Hier
werden die Änderungen an den beobachteten Subjekten gemeldet. Ebenfalls in beiden
Klassen enthalten ist eine Verbindung zum Importer_Controller (controller). Hierdurch
wird die Kommunikation mit dem Controller und somit auch mit den Klassen des
Package model ermöglicht. Unter anderem erfolgt hierüber die Anmeldung als Beobachter
bei den beobachteten Klassen oder der Start des Importvorgangs mit Übergabe der
eingegebenen Parameter.
Abbildung 5.6: UML-Klassendiagramm des Package view.
Die Klassen des Package view dienen somit ausschließlich der Präsentation bzw. Eingabe
von Daten gegenüber dem Benutzer und enthalten nach dem MVC-Entwurfsmuster
keine Steuerungs- oder Programmlogik.
Das Package controller enthält drei Klassen, welche die Funktionen zur Steuerung
des Importvorgangs implementieren. Der Importer_Controller ist die zentrale Klas-
60

se zur Steuerung des gesamten Importvorgangs. Hier werden die vom Benutzer eingegebenen
Daten verarbeitet und der Import vorbereitet (startImport()), indem z.B.
checkFile() die ausgewählte NAS-Datei überprüft und getLineCount() die Gesamtzahl
der Zeilen in dieser Datei ausliest (wird zur Überwachung des Fortschritts benötigt).
Mit startParsing() wird dann - je nach Wahl des Benutzers - einer der zur Verfügung
stehenden Parser gestartet.
Auch während des laufenden Importvorgangs wird der Importer_Controller benötigt:
getOK() stellt eine lokale Kopie des zuvor vom Datenbankserver eingelesenen Objektartenkatalogs
zur Verfügung (siehe Klasse OK des Package model). Der Zwischenspeicher
für Beziehungen ist für die Klassen des Importers über getRelations() erreichbar.
Die Schnittstelle zum Datenbankserver ist in der Klasse DB_Manager zu finden. Neben allgemeinen
Methoden zur Verbindungsverwaltung (connect(), logoff()) werden hier die
Prepared Statements zur Datenmanipulation vorbereitet. Dies ist nötig, da die Tabellennamen
vom gewählten Gebiet und von der Modellart abhängig sind und jedes Statement
erst erstellt werden kann, nachdem diese Daten durch den Benutzer eingegeben und an
den DB_Manager übermittelt (setSchema(gebiet, modellart)) wurden. Die Methoden
write_Objekt, write_Geometry etc. setzen dann für jede Operation (Einfügen eines Objekts,
Einfügen der Geometrie zu einem Objekt) die Parameter des passenden Prepared
Statement und führen dies auf dem Datenbankserver aus. Zur Kommunikation mit der
Datenbank wird der Oracle JDBC driver in der Version 10.2.0.1.0 (ojdbc14.jar) verwendet.
Abbildung 5.7: UML-Klassendiagramm des Package controller.
Der ImportProgressManager verwaltet die Fortschrittsklasse des Modells, indem er bei-
61

spielsweise eine Liste der Beobachter führt und diese bei den beobachteten Klassen anmeldet.
Auch der Zugriff auf die Fortschrittsinstanz ist über diesen Controller realisiert.
Alle Klassen dieses Pakets folgen dem Singleton-Pattern (Einzelstück), da es je Controllerklasse
nur eine Instanz geben sollte.
Das Package model umfasst alle Klassen des Datenmodells und der Programmlogik zu
diesem Modell. Die Fachobjekte werden in der Klasse Feature modelliert. Mit Hilfe dieser
Datenstruktur werden die sequentiell gelesenen Teile eines Fachobjekts zusammengesetzt.
Der Parser erstellt beim Lesen des Startelements eines neuen Fachobjekts eine neue
Instanz dieser Klasse. Werden dann im weiteren Parsingverlauf Attribute, Beziehungen
oder eine Geometrie gelesen, so werden diese dem Fachobjekt mit den entsprechenden
set()-Methoden zugeordnet. Wird das Endelement eines Fachobjekts durch den Parser
gelesen, so wird die Instanz des Fachobjekts mit der Methode write() gespeichert. Dies
geschieht entweder direkt in die Datenbank (writeObjekt(), writeGeometry()) oder
zunächst in den lokalen Zwischenspeicher (writeAttributes()).
Abbildung 5.8: UML-Klassendiagramm des Package model.
Mit der Klasse Relations wurde für den NAS-Importer eine Datenstruktur zum tempo-
62

ären Speichern von Beziehungen entwickelt. Dies ist notwendig, da bei der seriellen Verarbeitung
des XML- bzw. NAS-Dokuments ein in einer Beziehung referenziertes Fachobjekt
erst nach dem Fachobjekt eingelesen werden kann, von dem die Beziehung ausgeht.
Beispielsweise kann ein Fachobjekt durch die Beziehung hatDirektUnten auf die Fachobjekte
verweisen, die räumlich unter dem Objekt liegen. Die Zuordnung erfolgt über
die ObjektID (Konkatenation von Identifikator und Lebenszeitintervallanfang). Existiert
das referenzierte Fachobjekt in der Datenbank noch nicht, da es in der Datei weiter ” hinten“
steht (höhere Zeilennummer), läuft die Beziehung ” ins Leere“. Schreibt man eine
solche Beziehung direkt in die Datenbank, so werden Fremdschlüsselbeziehungen verletzt.
Die Klasse Relations speichert die Beziehungen zunächst in JAVA-Objekten ab
und schreibt sie erst dann in die Datenbank, wenn der Parser signalisiert, dass alle Fachobjekte
eingelesen wurden.
Abbildung 5.9: Screenshot des NAS-Importers mit grafischer Benutzeroberfläche (GUI).
Zu jeder Parser-Implementierung muss im Paket model eine passende Importerklasse existieren,
die das Interface IImporter mit der einzigen Methode start() implementiert.
63

Dies sind hier die Klassen SAX_Importer und StAX_Importer. Sie haben die Aufgabe,
die spezifische Parser-Implementierung zu initialisieren, zu starten und dann die gelesenen
Daten (inklusive eventuell nötiger Typ/Formatumwandlung) an die entsprechenden
Methoden des Common_Handler ” durchzureichen“. Die Klasse SAX_Handler ist nötig, da
die SAX-Implementierung die Behandlung der Parser-Ereignisse in einer extra Klasse
erwartet.
Zur Behandlung der Geometrien gibt es die Klasse GMLReader. Hier werden die durch
den Common_Handler vom Parser ” durchgereichten“ Geometrien weiter verarbeitet. Die
genaue Funktionsweise ist im folgenden Abschnitt 5.3 beschrieben.
Der Common_Handler ist die gemeinsame, parserunabhängige Klasse zur Verarbeitung
der auftretenden Ereignisse und der eingelesenen Daten. Er implementiert das einfache
Interface IHandler, das genau diese Methoden vorgibt. Die Funktionsweise der Verarbeitungsklasse
Common_Handler ist im vorigen Abschnitt 5.1 anhand eines deterministischen
endlichen Automaten (DEA) beschrieben.
Abbildung 5.10: Screenshot der Konsolenversion des NAS-Importers.
Die Klasse OK stellt in einer lokalen Datenstruktur den Objektartenkatalog bereit, der
auf dem Datenbankserver hinterlegt ist. Bei jedem Einfügen eines Fachobjekts bzw. eines
Attributes zu einem Fachobjekt muss zu der aus der NAS-Datei gelesenen Bezeichnung
die passende ObjektartNr bzw. Kennung aus dem Objektartenkatalog geholt werden.
Um die Kommunikation mit den Datenbankserver zu minimieren, wird der Objektartenkatalog
bei der Initialisierung einmalig durch diese Klasse eingelesen. Die Speicherung
erfolgt jeweils in einer HashMap mit der NASBezeichnung als Schlüssel und ObjektartNr
bzw. Kennung als Wert. Die Abfragen an den Objektartenkatalog finden im Programmablauf
dann ausschließlich lokal statt.
64

Die beiden Enumerationen (Aufzählungen) Parsertype und Modellart beinhalten die
verfügbaren Parser bzw. die Modellarten. So wird zum Einem die fehlerhafte Zuweisung
von Werten vermieden und bei JAVA auch eine höhere Typsicherheit erreicht, zum
Anderen ist das Programmieren mit den zuvor vorgegebenen Werten einfacher und übersichtlicher.
Abbildung 5.11: UML-Klassendiagramm des Package util.
Die einzige Klasse im Package util ist die Implementierung eines einfachen Log-Systems.
Es wird eine Textdatei im Programmverzeichnis angelegt, in welche die Einträge geschrieben
werden. Die write()-Methode ist statisch und kann von allen weiteren Klassen des
Importers genutzt werden. Diese Funktion wird zum Protokollieren von Informationen
einerseits und Fehlermeldungen (z.B. von Exceptions) andererseits ausgiebig genutzt.
Dies ermöglicht eine gute Überwachung des Importverlaufs und eine präzise Fehlerdiagnose.
Eine detaillierte Beschreibung zu allen Klassen und Methoden des NAS-Importers findet
sich in der beigefügten Java Dokumentation (JavaDoc) des Projekts. Diese befindet sich
im Verzeichnis doc des Projektordners.
5.3 Behandlung der GML-Geometrien
Das in dieser Arbeit verwendete Datenbanksystem Oracle 10g enthält zwar Funktionen,
um vorhandene Daten aus der Datenbank nach GML zu exportieren 3 , nicht aber
für den umgekehrten Weg [KGB04]. Der Import der Geometrien, die in einer NAS-Datei
innerhalb des Elements des jeweiligen Fachobjekts gespeichert sind,
musste also über eigene Funktionen realisiert werden.
Oracle selbst veröffentlicht ein Codebeispiel 4 , mit dem es möglich ist, GML-Daten einzulesen
und in die Datenbank zu speichern. Dies geschieht mit Hilfe der Oracle Spatial Java
Class Library, einer Sammlung von Klassen, die die Funktionen von Oracle Spatial in
JAVA abbilden. Da diese Klassen jedoch nur GML in den Versionen 1 und 2 unterstützen,
entfällt auch dieser Weg zum Importieren der in GML 3 verfassten Geometrien der NAS.
Bei der Suche nach einer externen Lösung fiel die Wahl dann auf GeoTools [GT07a].
3 Dies leistet die Funktion SDO_UTIL.TO_GMLGEOMETRY(sdo_geometry)
4 http://www.oracle.com/technology/sample code/products/spatial/index.html (06.08.2007)
65

GeoTools ist eine modular aufgebaute Sammlung von JAVA-Bibliotheken zum Bearbeiten,
Darstellen und Konvertieren von GeoDaten. Das Projekt hat sich dabei zum Ziel
gesetzt, stets die OGC-Spezifikationen komplett zu implementieren. GeoTools steht unter
der GNU Lesser General Public License (LGPL) und ist somit samt Quelltexten frei
erhältlich. Die Software wird von einer großen Entwicklergemeinde aktiv entwickelt, wodurch
eine stetige Weiterentwicklung auch im Hinblick auf zukünftige OGC-Standards
zu erwarten ist. Des weiteren ist GeoTools gut dokumentiert: die Dokumentation der
einzelnen Module findet sich im GeoTools UserGuide unter [GT07b].
Versuche, mit der zur Zeit (Stand: August 2007) als stabil veröffentlichten Version (2.3.3)
zu arbeiten, scheiterten an den bereits oben genannten Kriterien: die GML 3-Unterstützung
ist in dieser Version noch nicht integriert. Die aktuelle Testversion (2.4-RC0) der
GeoTools 2.4-Serie unterstützt bereits fast vollständig GML 3 und wird daher für den
Importer verwendet.
Auch in dieser Version galt es zunächst, einige Hürden zu überwinden: die Umsetzung
von Flächen in GML wurde in der NAS und somit in den Testdatensätzen sehr kompliziert
gewählt. Die Darstellung der Geometrien wird in einer sehr allgemeinen Form
angegeben:
Flächen () werden aus verschiedenen ” Stücken“ () zusammengesetzt,
die wiederum durch Polygone () realisiert sind. Diese
Polygone werden durch einen äußeren und optional einem oder mehreren inneren Ringen
() dargestellt, deren Liniensegmente jeweils aus Kurven () bestehen.
Diese Darstellung erlaubt nicht nur linear interpolierte Polygone (), sondern kann auch Flächen darstellen, deren Begrenzungslinien aus Kreisbögen
oder anderen in GML 3 zum GML Sprachumfang hinzugekommenen Geometrien
zusammengesetzt sind.
Ein sehr einfach gehaltenes Beispiel für diese allgemeine Art der Darstellung eines Polygons
ist in Anhang C zu finden. Dort wird der Einheitswürfel des R 2 nach dem oben
beschriebenen Muster in GML dargestellt.
Die in GeoTools verwendete Programmbibliothek JTS Topology Suite (JTS) [Viv06],
die JAVA-Klassen für ein räumliches Objektmodell zur Verfügung stellt, ist nicht in der
Lage, diese Geometrien darzustellen. Zunächst konnten mit dem NAS-Importer deshalb
nur Linien- und Punktgeometrien eingelesen werden. Eine mit dem Programm Open-
JUMP 5 erstellte Visualisierung der so eingelesenen Geometrien findet sich in Abbildung
5.12.
Um in Zukunft auch komplexere Geometrien verarbeiten zu können arbeitet das GeoTools-
5 http://www.openjump.org
66

Team bereits an einem erweiterten Geometriemodell, der so genannten GeoAPI 6 . Als
Erscheinungstermin für diese neue Geometriebibliothek wird jedoch nur ” the moment
they are ready“ angegeben. Es musste also eine eigene Lösung zur Verarbeitung der
Geometrien erstellt werden.
Hierzu wurde der Ansatz verfolgt, die gegebenen Geometrien vor der Verarbeitung durch
GeoTools zu vereinfachen. Da bei den ATKIS-Daten nur linear interpolierte Polygone zur
Darstellung der Flächen verwendet werden, können die allgemein gehaltenen Flächengeometrien,
wie sie oben beschrieben sind, auf Geometrien des Typs
eingeschränkt werden.
Abbildung 5.12: Kartenausschnitt des Testdatensatzes mit Punkt- und Liniengeometrien.
Visualisiert mit OpenJUMP.
Die entsprechend vereinfachte GML-Darstellung durch ein Polygon zu dem in Anhang
C gezeigten Einheitswürfel des R 2 ist Folgende:
6 http://docs.codehaus.org/display/GEOTDOC/02+GeoAPI
67

0,0 0,1 1,1 1,0 0,0
Der geschlossene Polygonzug wird durch eine Liste von Eckpunkten angegeben, wobei
der letzte Punkt dieser Liste dem Anfangspunkt entsprechen muss. Ein interner Ring ist
auch in dieser Darstellung (durch analog zu ) möglich.
Zur Transformation der erstgenannten Darstellung in letztere steht in der Klasse
GMLReader die Methode convertSurface(String gml) zur Verfügung, die als Parameter
die aus der NAS-Datei eingelesene Flächengeometrie erhält.
Hier kommt in Form der Bibliothek JDOM 7 ein Document Object Model (DOM)-basierter
Ansatz (siehe Abschnitt 2.1.1) zur Verarbeitung des XML- ” Dokuments“ (dies ist in diesem
Fall die als Parameter übergebene GML-Geometrie) zum Einsatz. Da die Struktur
des XML-Dokuments genau bekannt ist, stellt der direkte Zugriff auf einzelne Elemente,
der durch das DOM ermöglicht wird, die schnellste und einfachste Art der Implementierung
dar.
Vom Wurzelelement aus wird transitiv 8 der äußere und - sofern vorhanden
- ein oder mehrere innere Ringe () ausgewählt, die in ihren Segmenten
() je zwei Koordinatenpaare als Kindelemente haben (ebenfalls nicht
direkt sondern transitiv). Diese Punkte werden nun in die Liste der Eckpunkte des neuen
Polygons aufgenommen.
Durch diese Vereinfachung können die Flächen anschließend von der JTS-Bibliothek
und somit von GeoTools verarbeitet werden. Eine Visualisierung der nun komplett eingelesenen
Geometrien findet sich in Abbildung 5.13.
Die Umwandlung der gelesenen GML-Geometrien (hier gespeichert im String gml) in
ein JTS-Geometrieobjekt erfolgt durch folgenden Code:
org.geotools.xml.Configuration configuration = new GMLConfiguration();
org.geotools.xml.Parser parser = new org.geotools.xml.Parser(
configuration);
InputStream xml = new ByteArrayInputStream(gml.getBytes());
Geometry jtsgeom = (Geometry) parser.parse(xml);
Es wird zunächst ein GeoTools-XML-Parser-Objekt erstellt, das als Parameter ein Konfigurationsobjekt
bekommt. Dieses Objekt entstammt dem GML3-Paket von GeoTools
7 http://www.jdom.org
8 Transitiv bedeutet in diesem Fall, dass nicht direktes Kindelement von
ist und in der XML-Baumstruktur noch einige Elemente dazwischen liegen.
68

Abbildung 5.13: Kartenausschnitt des Testdatensatzes inklusive der flächenförmigen
Geometrien. Visualisiert mit OpenJUMP.
und signalisiert dem Parser somit, dass ein GML3-konformes XML-Dokument zu erwarten
ist. Der Parser liefert als Ergebnis einen String zurück, der in ein JTS-Geometrieobjekt
gecasted werden kann (explizite Typumwandlung).
Zur Fehlerbehandlung bietet es sich an, die letzte Zeile des Codes mit einem try-catch-
Block zu umschließen, der eine java.lang.ClassCastException abfängt, falls eine Geometrie
nicht korrekt gelesen und zu einer JTS-Geometrie transformiert werden konnte.
Das Schreiben der Geometrien in die Datenbank erfolgt ebenfalls mit Hilfe der GeoTools-
Klassen, genauer gesagt durch das Oracle Spatial Plugin:
Connection conn = DB_Manager.getInstance().getConn();
OracleConnection oconn = (OracleConnection) conn;
GeometryConverter conv = new GeometryConverter(oconn);
STRUCT ogeom = conv.toSDO(this.geom);
DB_Manager.getInstance().write_Geometry(this.identifikator, ogeom);
69

Zunächst benötigt das GeoTools-Plugin eine spezielle OracleConnection, die jedoch
aus der bestehenden JDBC-Datenbankverbindung erzeugt werden kann. Nun kann eine
Instanz der Klasse GeometryConverter erstellt werden, die dann mit der Methode
toSDO(geometry) die JTS-Geometrie in ein Oracle Spatial-konformes SDO_Geometry-
Objekt umwandelt. Dieses Objekt kann dann mit dem Datenbankmanager des NAS-
Importers in die Datenbank geschrieben werden.
GML-
String
GML3-Configuration
Parser
JTS Geometry Oracle Geometry DB_Manager Oracle-
Connection
Eingabe Ausgabe
Abbildung 5.14: Ein- und Ausgabe der GML-Geometrien.
DB-Server
Der komplette Vorgang - aufgeteilt in Ein- und Ausgabe - ist in Abbildung 5.14 dargestellt.
Die zu GeoTools gehörenden Klassen sind grün markiert.
5.4 Vergleich der Parser-Engines
In diesem Abschnitt sollen die beiden Parser-Engines Simple API for XML (SAX) und
Streaming API for XML (StAX) im Hinblick auf Geschwindigkeit, Zuverlässigkeit und
Einfachheit der Implementierung verglichen werden. Konkret werden die beiden Implementierungen
von SAX bzw. StAX betrachtet, die Bestandteil der aktuellen JAVA-
Version, JAVA 6, sind.
Bei diesem Aspekt der Verfügbarkeit kann SAX punkten: die Implementierung ist bereits
seit JAVA 1.4 fester Bestandteil der XML-Pakete von JAVA. StAX gehört erst seit
JAVA 6 zur JAVA-API. Steht auf einem System diese Version nicht zur Verfügung, muss
eine StAX-Implementierung über eine externe Bibliothek eingebunden werden.
Im Bezug auf die Zuverlässigkeit konnten keine gravierenden Nachteile festgestellt werden.
Die StAX-Implementierung ” ignorierte“ vereinzelt das Startelement des Dokuments
und das damit verbundene Ereignis wurde nicht ausgelöst. So konnte die Startzeit des
Parsingvorgangs (s.u.) nicht zuverlässig dokumentiert werden. Dies musste für den StAX-
Parser anderweitig implementiert werden (die Startzeit wird bei der Initialisierung des
Parsers gesetzt). Eine Erklärung für dieses Verhalten konnte nicht gefunden werden.
Weitere Mängel wurden nicht festgestellt, es wurden stets alle Elemente der Testdatensätze
korrekt eingelesen.
70

Für den SAX-Parser mussten allerdings teilweise kompliziertere Lösungen gewählt werden,
als für den StAX-Parser nötig gewesen wären. In [Ull06] heißt es zum SAX-Parser
bzw. zur Methode characters(), die den Text verarbeitet, der zwischen einem Startelement
und dem dazugehörigen Endelement im XML-Dokument steht:
” Es ist nicht festgelegt, ob der Parser den Text an einem Stück liefert oder
in kleinen Stücken.“
Dies bedeutet konkret, dass Text, der vom Parser durch die Methode geliefert wird, auch
in Bruchstücken gelesen werden kann. Beispielsweise der Lebenszeitintervallanfang
wird zur weiteren Verarbeitung im Format 9999-01-0100:00:00 benötigt. Während der
Tests wurde durch den SAX-Parser teilweise nur 9999-01- geliefert, was zu einer unerwarteten
Ausnahme führte und mit einer Sonderbehandlung verhindert werden musste.
Mit der StAX-Implementierung kann man sicher sein, stets den vollständigen Text geliefert
zu bekommen.
Für die Messung der Parsergeschwindigkeit wurden ebenfalls praktische Tests durchgeführt.
Anhand zweier NAS-Testdatensätze mit 10000 (Testdatensatz 1 ) bzw. gut 5000
Fachobjekten (Testdatensatz 2 ) sollte unter realen Bedingungen die Dauer eines Importvorgangs
ermittelt werden: durch die beim Lesen des Start- bzw. Endelements des
Dokuments auftretenden Ereignisse wird ein Zeitstempel der aktuellen Unixzeit 9 des
Testsystems zu Beginn und zum Ende des Parsings in eine Logdatei geschrieben. Als
Differenz dieser beiden Werte erhält man somit die genaue Zeit (in Millisekunden), die
der NAS-Importer zum Verarbeiten des Dokuments benötigt.
Die Tests fanden allesamt im lokalen Netz des Fachgebiets Datenbanken und Informationssysteme
(DBIS) an der Leibniz Universität Hannover statt. In diesem Netz befindet
sich auch der Datenbankserver, der zur Speicherung genutzt wird. Die Messungen wurden
in den späten Abendstunden durchgeführt, um die Messergebnisse nicht durch konkurrierende
Prozesse zu verfälschen, die im alltäglichen Betrieb zu den Hauptarbeitszeiten
anfallen. Es wurden je Testdatensatz zwei Messungen durchgeführt und daraus ein Mittelwert
gebildet.
Testdatensatz 1 Testdatensatz 2
SAX: 135 Minuten 78 Minuten
StAX: 134 Minuten 77 Minuten
Differenz: 1 Minute 1 Minute
Tabelle 5.1: Verarbeitungszeiten der betrachteten Parser-Implementierungen mit vollständig
implementiertem NAS-Importer (Messung 1).
Die erste Messung (Tabelle 5.1) wurde durchgeführt, als der Importer bereits komplett
9 http://de.wikipedia.org/wiki/Unixzeit
71

implementiert war. Es werden also alle Fachobjekte mit all ihren Attributen und Beziehungen
in die dafür vorgesehenen Tabellen eingelesen. Auch die Zeit, die zur Verarbeitung,
Umwandlung und Speicherung der GML-Geometrien benötigt wird, ist in dieser
gesamten Verarbeitungszeit enthalten.
Um die Parser-Implementierungen noch einmal isoliert von der Implementierung des
NAS-Importers zu testen, wurde dieser stark vereinfacht. Die einzige Funktion des so
veränderten Importers bestand darin, die Objektart der gelesenen Fachobjekte auf der
Konsole auszugeben. In dieser Implementierung wurden Attribute, Beziehungen und
Geometrien der Fachobjekte nicht verarbeitet. Auch die Kommunikation mit dem Datenbankserver
wurde temporär auskommentiert. Die Ergebnisse dieser zweiten Messung
sind in der nachfolgenden Tabelle 5.2 dargestellt:
Testdatensatz 1 Testdatensatz 2
SAX: 6406 Millisekunden 2843 Millisekunden
StAX: 6312 Millisekunden 2812 Millisekunden
Differenz: 94 Millisekunden 31 Millisekunden
Tabelle 5.2: Verarbeitungszeiten der betrachteten Parser-Implementierungen mit verändertem
Importprogramm (Messung 2).
Vergleicht man nun die Zeiten beider Messungen, so wird deutlich, dass die Parsing-
Zeit den geringsten Anteil an der Gesamtzeit des Importvorgangs hat. Ein Großteil der
Verarbeitungszeit während des Importvorgangs wird somit für die Verarbeitung der gelesenen
Daten im internen Datenmodell (z.B. die Erstellung von neuen Feature-Instanzen,
Zuordnung der gelesenen Attribute usw.), für die Behandlung der Geometrien oder für
die Kommunikation mit dem Datenbankserver (es finden beispielsweise pro gelesenem
Fachobjekt ca. fünf schreibende Zugriffe auf die Datenbank statt) genutzt.
Die zweite Messung könnte somit noch die genaueste Aussage über die reine Parsing-
Geschwindigkeit der Implementierungen geben: hier zeigt sich ein geringer Geschwindigkeitsvorteil
bei der StAX-Implementierung. Dieser bewegt sich jedoch mit wenigen
Millisekunden in einem für menschliche Nutzer kaum wahrnehmbaren Bereich. Da diese
zweite Testsituation nur ein konstruiertes Szenario darstellt und die Gesamtgeschwindigkeit
eines Importvorgangs - wie oben beschrieben - stärker von anderen Faktoren
abhängt, wird der Vorsprung von StAX relativiert.
Abschließend lässt sich zum Aspekt Geschwindigkeit festhalten, dass bei einer Gesamtzeit
von über zwei Stunden für den ersten Testdatensatz eine Differenz von einigen
Millisekunden nicht wahrgenommen werden kann. Deshalb spielt der Faktor ” Geschwindigkeit“
bei der Wahl einer Parser-Implementierung keine Rolle.
Insgesamt ergibt sich ein relativ einheitliches Bild beider Implementierungen, die sich in
72

den betrachteten Faktoren kaum unterscheiden. Wer z.B. nicht die neueste JAVA-Version
zur Verfügung hat und keine externen Bibliotheken verwenden möchte, sollte eher SAX
benutzen; hat man vielleicht bereits ein Projekt mit StAX realisiert oder gefallen die
besseren Einflussmöglichkeiten auf die Position des Parsers, so bietet sich StAX an. Das
Endergebnis ist mit beiden Varianten zufrieden stellend.
Da die beiden oben vorgestellten Messungen keinen Hinweis darauf geben, welcher Schritt
des Importvorgangs bzw. welche Komponente des NAS-Importers die hohe Verarbeitungszeit
verursacht, wurden weitere Messungen durchgeführt. Zunächst wurde der NAS-
Importer so verändert, dass keine Kommunikation mit dem Datenbankserver stattfand.
Hierzu wurden die Methoden zum Schreiben der Fachobjekte, Attribute usw. in die
Datenbank auskommentiert. Da im vorigen Teil dieses Abschnitts bereits ein Geschwindigkeitsunterschied
aufgrund der verwendeten Parser-Implementierung ausgeschlossen
wurde, wurden die Tests nur mit der StAX-Implementierung durchgeführt. Auch wurde
in dieser Messung nur ein Testdatensatz betrachtet, da die vorigen Messungen keinen
Einfluss der Dateigröße bzw. Anzahl der Fachobjekte auf die Verarbeitungszeit erkennen
ließen.
Testdatensatz 1
StAX: 125 Minuten
Differenz zu Messung 1: 9 Minuten
Tabelle 5.3: Verarbeitungszeiten des NAS-Importers mit Nutzung des internen Datenmodells
aber ohne Kommunikation mit dem DB-Server (Messung 3).
Die hier ermittelten und in Tabelle 5.3 dargestellten Werte schließen die Anbindung an
die Datenbank als Ursache für die lange Verarbeitungszeit aus. Vergleicht man Messung
1 und Messung 3, so sieht man, dass für die Kommunikation mit dem Datenbankserver
lediglich neun Minuten mehr gebraucht werden.
Es muss also weiter untersucht werden, wie sich die übrigen 125 Minuten zusammensetzen.
Hierzu wurde die für die dritte Messung eingesetzte Version des NAS-Importers um
die Ausgabe weiterer Informationen zur Verarbeitungszeit eines einzelnen Fachobjekts
ergänzt. Hierbei wurde eine durchschnittliche Verarbeitungsdauer von 1100 Millisekunden
pro Fachobjekt gemessen. Die Verarbeitung einer Geometrie trug im Durchschnitt
1000 Millisekunden zu diesem Wert bei.
Somit wurde die Verarbeitung der Geometrien als Hauptursache für die lange Verarbeitungszeit
des NAS-Importers identifiziert.
73

Kapitel 6
Fazit und Ausblick
6.1 Fazit
In mehreren Bundesländern laufen bereits Vorbereitungen zur Einführung des AAA-
Modells. Es werden die Voraussetzungen für einen Umstieg geprüft, teilweise werden
Testsysteme eingerichtet, die in anderen Ländern bereits seit einiger Zeit in Benutzung
sind. Wenige Länder haben bereits mit der Datenmigration begonnen. Niedersachsen
sieht eine Migration im Jahr 2008 vor ([Ueb06]), andere Länder folgen in den nächsten
Jahren. Unter diesen Voraussetzungen ist in naher Zukunft mit einer weiten Verbreitung
des AAA-Modells im täglichen Praxiseinsatz zu rechnen.
Einen großen Vorteil bietet das einheitliche Konzept des AAA-Modells besonders für
Benutzer mindestens zweier der zuvor getrennt geführten Fachinformationssysteme für
raumbezogene Daten. Beispielsweise die Harmonisierung der Objektartenkataloge von
ATKIS und ALKIS oder die gemeinsame Verwendung des AAA-Basisschemas für AL-
KIS, AFIS und ATKIS minimieren den Unterschied zwischen den Komponenten und
erleichtern somit auch die Einarbeitung.
Da das AAA-Modell sozusagen als ” Zweite Generation“ der Informationssysteme zur
digitalen Verwaltung von geografischen Daten gilt, konnten Erfahrungen aus den vergangenen
Jahrzehnten in die Planung mit einfließen und veraltete Konzepte überdacht
werden. Besonders die Versionierung ist als neue Errungenschaft hervorzuheben. Eine
lückenlose Historie kann sehr nützlich sein und auch der dadurch höhere Speicherbedarf
ist im Zeitalter stetig fallender Speicherpreise leicht zu rechtfertigen.
Die konsequent durchgeführte modellbasierte Entwicklung mit Hilfe der Unified Modeling
Language (UML) ist durch die weite Verbreitung dieses Standards ein lobenswerter
Ansatz. Leider muss an der Durchführung durch die AdV Kritik geübt werden: da die
Ergebnisse des Entwicklungsprozess nur in einem proprietären Dateiformat der Software
Rational Rose veröffentlicht werden, ist die Verwendung dieser Dateien nur einem kleinen
Benutzerkreis vorbehalten, der Zugriff auf die o.g. Software hat. Erschwerend kommt
74

hinzu, dass die textuellen Formulierungen in der GeoInfoDok teilweise ungenau sind und
einige konkrete Fragen nicht beantworten können. Gerade in diesen Situationen ist ein
Blick in die Modelldateien unerlässlich. Hier sollte die AdV nachbessern und zumindest
einen Export der Daten in ein freies Dateiformat veröffentlichen. So verfügt Rational Rose
beispielsweise über einen Web-Export, der das komplette Datenmodell nach HTML
übertragen kann, wodurch es mit jedem Webbrowser angesehen werden kann.
Dass es auch anders geht, zeigt die Spezifikation der Normbasierten Austauschschnittstelle
(NAS). Als GML-Anwendungsschema veröffentlicht, ist der Zugang zu diesem Datenmodell
einfach möglich. Generell kann gesagt werden, dass es der AdV bei der Entwicklung
der NAS gelungen ist, eine plattformunabhängige und streng an offenen Standards
orientierte Datenaustauschschnittstelle zu entwerfen, die besonders den Austausch von
Daten über das Internet berücksichtigt. Durch die große Menge an Verwaltungsdaten
(Overhead) führen NAS-konforme Daten allerdings schnell zu großen Dateien. Dies ist
der Preis der Universalität gegenüber einem proprietären Dateiformat.
Innerhalb des WIPKA-Projekts werden mit zunehmender Verbreitung des AAA-Modells
mehr und mehr AAA-konforme Geodaten in der MRDB gespeichert und verarbeitet
werden. Die vorliegende Arbeit leistet dazu einen Beitrag, indem ein AAA-konformes
ATKIS-Datenbankschema vorgestellt und ein Importer für NAS-Dateien erstellt wurde.
Somit ist ein erster Schritt in Richtung der Kompatibilität zum AAA-Modell getan. Der
aktuelle Entwicklungsstand dieser Komponenten sollte jedoch noch nicht als endgültig
bezeichnet werden. Das AAA-Modell befindet sich in einigen Punkten noch in Bearbeitung
und es fehlen Erfahrungen aus dem alltäglichen Praxiseinsatz der Software.
Vorschläge zur weiteren Entwicklung von AAA-konformen Komponenten innerhalb der
MRDB werden im folgenden Abschnitt angesprochen.
6.2 Ausblick
Durch diese Arbeit wurde ein Grundstein für die zukünftige Verwendung des AAA-
Modells im Rahmen des WIPKA-Projekts gelegt. Das erstellte Datenbankschema bietet
eine solide Basis zur Verwaltung von raumbezogenen Daten, die nach den Vorgaben des
AAA-Modells dort gespeichert sind. Die Realisierung der Datenaustauschschnittstelle
ist durch den NAS-Importer zumindest in eine Richtung schon implementiert und kann
- mit Einschränkungen durch die lange Dauer des Importvorgangs - bereits produktiv
eingesetzt werden. Dennoch gibt es bei einem so umfangreichen Thema stets weitere
Verbesserungen und Erweiterungsmöglichkeiten. Einige davon, die in naher Zukunft eine
Rolle spielen werden, sollen im Folgenden vorgestellt werden.
Im Rahmen dieser Arbeit wurde der NAS-Importer als eigenständiges Programm konzipiert.
Für den praktischen Einsatz innerhalb des WIPKA-Projekts sollte der NAS-
Importer fest in das Programm GeoFoed (siehe [Man02]) integriert werden. Diese Softwa-
75

e wird an der Leibniz Universität Hannover zur Verwaltung der Multi-Repräsentations-
Datenbank (MRDB) verwendet und realisiert den Zugriff auf diese. Die Integration in
GeoFoed besteht im Wesentlichen aus der Erstellung einer neuen Programmoberfläche -
eben der Oberfläche von GeoFoed. Da der NAS-Importer auf dem MVC-Pattern basiert,
das die Programmlogik von der Präsentation trennt, sind hier keine Probleme bei der
Integration zu erwarten.
Der NAS-Importer sollte in Zukunft um ein Modul ergänzt werden, welches den Objektartenkatalog
(und somit auch den Attributartenkatalog und die Codelisten) automatisch
in die Datenbank einlesen kann. Dies konnte bisher nicht verwirklicht werden, da
der Objektartenkatalog von offizieller Seite noch nicht in einem elektronisch gut lesbaren
Format veröffentlicht wurde. Zudem befindet sich das AAA-Modell und insbesondere der
Objektartenkatalog weiterhin in Entwicklung und es kann nicht abgesehen werden, welche
Teile der Dokumente sich noch ändern werden. Sind diese Voraussetzungen erfüllt,
so kann der NAS-Importer leicht - beispielsweise durch eine weitere Parserklasse - um
ein solches Modul erweitert werden.
Ebenfalls Raum für Verbesserungen bietet die Arbeitsgeschwindigkeit des NAS-Importers.
In der für diese Arbeit erstellten Version braucht ein Import des größeren Testdatensatzes
(10000 Fachobjekte) über zwei Stunden Rechenzeit. Ein Großteil der Zeit wird für
die Verarbeitung der Geometrien genutzt (siehe Abschnitt 5.4). Eventuell ist hier in Zukunft
durch die stetige Weiterentwicklung der verwendeten GeoTools-Bibliotheken eine
Optimierung zu erwarten. Beispielsweise könnte die geplante GeoAPI als neues Geometriemodell
von GeoTools ebenfalls kürzere Verarbeitungszeiten mit sich bringen. Ist dies
nicht der Fall und die Arbeitsgeschwindigkeit in ihrer aktuellen Höhe erweist sich im
Praxiseinsatz als unzureichend, müsste über eine Alternative zu GeoTools nachgedacht
werden und z.B. eine eigene Implementierung begonnen werden.
Im Rahmen dieser Arbeit konnte die Verarbeitung der Geometrien nicht weiter optimiert
werden. Die Geometriebehandlung als Ursache für die lange Importzeit wurde erst
relativ spät festgestellt, da die Verarbeitung aller Geometrien aufgrund diverser Probleme
(siehe Abschnitt 5.3) ebenfalls erst spät implementiert werden konnte. Des Weiteren
konnte auch nach intensiver Recherche keine Alternative zur Verwendung von GeoTools
gefunden werden. Es ist zur Zeit (Stand: September 2007) keine Software verfügbar, die
1. GML 3 verabeiten kann und
2. in ein JAVA-Programm integriert oder innerhalb eines Oracle-Datenbankservers
verwendet werden kann und
3. frei verfügbar ist.
Für eine Produktivversion des NAS-Importers sollte überlegt werden, nur noch eine
Parser-Implementierung zu verwenden. Die Konzeption des NAS-Importers mit zwei
76

Parserklassen diente zum Vergleich beider Implementierungen. Um das Programm möglichst
klein zu halten und eine zusätzliche Fehlerquelle zu eliminieren, sollte eine Parserklasse
entfernt werden. In Abschnitt 5.4 wird die Verwendung der StAX-Implementierung
empfohlen.
Bei der Implementierung des relationalen Datenbankschemas wurden Integritätsbedingungen
hauptsächlich über Fremdschlüssel realisiert. So wird z.B. bei der Attributzuweisung
sichergestellt, dass dieser Attributtyp auch Bestandteil des Attributartenkataloges
ist oder dass beide Objekte, die an der Beziehung hatDirektUnten teilnehmen, auch
wirklich in der Datenbank enthalten sind.
Auf die Prüfung weiterer Integritätsbedingungen wird in diesem Kontext verzichtet, da
davon ausgegangen wird, dass die gelieferten und zu importierenden NAS-Daten korrekt
sind. Ohne diese Voraussetzung müsste beispielsweise überprüft werden, ob ein angegebener
Attributtyp für die Objektart eines Fachobjekts zulässig ist, ob Attributwerte
in einem bestimmten Bereich liegen (z.B. Anzahl der Fahrstreifen einer Straße größer
0) und so weiter. Es handelt sich hierbei also hauptsächlich um Integritätsbedingungen,
welche die durch den Objektartenkatalog festgelegten Vorgaben prüfen. Hier wird der
praktische Einsatz zeigen, ob weitere Integritätsbedingungen notwendig sind.
Zur vollständigen Integration in die MRDB sind noch einige zusätzliche Informationen
nötig, damit Programme und Algorithmen wie das Matching die AAA-Daten verarbeiten
können. Das Matchingverfahren sieht zu Beginn eine semantische Filterung vor (siehe
[LMT04]). Hierbei werden die Fachobjekte anhand ihrer thematischen Eigenschaften,
beispielsweise der Objektart, klassifiziert. Es wird eine Zuordnungstabelle von Objekten
zweier Maßstäbe erstellt, die sich semantisch überlappen und so das gleiche Realweltobjekt
darstellen können. So wird sichergestellt, dass z.B. niemals ein Haus einer Straße
zugeordnet werden kann. Abbildung 6.1 zeigt eine solche Tabelle mit Klassenzuordnungen.
Eine ObjektartNr des BASIS-DLM wird dabei einer ObjektartNr des DLM1000
zugeordnet.
1
2
3
Objektart BASIS-DLM DLM1000
AX_Strassenachse
AX_Fahrbahnachse
AX_Bahnstrecke
AX_Platz
Abbildung 6.1: Klassenzuordnungen für die semantische Filterung anhand des BASIS-
DLM und DLM1000 (Ausschnitt). Eigene Darstellung nach [LMT04].
77

In diesem Beispiel gibt es eine Objektart (AX_Bahnstrecke), die in beiden Datenbeständen
äquivalent vorhanden ist und somit die gleiche Objektart für ein Realweltobjekt gewählt
werden kann. Zu AX_Platz gibt es im DLM1000 keine äquivalente Objektart und
es existiert auch keine Objektart, durch die ein Platz der realen Welt repräsentiert werden
könnte. AX_Fahrbahnachse aus dem BASIS-DLM hingegen kann im DLM1000 einer
Straßenachse zugeordnet werden. In diesem kleineren Maßstab wird nicht mehr zwischen
einzelnen Fahrbahnen unterschieden, weswegen der OK des DLM1000 die Objektart
AX_Fahrbahnachse nicht enthält. Semantisch kann die Objektart AX_Fahrbahnachse
der Objektart AX_Strassenachse gleichgesetzt werden.
Diese Zuordnungen komplett manuell zu erstellen ist bei vier verschiedenen Objektartenkatalogen
sehr aufwändig. Automatisierte Verfahren (zumindest könnten Objektarten,
die in allen Maßstäben vorhanden sind, automatisch zugeordnet werden) benötigen einen
elektronisch verfügbaren Objektartenkatalog. Da diese Voraussetzung zur Zeit noch nicht
erfüllt ist (s.o.), konnten die Tabellen zur Klassenzuordnung in dieser Arbeit noch nicht
realisiert werden.
6.3 Motivation zur Implementierung eines
NAS-Exporters
Da die in die MRDB importierten Geodaten durch die verschiedenen dort implementierten
Verfahren, z.B. das Matching, verändert werde können, ist eine Exportfunktion
notwendig, um diese veränderten Daten auch in Anwendungen außerhalb der MRDB
nutzen zu können. Im Rahmen des Matchings werden beispielsweise die Zuordnungen
(Links) den Daten hinzugefügt; Änderungen an den vorhandenen Daten sind beispielsweise
durch Geometrieanpassungen möglich.
Abbildung 6.2 zeigt den so entstehenden typischen Datenfluss.
NAS-Datei
AAA-Daten
MRDB
Matching
Links
AAA-Daten
NAS-Datei
mit Links
Abbildung 6.2: Datenfluss von AAA-NAS-Daten in der MRDB inklusive Im- und Export.
78

Vor diesem Szenario können nun Anforderungen an den NAS-Exporter erhoben werden:
1. Verlustloser Export: die zuvor mit dem NAS-Importer eingelesenen Daten sollen
vollständig rekonstruierbar sein.
2. Einarbeitung der Links in die NAS-Daten: sämtliche durch das Matching
erstellte Zuordnungen sollen exportiert werden, und die dadurch verknüpften Fachobjekte
sollen referenziert werden.
Ideen zur Umsetzung eines NAS-Exporters nach diesen Vorgaben werden im folgenden
Abschnitt diskutiert.
6.4 Entwurf und Ideen zur Implementierung
Der NAS-Exporter hat die Aufgabe, geografische Daten (zunächst ATKIS-Daten), die
in einem nach dem AAA-Modell erstellten Datenbankschema verwaltet werden, in eine
NAS-Datei zu exportieren. Dieser Vorgang wird in Abbildung 6.3 illustriert.
DB-Server
ATKIS-Daten
Fachobjekte
Geometrien
Beziehungen
NAS-
Exporter
NAS-
Datei
Abbildung 6.3: Export von NAS-Daten aus einer ATKIS-Datenbank.
Die erste im vorigen Abschnitt erwähnte Anforderung eines verlustlosen Exports ist einfach
zu realisieren. Bei der Implementierung des NAS-Importers wurde diese Anforderung
bereits berücksichtigt, und somit ist eine wichtige Voraussetzung für den Exporter
bereits umgesetzt.
Die zweite Anforderung lässt sich durch die Spezifikation der NAS nicht realisieren. Im
ursprünglichen NAS-GML-Anwendungsschema sind keine Links vorgesehen. Folgende
Lösungswege bieten sich an:
1. Erweiterung des GML-Anwendungsschemas für NAS-Dateien um Datenstrukturen
für Links.
79

2. Speicherung der Links in einer zusätzlichen Datei. Die NAS-Datei enthält dann
keine Informationen über die Links, sondern diese müssten in einem zusätzlichen
Verarbeitungsschritt in eine Anwendung importiert werden.
Hier ist allgemein die zweite Methode zu bevorzugen, da so die exportierte NAS-Datei
weiterhin von allen AAA-konformen Systemen verarbeitet werden kann. Durch den erstgenannten
Ansatz würde sozusagen ein neues Fachschema entwickelt werden, dessen Daten
von anderen Importprogrammen ohne Kenntnis des neuen GML-Anwendungsschemas
nicht verarbeitet werden können.
Die Behandlung der Geometrien gestaltet sich beim NAS-Exporter ähnlich schwierig,
wie bei der Implementierung des NAS-Importers. Wie schon in Abschnitt 5.3 erwähnt,
stellt Oracle Spatial eine Funktion
SDO_UTIL.TO_GMLGEOMETRY(sdo_geometry)
zur Verfügung, die eine in der Datenbank gespeicherte Geometrie in GML ausgibt. Da
die AdV im Rahmen der GeoInfoDok jedoch genaue Vorgaben bezüglich der Codierung
der Geometrien in GML vorgibt und dabei GML 3 verwendet wird, kann hierdurch keine
standardkonforme Ausgabe erreicht. GeoTools bietet unter dem Stichwort XML Transform
1 ein Exportmodul an, welches Daten aus dem intern verwendeten Geometriemodul
in XML und somit auch GML exportieren kann.
Diese Möglichkeit sollte vor der Integration in den NAS-Exporter im Hinblick auf Standarderfüllung
(GeoInfoDok), Geschwindigkeit und Zuverlässigkeit anhand von praktischen
Tests überprüft werden. Kann kein zufrieden stellendes Ergebnis erzielt werden,
so muss eventuell eine eigene Lösung implementiert werden.
Bei der Entwicklung des NAS-Importers wurde Wert auf eine möglichst modulare Implementierung
gelegt. Durch diese Vorgabe ist es nun möglich, zahlreiche Komponenten
des Importers für den Exporter wieder zu verwenden:
Das interne Datenmodell kann mit kleinen Veränderungen wie bisher genutzt werden.
So wird beispielsweise auch beim Export aus der Datenbank der Objektartenkatalog (in
Form der Klasse OK) benötigt, diesmal um einer ObjektartNr wieder die äquivalente
NASBezeichnung zuweisen zu können.
Auch die Feature-Klasse kann weiter verwendet werden, um ein Fachobjekt schrittweise
aufzubauen. So werden beispielsweise erst die allgemeinen Daten zu einen Objekt aus der
Datenbank gelesen, dann eine eventuell vorhandene Geometrie, die verschiedenen Attribute
usw. Die Datenstruktur Feature sollte für den Export noch um die Beziehungen
erweitert werden. Diese wurden beim Import zunächst lokal zwischengespeichert (Klasse
Relations) und nach dem Einlesen aller Fachobjekte in der Datenbank gespeichert. Für
1 http://docs.codehaus.org/display/GEOTDOC/03+XML+Transform
80

den Export wird die direkte Zuordnung einer Beziehung zu einem Fachobjekt benötigt.
Zum Schreiben der NAS-Datei sollte es eine Klasse nach Vorbild des DB_Managers geben,
die Methoden zum Schreiben in eine NAS-Datei implementiert. Diese Methoden
können dann auch von der Klasse Feature verwendet werden, um eine Feature-Instanz
zu speichern.
Für die Kommunikation mit der Datenbank kann weiter der DB_Manager verwendet
werden. Da die Klasse bisher nur Methoden zum Schreiben von Daten in die Datenbank
vorsieht, müssen zunächst Methoden zum Lesen der Daten aus der Datenbank hinzugefügt
werden.
Eine Programmoberfläche sollte für den NAS-Exporter komplett neu erstellt werden.
Die anzuzeigenden Daten bzw. Optionen unterscheiden sich zu sehr von denen des Importers.
Da auch der NAS-Exporter in die MRDB bzw. in GeoFoed integriert werden soll,
bietet sich die Erstellung einer Oberfläche für diesen Zweck an. Wie schon in Abschnitt
6.2 erwähnt, sollte die Erstellung einer weiteren Oberfläche dank des MVC-Pattern keine
Probleme darstellen.
81

Anhang A
Objektartenübersicht ATKIS-OK
BASIS-DLM
• Objektartengruppe ExternalCodeLists
• Objektbereich AAA Basisschema
– Objektartengruppe AAA Praesentationsobjekte
∗ Objektart AP GPO
∗ Objektart AP PPO
∗ Objektart AP LPO
∗ Objektart AP FPO
∗ Objektart AP TPO
∗ Objektart AP PTO
∗ Objektart AP LTO
∗ Objektart AP Darstellung
• Objektbereich Flurstücke, Lage, Punkte
– Objektartengruppe Angaben zur Lage
∗ Objektart AX LagebezeichnungMitHausnummer
∗ Objektart AX LagebezeichnungMitPseudonummer
∗ Objektart AX Lagebezeichnung
∗ Objektart AX Lage
– Objektartengruppe Angaben zum Netzpunkt
– Objektartengruppe Angaben zum Punktort
– Objektartengruppe Fortführungsnachweis
– Objektartengruppe Angaben zur Reservierung
– Angaben zur Historie
– Personen- und Bestandsdaten
∗ Objektart AX Person
∗ Objektart AX Anschrift
• Objektbereich Gebäude
– Objektartengruppe Angaben zum Gebäude
∗ Objektart AX Gebaeude
∗ Objektart AX Bauteil
∗ Objektart AX Nutzung Gebaeude
83

∗ Objektart AX Lage
• Objektbereich Tatsächliche Nutzung
– Objektart AX TatsaechlicheNutzung
– Objektartengruppe Siedlung
∗ Objektart AX Wohnbauflaeche
∗ Objektart AX IndustrieUndGewerbeflaeche
∗ Objektart AX Halde
∗ Objektart AX Bergbaubetrieb
∗ Objektart AX TagebauGrubeSteinbruch
∗ Objektart AX FlaecheGemischterNutzung
∗ Objektart AX FlaecheBesondererFunktionalerPraegung
∗ Objektart AX SportFreizeitUndErholungsflaeche
∗ Objektart AX Friedhof
– Objektartengruppe Verkehr
∗ Objektart AX Strassenverkehr
∗ Objektart AX Strasse
∗ Objektart AX Strassenachse
∗ Objektart AX Fahrbahnachse
∗ Objektart AX Fahrwegachse
∗ Objektart AX Platz
∗ Objektart AX Bahnverkehr
∗ Objektart AX Bahnstrecke
∗ Objektart AX Schiffsverkehr
– Objektartengruppe Vegetation
∗ Objektart AX Landwirtschaft
∗ Objektart AX Wald
∗ Objektart AX Gehoelz
∗ Objektart AX Heide
∗ Objektart AX Moor
∗ Objektart AX Sumpf
∗ Objektart AX UnlandVegetationsloseFlaeche
∗ Objektart AX FlaecheZurZeitUnbestimmbar
– Objektartengruppe Gewässer
∗ Objektart AX Fliessgewaesser
∗ Objektart AX Wasserlauf
∗ Objektart AX Kanal
∗ Objektart AX Gewaesserachse
∗ Objektart AX Hafenbecken
∗ Objektart AX StehendesGewaesser
∗ Objektart AX Meer
• Objektbereich Bauwerke, Einrichtungen und sonstige Angaben
– Objektart AX BauwerkeEinrichtungenUndSonstigeAngaben
– Objektartengruppe Bauwerke und Einrichtungen in Siedlungsflächen
∗ Objektart AX Turm
∗ Objektart AX BauwerkOderAnlageFuerIndustrieUndGewerbe
∗ Objektart AX VorratsbehaelterSpeicherbauwerk
∗ Objektart AX Transportanlage
∗ Objektart AX Leitung
∗ Objektart AX BauwerkOderAnlageFuerSportFreizeitUndErholung
84

∗ Objektart AX HistorischesBauwerkOderHistorischeEinrichtung
∗ Objektart AX SonstigesBauwerkOderSonstigeEinrichtung
∗ Objektart AX EinrichtungInOeffentlichenBereichen
– Objektartengruppe Besondere Anlagen auf Siedlungsflächen
∗ Objektart AX Ortslage
∗ Objektart AX Hafen
∗ Objektart AX Schleuse
∗ Objektart AX Grenzuebergang
∗ Objektart AX Testgelaende
– Objektartengruppe Bauwerke, Anlagen und Einrichtungen für den Verkehr
∗ Objektart AX BauwerkImVerkehrsbereich
∗ Objektart AX Strassenverkehrsanlage
∗ Objektart AX WegPfadSteig
∗ Objektart AX Bahnverkehrsanlage
∗ Objektart AX SeilbahnSchwebebahn
∗ Objektart AX Gleis
∗ Objektart AX Flugverkehrsanlage
∗ Objektart AX EinrichtungenFuerDenSchiffsverkehr
∗ Objektart AX BauwerkImGewaesserbereich
– Objektartengruppe Besondere Vegetationsmerkmale
∗ Objektart AX Vegetationsmerkmal
– Objektartengruppe Besondere Eigenschaften von Gewässern
∗ Objektart AX Gewaessermerkmal
∗ Objektart AX Polder
– Objektartengruppe Besondere Angaben zum Verkehr
∗ Objektart AX Netzknoten
∗ Objektart AX Nullpunkt
∗ Objektart AX Abschnitt
∗ Objektart AX Ast
– Objektartengruppe Besondere Angaben zum Gewässer
• Objektbereich Relief
∗ Objektart AX Wasserspiegelhoehe
∗ Objektart AX SchifffahrtslinieFaehrverkehr
∗ Objektart AX Gewaesserstationierungsachse
∗ Objektart AX Sickerstrecke
– Objektartengruppe Reliefformen
∗ Objektart AX BoeschungKliff
∗ Objektart AX Boeschungsflaeche
∗ Objektart AX DammWallDeich
∗ Objektart AX Einschnitt
∗ Objektart AX Hoehleneingang
∗ Objektart AX FelsenFelsblockFelsnadel
∗ Objektart AX Duene
∗ Objektart AX Hoehenlinie
– Objektartengruppe Primäres DGM
∗ Objektart AX Erfassung DGM
∗ Objektart AX Gelaendekante
– Objektartengruppe Sekundäres DGM
85

• Objektbereich Gesetzliche Festlegungen, Gebietseinheiten, Kataloge
– Objektartengruppe Öffentlich-rechtliche und sonstige Festlegungen
∗ Objektart AX AndereFestlegungNachWasserrecht
∗ Objektart AX SchutzgebietNachWasserrecht
∗ Objektart AX NaturUmweltOderBodenschutzrecht
∗ Objektart AX SchutzgebietNachNaturUmweltOderBodenschutzrecht
∗ Objektart AX Denkmalschutzrecht
∗ Objektart AX SonstigesRecht
∗ Objektart AX Schutzzone
– Objektartengruppe Bodenschätzung, Bewertung
– Objektartengruppe Kataloge
∗ Objektart AX Nationalstaat
∗ Objektart AX Bundesland
∗ Objektart AX Regierungsbezirk
∗ Objektart AX KreisRegion
∗ Objektart AX Gemeinde
∗ Objektart AX Gemeindeteil
∗ Objektart AX Verwaltungsgemeinschaft
∗ Objektart AX Dienststelle
∗ Objektart AX LagebezeichnungKatalogeintrag
∗ Objektart AX Gemeindekennzeichen
∗ Objektart AX Katalogeintrag
∗ Objektart AX Dienststelle Schluessel
∗ Objektart AX Bundesland Schluessel
∗ Objektart AX Regierungsbezirk Schluessel
∗ Objektart AX Kreis Schluessel
∗ Objektart AX VerschluesselteLagebezeichnung
∗ Objektart AX Verwaltungsgemeinschaft Schluessel
– Objektartengruppe Geographische Gebietseinheiten
∗ Objektart AX Landschaft
∗ Objektart AX KleinraeumigerLandschaftsteil
∗ Objektart AX Gewann
∗ Objektart AX Insel
∗ Objektart AX Wohnplatz
– Objektartengruppe Administrative Gebietseinheiten
∗ Objektart AX KommunalesGebiet
∗ Objektart AX Gebiet Nationalstaat
∗ Objektart AX Gebiet Bundesland
∗ Objektart AX Gebiet Regierungsbezirk
∗ Objektart AX Gebiet Kreis
∗ Objektart AX Kondominium
∗ Objektart AX Gebietsgrenze
∗ Objektart AX Gebiet
• Objektbereich Nutzerprofile
– Objektartengruppe Nutzerprofile
∗ Objektart AX Benutzer
∗ Objektart AX Benutzergruppe
∗ Objektart AX BenutzergruppeMitZugriffskontrolle
∗ Objektart AX BenutzergruppeNBA
∗ Objektart AX BereichZeitlich
∗ Objektart AX FOLGEVA
∗ Objektart AX Portionierungsparameter
86

Anhang B
Übersicht über das relationale
Datenbankschema
Tabelle Objekt:
Objekt(Identifikator, Objektart → Objektartenkatalog)
Tabelle Identifikatoren:
Objektversion(ObjektID, Identifikator → Objekt, LebenszeitintervallAnfang,
LebenszeitintervallEnde NULL , Anlass)
Tabelle REO:
REO(ReoID → Objekt, Geometrie)
Tabelle NREO:
NREO(NReoID → Objekt)
Tabelle ZUSO:
ZUSO(ZusoID → Objekt, Teil → Objekt)
Tabelle Praesentationsobjekt:
Praesentationsobjekt(PraesentationsobjektID → Objekt, Schriftinhalt,
Fontsperrung, Skalierung, HorizontaleAusrichtung, VertikaleAusrichtung,
Geometrie)
Tabelle hatDirektUnten:
hatDirektUnten(Oben → Objekt, Unten → Objekt)
Tabelle dientZurDarstellungVon:
dientZurDarstellungVon(Objekt → Objekt, Praesentationsobjekt → Praesentationsobjekt)
87

Tabelle istAbgeleitetAus:
istAbgeleitetAus(Kartengeometrieobjekt → Objekt, Basisobjekt → Objekt)
Tabelle ObjektArtenKatalog:
ObjektArtenKatalog(ObjektartNr, NASBezeichnung, Beschreibung NULL )
Tabelle AttributArtenKatalog:
AttributArtenKatalog(Kennung, NASBezeichnung, Beschreibung NULL ,
Datentyp)
Tabelle Codelisten:
Codelisten(Name → AttributArtenKatalog, Nummer, Bezeichnung)
Tabelle AttributZuweisung:
AttributZuweisung(ObjektID → Objektversion, Kennung → AttributArten-
Katalog, AttributWert)
Tabelle insert (Fortführungsaufträge):
insert(Anlass, ObjektID, Datum NULL )
Tabelle delete (Fortführungsaufträge):
delete(Anlass, ObjektID, Datum NULL )
Tabelle replace (Fortführungsaufträge):
replace(Anlass, ObjektID, Attributkennung, Attributwert, Datum NULL )
Sicht Objektview (MRDB-Integration):
Objektview(ObjektID, Objektgeometrie, Objektart)
Sicht Attributview (MRDB-Integration):
Attributview(ObjektID, Kennung, Wert)
Sicht Namenview (MRDB-Integration):
Namenview(ObjektID, Name)
88

Anhang C
Einheitswürfel dargestellt durch
gml:Surface
0 0
0 1
0 1
1 1
89

1 1
1 0
1 0
0 0
(0,1) (1,1)
(0,0)
Y
(1,0)
Abbildung C.1: Darstellung des Einheitswürfels im R 2 .
90
X

Anhang D
Abkürzungsverzeichnis
AAA AFIS-ALKIS-ATKIS
AdV Arbeitsgemeinschaft der Vermessungsverwaltungen der Länder der
Bundesrepublik Deutschland
AFIS Amtliches Festpunktinformationssystem
ALB Automatisiertes Liegenschaftsbuch
ALK Automatisierte Liegenschaftskarte
ALKIS Amtliches Liegenschaftskatasterinformationssystem
API Application programming interface
ATKIS Amtliches Topographisch-Kartographisches Informationssystem
BKG Bundesamt für Kartographie und Geodäsie
CRS Coordinate Reference System
DBMS Datenbankmanagementsystem
DEA Deterministischer endlicher Automat
DGM Digitales Geländemodell
DLM Digitales Landschaftsmodell
DOM Document Object Model
DTD Document Type Definition
FES Filter Encoding Specification
GML Geography Markup Language
91

ISO International Organization for Standardization
JTS JTS Topology Suite
LGPL GNU Lesser General Public License
MRDB Multi-Repräsentations-Datenbank
MVC Model View Controller
NAS Normbasierte Austauschschnittstelle
NREO Nicht-raumbezogenes Elementarobjekt
OGC Open Geospatial Consortium
OK Objektartenkatalog
REO Raumbezogenes Elementarobjekt
SAX Simple API for XML
SSH Secure Shell
StAX Streaming API for XML
SQL Structured Query Language
UML Unified Modeling Language
URN Uniform Resource Name
W3C World Wide Web Consortium
WCS Web Coverage Service
WFS Web Feature Service
WIPKA Wissensbasierter Photogrammetrisch-Kartographischer Arbeitsplatz
WMS Web Map Service
XML Extensible Markup Language
XSD XML Schema Definition
ZUSO Zusammengesetztes Objekt
92

Abbildungsverzeichnis
2.1 Darstellung eines XML-Dokuments in einer Baumstruktur. . . . . . . . . 9
2.2 UML-Klassendiagramm der Geometrietypen von GML 3.0 aus [OGC02]. 13
3.1 Das AAA-Anwendungsschema. . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2 Pakete des AAA-Basisschemas. Eigene Darstellung nach [AdV06]. . . . . 21
3.3 Die vier Basisklassen für Objekte im Zusammenhang. Eigene Darstellung
nach [AdV06]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4 Aufbau eines ZUSOs am Beispiel einer Straße. Eigene Darstellung nach
[AdV06]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.5 Darstellung der Klassenhierarchie im AAA-Anwendungsschema anhand
der Fachobjekte AX Friedhof, AX Strasse und AX Strassenachse. . . . . 27
3.6 Beziehungen zwischen einem ZUSO und zwei REOs, die Bestandteil des
ZUSOs sind. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.7 Kartenausschnitt eines ATKIS-NAS-Testdatensatzes im BASIS-DLM. Visualisiert
mit GML Viewer von Snowflake Software [Sno06] . . . . . . . . 31
3.8 Kodierung des UML-Anwendungsschemas nach XML Schema. . . . . . . 34
4.1 Entity-Relationship-Diagramm für das ATKIS-Datenmodell . . . . . . . 40
4.2 Aufbau der MRDB nach [Con97]und [Man02]. . . . . . . . . . . . . . . . 50
5.1 Aufbau des MVC-Entwurfsmusters. . . . . . . . . . . . . . . . . . . . . . 54
5.2 Verwendung des Observer-Patterns im Kontext des NAS-Importers. . . . 55
5.3 Verwendung des Adapter-Patterns im Kontext des NAS-Importers. . . . 56
5.4 DEA zur Darstellung der Funktionsweise des Importers. . . . . . . . . . . 57
5.5 Datenfluss im Ablauf des NAS-Importers von der NAS-Datei bis in die
Datenbank. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.6 UML-Klassendiagramm des Package view. . . . . . . . . . . . . . . . . . 60
5.7 UML-Klassendiagramm des Package controller. . . . . . . . . . . . . . 61
5.8 UML-Klassendiagramm des Package model. . . . . . . . . . . . . . . . . 62
5.9 Screenshot des NAS-Importers mit grafischer Benutzeroberfläche (GUI). . 63
5.10 Screenshot der Konsolenversion des NAS-Importers. . . . . . . . . . . . . 64
5.11 UML-Klassendiagramm des Package util. . . . . . . . . . . . . . . . . . 65
5.12 Kartenausschnitt des Testdatensatzes mit Punkt- und Liniengeometrien.
Visualisiert mit OpenJUMP. . . . . . . . . . . . . . . . . . . . . . . . . . 67
93

5.13 Kartenausschnitt des Testdatensatzes inklusive der flächenförmigen Geometrien.
Visualisiert mit OpenJUMP. . . . . . . . . . . . . . . . . . . . . 69
5.14 Ein- und Ausgabe der GML-Geometrien. . . . . . . . . . . . . . . . . . . 70
6.1 Klassenzuordnungen für die semantische Filterung anhand des BASIS-
DLM und DLM1000 (Ausschnitt). Eigene Darstellung nach [LMT04]. . . 77
6.2 Datenfluss von AAA-NAS-Daten in der MRDB inklusive Im- und Export. 78
6.3 Export von NAS-Daten aus einer ATKIS-Datenbank. . . . . . . . . . . . 79
C.1 Darstellung des Einheitswürfels im R 2 . . . . . . . . . . . . . . . . . . . . 90
94

Tabellenverzeichnis
3.1 Objektartenkatalogeintrag AX Friedhof aus dem ATKIS-OK Basis-DLM 33
5.1 Verarbeitungszeiten der betrachteten Parser-Implementierungen mit vollständig
implementiertem NAS-Importer (Messung 1). . . . . . . . . . . . 71
5.2 Verarbeitungszeiten der betrachteten Parser-Implementierungen mit verändertem
Importprogramm (Messung 2). . . . . . . . . . . . . . . . . . . 72
5.3 Verarbeitungszeiten des NAS-Importers mit Nutzung des internen Datenmodells
aber ohne Kommunikation mit dem DB-Server (Messung 3). . . 73
95

Literaturverzeichnis
[AdV06] AdV. Dokumentation zur Modellierung der Geoinformationen des amtlichen
Vermessungswesens (GeoInfoDok). Arbeitsgemeinschaft der Vermessungsverwaltungen
der Länder der Bundesrepublik Deutschland (AdV), 5.1 Aufl.,
2006. URL http://www.adv-online.de/.
[AdV07] AdV. Das externe Modell, Datenaustausch (ZIP-Datei mit sämtlichen XML-
Schemadateien). Arbeitsgemeinschaft der Vermessungsverwaltungen der
Länder der Bundesrepublik Deutschland (AdV), 5.1.1 Aufl., 2007. URL
http://www.adv-online.de/.
[Bri05] T. Brinkhoff. Geodatenbanksysteme in Theorie und Praxis – Einführung
in objektrelationale Geodatenbanken unter besonderer Berücksichtigung von
Oracle Spatial. Wichmann, 1 Aufl., 2005.
[BT07] BEOLINGUS-Team. BEOLINGUS - Online-Wörterbuch Englisch-Deutsch
und Deutsch-Englisch. Technische Universität Chemnitz, 2007. URL http:
//www.beolingus.de.
[Con97] S. Conrad. Föderierte Datenbanksysteme - Konzepte der Datenintegration.
Springer, 1 Aufl., 1997.
[GHJV95] E. Gamma, R. Helm, R. Johnson, J. Vlissides. Design Patterns - Elements of
Reusable Object-Oriented Software. Addison-Wesley Longman, 1 Aufl., 1995.
[GT07a] GeoTools-Team. GeoTools - The Open Source Java GIS Toolkit. GeoTools
Project, 2007. URL http://geotools.codehaus.org.
[GT07b] GeoTools-Team. GeoTools Users Guide. GeoTools Project, 2007. URL http:
//docs.codehaus.org/display/GEOTDOC/Home.
[ISO03] ISO. ISO 19107:2003 - Geographic information – Spatial schema. International
Organization for Standardization, 90.92 Aufl., 2003. URL
http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?
CSNUMBER=26012.
[ISO06] ISO. ISO 19118:2005 - Geographic information – Encoding. International
Organization for Standardization, 60.60 Aufl., 2006. URL http://www.iso.
org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=37796.
96

[ISO07] ISO. ISO/PRF 19136 - Geographic information – Geography Markup
Language (GML). International Organization for Standardization, 50.20
Aufl., 2007. URL http://www.iso.org/iso/en/CatalogueDetailPage.
CatalogueDetail?CSNUMBER=32554.
[KGB04] R. Kothuri, A. Godfrind, E. Beinat. Pro Oracle Spatial. Apress, 1 Aufl.,
2004.
[KM03] M. Klettke, H. Meyer. XML & Datenbanken - Konzepte, Sprachen und Systeme.
dpunkt.Verlag, 1 Aufl., 2003.
[LBTR04] R. Lake, D. S. Burggraf, M. Trninic, L. Rae. Geography Mark-Up Language:
Foundation for the Geo-Web. Wiley, 1 Aufl., 2004.
[Lip06] U. Lipeck. Skript zur Vorlesung Grundlagen der Datenbanksysteme. Fachgebiet
Datenbanken und Informationssysteme, Leibniz Universität Hannover,
2006. URL http://www.dbs.uni-hannover.de.
[LMT04] U. W. Lipeck, D. Mantel, M. Tiedge. Identifikation kartographischer Objekte
in föderierten räumlichen Datenbanken. Techn. Ber. DB-01/2004. Institut
für Informationssysteme, Universität Hannover, 2004. URL http://www.
dbs.uni-hannover.de.
[Man02] D. Mantel. Konzeption eines Föderierungsdienstes für geographische Datenbanken;
Diplomarbeit. Fachgebiet Datenbanken und Informationssysteme,
Universität Hannover, 2002. URL http://www.dbs.uni-hannover.de.
[Nie07] R. Niehaus. Lokale Matching- und Update- Verfahren für eine räumliche
Multi-Repräsentations-Datenbank; Bachelorarbeit. Fachgebiet Datenbanken
und Informationssysteme, Leibniz Universität Hannover, 2007. URL http:
//www.dbs.uni-hannover.de/.
[OGC02] OGC. OpenGIS R○Geography Markup Language (GML) Encoding Specification.
Open Geospatial Consortium Inc., 3.0 Aufl., 2002. URL http:
//portal.opengeospatial.org/files/?artifact_id=7174.
[OGC05a] OGC. GML Point Profile. Open Geospatial Consortium Inc., 0.4 Aufl., 2005.
URL http://portal.opengeospatial.org/files/?artifact_id=11606.
[OGC05b] OGC. OpenGIS R○Filter Encoding Implementation Specification. Open
Geospatial Consortium Inc., 1.1.0 Aufl., 2005. URL http://portal.
opengeospatial.org/files/?artifact_id=8340.
[OGC05c] OGC. Web Feature Service Implementation Specification. Open Geospatial
Consortium Inc., 1.1 Aufl., 2005. URL http://portal.opengeospatial.
org/files/?artifact_id=8339.
97

[OGC06a] OGC. Geography Markup Language (GML) simple features profile. Open
Geospatial Consortium Inc., 1.0.0 Aufl., 2006. URL http://portal.
opengeospatial.org/files/?artifact_id=15201.
[OGC06b] OGC. OpenGIS R○Web Map Server Implementation Specification. Open
Geospatial Consortium Inc., 1.3.0 Aufl., 2006. URL http://portal.
opengeospatial.org/files/?artifact_id=14416.
[OGC06c] OGC. Web Coverage Service (WCS) Implementation Specification. Open
Geospatial Consortium Inc., 1.1.0 Aufl., 2006. URL https://portal.
opengeospatial.org/files/?artifact_id=18153.
[Opi03] H. Opitz. Entwurf und Implementierung einer kartographischen Datenbank
nach dem AFIS-ALKIS-ATKIS-Referenzmodell; Studienarbeit. Fachgebiet
Datenbanken und Informationssysteme, Leibniz Universität Hannover,
2003. URL http://www.dbs.uni-hannover.de/ftp/studienarbeiten/
opitz/studienarbeit.pdf.
[SKPH03] W. Schmidt, J. Knappen, H. Partl, I. Hyna. LATEX2ε -Kurzbeschreibung.
Walter Schmidt, 2 Aufl., 2003. URL ftp://dante.ctan.org/tex-archive/
info/lshort/german/.
[Sno06] SnowflakeSoftware. GML Viewer - Generic GML viewer capable of reading
any GML2 or GML3 dataset. (kostenlos; Registrierung erforderlich).
Snowflake Software, 3 Aufl., 2006. URL http://www.snowflakesoftware.
co.uk/products/gmlviewer/index.htm.
[Ueb06] R. Ueberholz. AAA und ETRS89/UTM in Niedersachsen - Strategie und Einführungskonzept.
LGN, 2006. URL http://cdl.niedersachsen.de/blob/
images/C21110566_L20.pdf.
[Ull06] C. Ullenboom. Java ist auch eine Insel. Programmieren mit der Java Standard
Edition Version 6. Galileo Computing, 6 Aufl., 2006. URL http:
//galileocomputing.de/openbook/javainsel6/.
[Viv06] VividSolutions. JTS Topology Suite - an API for modelling and manipulating
2-dimensional linear geometry. (LGPL). Vivid Solutions, 1 Aufl., 2006. URL
http://www.vividsolutions.com/jts/JTSHome.htm.
[W3C01] W3C. XML Linking Language (XLink) Version 1.0. World Wide Web Consortium
(W3C), 1 Aufl., 2001. URL http://www.w3.org/TR/xlink/.
[W3C04a] W3C. XML Schema Part 1: Structures (Second Edition). World Wide
Web Consortium (W3C), 1 Aufl., 2004. URL http://www.w3.org/TR/
xmlschema-1/.
98

[W3C04b] W3C. XML Schema Part 2: Datatypes (Second Edition). World Wide
Web Consortium (W3C), 1 Aufl., 2004. URL http://www.w3.org/TR/
xmlschema-2/.
[W3C06a] W3C. Extensible Markup Language (XML) 1.0 (Fourth Edition). World
Wide Web Consortium (W3C), 1 Aufl., 2006. URL http://www.w3.org/
TR/2006/REC-xml-20060816/.
[W3C06b] W3C. Namespaces in XML 1.0 (Second Edition). World Wide Web
Consortium (W3C), 1 Aufl., 2006. URL http://www.w3.org/TR/2006/
REC-xml-names-20060816/.
[W3C07] W3C. XML Path Language (XPath) 2.0. World Wide Web Consortium
(W3C), 2 Aufl., 2007. URL http://www.w3.org/TR/xpath20/.
99

Erklärung
Hiermit versichere ich, dass ich die vorliegende Arbeit und die zugehörige Implementierung
selbständig verfasst und dabei nur die angegebenen Quellen und Hilfsmittel verwendet
habe.
Hannover, 11. September 2007
Michael Schäfers
100