Thema - bei der LISt Gesellschaft für Verkehrswesen und ...

Thema:
Diplomarbeit
Konzeption einer Geodateninfrastruktur für die
Sächsische Straßenbauverwaltung
Verfasser: Stefan Wolff
betreuender Professor: Prof. Dr.-Ing. Robert Baumgartl
Betreuer: Herr Dipl.-Ing. Marcel Czerny
eingereicht:
Dresden, 28.03. 2011

Danksagung
An dieser Stelle möchte ich allen Dank sagen, die mich in meinen Fragen unterstützt
haben und für Gespräche stets zur Verfügung standen. Insbesondere möchte ich Herrn
Göpfert, Geschäftsführer der LISt GmbH, der es mir ermöglichte, sowohl mein
Praktikum als auch meine Diplomarbeit zu absolvieren sowie Herrn Czerny und Herrn
Klemm, die mich bei der Bearbeitung meiner Diplomarbeit betreuten, danken.
Des Weiteren danke ich Herrn Professor Baumgartl, der mich an der HTW-Dresden für
die Dauer meiner Arbeit unterstützt und betreut hat.
Ein besonderer Dank geht an meine Familie, die mir dieses Studium ermöglichte und
stets einen wichtigen Rückhalt darstellte. In diesem Sinne widme ich diese Arbeit auch
insbesondere meinem im Jahr 2010 verstorbenen Vater.

Eigenständigkeitserklärung
Hiermit bestätige ich, dass ich die vorliegende Arbeit zum Thema
„Konzeption einer Geodateninfrastruktur für die Sächsische Straßenbauverwaltung“
selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel
verwendet habe.
Dresden, 28.03.2011
Stefan Wolff

Inhaltsverzeichnis
1 Einleitung 1
1.1 Motivation .............................................................................................................. 1
1.2 Zielsetzung .............................................................................................................. 2
1.3 Struktur der Arbeit ............................................................................................... 3
2 Grundlagen 4
2.1 Definition Geoinformationssystem ....................................................................... 4
2.2 Definition Geodateninfrastruktur ........................................................................ 5
2.3 INSPIRE ................................................................................................................. 6
2.4 Webservices ............................................................................................................ 8
2.4.1 WMS ........................................................................................................................ 8
2.4.2 WFS ......................................................................................................................... 9
2.4.3 CSW ....................................................................................................................... 11
2.4.4 WPS ....................................................................................................................... 11
2.4.5 WCS ....................................................................................................................... 12
2.4.6 WMTS ................................................................................................................... 12
3 Ausgangssituation in der LISt GmbH 14
3.1 Technische Grundlagen ...................................................................................... 14
3.1.1 Verfügbare Hardware ............................................................................................ 14
3.1.2 Verwendete Techniken .......................................................................................... 15
3.2 Analyse bestehender Fachverfahren und Geodaten ......................................... 15
4 Konzept einer möglichen Geodateninfrastruktur der SBV 19
4.1 Einführung ........................................................................................................... 19
4.2 Beschreibung des Produktionskomplexes ......................................................... 20
4.2.1 Erste Ausbaustufe .................................................................................................. 20
4.2.2 Zweite Ausbaustufe ............................................................................................... 23
I

4.3 Beschreibung des INSPIRE Komplexes ............................................................ 26
4.3.1 Erste Ausbaustufe .................................................................................................. 26
4.3.2 Zweite Ausbaustufe ............................................................................................... 26
4.4 Beschreibung der Entwicklungs- und Testumgebung ..................................... 27
4.4.1 Verwendete Dateiformate ...................................................................................... 28
4.4.2 Software zur Umsetzung der Webservices ............................................................ 30
4.4.3 Client Software ...................................................................................................... 31
5 Teilweiser Aufbau einer prototypischen GDI 32
5.1 Test der Datenbanksysteme ................................................................................ 32
5.2 Implementierung der Geodatenbank ................................................................. 33
5.2.1 Datenimport ........................................................................................................... 33
5.2.2 Zugriffsschutz der Geodatenbank .......................................................................... 33
5.3 Übersicht der verwendeten Software ................................................................. 41
5.3.1 Webservices ........................................................................................................... 42
5.3.2 Desktop-GIS .......................................................................................................... 45
6 Zusammenfassung 48
7 Ausblick 49
Anhang 51
A1 mögliche Geodateninfrastruktur der Sächsischen Straßenbauverwaltung ....... 51
A2 PostgreSQL Rechteverwaltung .............................................................................. 51
A3 Skript zur Geschwindigkeitsmessung eines WMS ............................................... 55
Bibliographie 59
Literatur ......................................................................................................................... 59
Internet ........................................................................................................................... 60
II

Abbildungsverzeichnis
Abbildung 1: Struktur der europäischen GDI nach INSPIRE [vgl. i2]........................... 6
Abbildung 2: Zeitplan zur Umsetzung der INSPIRE Richtline [i3] ............................... 7
Abbildung 3: Funktionsprinzip WMS ............................................................................. 9
Abbildung 4: Funktionsprinzip WFS ............................................................................ 10
Abbildung 5: Zusammenarbeit der Services ................................................................. 13
Abbildung 6: Aufbau eines Blade Servers [i6] ............................................................. 14
Abbildung 7: Ausgangssituation in der LISt GmbH ..................................................... 18
Abbildung 8: ERM der Rechteverwaltung .................................................................... 35
Abbildung 9: Zentraler Datenbank-View der Rechtverwaltung ................................... 36
Abbildung 10: Instead of Update Trigger des zentralen Views ...................................... 37
Abbildung 11: Instead of Delete Trigger des zentralen Views ....................................... 37
Abbildung 12: Instead of Insert Trigger des zentralen Views ........................................ 38
Abbildung 13: Before Update Trigger der Datentabelle ................................................. 39
Abbildung 14: Bildschirmfoto der Rechteverwaltung im Kartenfenster von MapInfo .. 40
Abbildung 15: Bildschirmfoto der Rechteverwaltung im Datenfenster von MapInfo ... 40
Abbildung 16: Auswahlmenü des MapInfo "Direktzugriff" Modus ............................... 41
Abbildung 17: Antwortzeiten der WMS ......................................................................... 44
Abbildung 18: PostgreSQL zentraler Datenbank-View der Rechteverwaltung ............. 51
Abbildung 19: PostgreSQL Before Update Trigger der Datentabelle ............................ 52
Abbildung 20: PostgreSQL Triggerfunktion der Datentabelle ....................................... 52
Abbildung 21: PostgreSQL Instead of Insert Rule des zentralen Views ........................ 53
Abbildung 22: PostgreSQL Instead of Update Rule des zentralen Views ...................... 53
Abbildung 23: PostgreSQL Instead of Delete Rule des zentralen Views ....................... 53
Abbildung 24: Skript (Bash) zur Generierung der WMS Anfragen ............................... 57
Abbildung 25: Skript (Bash) zur parallelen Ausführung des Mess-Skripts .................... 57
Abbildung 26: Skript (Bash) zur Messung von Antwortzeiten der WMS Anfragen ...... 58
III

Tabellenverzeichnis
Tabelle 1: ESRI Dateiformate ......................................................................................... 28
Tabelle 2: MapInfo Dateiformate.................................................................................... 28
Tabelle 3: AutoCAD Dateiformate ................................................................................. 28
Tabelle 4: XML-basierte Dateiformate ........................................................................... 29
Tabelle 5: Rasterformate ................................................................................................. 29
Tabelle 6: Einheitliche Austauschformate der Verwaltungen ........................................ 29
Tabelle 7: Sonstige Dateiformate .................................................................................... 30
Tabelle 8: Vergleich GeoServer und deegree ................................................................. 43
Tabelle 9: Übersicht Desktop-GIS .................................................................................. 47
IV

Abkürzungsverzeichnis
AAA AAA Datenmodell (ATKIS, ALKIS, AFIS)
AFIS Amtliches Festpunkt Informationssystem
ALB Automatisiertes Liegenschaftsbuch
ALK Automatisierte Liegenschaftskarte
ALKIS Amtliches Liegenschaftskataster Informationssystem
ATKIS Amtlich Topographisch Kartographisches
Informationssystem
ASB Anweisung Straßeninformationsbank
CGI Common Gateway Interface
CSW Web Catalogue Service
DGM Digitales Geländemodell
DLM Digitales Landschaftsmodell
DOP Digitale Orthophotos
DTK Digitale Topographische Karte
ECW Enhanced Compressed Wavelet
EG Europäische Gemeinschaft
ETL Extract, Transform, Load
FCGI Fast Common Gateway Interface
GDI Geodateninfrastruktur
GeoMIS Geomatik Metadaten-Informations-System
GIS Geoinformationssystem
GML Geographic Markup Language
GUI Graphical User Interface
V

HTTP Hypertext Transfer Protocol
INSPIRE Infrastructure for Spatial Information in Europe
ISO International Organization for Standardization
ISS INSPIRE Synchronisations Service
ODBC Open Database Connectivity
OGC Open Geospatial Consortium
OKSTRA ® Objektkatalog für das Straßen- und Verkehrswesen
OKWS OKSTRA ® Webservice
SBV Sächsische Straßenbauverwaltung
SDI Spatial Data Infrastructure
SMUL Sächsisches Ministerium für Umwelt und Landwirtschaft
SMWA Sächsisches Ministerium für Wirtschaft, Arbeit und
Verkehr
SOA Service Oriented Architecture
SQL Structured Query Language
UMN University of Minnesota
WCPS Web Coverage Processing Service
WCS Web Coverage Service
WFS Web Feature Service
WFS-T Web Feature Service-Transactional
WMS Web Map Service
WMTS Web Map Tile Service
WPS Web Processing Service
XML Extended Markup Language
VI

1. Einleitung
1 Einleitung
1.1 Motivation
In der heutigen Zeit sind digitale Daten mit Raumbezug nicht mehr wegzudenken.
Zweifelsohne kommen wir in unserem täglichen Leben mit raumbezogenen Daten,
sogenannten Geodaten in Berührung.
Diese Daten können mit geeigneter Software (Geoinformationssystemen, kurz GIS)
erstellt, verarbeitet, analysiert und verbreitet werden. Das ermöglicht ein breites
Einsatzspektrum sowohl in der Industrie, Wirtschaft als auch in der Verwaltung.
Im Rahmen des studienbegleitenden Praxissemesters bei der Firma LISt Gesellschaft
für Verkehrswesen und ingenieurtechnische Dienstleistungen GmbH (LISt GmbH)
wurde ich erstmals mit den Themen Geodaten und Webservices konfrontiert. Dies war
für mich ein interessanter Blick über das an der Hochschule für Technik und Wirtschaft
Dresden (HTW – Dresden) vermittelte informationstechnische Wissen hinaus und hat
mein Interesse geweckt, weiter an diesem Thema zu arbeiten.
Mit der stetig wachsenden Nutzung von Geodaten und der bisher starren Infrastruktur
zum Austausch dieser, wird in Zeiten von schnelllebigen Technologien, Standards und
INSPIRE, der Einsatz monolithischer Informationssysteme durch serviceorientierte
Architekturen (SOA) abgelöst. Das bedeutet, dass die GIS Funktionalitäten hinsichtlich
Transformation, Darstellung und Verarbeitung von Geodaten nunmehr von
Webdiensten übernommen werden.
Mit der Einführung der Richtlinie INSPIRE und deren Umsetzung in nationales Recht
(Gesetz über das Geoinformationswesen im Freistaat Sachsen) wird der Grundstein zum
Aufbau von Geodateninfrastrukturen gelegt, wodurch auch Veränderungen innerhalb
der Sächsischen Straßenbauverwaltung (SBV) ausgelöst werden.
Als Dienstleister der SBV entwickelte sich die LISt GmbH in den letzten Jahren zu
einem modernen Dienstleistungsunternehmen. Im Rahmen der Sächsischen
1

1. Einleitung
Verwaltungs- und Funktionalreform im Jahr 2000 wurde der Betrieb des Sächsischen
Landesinstituts für Straßenbau 2001 auf die GmbH übertragen. So breit gefächert wie
die Aufgaben der Straßenbauverwaltung sind, so facettenreich ist auch das
Tätigkeitsspektrum der Gesellschaft. Es umfasst unter anderem die Weiterentwicklung,
das Führen von zentralen Fachverfahren sowie Kartographie und
Ingenieurvermessungen. Des Weiteren ist sie maßgeblich an der Entwicklung
fachspezifischer Konzeptionen für die SBV beteiligt.
Bisher wurden die Daten von der jeweils zuständigen Behörde je nach
Anwendungszweck in unterschiedlichen Datenmodellen gespeichert, was einen
Austausch bzw. eine Zusammenarbeit erschwerte.
Die Erkenntnis, dass sich die Arbeitseffizienz enorm steigern lässt, wenn die dezentral
vorliegenden Daten aus den unterschiedlichen Zuständigkeitsbereichen, wie z.B.
Verwaltung des Verkehrsnetzes, Erhaltung bzw. Unterhaltung von Ingenieurbauwerken,
Umweltschutz, etc. gemeinsam nutzbar sind, führt wiederum zu einem erheblichen
Interessenanstieg am Thema GDI.
1.2 Zielsetzung
Mit der stetigen Entwicklung neuer Technologien und Standards zur Nutzung und
Verbreitung von Geodaten ist der Aufbau einer Geodateninfrastruktur in der SBV
sinnvoll.
Mit der vorliegenden Diplomarbeit soll die Konzeption einer möglichen
Geodateninfrastruktur erfolgen. Die mögliche GDI soll zu bestehenden Fachverfahren
kompatibel und für zukünftige Fachverfahren vorbereitet sein. Es sollen dabei die
möglichen Komponenten für den Einsatz in der GDI getestet werden. Die gewonnenen
Erkenntnisse sollen als Grundlage für den prototypischen Aufbau dieser dienen.
Das bisherige dateibasierte Speichern von Geodaten soll dabei durch die
Implementierung einer Geodatenbank abgelöst werden. Im Rahmen der Arbeit sollen
sowohl kommerzielle als auch Open Source Produkte zur Anwendung innerhalb der
2

1. Einleitung
Geodateninfrastruktur kommen und zusätzlich auf produktive Einsatztauglichkeit
getestet werden.
1.3 Struktur der Arbeit
Im Folgenden werden der Aufbau und die Struktur dieser Arbeit beschrieben, wobei
zunächst die Grundlagen erläutert werden. Hierbei erfolgt eine Abgrenzung der Begriffe
Geoinformationssystem und Geodateninfrastruktur. Im Weiteren werden die
europäische Richtlinie INSPIRE sowie die Funktionsweise der zur Realisierung dieser
Arbeit eingesetzten Webservices vorgestellt.
Im nächsten Kapitel erfolgt die Analyse der Ausgangssituation der LISt GmbH. Es
werden dabei zunächst die bestehende Hardware untersucht und die eingesetzten
Techniken vorgestellt. Anschließend erfolgt die Analyse bestehender Fachverfahren und
Geodaten. Nach Darstellung der Ausgangssituation beginnt der aus zwei Teilen
bestehende Hauptteil dieser Arbeit.
Im ersten Teil wird ein Konzept einer möglichen Geodateninfrastruktur in der
Sächsischen Straßenbauverwaltung vorgestellt. Hierzu erfolgt zunächst eine
Beschreibung der Bestandteile sowie der Ausbaustufen des Konzepts. Anschließend
werden diese detailliert erläutert.
Die Umsetzung dieses Konzepts erfolgt im zweiten Teil. In diesem Kapitel wird die
Implementierung der Geodatenbank erklärt. Des Weiteren werden die zur Umsetzung
der Webservices eingesetzten Softwareprodukte vorgestellt.
In den letzten Kapiteln wird zunächst die vorliegende Arbeit zusammengefasst, bevor
anschließend ein Ausblick über künftige Erweiterungen des GDI Konzepts erfolgt.
3

2. Grundlagen
2 Grundlagen
2.1 Definition Geoinformationssystem
Bill/Fritsch (1994)[BILL]: „Ein Geo-Informationssystem ist ein rechnergestütztes
System, das aus Hardware, Software, Daten und den Anwendungen besteht. Mit ihm
können raumbezogene Daten digital erfasst und redigiert, gespeichert und reorganisiert,
modelliert und analysiert sowie alphanumerisch und grafisch präsentiert werden.“
Nach Meinung des Autors umfasst die Definition eines Geoinformationssystems nach
Bill/Fritsch die wesentlichen Bestandteile eines GIS (Hardware/Software/Daten) sowie
dessen Funktionalitäten und soll als Definitionsgrundlage für diese Arbeit dienen.
Sie stellt eindeutig dar, dass es sich bei einem GIS um ein alleinstehendes System
handelt, welches zum Erfassen, Bearbeiten, Präsentieren, Verwalten und Analysieren
von Geodaten dient. Die folgenden fachlichen Informationssysteme werden von GIS
Funktionalitäten unterstützt:
Landinformationssysteme (LIS),
Kommunale Informationssysteme (KIS),
Umweltinformationssystem (UIS),
Bodeninformationssystem (BIS) und
Fachinformationssystem (FIS).
Zur Entwicklung von komplexen Geoanwendungen und deren Funktionen wurden
durch die OGC diverse Standards verabschiedet. Hierzu zählt zum Beispiel die OGC
Normenreihe 191xx.
4

2. Grundlagen
2.2 Definition Geodateninfrastruktur
Der Begriff Geodateninfrastruktur ist ein Synonym für die englische Bezeichnung
Spatial Data Infrastructure (SDI). Im Folgenden sind zwei bekannte Definitionen zu
sehen, die die Inhalte einer GDI gut erkennen lassen, aber dennoch verschiedene
Sichtweisen beinhalten.
GROOT & McLAUGHIN (2000)[GROOT] zufolge „umfasst eine GDI einerseits
vernetzte Geodatenbanken und Funktionalitäten zum Umgang mit diesen Daten,
andererseits aber auch den Bereich der institutionellen, organisatorischen,
technologischen und wirtschaftlichen Ressourcen, die Entwicklung und Pflege der GDI
sowie den verantwortungsvollen Umgang mit den darin zur Verfügung stehenden
Geoinformationen unterstützen.“
RAJABIFARD (2002)[RAJA]: „Nutzer, Netzwerk, Regeln, Standards und Daten sind
grundlegende Bestandteile einer GDI, wobei das Konglomerat aus Netzwerk, Regeln
und Standards das eigentliche Vehikel darstellt, das den Nutzern den Zugang zu den
Daten ermöglicht - ohne, dass die Vielfalt der Anwendungszusammenhänge vorher oder
auch zum Zeitpunkt der Nutzung bekannt ist.“
Während in der Definition nach GROOT / McLAUGHIN primär die Funktionalitäten
erläutert werden, beschreibt RAJABIFARD die Bestandteile einer GDI.
Es ist daher festzuhalten, dass eine GDI ein komplexes Netzwerk zum Austausch von
Geodaten bezeichnet, d.h. es umfasst mehrere Geoinformationssysteme. Sie besteht aus
Geobasisdaten, Geofachdaten, standardisierten Diensten (Geodienste) und Clients.
Durch Einsatz einer Geodateninfrastruktur wird der Zugang zu Geodaten, die ansonsten
separat in den GIS der einzelnen Institutionen vorliegen, ermöglicht.
Neben der technischen Infrastruktur zur Bereitstellung der Daten benötigt eine GDI
fachliche Regelungen. Als Beispiel sei hier INSPIRE genannt.
5

2. Grundlagen
2.3 INSPIRE
Die Richtlinie INSPIRE steht für „Infrastructure for Spatial Information in Europe“
2007/2/EG des Europäischen Parlaments und des Rates zur Schaffung einer
Geodateninfrastruktur in der Europäischen Gemeinschaft (EG) vom 15. Mai 2007. Ziel
der INSPIRE-Richtline ist insbesondere die grenzüberschreitende Nutzung von Daten
(insbesondere der Umweltpolitik) im Wirtschaftsraum Europa. [i1]
Zur Umsetzung der Richtlinie wurden Durchführungsbestimmungen erlassen, in denen
unter anderem technische und fachliche Angelegenheiten wie
Metadaten,
Darstellungs- / Download- /Transformationsdienste und
einheitlich zu nutzende Datenschemen
geregelt sind.
Diese Bestimmungen sollen Interoperabilität ermöglichen und durch öffentliche
Verfügbarkeit der Daten Doppelarbeit vermeiden. Dies führt wiederum zu einer
Effizienzsteigerung und einer Reduzierung der Datenredundanz einschließlich der damit
verbundenen Kostensenkung zur Datenpflege. Damit verstärkt die INSPIRE Richtline
den Gedanken für den Aufbau von Geodateninfrastrukturen.
INSPIRE
GDI-DE
GDI der Bundesländer
Kommunale
GDI
GDI weiterer europäischer
Staaten
Abbildung 1: Struktur der europäischen GDI nach INSPIRE [vgl. i2]
6

2. Grundlagen
Bereits eingeführte und anerkannte, internationale, technische Standards des Open
Source Consortiums (OGC) oder der International Organization for Standardization
(ISO) bilden hierbei die Basis. Unter anderem werden die Standards ISO 19115, ISO
19119 und ISO 19142 eingehalten. Die betroffenen Geodaten, welche in digitaler Form
die Teile des Hoheitsgebiets der Bundesrepublik Deutschland abbilden und von einer
Behörde oder Dritten verbreitet werden, sind thematisch gegliedert (Annex I – III).
Des Weiteren beinhaltet die Richtlinie, wie in Abbildung 2 dargestellt, einen
umfassenden Zeitplan zur Anpassung der Metadaten und zur Implementierung der
benötigten Komponenten.
Abbildung 2: Zeitplan zur Umsetzung der INSPIRE Richtline [i3]
Gegenwärtig stehen nur sehr wenige Dienste und Metadaten öffentlich zur Verfügung,
wodurch die Einhaltung des offiziellen Zeitplans in Frage gestellt wird.
7

2. Grundlagen
2.4 Webservices
Nachfolgend werden die zum Aufbau der GDI nötigen Technologien definiert und
deren allgemeine Funktionsweise kurz vorgestellt. Alle genutzten Webservices sind
nach dem OGC standardisiert, welche wiederum auf der ISO-Normenfamilie 19100
basieren und somit die technische Vorgabe der INSPIRE-Richtlinie erfüllen. [vgl.i4]
Die nach INSPIRE geforderten Dienste lauten im Einzelnen:
Web Map Service (WMS),
Web Feature Service (WFS) sowie
Web Catalogue Service (CSW).
Neben den geforderten Diensten sind die folgenden Webservices für den Aufbau einer
GDI dennoch interessant:
Web Processing Service (WPS),
Web Coverage Service (WCS) und
Web Map Tile Service (WMTS).
2.4.1 WMS
Ein WMS liefert nach einer erfolgreichen HTTP-Anfrage einen statischen, visuellen
Kartenausschnitt in einem einfachen Rasterformat (z.B. jpeg oder png). Als Datenbasis
dienen dabei Raster- und Vektordaten. Diese können dateibasiert, in Datenbanken
gespeichert oder als Webservice (z.B. WFS, WMS) vorliegen.
Der OGC-konforme WMS-Server antwortet auf drei Anfragen:
GetCapabilities,
GetMap und
GetFeatureInfo,
8

2. Grundlagen
wobei mittels der GetCapabilities-Anfrage die Fähigkeiten des WMS, z.B. unterstützte
Dateiformate, vorhandene Layer, etc. geliefert werden. Durch den GetMap-Request
erfolgt die Abfrage eines Kartenausschnitts. Hier stehen zusätzlich diverse Parameter,
wie z.B. Kartengröße, der Kartenausschnitt, das Bildformat und die gewünschten
Kartenschichten, die sowohl Vektor- als auch Rasterdaten sein können, zur Verfügung.
Die optionale GetFeatureInfo-Anfrage liefert Angaben über eine im Kartenausschnitt
befindliche Position, wie z.B. Straßenname oder Stand der Daten. Die Funktionsweise
ist in Abbildung 3 dargestellt. [vgl. i5]
Internet
2.4.2 WFS
Client (Browser, MapInfo, …)
GetCapabilities
GetMap
GetFeatureInfo
Rasterdaten
Abbildung 3: Funktionsprinzip WMS
Im Gegensatz zum WMS liefert ein Web Feature Service Vektordaten. Ein WFS-Server
antwortet auf sechs verschiedene Anfragen:
GetCapabilities,
DescribeFeatureType,
GetFeature,
GetGmlObject,
Transaction und
LockFeature.
WMS
statischer
Kartenausschnitt
Vektordaten
9

2. Grundlagen
Die Datenbasis bilden Vektordaten, die sowohl als Datei als auch in Form einer
Datenbank vorliegen können. Analog zum WMS liefert GetCapabilities die möglichen
Anfragen des Services. Die Struktur der Geodaten wird auf die DescribeFeatureType-
Anfrage als XML-Dokument ausgeliefert. Einzelne Instanzen der Geodaten werden
durch die GetFeature-Anfrage übertragen.
Beinhaltet ein WFS-Server die oben beschriebenen drei Services, so nennt man ihn
einen Basic WFS-Server. Unterstützt er weiterhin die GetGmlObject 1 -Anfrage, wird
dieser als XLink 2 WFS bezeichnet. Die Transaction- und LockFeature-Anfrage dienen
zur Bereitstellung von Transaktionen, welche im Mehrnutzerbetrieb bei schreibendem
Zugriff benötigt werden. Hierbei dient die Transaction-Abfrage zur eigentlichen
Datenoperation. Die LockFeature-Anfrage hingegen dient der Sperrung eines
Datensatzes für die jeweilige Transaktion, um den parallelen Datenzugriff einer anderen
Instanz zu verhindern. Werden sowohl Funktionen des Basic-, des XLink-WFS und
zusätzlich die Transaction- und LockFeature-Anfrage unterstützt, spricht man vom
Transaction-WFS (WFS-T). Die Funktionsweise des WFS-(T) ist in Abbildung 4
dargestellt. [vgl. i5]
Internet
GetCapabilities
DescribeFeatureType
GetFeature
GetGmlObject
Transaction
LockFeature
Abbildung 4: Funktionsprinzip WFS
Client (Browser, MapInfo, …)
WFS
Vektordaten
XML-Dokument
1
Die GetGmlObject - Anfrage benötigt zwingend den Primärschlüssel (ObjectId) und liefert als Ergebnis
eine GML (Geo Markup Language) Datei mit einzelnen Elementinstanzen (z.B. nur die Geometrie).
2
XLink ist eine attributbasierte Syntax zur Definition von Links in XML-Dokumenten.
10

2. Grundlagen
2.4.3 CSW
Im Gegensatz zum WMS und WFS dient der Web Catalogue Service nicht zur
Auslieferung oder Bearbeitung der Geodaten.
Der CSW enthält Metadaten über verfügbare Geodaten und Dienste. Die Auswahl wird
über eine in der GDI vorhandene Suchmaschine – GeoMIS genannt – durchgeführt.
Die Abkürzung GeoMIS bedeutet Geomatik Metadaten-Informations-System. Ein
GeoMIS ist als Vermittler von Geodaten und Geodiensten zu betrachten. Zur
Vermittlung des gewünschten Dienstes bzw. der Geodaten greift das GeoMIS auf
Informationen der zur Verfügung stehenden CSW zurück. [vgl. i5]
2.4.4 WPS
Ein weiterer für das GDI Konzept interessanter, aber in der INSPIRE Richtlinie nicht
berücksichtigter Service ist der von der OGC verabschiedete Web Processing Service.
Durch den WPS können auf dem Server bereitliegende Programme (Prozesse) von
einem anderen Standort ausgeführt werden. Zur Verfügung gestellte Funktionen können
räumliche, thematische, und zeitliche Analysen bzw. Operationen durchführen. Hierbei
stehen folgende Anfragen zur Verfügung:
GetCapabilities,
DescribeProcess und
Execute.
Mittels GetCapabilities wird Auskunft über alle verfügbaren Prozesse gegeben.
Detaillierte Informationen (ein- und ausgehende Variablen) über einen einzelnen
Prozess ermöglicht die DescribeProcess-Anfrage. Zur Ausführung des gewünschten
Prozesses dient der Execute-Befehl. [vgl. i5]
11

2. Grundlagen
2.4.5 WCS
Durch den Einsatz eines Web Coverage Services wird die clientseitig, Semantik
gerechte Weiterverarbeitung von Rasterdaten ermöglicht. Ein WCS liefert wie der
WMS Rasterdaten, allerdings liegen die Geodaten in einem raumbasierten Datenmodell
vor.
WCS kann somit als „Geschwisterstandard“ des Web Feature Service (WFS) für
Rasterdaten bezeichnet werden, da keine statischen Bilder (WMS), sondern einzelne
Features geliefert werden. Damit erlaubt der WCS komplexe Anfragen zu digitalen
Geländemodellen, Dreiecksvermaschungen, aber auch einfachen Luftbildern. Anstelle
von GetMap wird die Operation GetCoverage genutzt.
Die bereitgestellten Formate sind unter anderem GML und GeoTIFF. [vgl. i5]
2.4.6 WMTS
Der OGC WMTS bildet einen Standard zum Zwischenspeichern von Kartendiensten
(WMS, WCS). Er soll künftig die nicht standardisierten Tile Caches ersetzen.
Im Gegensatz zu den Tile Caches, bei denen die Bildpyramide mit der Ausdehnung der
Karte bzw. Layer gekoppelt ist, wird dies im WMTS getrennt gespeichert. Die
Bildpyramide ist ein räumliches Konstrukt mit einer festen Ausdehnung, einer
geographischen Projektion sowie mehreren Maßstäben. Die Karten, welche in kleinere
vordefinierte Bildausschnitte (Kacheln) zerlegt sein können, werden anschließend in
diesem Gerüst positioniert. Die einzelnen Kacheln werden dabei nicht mehr vom
Server, sondern vom Client verwaltet, d.h. der Client fordert diese an, stellt sie in einem
HTML Dokument dar und löscht diese nach Verlassen wieder.
Der Vorteil gegenüber einem Tile Cache besteht darin, dass weitere Webservices dieses
Gerüst nutzen, wodurch diese besser überlagert werden können.
12

2. Grundlagen
Durch den Einsatz eines WMTS werden analog zum Tile Cache Daten
zwischengespeichert, wodurch zum einen die Abfragen beschleunigt und zum anderen
die genutzten Webservices entlastet werden. [vgl. i5]
Das Zusammenwirken der vorgestellten Dienste ist in der nachfolgenden Grafik
dargestellt. Im Einzelnen sind die vorgestellten Webservices, deren Datenspeicher
(sowohl Raster- als auch Vektordaten) sowie die Clients abgebildet.
Abbildung 5: Zusammenarbeit der Services
13

3. Ausgangssituation in der LISt GmbH
3 Ausgangssituation in der LISt GmbH
3.1 Technische Grundlagen
3.1.1 Verfügbare Hardware
Während der Erstellung dieser Arbeit erfolgte eine Sichtung der bestehenden Hardware
in der LISt GmbH. Die Vielzahl von Servern dient in erster Linie zur Erfüllung der
Aufgaben als Dienstleister. Für die Realisierung des prototypischen Aufbaus der GDI
wurden ein Server Blade sowie ein Arbeitsplatzrechner verwendet. Das Server Blade ist
ein Modul des Blade Servers. Wie in Abbildung 6 ersichtlich, besteht ein Blade Server
aus einem Gehäuse (Blade Center), welches wiederum die einzelnen Server (Server
Blades) beinhaltet.
Abbildung 6: Aufbau eines Blade Servers [i6]
Blade Center
Server Blade
Das Gehäuse stellt dabei Stromanschlüsse, Kühlung, Netzwerkanschlüsse sowie eine
Management-Oberfläche für die einzelnen Server Blades zur Verfügung.
Dieser modulare Aufbau bietet den Vorteil, dass der Blade Server einfach erweitert
werden kann. Das eingesetzte Server Blade ist mit je zwei Quadcore Intel Ceon E5400
mit einer Taktung von 4x2.83 GHz ausgestattet und verfügt über einen Arbeitsspeicher
von 32 GB. Die Speicherung der Daten erfolgt auf dem über Glasfaser angebundenen
Storage Center.
Der eingesetzte Desktop-PC verfügt über einen Intel i7 @2.8 GHz Prozessor sowie 4
GB RAM, sowie einer S-ATA Festplatte von 1 TB Speicher.
14

3. Ausgangssituation in der LISt GmbH
Weitere bestehende Server sowie der Aufbau der internen Netzwerkstruktur können
dabei vernachlässigt werden und werden somit nicht explizit aufgeführt.
3.1.2 Verwendete Techniken
Zur Umsetzung der benötigten Server wird auf die Technologie der Virtualisierung
zurückgegriffen. Ein wesentlicher Vorteil gegenüber der nativen Installation der Server
ist die Snapshot Technologie, welche sowohl das Speichern als auch das Laden von
Zuständen virtueller Maschinen ermöglicht. Somit ist es möglich, vor einer
Funktionserweiterung des virtuellen Servers einen Snapshot zu erstellen, der im
unerwarteten Fehlerfall wiederhergestellt werden kann. Eine Neuinstallation des
gesamten Servers wird dadurch vermieden.
Die virtuellen Server können zu Test- und Installationszwecken auf dem am
Arbeitsplatz vorhandenen Desktop-Rechner erstellt und konfiguriert werden, bevor sie
im Anschluss auf die Blade Server integriert werden. Die auf den Blade Servern im
Einsatz befindliche Software VMWare ermöglicht den parallelen Betrieb mehrerer
virtueller Maschinen auf einem physischen Server. Dies führt zur optimalen
Ausnutzung der vorhandenen Rechenleistung.
Durch den Einsatz dieser Hard- und Softwarekomponenten können Datenreplikation,
Hardware-Unabhängigkeit, Ausfallsicherheit und Verfügbarkeit gewährleistet werden.
Sie stellen somit keinen weiteren Bestandteil dieser Arbeit dar.
3.2 Analyse bestehender Fachverfahren und Geodaten
Geodaten werden in zwei Kategorien eingeteilt: Raster- und Vektordaten. Rasterdaten
bestehen aus Rasterpunkten, die in der Regel quadratisch und gleich groß sind.
Typische Vertreter sind unter anderem digitale Orthophotos, Satellitenbilder,
Luftaufnahmen und Geländehöhenmodelle. Im Gegensatz zu Rasterdaten beinhalten
Vektordaten keine Rasterpunkte sondern geometrische Primitiva wie zum Beispiel
15

3. Ausgangssituation in der LISt GmbH
Punkte, Linien oder Flächen zur Beschreibung des jeweiligen Sachverhalts. Dies
wiederum ermöglicht ein breites Anwendungsspektrum. Raster- und Vektordaten
können somit landschaftliche Umrisse wie Straßen, Wege oder politische Grenzen
(Bundes-, Landes-, Landkreisgrenzen) abbilden.
Viele in der Straßenbauverwaltung genutzte Fachverfahren haben bereits einen Bezug
zu Geodaten. Hierzu zählen:
TT-SIB ® ,
FIS-Baum,
FIS-Art,
KISS/KoKa-Nat und
ProUI.
Die TT-SIB ® ist eine Straßeninformationsbank auf Grundlage der „Anweisung
Straßeninformationsbank“ (ASB) und dient der Verarbeitung von
vermessungstechnischen Daten nach einem objektorientierten Prinzip und deren
Visualisierung in einem geographischen Informationssystem (MapInfo). Des Weiteren
können über das Webauskunftssystem TT-SIB ® INFOSYS die Daten der TT-SIB ®
kartenbasiert dargestellt werden. Funktionen zur Analyse der Sachdaten stehen ebenfalls
zur Verfügung.
Die Fachanwendung FIS-Baum ermöglicht die Durchführung und Dokumentation von
Regelkontrollen und Maßnahmenplanungen des Baumbestandes am klassifizierten
Straßennetz im Freistaat Sachsen. Seit 2010 ist die Verwaltung von objektbezogenen
Maßnahmen (Bäume auf Grundstücken des Freistaats Sachsens) ebenfalls möglich. Als
Planungs-, Bearbeitungs- und Verwaltungswerkzeug von Artenschutzmaßnahmen im
Geltungsbereich der Straßenbauverwaltung des Freistaats Sachsen wird FIS-Art genutzt.
Die Fachanwendung KISS dient der Verwaltung von Kompensationsmaßnahmen für die
Straßenbauverwaltung (SMWA). Zur Verwaltung von Kompensationsflächen im
Rahmen des Naturschutzes für das Ministerium für Umwelt und Landwirtschaft
(SMUL) dient KoKa-Nat (Ökokontoverordnung).
Die Anwendung ProUI wird zur Kosten- / Leistungserfassung für den
Straßenbetriebsdienst eingesetzt.
16

3. Ausgangssituation in der LISt GmbH
In den Fachverfahren werden ausschließlich Vektordaten bearbeitet. Diese nutzen je
Fachverfahren und Einsatzzweck unterschiedliche Geometrien. Es werden einfache
geometrische Primitiva wie Punkte (Bäume) oder Linien (Straßen und Wege) sowie
komplexere Polygone (Flurstücke, Kompensationsflächen) genutzt. Die Speicherung
der zugehörigen geometrischen Daten erfolgt auf unterschiedlichen Wegen.
Die zukünftig favorisierte Lösung ist die Ablage der Geodaten in einer Oracle Spatial
Fachdatenbank. Alte Fachverfahren hingegen benutzen die Software MapInfo der Firma
Pitney Boweys. Dieses GIS wird bisher nur zur dateibasierten Speicherung von
Geodaten eingesetzt. Die abgespeicherten Dateien werden den Sachbearbeitern über
einen Windows Datei-Server zentral bereitgestellt. Durch die dateibasierte Speicherung
entstehen jedoch wesentliche Nachteile im Zugriffsschutz und Mehrnutzerbetrieb.
Sowohl die zeitlich parallele Bearbeitung der gleichen Datei durch zwei Nutzer als auch
die Sperrung einzelner Datensätze vor einem einzelnen Benutzer sind nicht möglich.
Die Praxis in den Fachverfahren KISS/KoKa-Nat zeigt, dass bei parallelem Zugriff nur
der erste Nutzer Schreibrechte und jeder folgende Nutzer maximal Leserechte erhalten
kann. Der Datenzugriff in den Fachanwendungen FIS-Baum, FIS-Art und ProUI erfolgt
mittels eingebetteter SQL-Befehle. Die Anwendungen TT-SIB ® und FIS-Baum wurden
bereits um einen OGC-konformen WFS und WMS erweitert. Die Ausgangssituation in
der LISt GmbH ist in Abbildung 7 dargestellt.
17

3. Ausgangssituation in der LISt GmbH
Abbildung 7: Ausgangssituation in der LISt GmbH
Des Weiteren liegen digitale Orthophotos als Datenbasis für einen künftigen WMS zur
Auslieferung von Luftbildern analog zum WMS des Staatsbetriebes
Geobasisinformation und Vermessung Sachsen (GeoSN) vor. Die Rasterdaten wurden
von GeoSN bereitgestellt und liegen original im GeoTIFF Format vor. Zur Reduzierung
des benötigten Speicherbedarfs wurden sie in das ECW Format konvertiert. Sie
umfassen jeweils einen Ausschnitt von zwei Quadratkilometern. Die Bildgröße beträgt
10.000 mal 10.000 Pixel, was einer rechnerischen Auflösung von 20 cm/Pixel
entspricht. Bei den vorliegenden Daten handelt es sich um Orthophotos des Freistaats
Sachsen, die in regelmäßigen Abständen gebietsweise aktualisiert werden.
18

4. Konzept einer möglichen Geodateninfrastruktur der SBV
4 Konzept einer möglichen Geodateninfrastruktur der SBV
4.1 Einführung
Im folgenden Kapitel wird ein mögliches Architekturkonzept für die GDI-SBV
vorgestellt. Die Beschreibung bezieht sich auf die im Anhang beigefügte Abbildung A1.
Die in Abbildung A1 enthaltenen Begriffe sind im Text zur besseren Orientierung in
Bezug zur Grafik kursiv gedruckt.
Das Konzept beinhaltet zwei Ausbaustufen: die erste Ausbaustufe umfasst
grundlegende Bestandteile der GDI, deren Aufbau priorisiert werden sollte. Die zweite
Stufe enthält weitere Komponenten, deren Einsatz einen erheblichen Mehrwert in
Bezug auf die Datenverarbeitung bieten, jedoch vorerst nicht zwingend nötig sind.
Die Infrastruktur ist in drei Komplexe aufgeteilt:
Produktion,
INSPIRE und
Entwicklungs- und Testumgebung,
Jeder dieser Komplexe ist wiederum horizontal in drei Abschnitte gegliedert. Die Basis
dieser Geodateninfrastruktur bilden die Geodaten, die sowohl als Datei als auch in Form
einer Datenbank vorliegen können. In Abbildung A1 sind die Daten in jeder Säule als
unterste Ebene dargestellt. Die mittlere Ebene jeder Säule bilden Webservices, welche
der Datenaufbereitung, Datenweiterverarbeitung und der Datenauslieferung dienen. Die
im oberen Teil der Säulen dargestellten Clients können durch Nutzung der Webdienste
die Geodaten verarbeiten. Die Clients wiederum können von Mitarbeitern im Intranet
der SBV, im Sächsischen Verwaltungsnetz (SVN) und im Kommunalen DatenNetz
(KDN) verwendet werden. Zu den Nutzern gehören unter anderem Mitarbeiter
des Autobahnamtes Sachsen (ABA),
der Landesdirektionen,
der Straßenbauämter und
der Landkreise mit Straßenmeistereien.
Im Folgenden werden die einzelnen Komplexe der GDI näher betrachtet.
19

4. Konzept einer möglichen Geodateninfrastruktur der SBV
4.2 Beschreibung des Produktionskomplexes
4.2.1 Erste Ausbaustufe
Der Produktionszweig des GDI Konzepts ist als mittlere Säule in Abbildung A1
dargestellt.
Datenbasis
Grundlage dieses Zweiges ist die Datenbasis, die aus zwei Teilen besteht:
die durch GeoSN gelieferten dateibasierten Geobasisdaten und den
Datenbankmanagementsystemen.
Die Geobasisdaten sind thematisch wie folgt untergliedert:
Daten nach der AAA Datenmodellierung:
• ATKIS (Amtliches Topographisch-Kartographisches Informations-
system ),
• ALKIS (Amtliches Liegenschaftskataster-Informationssystem),
• AFIS (Amtliches Festpunktinformationssystem) sowie
sonstige Daten.
Das bundesweit einheitliche System ATKIS dient dem Erfassen digitaler
geotopographischer Informationen. Es stellt die öffentlich-rechtliche Datenbasis für die
Anbindung geothematischer Fachdaten dar. Zu den bereitgestellten digitalen
Erdoberflächenmodellen gehören Digitale Geländemodelle (DGM), Digitale
Landschaftsmodelle (DLM), Digitale Topographische Karten (DTK) und Digitale
Orthophotos (DOP). Die Daten der bisherigen Verfahren ALK (Automatisierte
Liegenschaftskarte) und ALB (Automatisiertes Liegenschaftsbuch) werden in ALKIS zu
einem gemeinsamen Datenbestand gebündelt. Festpunkte werden im Amtlichen
Festpunktinformationssystem (AFIS) verwaltet. [vgl. i7, VERM]
In der Kategorie sonstige sind weitere Themen, die nicht Bestandteil des AAA-
Datenmodells sind, und für zukünftig neu anfallende Aufgaben genutzt werden,
enthalten. Hierzu gehören z.B. Umweltdaten, historische Karten, Lasermesspunkte
sowie 3D-Gebäudemodelle.
20

4. Konzept einer möglichen Geodateninfrastruktur der SBV
Den zweiten Teil der Datenbasis bilden die Datenbankmanagementsysteme. Diese
werden in Fachdatenbanken (TT-SIB ® , FIS-Baum, FIS-Art, ProUI, eGovernment) und
in die neu entwickelte Geodatenbank für Kartographie und klassische Fachverfahren
(KISS/KoKa-Nat) eingeteilt. Diese neu entwickelte Datenbank dient der Speicherung
der ursprünglich dateibasierten Geodaten. Vorteil des Einsatzes einer Datenbank,
anstelle der dezentralen, dateibasierten Speicherung, ist der Mehrnutzerbetrieb. Die
manuelle Aufspaltung, Verteilung, anschließende Sammlung und Synchronisation von
Datenbeständen kann somit entfallen. Ein wichtiger Bestandteil dieser Arbeit ist die
Implementierung eines Zugriffsschutzes. Dieser soll die Schreibrechte zwischen
einzelnen Datensätzen und einem Nutzer organisieren. Die Verteilung der Rechte soll
dabei analog zur bisher erfolgten Aufteilung in einzelne Dateien erfolgen. Die
entstandene Geodatenbank beinhaltet damit die ursprünglich als MapInfo TAB Dateien
vorliegenden Geodaten der Fachanwendungen TT-SIB ® , KISS und KoKa-Nat.
Der Datenzugriff der Fachanwendungen erfolgt nach dem Client-Server-Prinzip durch
eingebettete SQL-Befehle.
Webservices
Als interoperabler Baustein, der zur Auslieferung von Geodaten der Fachanwendungen
dient, werden OGC-konforme WFS-T eingesetzt. Die WFS können lokal auf dem
Datenbank-Server installiert werden, was zur Reduzierung des Datenverkehrs und damit
zu einer Geschwindigkeitssteigerung führt. Zum Schutz vor Überlastung (Denial of
Service) können die WFS-T bei steigender Anzahl von Nutzern und Daten jeweils
separat auf einem extra Server installiert werden. Hierdurch wird bei Ausfall eines
WFS-T der Betrieb der übrigen Dienste gewährleistet.
Um die Visualisierung von gelieferten Fremddaten in der eigenen Fachanwendung zu
ermöglichen wird ein WMS eingesetzt. Dieser bezieht seine Daten von den WFS-T
fremder Fachanwendungen und stellt deren Datenbestand in Form von statischen
Bildern (jpeg, png) dar. Zur Reduzierung der Antwortzeit des WMS wird zusätzlich ein
WMTS als Proxy eingesetzt, d.h. alle Anfragen erfolgen zunächst an den WMTS. Ist
kein entsprechender Eintrag im WMTS vorhanden, leitet dieser die Anfrage an den
WMS weiter und speichert dessen Antwort zwischen.
21

4. Konzept einer möglichen Geodateninfrastruktur der SBV
Ein wesentlicher Bestandteil der GDI ist die Bereitstellung der digitalen Orthophotos als
WMS (DOP SBV). Durch die Einführung des DOP SBV ist die Nutzung von Luftbildern
auch während der Ausfallzeiten des WMS von GeoSN gewährleistet. Zusätzlich wird
eine weitere Inkarnation dieses WMS, welcher auf tragbaren Geräten zur offline-
Nutzung verfügbar ist, entwickelt. Ein wesentlicher Aspekt, nämlich die Nutzung im
Außendienst, ist somit gewährleistet.
Clients
Durch den Einsatz der beschriebenen Webservices ist es möglich, diese in die
jeweiligen Fachanwendungen einzubinden. Weiterhin besteht die Möglichkeit
Webservices fremder Fachanwendungen als Ebene in die eigene Fachanwendung
einzubinden, wodurch Synergieeffekte entstehen. Die Nutzung weiterer Desktop-GIS,
die beschriebene Webservices unterstützen, ist ebenfalls möglich.
Arbeitsplatz für Geodatenmanagement
Eine Besonderheit des Produktionszweigs ist der „Arbeitsplatz für
Geodatenmanagement“. Nutzern dieses Arbeitsplatzes stehen alle Daten und Dienste in
der GDI-SBV zur Verfügung. Der Arbeitsplatz wird zur Erfüllung mehrerer
fachspezifischer Aufgaben eingesetzt. Diese sind unter anderem:
Konvertierung erhaltener Geodaten,
Synchronisation neuer, dateibasierter Datenlieferungen mit dem vorhandenen
Datenbestand,
Erstellung von Metadaten, d.h. Informationen über vorhandene Dienste und
Geodaten,
Test neuer Verfahren sowie Dokumentation der Ergebnisse,
Erstellung von automatisierten Datentransformationsroutinen sowie
nicht automatisierbare Auswertung von Geodaten und deren Zusammenhänge.
Zur Erfüllung dieser Aufgaben enthält dieser Arbeitsplatz das Datentransformations-
Tool Feature Manipulation Engine (FME) der Firma Safe Software, sowie verschiedene
GIS Clients. Die FME ermöglicht hierbei lesenden und schreibenden Datenzugriff auf
über 200 verschiedene Datenformate, eine schnelle Konvertierung zwischen den
Datenformaten sowie eine Prozessierung von Geodaten durch den Aufbau von FME
Workbenches.
22

4. Konzept einer möglichen Geodateninfrastruktur der SBV
4.2.2 Zweite Ausbaustufe
Datenbasis
Bisher erfolgte der Import bzw. Export der Daten aus den einzelnen Fachdatenbanken,
die nach dem Objektkatalog für das Straßen- und Verkehrswesen (OKSTRA®)
standardisiert sind, dateibasiert. [i8]
In der zweiten Ausbaustufe wird der Datenzugriff der Fachdatenbanken um
Webservices erweitert, d. h. es werden spezielle OKSTRA ® Webservices (OKWS)
benötigt, da die komplexe Datensemantik der OKSTRA ® -konformen Daten nicht durch
einen OGC-konformen Webservice darstellbar ist. Das Konzept der OKWS sieht vor,
dass diese als öffentliche Schnittstelle zum Datenaustausch zwischen den Verwaltungen
dienen. Für die OKWS existierten zum Zeitpunkt dieser Arbeit keine Softwarelösungen.
Webservices
Weiterhin werden zur Verarbeitung der Geodaten oder zum Aufbau neuer
Dienstleistungen der FME Server und ein WPS eingesetzt. Aufgabe dieser
Verarbeitungsdienste ist beispielsweise die Analyse, Transformation oder
Verschneidung von Geodaten. Der FME Server kann hierbei Aufgaben, die in der FME
am „Arbeitsplatz für Geodatenmanagement“ erstellten FME Workbenches,
automatisiert abarbeiten und diese als Webservice ausliefern. Die Verarbeitungsdienste
nutzen die Datenquellen WFS-T und dateibasierte Daten. Die verarbeiteten Daten
werden entweder an die Webservices WMS und WMS-SBV oder an einen
Generalisierungsdienst weitergeleitet. Aufgabe des Generalisierungsdienstes ist es,
einzelne Sachverhalte in Abhängigkeit vom gewählten Maßstab der Karte, vereinfacht
bzw. verallgemeinert wieder auszugeben. [vgl. i9] Positiver Nebeneffekt ist die
Reduzierung des Datenverkehrs. Weiterhin wird zur Optimierung ein WFS Cache
eingeführt. Der WFS Cache funktioniert analog dem WMS Cache, d.h. er reduziert die
Antwortzeit des WFS und entlastet diesen zugleich. Zur Verarbeitung von Rasterdaten
wird ein Web Coverage Dienst verwendet. Der WCS ermöglicht im Gegenteil zum
WMS die semantikgerechte Auslieferung von Rasterdaten, d.h. es werden anstelle von
statischen Bildern eines Kartenausschnittes die basierenden Rasterdaten des Ausschnitts
übertragen.
23

4. Konzept einer möglichen Geodateninfrastruktur der SBV
Clients
Des Weiteren werden die Clients um das Geoportal SBV erweitert. Das Geoportal lässt
sich über den Webbrowser nutzen. Die Nutzer könnten sowohl Mitarbeiter der SBV,
Landkreise, Meistereien sowie die Öffentlichkeit sein. Durch den Einsatz eines
Geoportals kann der Datenzugriff auch ohne Fachanwendung erfolgen, d.h. dem Nutzer
werden fachspezifische Informationen über dieses Portal im Webbrowser bereitgestellt.
Positiver Nebeneffekt ist die Entlastung der Administratoren, da keine zusätzliche
Software benötigt wird und das Portal nicht lokal installiert werden muss. Dem Nutzer
wird dabei eine übersichtliche GUI zur Verfügung gestellt, die nach seinen eigenen
Wünschen personalisiert werden kann, wie z.B. Zoomstufe, Kartenausschnitt,
Ebenendarstellung, Ebenenreihenfolge. Weiterhin stellt das Geoportal Such- und
Analysefunktionen online bereit, wodurch den Nutzern einfache
Recherchemöglichkeiten über den verteilt vorliegenden Geodatenbestand angeboten
werden.
Zusätzlich kann das Geoportal öffentlich bereitgestellt werden, wodurch die Bürger auf
die Daten der Straßenbauverwaltung zugreifen können. Damit ergibt sich beispielsweise
ein Mehrwert hinsichtlich der Auskunft über Baumaßnahmen, Straßensperrungen,
Unfälle oder Umleitungen.
Arbeitsplatz für Geodatenmanagement
Der im „Arbeitsplatz für Geodatenmanagement“ neu eingeführte Web Catalogue
Service (CSW) dient der Speicherung und Auslieferung von Metadaten, welche in der
ersten Ausbaustufe von Mitarbeitern manuell in den CSW des GeoSN eingetragen
wurden. Durch die Einführung dieses Dienstes kann die benötigte Synchronisation der
Metadaten mit dem CSW des GeoSN automatisiert erfolgen. Des Weiteren wird dieser
Arbeitsplatz um die OKSTRA ® ETL 3 Tools erweitert. Diese bestehen aus dem
Objektbrowser und diversen Prüfprogrammen. Die Programme stellen die syntaktische
und semantische Korrektheit der Daten sicher. Der Objektbrowser hingegen wird zur
Anzeige der einzelnen Datensätze genutzt.
3 ETL: Extract, Transform, Load ist ein Prozess, der Daten aus unterschiedlich strukturierten
Datenquellen in einer Zieldatenbank zusammenführt.
24

4. Konzept einer möglichen Geodateninfrastruktur der SBV
Eine wesentliche Erweiterung ist die Einführung des ArcGIS Servers. Dieses Produkt
vereint dabei wesentliche GIS Funktionalitäten, wodurch keine weiteren
Softwarewerkzeuge benötigt werden. Der Nutzer kann dabei auf einfache und schnelle
Weise Geodaten verarbeiten. Zu den Anwendungsgebieten gehören beispielsweise:
einfaches Datenmanagement umfangreicher Datenbestände (Vektor- /
Rasterdaten),
unkomplizierte Erstellung von browserbasierten Anwendungen,
integrierte Editierwerkzeuge im Browser,
umfangreiche Analysefunktionen für Geodaten (Erstellung, Organisation und
Visualisierung von Zeitbezügen für Geodaten),
Entwicklung mobiler GIS Anwendungen sowie
einfache Realisierung von Webservices (WMS, WCS, WFS, WFS-T).
Der größte Vorteil der ArcGIS-Produktfamilie ist, dass die Mitarbeiter nicht über eine
Vielzahl von Software verfügen müssen, sondern durch die Kompatibilität der Produkte
zeitsparend Daten verarbeiten können. [i10]
25

4. Konzept einer möglichen Geodateninfrastruktur der SBV
4.3 Beschreibung des INSPIRE Komplexes
4.3.1 Erste Ausbaustufe
Datenbasis
Zur Bereitstellung der INSPIRE-konformen Geodaten dienen die Fachdatenbanken als
Datenbasis. Da diese in einem nicht INSPIRE-konformen Datenschema vorliegen,
müssen diese zunächst in ein solches überführt werden. Zu diesem Zweck wird die im
„Arbeitsplatz für Geodatenmanagement“ vorhandene FME eingesetzt. Zur
Datenüberführung wird eine sogenannte Workbench erstellt. Diese bildet die
Prozessierung von Geodaten ab. Bei fehlerfreier Funktion soll dieser Prozess Skriptbasiert
ausgelagert werden.
Webservices
Die öffentliche Bereitstellung der Daten wird durch Einsatz eines WFS und eines WMS
ermöglicht. Der WMS bezieht seine Daten vom beschriebenen INSPIRE WFS und stellt
diese der Öffentlichkeit zur Verfügung. Die nach dem „Gesetz über den Zugang zu
digitalen Geodaten“ [i11] bzw. „Gesetz über das Geoinformationswesen im Freistaat
Sachsen“[i12] geforderte qualitative, öffentliche Bereitstellung ist somit erfüllt. Zur
Erfüllung der quantitativen Anforderungen ist es sinnvoll, diese über eine zentrale
Plattform bereit zu stellen.
4.3.2 Zweite Ausbaustufe
Datenbasis
Die in der ersten Ausbaustufe erstellten Transformationsskripte können analysiert und
durch die Entwicklung eigener Skripte auf der Basis geeigneter Open Source
Bibliotheken, wie beispielsweise GeoTools, erstellt werden.
26

4. Konzept einer möglichen Geodateninfrastruktur der SBV
Webservices
In der zweiten Ausbaustufe wird sowohl der Erhalt als auch der Versand von INSPIRE
Daten zwischen einzelnen INSPIRE Daten haltenden Stellen umgesetzt. Die
Auslieferung der Daten an externe INSPIRE Datenbank-Server erfolgt dabei durch
einen INSPIRE Synchronisations Service (ISS)-Server. Dieser agiert analog zu einem
WFS, besitzt jedoch eine Protokollerweiterung zur Regelung der Datensynchronisation.
Der ISS-Server bearbeitet beispielsweise die Anfrage über geänderte Daten seit einem
beliebigen Zeitpunkt und überträgt anschließend die Ergebnisse. Zum Erhalt von
INSPIRE Daten wird ein ISS Client als Gegenstück eingesetzt. Die durch den Client
angeforderten Daten werden an die FME bzw. Skripte übergeben. Diese entscheiden,
welche der übertragenen Daten letztlich in den eigenen INSPIRE Datenbestand oder in
die Fachdatenbanken importiert werden.
Aus Optimierungsgründen wird der WFS analog dem Produktionszweig an einen
Generalisierungsdienst gekoppelt.
Für den beschriebenen Generalisierungsdienst und den INSPIRE Synchronisations
Service (Client und Server) existierte zum Zeitpunkt der Arbeit keine geeignete
Softwarelösung.
4.4 Beschreibung der Entwicklungs- und Testumgebung
Die dritte Säule stellt die Entwicklungs- und Testumgebung dar. Diese bildet einen
wesentlichen Bestandteil der GDI, da alle Clients und Services des Produktions- und
INSPIRE Zweiges vor ihrem produktiven Einsatz in diesem Pfad entwickelt und
getestet werden. Wesentlich ist, dass die Entwicklungs- und Testumgebung vom
Produktionszweig abgegrenzt ist, d.h. eventuelle Misserfolge wirken sich nicht auf die
Produktion aus. Den Entwicklern stehen für alle Webservices verschiedene
Softwarelösungen zur Verfügung. Zusätzlich können sie auf eine mit allen gängigen
Frameworks vorinstallierte Testumgebung zur Entwicklung eigener Webservices und
Clients zugreifen. Als Testdaten dienen hierbei Kopien der Produktionsdaten. Neben
den Datenbanken stehen diverse Dateiformate zum Test zur Verfügung.
27

4. Konzept einer möglichen Geodateninfrastruktur der SBV
4.4.1 Verwendete Dateiformate
Im Folgenden sind alle Formate, die in der LISt GmbH und der SBV zur Erfüllung ihrer
Aufgaben eingesetzt werden, aufgelistet [vgl. i13]:
ESRI
Shapefile
Beschreibung
Dateisammlung besteht mindestens aus DBF, SHP, SHX
DBF dBASE Format zur Speicherung von Sachdaten
SHP Speicherung von Geometriedaten
SHX Geometrieindex
PRJ Projektion
Personal
GDB
MS Access basiert, Speicherung von Vektordaten
File GDB Speicherung von Raster- und Vektordaten
Tabelle 1: ESRI Dateiformate
MapInfo
Tab-Datei
Beschreibung
Dateisammlung besteht mindestens aus: TAB, DAT, IND, MAP
TAB Definition von Datenstrukturen und Metadaten
DAT Speicherung der Datenstrukturen (dBASE IV Format)
IND Geometrieindex
MAP Speicherung von Geometriedaten
MIF/MID MapInfo Interchange Format, genutzt für Daten Im- / Export
Tabelle 2: MapInfo Dateiformate
AutoCAD
Beschreibung
DXF Drawing Interchange File Formats, ASCI Austauschformat für CAD
Anwendungen
DWG Drawing, binäres Austauschformat für CAD Anwendungen
Tabelle 3: AutoCAD Dateiformate
28

4. Konzept einer möglichen Geodateninfrastruktur der SBV
XML-basiert
Beschreibung
GML Geography Markup Language, Auszeichnungssprache zur
Beschreibung raumbezogener Objekte
City GML City Geography Markup Language, Anwendungsschema zur
Beschreibung von 3D Stadtmodellen
KML Keyhole Markup Language
SVG Scalable Vector Graphics
GPX GPS Exchange Format
Tabelle 4: XML-basierte Dateiformate
Rasterdatenformate
Beschreibung
GeoTIFF verlustfreie Speicherung großer Rasterdaten möglich
ECW Enhanced Compressed Wavelet,
komprimierte Speicherung großer Rasterdaten möglich
MrSID Multi Resolution Seamless Image Database,
Tabelle 5: Rasterformate
komprimierte Speicherung großer Rasterdaten möglich
Einheitliche Austauschformate der Verwaltungen der Länder
Beschreibung
EDBS Einheitliche Datenbankschnittstelle, standardisiertes Datenformat zum
Austausch von Geodaten (ALK, ATKIS)
NAS Normbasierte Austauschschnittstelle, neue Datenschnittstelle zum
Austausch von Geodaten (AFIS, ALKIS und ATKIS), EDBS wird
künftig von NAS abgelöst.
Tabelle 6: Einheitliche Austauschformate der Verwaltungen
29

4. Konzept einer möglichen Geodateninfrastruktur der SBV
Sonstige Dateiformate
Beschreibung
GDF Geographic Data Files, Dateiaustauschformate für vektorisierte
Kartendaten, insbesondere für Straßenkarten
CDR, CMX Vektorformat für Corel Draw Zeichnungen
PDF(3D) Portable Document Format, Dateiformat für Dokumente
3D: Speicherung von CAD Daten, das Betrachten und Interagieren ist
ohne extra CAD Software möglich
JPEG Norm für Methoden zur Bildkompression, umgangssprachlich werden
damit Dateien im JPEG Interchange Format (JFIF) bezeichnet
Tabelle 7: Sonstige Dateiformate
4.4.2 Software zur Umsetzung der Webservices
Durch das Angebot der unterschiedlichen Softwareprodukte können die Entwickler
diese komfortabel testen und über deren praktische Einsatztauglichkeit entscheiden.
Zur Umsetzung von Webservices werden vorerst die Produkte deegree, GeoServer,
UMN MapServer, GeoNetwork sowie MapProxy eingesetzt. Die Produkte deegree und
GeoServer stellen hierbei die Webservices WPS, WFS-T, WCS sowie einen WMS
bereit. UMN MapServer wird als WMS und WFS eingesetzt. Für den jüngsten OGC
Standard WMTS steht bisher lediglich die Softwarelösung MapProxy zur Verfügung.
Ebenso steht für die Umsetzung eines CSW nur ein Softwareprodukt zur Verfügung –
GeoNetwork.
Zur Entwicklung eigener Webservices werden die Entwicklungsbibliotheken GEOS,
FDO, OSSIM, GeoTools, MetaCRS, GDAL/OGR sowie PostGIS eingesetzt.
30

4. Konzept einer möglichen Geodateninfrastruktur der SBV
4.4.3 Client Software
In der Kategorie Clients wird zwischen Server- und Browser-basierten Webclients
sowie nativen Anwendungen unterschieden. Unter der Kategorie „Browser-basierte
Webclients“ werden Clients, die in einen Webbrowser integriert werden,
zusammengefasst. Diese Webclients verfügen dabei über integrierte Funktionalitäten
(bspw. Zoom, Überlagerung von Webservices, etc.) zur Nutzung der eingebundenen
Webservices. Server-basierte Webclients hingegen nutzen auf dem Server
bereitgestellte Funktionalitäten (bspw. Analysefunktionen) und dienen lediglich der
formatierten Ausgabe der Ergebnisse. Unter nativen Anwendungen sind wiederum
bereits bestehende Software GIS zusammengefasst, die je Betriebssystem als eigenes
Installationspaket bereitstehen.
Zur Entwicklung eigener Webclients (Server-/Browser-basiert) werden, wie bereits
erwähnt, Frameworks genutzt.
Im Folgenden sind einige der zum Zeitpunkt der Diplomarbeit verfügbaren Produkte
aufgelistet, wobei kommerzielle Produkte kursiv dargestellt sind.
Browser-basierte Webclients:
• OpenLayers, Mapbuilder, Mapfish, Legato, Geomajas
Server-basierte Webclients:
• Carbon Tools, Mapbender
native Anwendungen:
• Gaia, Grass GIS, gvSIG, MapInfo, Mapviewer, ArcPad, OpenJump,
Quantum GIS, rasdaman, uDig
31

5. Teilweiser Aufbau einer prototypischen GDI
5 Teilweiser Aufbau einer prototypischen GDI
Im Folgenden wird eine Vorstellung und anschließend ein Vergleich von ausgewählten
genutzten Softwareprodukten zur Umsetzung des GDI Konzepts vorgenommen. Es
wurden sowohl kommerzielle als auch Open Source Lösungen getestet. Des Weiteren
wurde die Technik zur Realisierung der Geodatenbank implementiert.
5.1 Test der Datenbanksysteme
Im Gegensatz zu “gewöhnlichen” Datenbanken speichern die Erweiterungen
PostgreSQL-PostGIS oder Oracle Spatial nicht nur Sachdaten, sondern auch
Geometriedaten. Sie stellen ebenfalls Befehle zum Analysieren, Erstellen und
Bearbeiten von Geometriedaten zur Verfügung. Die Datenbanksysteme PostgreSQL-
PostGIS und Oracle Spatial wurden jeweils auf einem virtuellen Server installiert und in
Betrieb genommen. Hinsichtlich der Installation wurden die Handbücher sowie bei
Open Source Vertreter die entsprechenden online Tutorials genutzt. Als Basis diente ein
Linux Betriebssystem (Debian, Oracle Enterprise Linux). Die Datenbanken
unterscheiden sich vor allem in der Syntax der angebotenen Funktionalitäten. In der
Leistungsfähigkeit wurde unter Nutzung gleicher Hardware hingegen kein gravierender
Unterschied festgestellt. Beide Datenbankmanagementsysteme lieferten die genutzten
Testdaten (ca. 100 000 Einträge) innerhalb weniger Sekunden. Lediglich bei der
Anbindung der Datenbank in einem GIS zeigten sich Probleme bei den zum Zeitpunkt
der Arbeit verfügbaren Treibern (ODBC). Beispielsweise konnte die Verbindung
zwischen der Open Source Datenbank PostgreSQL-PostGIS und dem kommerziellen
Desktop-GIS MapInfo erst nach der manuellen Aktualisierung des bereits installierten
ODBC Treibers erfolgen.
32

5. Teilweiser Aufbau einer prototypischen GDI
5.2 Implementierung der Geodatenbank
5.2.1 Datenimport
Die häufig vorliegenden MapInfo Dateien wurden durch eine Softwareroutine in die
Datenbank importiert. Hierzu wurden u.a. die Kommandozeilen Tools GDAL, shp2sdo
sowie Easy Loader (MapInfo) eingesetzt. Keines der genannten Tools konnte im Test
überzeugen. Entweder mangelte es an der Bedienbarkeit oder an der Funktionalität.
Beispielsweise konnten nicht alle getesteten TAB Dateien fehlerfrei importiert werden.
Die Importvorgänge wurden entweder unter Ausgabe nicht interpretierbarer
Fehlermeldung abgebrochen oder es wurden lediglich Teile der Daten importiert.
Das einzig überzeugende Produkt im Test war die kommerzielle Software FME, welche
sich sowohl durch gute Bedienbarkeit als auch durch umfassende Funktionalität im
Bereich Dateitransformation sowie Schnelligkeit bei der Datenverarbeitung auszeichnet.
Durch die große Anzahl der unterstützten Dateiformate ist der Einsatz unterschiedlicher
Softwareprodukte je Dateiformat nicht mehr nötig. Die damit verbundene Recherche
und Einarbeitungszeit entfällt. Die FME befindet sich in der LISt GmbH bereits im
Einsatz.
5.2.2 Zugriffsschutz der Geodatenbank
Die durch die FME in eine Datenbank importierten Daten lassen sich mit Hilfe von
Geoinformationssystemen bearbeiten, unter anderem auch durch das in der SBV
eingesetzte GIS MapInfo. Durch die Verwendung einer Datenbank, anstelle der auf
einer Windows Freigabe bereitgestellten MapInfo Dateien, werden mehrere Probleme
gelöst. Das Wichtigste hierbei ist der Mehrnutzerbetrieb. Durch den Mehrnutzerbetrieb
entfallen u.a. der manuelle, monatliche Austausch und die damit verbundene ebenfalls
manuelle Datensynchronisation von MapInfo Daten. Des Weiteren vereinfacht der
Einsatz einer zentralen Datenbank sowohl die Datenpflege als auch deren Wartung.
Weitere resultierende Vorteile sind die Aktualität sowie die Verfügbarkeit der Daten
33

5. Teilweiser Aufbau einer prototypischen GDI
und die Reduzierung redundanter (d.h. doppelter) Datenhaltung in unterschiedlichen
Behörden.
Durch die zentrale Speicherung aller verfügbaren Informationen ist jedoch die
Implementierung eines geeigneten Zugriffsschutzes, der es ermöglicht Datentupel (d.h.
Zeilen in einer Tabelle) einzeln zu verwalten, unerlässlich.
Die hier vorgestellte Lösung nutzt dabei ausschließlich die zur Verfügung stehenden
Datenbankfunktionalitäten. Hierbei unterscheiden sich die eingesetzten Datenbanken
Oracle und PostgreSQL insbesondere in der Syntax für Trigger, wodurch die hier
vorgestellte Lösung für Oracle Datenbanken nicht 1:1 portiert werden kann. Eine
Portierung wurde jedoch umgesetzt und befindet sich im Anhang [A2].
Voraussetzung für die entwickelte Nutzerverwaltung ist, dass jeder Nutzer der
Datenbank einen eigenen eindeutigen digitalen Namen besitzt. Das heißt, es kann
zwischen Mitarbeitern gleichen Vor- und Nachnamens differenziert werden. Im
vorgestellten Fall wird der Anmeldename des Nutzers an der Datenbank zur
Identifizierung genutzt. Im praktischen Einsatz kann diese Identifizierungsmethode
ausgetauscht werden, u.a. sind Domainanmeldung oder der Datenbestand einer bereits
bestehenden Nutzerverwaltung, denkbar.
Für die Umsetzung des zeilenweisen Schreibschutzes werden folgende Komponenten
zusätzlich zur eigentlichen Datentabelle benötigt:
einmalig eine Tabelle aller verfügbaren Nutzer,
je Datentabelle eine zusätzliche Tabelle zur Zuordnung des Schreibschutzes,
je Datentabelle eine zusätzliche View, welche die farbliche Visualisierung der
Schreibrechte ermöglicht,
je Datentabelle ein Trigger zur Ausführung des Zugriffschutzes,
je Datenview drei Trigger zur Umsetzung der Insert, Update und Delete Befehle,
je Datentabelle eine Sequenz zur automatischen Erhöhung des Primärschlüssels.
Des Weiteren wurde eine optionale Tabelle zur Visualisierung der Schreibrechte im
eingesetzten Desktop-GIS MapInfo erstellt.
34

5. Teilweiser Aufbau einer prototypischen GDI
Eine Übersicht über die genannten Komponenten ist in Abbildung 8 dargestellt, wobei
jedes Zahnrad einen Trigger symbolisiert. Der View nutzt dabei die Daten aller
Tabellen und wurde daher als Rahmen dargestellt.
Tabelle Nutzer
ID_Nutzer,
DBAnmeldung,
Name,
Vorname,
...
1..*
VIEW
Tabelle Nutzer - Daten
ID_Nutzer,
ID_Daten
Tabelle Mapinfostyles
ID_Styles,
Schreibrecht,
MI_Style
Abbildung 8: ERM der Rechteverwaltung
*..1
Tabelle mit Mapinfo Daten
ID_Daten,
Daten
Anschließend erfolgt der Zugriff auf die Geodaten durch den Nutzer ausschließlich über
den erzeugten View. Sollte der Datenzugriff dennoch auf der Basis-Tabelle erfolgen, so
ist der Schreibschutz ebenfalls aktiv, wird jedoch nicht visualisiert.
Der für die Auslieferung benötigte View hat dabei folgende Funktionen zu erfüllen:
Ermittlung des aktuellen Nutzers,
Visualisierung der Schreibrechte, sowohl in der Geometrie (farblich) als auch in
der Daten-Tabelle (Textvermerk),
Anzeige aller Daten der Basis-Tabelle.
Ein dafür geeigneter Datenbankview könnte wie folgt aussehen:
35

5. Teilweiser Aufbau einer prototypischen GDI
CREATE OR REPLACE VIEW Datentabelle_View as
(SELECT s.*, st.*, st.s_id AS MI_PRINX
FROM Datentabelle st, Nutzer_Daten sn, Nutzer n, MapInfostyles s
WHERE st.s_id = sn.s_id AND sn.n_id = n.n_id AND n.DBAnmeldename =
(SELECT user FROM dual)
AND s.id=2)
UNION ALL
(SELECT b.Schreibrecht, b.mi_style, a.*,a.ID as MI_PRINX
FROM Datentabelle a, MapInfostyles s
WHERE a.id NOT IN (
SELECT DISTINCT ns.s_id
FROM Nutzer_Daten nd, Nutzer n
WHERE ns.n_id=n.n_id AND n.DBAnmeldename =
(SELECT user FROM dual) )
AND s.id=1));
Abbildung 9: Zentraler Datenbank-View der Rechtverwaltung
Daten mit
Schreibrecht
Daten
ohne
Schreibrecht
Der in Abbildung 9 dargestellte View ermittelt zunächst alle Daten, auf die der Nutzer
Schreibrechte hat. Diese erste Datenmenge wird mit der optionalen Tabelle
Mapinfostyles verknüpft, so dass das jeweilige Schreibrecht pro Datentupel visualisiert
werden kann. Anschließend wird diese Datenmenge mit einer zweiten vereint. In der
zweiten Menge befinden sich all die Datensätze, auf welche dem Nutzer nur lesender
Zugriff gewährt wird. Die Ermittlung des aktuellen Nutzers erfolgt in diesem Beispiel
über den Befehl select dual from user und liefert den aktuellen Anmeldenamen des
Nutzers am Datenbanksystem. Falls gewünscht, kann hier, wie bereits beschrieben, eine
andere Nutzeridentifikation erfolgen.
Die farbliche Markierung kann ebenfalls beliebig geändert werden. Beispielsweise
könnten alle Daten, auf die der Nutzer Schreibrechte hat, in der Standardfarbe der
jeweiligen Kategorie erfolgen (Flüsse: blau, Grenzen: rot, etc.).
Der in Abbildung 9 dargestellte View ist laut Definition nur lesend nutzbar. Um auch
schreibenden Zugriff zu gewährleisten, müssen vier Trigger implementiert werden.
36

5. Teilweiser Aufbau einer prototypischen GDI
Die Aufgabe des ersten Triggers ist es, alle Datenbankoperationen (Insert, Update,
Delete) auf dem View zu ermöglichen. Dies erfolgt durch die Implementierung eines
Instead – of Triggers für jede dieser Operationen. Durch den in Abbildung 10
dargestellten Instead of Trigger können Einträge im View geändert werden.
CREATE OR REPLACE TRIGGER Datentabelle_View_INSTOFU
INSTEAD OF UPDATE ON Datentabelle_View"
BEGIN
END;
CREATE OR REPLACE TRIGGER Datentabelle_View_INSTOFD
INSTEAD OF DELETE ON Datentabelle_View"
BEGIN
END;
UPDATE Datentabelle
SET
"Spalte 1" = :new. "Spalte 1"
"Spalte 2" = :new. "Spalte 2"
…
WHERE "ID" = :old."ID";
Abbildung 10: Instead of Update Trigger des zentralen Views
Der Primärschlüssel der Tabelle (in Abbildung 10 „ID“ genannt) dient hierbei als
Referenz und kann nicht geändert werden. Sollte eine Änderung des Primärschlüssels
notwendig sein, muss der entsprechende Datensatz gelöscht und neu angelegt werden.
Um die Operation „delete“ (löschen) auf dem View zu ermöglichen, muss ein weiterer
Trigger erstellt werden. Dieser soll neben der Löschung des Eintrages aus der
Datentabelle ebenfalls die entsprechenden Einträge aus der Tabelle Nutzer_Daten für
diesen Datensatz löschen. Ein möglicher Trigger ist in Abbildung 11 dargestellt.
DELETE FROM Datentabelle WHERE "ID" = :old."ID";
DELETE FROM Nutzer_Daten WHERE "Daten_ID" = :old."ID";
Abbildung 11: Instead of Delete Trigger des zentralen Views
37

5. Teilweiser Aufbau einer prototypischen GDI
Ein weiterer Instead of Trigger wird für das Einfügen neuer Datensätze in den View
benötigt. Zusätzlich muss dieser, sobald ein neuer Datensatz eingefügt wurde, einen
entsprechenden Eintrag in der Nutzer_Daten Tabelle erzeugen. Durch diesen Eintrag
erhält der Ersteller des Datensatzes die Schreibrechte an diesem. Des Weiteren erfolgt
eine einfache Fehlerabfrage, so dass keine leeren Datensätze in den Datenbestand
aufgenommen werden können.
Dargestellt ist ein solcher Trigger in Abbildung 12.
CREATE OR REPLACE TRIGGER Datentabelle_View_INSTOFI"
INSTEAD OF INSERT ON Datentabelle_View
BEGIN
IF ( :new."Spalte 1" IS NOT NULL AND
)
THEN
ELSE
vollständig');
END IF;
:new."Spalte 2" IS NOT NULL AND…
:new."GEOM" IS NOT NULL
INSERT INTO Datentabelle(Spalte1, Spalte2 …, "GEOM", "ID")
VALUES(:new.Spalte1, :new.Spalte2, …, :new."GEOM",
SEQ_ID_Datentabelle.NEXTVAL);
INSERT INTO Nutzer_Daten(Nutzer_ID, Daten_ID)
VALUES((SELECT "ID" FROM Nutzer WHERE DBAnmeldename =
(SELECT user FROM dual)), SEQ_ID_Datentabelle.CURRVAL);
RAISE_APPLICATION_ERROR (-20101, 'Eingabe der Daten nicht
Abbildung 12: Instead of Insert Trigger des zentralen Views
Zuletzt ist ein Trigger für die Einhaltung der Schreibrechte erforderlich. Im Falle eines
unerlaubten Schreibzugriffes soll eine entsprechende Fehlermeldung erfolgen und eine
Manipulation der Daten verhindert werden.
Zu diesem Zweck prüft der Trigger vor dem möglichen Schreibzugriff die vorhandenen
Schreibrechte. Sind diese vorhanden, wird der Trigger ohne weitere Abarbeitung
38

5. Teilweiser Aufbau einer prototypischen GDI
beendet. Anderenfalls wird die gewünschte Fehlermeldung über mangelnde
Schreibrechte ausgegeben und die Datenmanipulation abgebrochen.
Der zu diesem Zweck eingesetzte Trigger ist in Abbildung 13 dargestellt.
CREATE TRIGGER Datentabelle_BefU
BEFORE UPDATE ON Datentabelle FOR EACH ROW
DECLARE
anz integer;
BEGIN
SELECT COUNT(d."Daten_ID") INTO anz
FROM Nutzer n, Nutzer_Daten d
WHERE d."Daten_ID"=:old.gid AND d."Nutzer_ID"=n."ID" AND n."Name"=
(SELECT user FROM dual);
If (:old.s_id :new.s_id or anz=0)
THEN
RAISE_APPLICATION_ERROR (-20102,'KEINE SCHREIBRECHTE');
END IF;
END;
Abbildung 13: Before Update Trigger der Datentabelle
Nach Implementierung der Trigger ist der zeilenweise Schreibschutz einsatzbereit. Zum
Abschluss wurde die optional zur visuellen Darstellung benötigte Tabelle Mapinfostyles
erstellt. Sie enthält zwei Datensätze mit je zwei Attributen. Zum einen die Farbe der
darzustellenden Datensätze – grün insofern Schreibrechte vorliegen – rot bei
Nichtvorliegen, zum anderen eine Textinformation über aktuell vorliegende
Schreibrechte –ja bzw. nein.
Zum Zugriff auf die gewünschten Daten muss eine Datenbankverbindung hergestellt
und der beschriebene View geöffnet werden.
In Abbildung 14 ist ein Beispiel eines Kartenausschnitts in MapInfo zu sehen. Im
vorliegenden Fall sind Kompensationsflächen dargestellt, wobei der aktuelle Nutzer für
rote Flächen Lese- und für grüne Flächen Schreibrechte besitzt.
39

5. Teilweiser Aufbau einer prototypischen GDI
Abbildung 14: Bildschirmfoto der Rechteverwaltung im Kartenfenster von MapInfo
Analog zur visuellen Differenzierbarkeit im Kartenfenster von MapInfo wurde auch im
Datenfenster ein Eintrag über vorliegende Rechte ergänzt. Das Ergebnis ist in
Abbildung 15 zu sehen.
Abbildung 15: Bildschirmfoto der Rechteverwaltung im Datenfenster von MapInfo
40

5. Teilweiser Aufbau einer prototypischen GDI
Während des Mehrnutzerbetriebs ist zu beachten, dass in MapInfo der Modus
„Direktzugriff“ von jedem Nutzer aktiviert wurde (siehe Abbildung 16 ).
Abbildung 16: Auswahlmenü des MapInfo "Direktzugriff" Modus
Anderenfalls ist kein paralleler Schreibzugriff möglich. Lokale Änderungen des
Datenbestands während der Bearbeitung in MapInfo werden erst nach der manuellen
Speicherung (Speichern Button) in der Datenbank für andere Nutzer sichtbar. Sollte
während der Bearbeitung MapInfo unerwartet beendet werden, sind alle bisherigen
Änderungen verloren. Eine manuelle Speicherung ist daher immer zu empfehlen.
5.3 Übersicht der verwendeten Software
Zur Auslieferung der in der Datenbank gespeicherten Daten über das Netzwerk ist der
Einsatz von Diensten notwendig. Für die beschriebenen WMS, WFS und CSW Dienste
wurde zum Zeitpunkt der Arbeit ebenfalls aktuelle Software getestet. Besonderer Wert
wurde hierbei auf Geschwindigkeit, Wartbarkeit, Zuverlässigkeit, Entwicklungsstand,
Aktualisierbarkeit und Bedienbarkeit gelegt.
41

5. Teilweiser Aufbau einer prototypischen GDI
5.3.1 Webservices
Degree und GeoServer
Im Rahmen der GDI werden Downloaddienste benötigt. Hierzu wurden als Web Feature
Server deegree sowie GeoServer eingesetzt.
Es handelt sich bei beiden Produkten um bekannte Open Source Lösungen, die stetig
weiterentwickelt werden. Sowohl GeoServer als auch deegree unterstützen das
Datenbanksystem PostgreSQL-PostGIS.
Ebenso bestehen keine Unterschiede bezüglich der angebotenen Webservices. Sowohl
GeoServer als auch deegree stellen die Services WFS-T, WMS, WPS und CSW zur
Verfügung. Die Installation beider Softwareprodukte wird jeweils durch Import eines
Apache Servlets realisiert.
Unterschiede bestehen jedoch bei der Nutzung einer Oracle Spatial Datenbank. Diese
wird zum Zeitpunkt der Arbeit lediglich von GeoServer unterstützt. Weiterhin
unterscheiden sich beide Produkte erheblich hinsichtlich der Bedien- und Wartbarkeit.
Während deegree die dateibasierte Konfiguration ohne weitere Informationen dem
Nutzer überlässt, wird durch GeoServer eine übersichtliche graphische Oberfläche
(GUI) zur Konfiguration bereitgestellt. Die GUI bietet sowohl Komfort als auch
Funktionalität. So werden beispielsweise geographische Daten, welche zur
Bereitstellung eines Dienstes benötigt werden (z.B. geographische Ausdehnung,
Projektion), via Knopfdruck berechnet und anschließend in die Konfiguration
übernommen. Der neu erstellte Dienst kann im Anschluss sofort genutzt werden. Auch
im Umgang mit großen Datenbeständen konnte GeoServer überzeugen. So war es
möglich eine 200 MB große, in die Datenbank importierte Testdatei problemlos mittels
WFS auszuliefern. Im Gegensatz zu GeoServer konnten mit deegree nur wenige MB
Daten fehlerfrei ausgeliefert werden. Eine Übertragung größerer Datenmengen war mit
dem deegree WFS nicht möglich. Aus diesem Grund wurde GeoServer als Web Feature
Service eingesetzt. Da jedoch zu erwarten ist, dass zukünftige Versionen von deegree
diese Fehler nicht mehr beinhalten, wird empfohlen, künftig erscheinende Versionen
von deegree erneut zu testen.
42

5. Teilweiser Aufbau einer prototypischen GDI
In Tabelle 8 sind diese Sachverhallte nochmals zusammengefasst.
GeoServer Deegree
Installation problemlos problemlos
Bedienbarkeit GUI dateibasiert, umständlich
Wartbarkeit GUI dateibasiert
Zuverlässigkeit keine Fehler festgestellt Speicherfehler bei großen
Datenmengen
Entwicklungsstand Version 2.2
laufende Entwicklung
Services WFS-(T), WMS, CSW, WPS
(beta)
Daten Oracle Spatial, PostgreSQL-
PostGIS; dateibasierte Vektor-
und Rasterdaten
Tabelle 8: Vergleich GeoServer und deegree
Version 3.0
laufende Entwicklung
WFS-(T), WMS, CSW, WPS
PostgreSQL-PostGIS;
dateibasierte Vektor- und
Rasterdaten
Die angebotenen WPS und WCS konnten auf Grund des zeitlichen Rahmens dieser
Diplomarbeit nicht getestet werden. Beide Services wurden dennoch installiert und
stehen für Folgearbeiten zur Verfügung.
UMN MapServer und MapProxy
Der für die Bereitstellung von Rasterdaten benötigte WMS erfolgte durch den Einsatz
des von der University of Minnesota (UMN) entwickelten Softwareprodukts UMN
MapServer. Dieses Programm kann sowohl Vektor- als auch Rasterdaten verarbeiten.
Der vom UMN angebotene WFS wurde ebenfalls getestet. Da die Konfiguration des
UMN MapServer analog zu deegree dateibasiert und somit weder nutzerfreundlich,
noch übersichtlich ist, wird auf die bereitgestellte WFS-Funktionalität nicht weiter
eingegangen.
Der angebotene WMS kann in unterschiedlichen Betriebsmodi konfiguriert werden. Zur
Ermittlung der leistungsfähigsten Konfiguration wurden folgende Modi getestet:
CGI und
FastCGI.
43

5. Teilweiser Aufbau einer prototypischen GDI
Die Messungen erfolgten auf einem Desktop-PC (2x3 Ghz, 2 GB Ram) und wurden
zehnmal wiederholt. Es wurden die Antwortzeiten der WMS auf 100 Abfragen, welche
mit Hilfe des im Anhang befindlichen Skripts generiert wurden, gemessen, wobei
jeweils 10 Abfragen parallel gesendet wurden. Die durchschnittliche Antwortzeit des
UMN MapServers beträgt 1,5 Sekunden und konnte unter Nutzung von FastCGI
lediglich um 0,1 Sekunden reduziert werden. Diese minimale Änderung ist durch die
Funktionsweise des MapServers bedingt, da bei jeder Anfrage die Konfigurationsdatei
(Map-Datei) verarbeitet wird.
Die Leistung des vom MapServer angebotenen WMS kann jedoch durch Einsatz eines
Proxy Servers gesteigert werden, welcher über einen vorgerechneten Datenbestand
verfügt. Durch diesen Bestand müssen Ergebnisse für Anfragen nicht berechnet,
sondern können direkt ausgeliefert werden. Lediglich Anfragen, deren Ergebnis nicht
bereits abgespeichert vorliegt, werden an den WMS des MapServers weitergeleitet. Dies
entlastet und beschleunigt den WMS zugleich. Das für diese Zwecke eingesetzte
Produkt ist ebenfalls eine Open Source Lösung und ist unter dem Namen MapProxy
bekannt. Durch dessen Einsatz wurde die Antwortzeit des WMS auf einen
Durchschnittswert von 0,9 Sekunden reduziert. Im Gegenzug hierzu stieg allerdings der
benötigte Speicherplatz. Bei einem Rasterdatenbestand (ECW-Dateien) von 182 GB
wurden durch Einsatz des MapProxys zusätzliche 84 GB benötigt.
Die Messwerte sind in Grafik dargestellt, wobei die Abszissenachse die gemessene Zeit
in Sekunden und die Ordinatenachse die Anzahl der Messwerte repräsentieren.
Anzahl der Messwerte
80
70
60
50
40
30
20
10
0
0,5 1 1,5 2 2,5 3 3,5 4 4,5 5 5,5 6
Antwortzeit in Sekunden
Abbildung 17: Antwortzeiten der WMS
CGI
FastCGI
MapProxy
44

5. Teilweiser Aufbau einer prototypischen GDI
5.3.2 Desktop-GIS
MapInfo und Quantum GIS
Als Desktop-GIS wurden hauptsächlich das Open Source Produkt Quantum GIS und die
kommerzielle Software MapInfo, welche bereits in der SBV genutzt wird, eingesetzt.
MapInfo unterstützt sowohl die kostenfreie Datenbank PostgreSQL-PostGIS (ab
MapInfo Version 10.0) als auch Oracle Spatial. Bezüglich der PostgreSQL-PostGIS
Unterstützung von MapInfo ist zu erwähnen, dass der Zugriff auf bestehende Views nur
lesbar erfolgen kann. Quantum GIS unterstützt hingegen lediglich den Einsatz einer
PostgreSQL-PostGIS Datenbank. Diese ist im Schreib- und Lesemodus nutzbar.
Beide Softwareprodukte bieten die Möglichkeit zur Nutzung der OGC-konformen
Webservices WFS und WMS.
Während der Nutzung von Quantum GIS (1.6) wurden massive Stabilitätsprobleme
festgestellt. Das Programm beendete sich aus nicht nachvollziehbaren Gründen in
unregelmäßigen Abständen. Es wird daher das Produkt MapInfo empfohlen. Insofern
zukünftig die Stabilitäts- und Kompatibilitätsprobleme des Open Source Vertreters
behoben werden, stellt dieser eine Alternative dar.
Außer den Produkten MapInfo und Quantum GIS wurden weitere Open Source GIS
getestet.
uDig und Gaia
Zu diesen gehören die Open Source Lösung uDig sowie das kostenfreie
Softwareprodukt Gaia. Beide Produkte stellen dem Nutzer eine übersichtliche GUI
bereit, was ihm eine intuitive Bedienung ermöglicht. Weiterhin unterstützen beide
Softwarelösungen die OGC Webservices WFS, WMS, WCS und WMTS. Im Gegensatz
zu Gaia bietet uDig die Möglichkeit des direkten Datenbankzugriffs sowohl auf Oracle-
Spatial als auch auf Postgresql-PostGIS Datenbanken. Während der Nutzung von uDig
wurden jedoch massive Stabilitätsprobleme festgestellt. Beispielsweise führte die
Anbindung einer Oracle Spatial Datenbank zu endlosen Wartezeiten oder die Auswahl
eines Webservices wurde unter Ausgabe einer Fehlermeldung („… Dies ist vermutlich
ein Programmierfehler. Bitte melden Sie ihn an das uDig-Team.“) beendet.
45

5. Teilweiser Aufbau einer prototypischen GDI
Im Gegensatz dazu wurden während des Einsatzes von Gaia keine Stabilitätsprobleme
festgestellt. Allerdings war das integrierte WFS-T Module sowohl zeitlich begrenzt als
auch durch die Anzahl der Operationen eingeschränkt, wodurch es sich lediglich zu
Test- und Entwicklungszwecken eignet. Weiterhin ist zu erwähnen, dass die Ladezeiten
der einzelnen Webservices länger als beispielsweise unter Nutzung von MapInfo sind.
Da es sich jedoch analog zu Quantum GIS bei uDig um einen Open Source Vertreter
handelt, dessen Entwicklung noch nicht abgeschlossen ist, wird empfohlen künftig
erscheinende Versionen dieses Produkts erneut zu testen.
Grass GIS
Ein weiterer getesteter Open Source Vertreter ist Grass GIS. Das ursprünglich zur
Bearbeitung von Rasterdaten genutzte Werkzeug entwickelte sich in den letzten Jahren
zu einem vollwertigen GIS zur Vektor- und Rasterdatenbearbeitung. Das Programm ist
dabei modular aufgebaut, d.h. es ist nicht als einzelnes großes Programm, sondern eher
als eine Funktionssammlung zu betrachten. Die Nutzung der einzelnen Module kann
sowohl durch Nutzung der GUI als auch durch Einsatz von Befehlen im integrierten
Terminal (Unix Shell) erfolgen. Zur Programmierung eigener Funktionalitäten stehen
neben der Unix Shell die Sprachen PERL und Python zur Verfügung.
Im Gegensatz zu den bereits vorgestellten Produkten, besitzt Grass GIS den
komplexesten Funktionsumfang. Dieser umfasst unter anderem:
Integration aller OGC Webservices sowie
über 400 Programme und Hilfsmittel zur Analyse und Bearbeitung von Vektor-
und Rasterdaten. [vgl. i14]
Während der Nutzung von Grass GIS traten im Gegensatz zu anderen Open Source
Produkten keine Stabilitätsprobleme auf. Die dem Nutzer zur Verfügung gestellte GUI
erwies sich jedoch allein durch die Anzahl der angebotenen Funktionen als sehr
unübersichtlich. Des Weiteren umfasst sie nicht alle Funktionalitäten, so dass
beispielsweise zur Integration eines WFS ein Kommandozeilenbefehl genutzt werden
muss. Die Bedienbarkeit ist damit die größte Schwäche von Grass GIS. Ein weiteres
Manko ist, dass während der Nutzung von Grass GIS (unter Windows) das Öffnen eines
WFS fehlerbedingt nicht möglich war. Dennoch könnte Grass GIS künftig eine gute
Alternative zu verfügbaren kommerziellen Produkten darstellen, insofern genannte
46

5. Teilweiser Aufbau einer prototypischen GDI
Schwächen behoben wurden. Auf Grund des großen Funktionsumfangs wären jedoch
längere Einarbeitungszeiten bzw. gezielte Schulungen der Mitarbeiter unumgänglich.
Eine Übersicht über einen Teil der Funktionalitäten der vorgestellten GIS ist in der
nachfolgenden Tabelle dargestellt.
Quantum
GIS (1.6)
MapInfo
(10.0)
uDig
(1.2.1)
Gaia (3.4) Grass GIS
(6.4.0)
Dokumentation Gut Sehr gut Gut Gut Sehr gut
WFS 1.0.0/- 1.0.0/1.1.0 1.0.0/1.1.0 1.0.0/1.1.0 1.0.0/1.1.0
WMS + + + + +
WCS - - + + +
WFS-T - + + + +
WMTS - - + + -
WPS - - + - +
Oracle Spatial + + + - +
PostgreSQL-PostGIS + + + - +
Tabelle 9: Übersicht Desktop-GIS
Zusammenfassend kann festgehalten werden, dass die vorgestellten Open Source GIS
derzeit nur bedingt als Alternative zu dem in der SBV eingesetzten GIS MapInfo zu
betrachten sind.
47

6. Zusammenfassung
6 Zusammenfassung
Inhalt der Diplomarbeit ist der konzeptionelle Entwurf einer möglichen
Geodateninfrastruktur für die Sächsische Straßenbauverwaltung. Es wurde ein
umfangreiches Konzept zum Aufbau einer solchen GDI erstellt und dessen
Umsetzbarkeit durch den prototypischen Aufbau ihrer Komponenten geprüft.
Das erstellte Konzept beinhaltet zwei Ausbaustufen und ist in drei Komplexe aufgeteilt:
Produktion, INSPIRE, Entwicklungs- und Testumgebung.
Als jeweilige Datenbasis dienen sowohl die vorliegenden Fachdatenbanken als auch die
im Rahmen der Diplomarbeit entworfene Geodatenbank. Die Geodatenbank ermöglicht
den Mehrnutzerbetrieb (ehemals) dateibasierter Fachanwendungen. Hierzu wurden die
Dateien in die Datenbank importiert und anschließend mit einem zeilenweisen
Zugriffsschutz, der auf Basis von Triggern erstellt wurde, versehen. Dieser wurde
sowohl für die Open Source Datenbank PostgreSQL-PostGIS als auch für den
kommerziellen Vertreter Oracle Spatial umgesetzt.
Weiterhin wurden unterschiedliche Produkte zur Bereitstellung der Webservices WMS,
WFS, WMTS sowie CSW konfiguriert und auf ihre Eignung im Rahmen der GDI
getestet. Insbesondere wurde ein performanter WMS zur Auslieferung von digitalen
Orthophotos des Freistaats Sachsen aufgebaut.
Durch den Einsatz der prototypisch aufgebauten GDI entstehen folgende Vorteile
gegenüber der aktuellen Situation:
Mehrnutzerbetrieb,
Bereitstellung der geforderten INSPIRE Daten,
effizientere Datennutzung,
vereinfachter Datenaustausch,
Aktualität der Daten,
Bereitstellung neuer Dienstleistungen,
alte Fachverfahren sind integrierbar.
48

7. Ausblick
7 Ausblick
Aufbauend auf das im Rahmen meiner Diplomarbeit entwickelte GDI Konzept sind
zukünftige Erweiterungen möglich und sinnvoll.
Wie bereits im Konzept dargestellt, könnten die Services Web Coverage Service und
Web Processing Service bzw. Web Coverage Processing Service (WCPS) in der SBV
zum Einsatz kommen. Mit Hilfe des WCS ist z.B. eine Auskunft über historische
Rasterdaten möglich. Beispielsweise können alle Luftbilder, welche die
straßenbaulichen Maßnahmen oder die Entwicklung des Baumbestands von 1990 - 2011
darstellen, abgefragt werden. Ein weiteres Beispiel wäre die Bedarfsanalyse für
Neupflanzungen von Bäumen in einer Region oder die Zustandsanalyse des
Baumbestands durch Einsatz von Infrarot-Bildern.
Der WPS könnte zur Bereitstellung neuer Dienstleistungen, insbesondere im Bereich
der Analyse von Geodaten, dienen. Ein mögliches Einsatzszenario für einen WPS wäre
beispielsweise die automatisierte Aktualisierung der für den WMS benötigten
Rasterdaten, sobald eine neue Datenlieferung vorliegt. Zu diesem Zweck könnten die
Transformationsroutinen (Datenformat, Projektion, etc.) prozessiert werden.
Die Realisierung des in Kapitel 4 vorgestellten Geoportals ist ein wesentlicher
Bestandteil der GDI SBV und sollte daher zeitnah erfolgen.
Der entwickelte DOP SBV könnte künftig erweitert werden. Das Luftbild könnte
grundsätzlich sowohl Straßenachsen als auch Netzknoten beinhalten. Weiterhin wäre
das Bereitstellen von kaskadierenden 4 WMS Ebenen mit Liegenschaftsdaten und
weiteren Fachinformationen der SBV möglich. Ein Wasserzeichen könnte die
Zugehörigkeit des WMS zur Straßenbauverwaltung dokumentieren. Insofern
gewünscht, kann der DOP-SBV der Öffentlichkeit bereitgestellt werden.
Ein weiterer Aspekt ist der Umgang mit INSPIRE Daten fremder Datenbestände.
Hierzu könnte, wie bereits in Kapitel 4 vorgestellt, der beschriebene Inspire
Synchronisations Service dienen. Da für diesen Dienst weder Client- noch Server-
4
Kaskadierender WMS: Kaskadierende WMS verbinden die Inhalte verschiedener einzelner WMS-
Dienste zu einem einzelnen Dienst.
49

7. Ausblick
Softwarelösungen existieren, muss dieser beispielsweise durch Erweiterung eines Open
Source WFS eigenständig entwickelt werden. Gleiches gilt für den in Kapitel 4
beschriebenen Generalisierungsdienst.
Weiterhin kann die vorgestellte Geodatenbank zur Steigerung der Bedienbarkeit bzw.
zur vereinfachten Administration erweitert werden. Folgende Erweiterungen wären
denkbar:
automatisierter Import der dateibasierten Daten in die Geodatenbank,
Realisierung eines Werkzeuges zur automatisierten Erstellung der
Datenstrukturen (Views, zusätzliche Tabellen, Sequenzen, Trigger),
Umsetzung eines Programms (mit GUI) zum Anlegen von Nutzern und der
Vergabe von Schreibrechten zwischen Nutzern und den Features (Datentupel).
Zur Geschwindigkeitssteigerung des UMN MapServers kann dieser als Apache-Modul
konfiguriert werden. Die zu erwartende Geschwindigkeitssteigerung ist auf das
Zwischenspeichern der Konfigurationsdatei zurück zu führen, d.h. diese wird nur beim
Start des Apache HTTP-Servers verarbeitet und anschließend im Arbeitsspeicher
bereitgestellt. Hierzu muss jedoch der Quellcode manuell angepasst werden.
Ein weiterer wesentlicher Aspekt, der im Rahmen dieser Arbeit nicht weiter
berücksichtigt wurde, ist die Sicherheit. Hierzu müssen geeignete
Autorisierungsmaßnahmen sowie Sicherheitsrichtlinien ermittelt und umgesetzt werden.
Ein wesentliches Thema in diesem Zusammenhang ist das Aktualisieren der genutzten
Software und der eingesetzten Server-Betriebssysteme. Dadurch werden zum einen
Sicherheitslücken geschlossen und zum anderen neue Funktionalitäten bereitgestellt.
50

Anhang
Anhang
A1 mögliche Geodateninfrastruktur der Sächsischen Straßenbauverwaltung
Der Infrastrukturplan wurde als faltbares Poster beigelegt.
A2 PostgreSQL Rechteverwaltung
Die Umsetzung der Rechteverwaltung unter PostgreSQL-PostGIS ist im Folgenden
dargestellt. Der Unterschied zur Oracle Spatial Umsetzung besteht im Wesentlichen in
der Programmierung der Trigger des zentrales Views, welche durch den Einsatz von
Regeln realisiert wurden.
Der zentrale Datenview wurde lediglich bei der Auswahl des aktuellen Nutzers
angepasst. Die Änderung ist in nachfolgendem Ausschnitt zu sehen.
CREATE OR REPLACE VIEW VIEW as
(…
WHERE … AND n.DBAnmeldename = (SELECT CURRENT_USER)
…
UNION ALL
(…
WHERE a.id NOT IN (
…
WHERE …n.DBAnmeldename = (SELECT CURRENT_USER)
…
Abbildung 18: PostgreSQL zentraler Datenbank-View der Rechteverwaltung
51

Anhang
Der Trigger zur Prüfung der Schreibrechte wurde wie folgt umgesetzt:
CREATE TRIGGER TRI_Datentabelle_BEFU
BEFORE UPDATE
ON Datentabelle
FOR EACH ROW
EXECUTE PROCEDURE function_tri_Datentabelle();
Abbildung 19: PostgreSQL Before Update Trigger der Datentabelle
Die ursprüngliche Funktionalität musste dabei in eine externe Funktion ausgelagert
werden:
CREATE OR REPLACE FUNCTION Datentabelle RETURNS trigger AS
$BODY$
DECLARE
anz integer;
BEGIN
SELECT INTO anz count(d."Daten_ID")
FROM Nutzer n, Daten_Nutzer d
WHERE d.Daten_ID=old.id AND d.Nutzer_ID=n.ID AND n.DBAnmeldename=
(SELECT CURRENT_USER);
IF tg_op = 'UPDATE' THEN
IF old. id new.id THEN
RAISE EXCEPTION 'Id darf nicht verändert werden ID % ',old.id;
END IF;
IF anz = 0 THEN
RAISE EXCEPTION 'KEINE RECHTE';
END IF;
END IF;
RETURN NEW;
END;$BODY$
LANGUAGE plpgsql VOLATILE
Abbildung 20: PostgreSQL Triggerfunktion der Datentabelle
Die Realisierung der Befehle Insert, Update und Delete auf dem zentralen View wurden
durch Rules implementiert. Diese sind im Folgenden abgebildet:
52

Anhang
Insert
CREATE OR REPLACE RULE DatentabelleV_Ins AS
ON INSERT TO Datentabelle_View DO INSTEAD
(INSERT INTO Datentabelle (…,geom, gid)
);
Update
CREATE OR REPLACE RULE VDatentabelle AS ON UPDATE TO View_Datentabelle
DO INSTEAD
(UPDATE Datentabelle
SET
"Spalte 1" = :new. "Spalte 1"
"Spalte 2" = :new. "Spalte 2"
…
WHERE "ID" = OLD."ID";
);
Delete
VALUES(…, NEW.geom, (SELECT nextval(Datentabelle_id_seq')));
INSERT INTO Daten_Nutzer("Nutzer_ID", "Daten_ID")
VALUES( (SELECT "ID" FROM Nutzer WHERE
);
"DBAnmeldename"=(SELECT CURRENT_USER)),
(SELECT currval(Datentabelle_id_seq '))
Abbildung 21: PostgreSQL Instead of Insert Rule des zentralen Views
Abbildung 22: PostgreSQL Instead of Update Rule des zentralen Views
CREATE OR REPLACE RULE VDatentabelle_Del AS
ON DELETE TO Datentabelle_View DO INSTEAD
(
DELETE FROM Datentabelle WHERE "id" = OLD."id";
DELETE FROM Nutzer_Daten WHERE "Daten_ID" = OLD."id";
);
Abbildung 23: PostgreSQL Instead of Delete Rule des zentralen Views
53

Anhang
Damit ist die Konfiguration der Rechteverwaltung abgeschlossen. Zur Nutzung von
PostgreSQL-PostGIS in MapInfo ist jedoch weiterhin zu beachten, dass alle Nutzer
einen lesenden Zugriff auf die Systemtabellen besitzen. Hierzu wurden alle Nutzer der
Gruppe gisgroup hinzugefügt. Die Erteilung der Schreibrechte erfolgte durch deren
Vergabe an diese Gruppe durch folgenden Befehl:
GRANT SELECT ON spatial_ref_sys, geometry_columns TO GROUP gisgroup;.
Durch den Einsatz von PostgreSQL-PostGIS entstanden folgende Probleme:
kein schreibender Zugriff auf den View in MapInfo möglich und
Visualisierung der Schreibrechte wird nicht dargestellt.
Die genannten Probleme wurden unter MapInfo (10.0) festgestellt. Da der Einsatz von
PostgreSQL erst seit dieser Version von MapInfo möglich ist, ist davon auszugehen,
dass diese Einschränkungen in künftigen Versionen nicht mehr zu erwarten sind.
54

Anhang
A3 Skript zur Geschwindigkeitsmessung eines WMS
Zur Messung der Antwortzeit wurde eine geeignete Methode in Form von Bash
Skripten entwickelt. Hierbei wurden drei Skripte implementiert. Die Aufgabe des ersten
Skripts ist die Generierung und Speicherung der WMS Anfragen, wobei drei Dateien
mit möglichen Anfragen (FastCGI, CGI, MapProxy) gespeichert werden. Die
Antwortdaten (Kartenausschnitte) der ermittelten Anfragen werden vor der Speicherung
der Befehle auf ihre Größe geprüft. Falls die Dateigröße kleiner als 15kB ist, handelt es
sich um einen überwiegend leeren Bildausschnitt und die Anfrage wird nicht
gespeichert.
Im Folgenden ist dieses Skript abgebildet.
#! /bin/bash
#gen_requests.sh
#Voraussetzung: Paket bc muss installiert sein
runden=100 # Anzahl der generierten Anfragen
opt=0 #Anfrage nur an FastCGI ?
#Adresse der Servicer
server="http://172.24.52.201/cgi-bin/mapserv?"
server1="http://172.24.52.201/cgi-bin/mapservcgi?"
server2="http://172.24.52.201:8080/service?"
#Speichern der abgesendeten Befehle in Datei:
befehlsspeicherfcgi=/home/befehlefcgi.txt
befehlsspeichercgi=/home/befehlecgi.txt
befehlsspeicherproxy=/home/befehleproxy.txt
extent=(4488731 5559627 4712844 5731538) #geographischer Bereich
AUSSCHNITTGR=10000 #maximale Breite der Kachel [Meter]
breite=800 #Kartengroesse definieren (Pixel)
hoehe=600
#Service
service="SERVICE=WMS&MAP=/var/www/sachsen.map"
service1="SERVICE=WMS&MAP=/var/www/sachsencgi.map"
service2="SERVICE=WMS"
version="VERSION=1.1.1" # Version des Service
request="REQUEST=GetMap" #Anfrage
#Ebenen
55

Anhang
layer="LAYERS=Sachsen_1,Sachsen_2,Sachsen_3,Sachsen_4,Sachsen_5,Sachsen_6"
layer2="LAYERS=Luftbilder"
proj="SRS=EPSG:31468" #Projektion
format="FORMAT=image/jpeg" #Bildformat
style="STYLES=" #Style (Standard leer)
basishor=${extent[0]}
basisver=${extent[1]}
hordiff=$(echo scale=0\; "${extent[2]} - ${extent[0]}" | bc) #horiz. Differenz des Extent
verdiff=$(echo scale=0\; "${extent[3]} - ${extent[1]}" | bc) #vert. Differenz des Extent
breitews="WIDTH=$breite" #Bildgröße als Text
hoehews="HEIGHT=$hoehe"
i=1 #Start der Schleife
while [ $i -le $runden ]
do
#zufaellige BBox (A(x1,y1) - B(x2,y2)) berechnen
#X Koordinate Punkt A
p1bbox=$(bc -l

Anhang
fi
fi
i=$(( $i + 1 ))
Das zweite Skript dient zur parallelen Ausführung der Messungen, wodurch die
Antwortzeiten während eines Mehrnutzerbetriebs getestet werden können. Hierzu
werden die im ersten Skript erzeugten Befehle in temporäre Dateien aufgeteilt.
Anschließend werden die Skripte zur Messung der Antwortzeit gestartet.
Dieses Skript ist im Folgenden abgebildet.
#! /bin/bash
#start_messung.sh
befehlsspeicher=$1
tmpfile=/home/
wmsstring=$server2$service2'&'$request'&'$version'&'$layer2'&'$proj'&'$bbox'&'
$style'&'$breitews'&'$hoehews'&'$format
printf "%s \n" $wmsstring >> $befehlsspeicherproxy
wmsstring=$server1$service1'&'$request'&'$version'&'$layer'&'$proj'&'$bbox'&'$s
tyle'&'$breitews'&'$hoehews'&'$format
printf "%s \n" $wmsstring >> $befehlsspeichercgi
Abbildung 24: Skript (Bash) zur Generierung der WMS Anfragen
i=0
j=1
paral=10
anzlin=`cat $befehlsspeicher | wc -l`
while [ $i -lt $anzlin ]
do
head -$paral $befehlsspeicher | tail -10 >$tmpfile$j
./messung.sh $j &
i=$(( $i + 10 ))
j=$(( $j + 1 ))
paral=$(( $paral + 10))
done
Abbildung 25: Skript (Bash) zur parallelen Ausführung des Mess-Skripts
Aufgabe des letzten Skriptes ist die Ausführung der WMS Anfragen. Zu diesem Zweck
werden die in der Datei gespeicherten Anfragen ausgeführt und die Ausführungszeiten
57

Anhang
sowie die erhaltenen Kartenausschnitte abgespeichert. Im Folgenden ist ein solches
Skript abgebildet:
#! /bin/bash
#messung.sh
zeitspeicher=/home/zeiten.xls
input=$1
nr=$(( $1 * 10 ))
for zeile in `cat $input`; do
tmp=$zeile
zeit=`/usr/bin/time -f "%e" wget -qO /home/bilder/$nr.jpg $tmp 2>&1`
zeit=$(echo $zeit | sed 's/[.]/,/g')
printf "%s \n" $zeit >> $zeitspeicher
nr=$(( $nr +1 ))
done
/bin/rm $1
Abbildung 26: Skript (Bash) zur Messung von Antwortzeiten der WMS Anfragen
Durch Einsatz dieser Skripte werden dieselben (zufälligen) Anfragen sowohl auf dem
MapServer (CGI, FastCGI) als auch auf dem MapProxy abgefragt und deren
Antwortzeiten erfasst, was wiederum einen Vergleich ermöglicht.
58

Bibliographie
Bibliographie
Literatur
[GROOT]
Geospatial data infrastructure - Concepts, cases, and good practice.
Richard Groot, John McLaughlin, John Douglas McLaughlin
Oxford University Press (2000)
[RAJA]
Future directions for SDI development, International Journal of Applied Earth
Abbas Rajabifard , Mary-Ellen F. Feeney, Ian P. Williamson. & Williamsen, I
Observation and Geoinformation (2002)
[BILL]
Grundlagen der Geo-Informationssysteme - Band1
Ralf Bill
Wichmann (1999)
[VERM]
Das deutsche Vermessungs- und Geoinformationswesen
Kummer/Frankenberger
Wichmann (2010)
59

Bibliographie
Internet
Zeitpunkt des letzten Zugriffs: 05.03.2011
[i1]
INSPIRE Flyer
http://www.gdi-de.org/download/flyer_broschueren/flyer_inspire.pdf
[i2]
Architekturkonzept GDI-DE
http://www.gdi-de.org/download/AK/GDI_ArchitekturKonzept_V1.pdf
[i3]
INSPIRE Zeitplan
http://www.gdi-de.org/inspire/zeitplan
[i4]
Verordnung (EG) Nr. 976/2009 der Kommision zur Durchführung der Richtlinie
2007/2/EG des Europäischen Parlaments und des Rates hinsichtlich der Netzdienste
http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2009:274:0009:0018:DE:PDF
[i5]
OGC Standards
http://www.opengeospatial.org/standards/
60

Bibliographie
[i6]
Fujitsu-Siemens
http://www.fujitsu.com/img/PR/2007/20070514-01al.jpg
[i7]
Staatsbetrieb Geobasisinformation und Vermessung Sachsen (GeoSN)
http://www.landesvermessung.sachsen.de/
[i8]
OKSTRA
http://www.okstra.de/
[i9]
Universität Münster
http://ifgivor.uni-muenster.de/vorlesungen/Geoinformatik/kap/kap8/k08_2.htm
[i10]
ESRI
http://www.esri-germany.de/products/arcgis/argisserver/features.html
[i11]
Gesetz über den Zugang zu digitalen Geodaten
http://www.gesetze-im-internet.de/bundesrecht/geozg/gesamt.pdf
61

Bibliographie
[i12]
Gesetz über das Geoinformationswesen im Freistaat Sachsen
http://www.gdi-de.org/download/inspire_gesetze/SaechsGDIG.pdf
[i13]
Datenformate
http://www.gdal.org/ogr/ogr_formats.html
[i14]
GDF-Hannover
http://www.gdf-hannover.de/lit_html/grasshandbuch_v12/node4.html
62

Internet
A1 mögliche Geodateninfrastruktur der Sächsischen Straßenbauverwaltung
SVN / KDN / Intranet SBV
Entwicklungs- und Testumgebung
ESRI
Shape
XML-basiert
Raster
GeoTIFF
Browser-basierte
Web-Clients
- Geomajas
- OpenLayers
- Legato
- Mapbuilder
- Mapfish
WMTS
- MapProxy
WMS
- deegree
- GeoServer
- UMN Mapserver
- IWAN Mapserver
Entwicklungs-
Bibliotheken
- GDAL / OGR
- GEOS - GeoTools
- FDO - MetaCRS
- OSSIM - PostGIS
Clients
Webservices
Raster- / Vektordaten, dateibasiert Datenbanken
DBF
Personal
GDB
File
GDB
MIF/MID/
TAB
DXF
DWG
GML City GML KML SVG GPX EDBS NAS
MrSID
ECW
JPEG
Verarbeitung
MapInfo AutoCAD
sonstige
Entwickler
native Anwendungen
(Windows/Unix/Mac/Mobil)
- ArcGIS Desktop / ArcPad - Cardo
- Gaia - Grass GIS - gvSIG
- MapWinGIS - Mapinfo - Mapviewer
- OpenJump - Quantum GIS - rasdaman
- uDig
WPS
- deegree
- GeoServer
WCS
- deegree
- GeoServer
GDF
Austausch
Corel Draw
PDF
(+3D)
WFS Cache
- Web Proxy
- Eigenentwicklung
CSW
- GeoNetwork
Server-basierte
Web-Clients
- Carbon Tools
- GeoTools
- Mapbender
WFS-T
- deegree
- GeoServer
- UMN Mapserver
DB mit Zugriffsschutz
- PostGIS
- Oracle Locator/Spatial
(MS SQL-Server)
Andere
- SpatialLite
Geobasisdaten, dateibasiert
ATKIS
DGM
ALKIS
ALK
Sonstige
Umweltdaten
Öffentlichkeit
Geo-Portal SBV
DLM DTK
ALB
Historische
Karten
WMTS
WMS
WCS
Verarbeitung
AFIS
DOP
Festpunkte
Laser3D-Gebäudemeßpunktemodell (Lärm)
Fachanwendungen
Geo-
Datenbank
KISS/KoKa-Nat TT-SIB ® INFOSYS
DOP SBV
WFS-T
Für Kartographie und klassische
Fachverfahren (KISS/KoKa-Nat)
Produktion .
Mitarbeiter
WPS FME Server
Geodatenzugriff
Clients
TT-SIB ®
Webservices
WFS-T WFS-T WFS-T WFS-T WFS-T
OKWS
TT-SIB ®
ProUI
Fachdatenbanken mit Geodaten
FIS-Baum
WFS Cache
Generalisierung-
Service (WFS)
ProUI FIS-Baum FIS-Art eGovernment
Datenbankmanagementsysteme
FIS-Art
eGovernment
Geodatenzugriff
per
WFS-T
OKWS OKWS OKWS
Direkter
Datenzugriff
per
Webservice
GIS-Clients
ETL-Tool
(FME-Client)
OKSTRA ETL-Tools
- Objektbrowser
- Prüfprogramm
CSW
ArcGIS Server
Arbeitsplatz
Geodatenmanagement
INSPIRE-Datennutzung
in der SBV
INSPIRE WMS
Legende
OKWS
Öffentlichkeit
Generalisierung-
Service (WFS)
INSPIRE WFS
INSPIRE Schemen
Datentransformation
ETL-Tool FME Konvertierungs-
Scripte
Benutzer
Nativer Client (exe)
Datenverarbeitung /
-transformation /
-konvertierung
dateibasierte Geodaten
OKSTRA® -konformer Web-
Feature-Service
Geodatenfluß, uni- / ...
ISS Client ISS Server
ISS Server ISS Client
INSPIRE
Die Symbole einer späteren Ausbaustufe
werden transparent dargestellt.
Dienst (Web-Service)
Web-basierter Client
(Internetbrowser)
Bibliothek von Softwareroutinen
für die
Geodatenverarbeitung
Datenbank-basierte
Geodaten
Datenbankerweiterung um
Rechtesystem für
Geofeatures
...bidirektional
Service- und andere Abkürzungen:
WFS-T Web Feature Service Transaktional, dient dem Geodatenzugriff lesend und
schreibend, Datenformat: GML, kein Datenverlust, Vektororientiert
WMS Web Map Service, dient der Kartendarstellung, liefert Rasterbild
WMTS Web Map Tile Service, Zwischenspeicher zur schnellen Kartendarstellung
CSW Catalogue Service for the Web, Server für Metadaten, wird später an den
Metadatenserver der GeoSN (GeoMIS ) angeschlossen
WPS Web Processing Service, automatische Geodatenverarbeitung nach frei
festgelegten Regeln
WCS Web Coverage Service, strukturierter Zugriff auf Rasterdaten (z.B.
Straßenoberflächenfotos aus Luftbildern und Querschnittsdaten)
ISS INSPIRE Synchronisation Service, WFS-Server/Client mit Protokollerweiterung um
nur geänderte, neue Daten zu übertragen bzw. veraltetete Daten zu löschen, dient
der effektiven Weitergabe von INSPIRE-Daten zwischen INSPIRE-Lieferanten
ETL Extraction Transform and Load, Werkzeug zur Datenverarbeitung / -transformation
und -konvertierung
DOP SBV Luftbildserver der SBV, ergänzt um weitere straßenrelevante Geoinformationen,
auch auf mobilen Geräten verfügbar