Entwurf und Implementierung einer webbasierten GIS-Projektmanagement- und Visualisierungs-Systemschnittstelle

Inhaltsverzeichnis

Abbildungsverzeichnis

Quellcodeverzeichnis

AbkUrzungsverzeichnis

Zusammenfassung

1 Einfuhrung
1.1 Hintergrund, Motivation und Problemdefinition
1.1.1 Ziel der GIS-Projektmanagement- und Visualisierungs-System schnittstelle
1.2 Aufbau der Arbeit

2 Anforderungsanalyse / Anforderungsdefinition
2.1 Anforderungen an das Projektmanagement-System
2.1.1 Eigenschaften von Projekten
2.1.2 Stufen der Planungsdurchftihrung unter dem Einsatz eines Projektmanagement-Systems
2.1.3 Anforderungen an die Groupware-Losung deren Funktionsum fang und Ziel-Ablauf
2.2 Geometrische Eigenschaften raumlicher Modelle
2.2.1 Konzepte geographischer Sachverhalte
2.3 Funktionen und Struktur von Moskito GIS
2.3.1 Verzeichnis-Struktur von Moskito GIS
2.3.2 Datenstruktur eines HDF-Plans
2.4 Technische Voraussetzungen zur Implementierung einer Groupware Losung und Entwicklung einer System-Schnittstelle
2.4.1 Web-Server
2.4.2 Programmiersprache
2.4.3 Datenbanksystem
2.5 Validierung und Zusammenfassung der Anforderungen

3 Diskussion und Auswahl der Technik
3.1 Recherche und Problemerkennung
3.1.1 Aufbau des Projektmanagement-Systems der eGroupWare
3.2 Technische Komponenten zur Einrichtung der eGroupWare-Umgebung
3.2.1 Web-Server
3.2.2 Datenbanksystem
3.2.3 Datensicherung und Datenpflege
3.3 Prasentationsformen raumbezogener Daten im Internet
3.3.1 Normierte Wege zur Prasentation raumbezogener Daten im Internet
3.3.2 Mogliche Losungswege zur Visuallaisierung von HDF-Datei Inhalten der Moskito GIS-Applikation
3.4 Auswahl der Programmiersprache zur Entwicklung der Visualisierungs System-Schnittstelle
3.4.1 Java
3.4.2 PHP und Java-Script
3.5 Zusammenfassung der Ergebnisse

4 Entwurf
4.1 Gesamtkonzept
4.1.1 Konzept des Projektmanager-Moduls der eGroupWare
4.1.2 Konzept der Visualisierungs-System-Schnittstelle
4.1.3 Gesamtaufbau
4.2 Inhalt
4.2.1 Parsen der HDF-Datei-Inhalte
4.2.2 Ausgleich der Mafistabsdifferenzen
4.2.3 Interaktive Inhalte des Visualisierungs-Moduls
4.3 Modulkonzept
4.3.1 Modulaufbau
4.3.2 Modulklassenfunktionen
4.3.3 Funktionsweise der Visualisierungs-System-Schnittstelle
4.3.4 Dynamische Generierung von Basisinhalten
4.4 Zusammenfassung der Ergebnisse

5 Implementierung
5.1 Anpassung des Projektmanagement-System der eGroupWare
5.1.1 Zugriffsrechtevergabe im Administrationsbereich der eGroup Ware
5.1.2 Anpassung der Templates
5.1.3 Anpassung der Steuerungsmechanismen
5.1.4 Anpassung der Datenbankeintrage
5.2 Installation der Umgebung
5.2.1 Aktivierung des GIS-Projektmanager-Moduls
5.3 Implementierung des Moduls zum Visualisieren von HDF-Datei-Inhalten
5.3.1 Implementierung der Visualisierungs-System-Schnittstelle
5.3.2 Implementierung des Visualisierungs-Moduls in die bestehen de GIS-Projektmanager Umgebung
5.4 Evaluierung

6 Schlussbemerkungen

Glossar

Literaturangaben

Internetquellen

Abbildungsverzeichnis

1.1 Aufbau und Funktion eines allgemeinen Informationssystems

2.1 Unstrukturiertes Datenmodell („Spaghetti-Modell”) (Quelle: (Hake u.a. 2002, S. 158)

2.2 Topologisches Datenmodell (Quelle: (Hake u. a. 2002, S. 158))

2.3 Hierarchisches Vektormodell (Quelle: (Hake u. a. 2002, S. 159)

2.4 Die Arbeitsstation von Moskito GIS

2.5 Beispiel einer Ordner-Struktur einer Moskito GIS Komponente

2.6 Grundkomponenten des Web-Dienstes

2.7 Verarbeitungsorientierte Sicht eines Anwendungssystems (Quelle: (Claus u. Schwill 2003, S. 155)(verandert))

2.8 Struktur eines auf einer Datenbank aufbauenden Anwendungssystems (Quelle: (Claus u. Schwill 2003, S. 156) (verandert))

3.1 Trennung der Steuerung, des Inhalts, des Layouts und der Struktur innerhalb des Projektmanagers der eGroupWare

3.2 Projektliste des Projektmanagers der eGroupWare

3.3 Vereinfachte Darstellung einer Internetlosung fur statische Karten

3.4 Weltkarte als sensitive Karte (Referenz: http://www.lonelyplanet.com)

3.5 Vereinfachte Darstellung einer Kommunikationsbasis zwischen einem Web-Server und einer GIS-Anwendung

3.6 Projektseite/Vorpommern Sud. Visualisierung von Moskito GIS In- halten mit Hilfe einer GIS-Schnittstellen-Software

3.7 Vereinfachte Darstellung einer Internetlosung fur die Erstellung dy namischer Karten auf der Basis der Moskito-GIS HDF-Datei-Inhalte

4.1 Benutzeroberflache des Admin-Moduls

4.2 GUI/Eingangsbereichs des Projektmanagers

4.3 Gesamtaufbau des GIS-PM mit Hervorhebung des Visualisierungs moduls

4.4 Graphische Benutzeroberflaache der Visualisierugs-System-Schnittstelle

4.5 Trennung der Steuerung, des Inhalts, des Layouts und der Struktur innerhalb des Visualisierungs-Moduls

4.6 Schema der Visualisierungs-System-Schnittstelle

5.1 Symbolaanderung

5.2 Ua berpruafung der Installation des GIS-Projektmanagers auf Vollstaan digkeit und Korrektheit der Datenbankeintraage

5.3 Zugriff af das eTemplate liber die GUI der eGroupWare

5.4 GUI des GIS-Projektmanager-Moduls

5.5 GUI des Visualisierungs-Moduls

Quellcodeverzeichnis

2.1 Ausdehnung des HDF-Plans

2.2 Informationen zum HDF-Plan

2.3 Objektzuweisung im HDF-Plan

4.1 Zugriffsrechtevergabe fur das neue GIS PM-Modul

4.2 PHP/Datei affnen (Referenz: http://de.php.net/)

4.3 PHP/Bildmatrix definieren (Referenz: http://de2.php.net/)

4.4 PHP/Transparenz bestimmen (Referenz: http://de2.php.net/)

4.5 PHP/Schleifen (Referenz: http://de2.php.net/)

4.6 Ermittlung des Bildfaktors

4.7 Referenzierung der Platzhalter innerhalb einer Variable

4.8 Hauptfunktionsklasse des Visualisierungsmoduls

4.9 Einleitung eines Java-Scripts

4.10 Interaktion des Visualisierungsmoduls

5.1 Eintragsergaonzung Moduleintrag im Admin-Bereich

5.2 Setzen der Schaltflache des Visualisierungs-Moduls im Template

5.3 Oo ffnen uobergebener Variable

5.4 Definition der Bildflaache

5.5 Auslesen von HDF-Inhalten

5.6 Funktion zur Berechnung des Mafistabsfaktors

5.7 Setzen der Ruckgabewerte zur Mafistabsfaktor-Berechnung

5.8 Variable zur Werteriickgabe

5.9 Zuweisung der URL-Inhalte

5.10 Verzeichnis auslesen und HDF-Dateien ermitteln

5.11 Projektabhangiges Verzeichnis auslesen

5.12 Setzen des Pfads

5.13 Einbindung von Dateien innerhalb der Modulklasse

5.14 Bsp. ersetzen der Template Platzhalter

5.15 Ersetzen der Template Platzhalter

5.16 Initialisierungsabschnittes der einzelnen Plaane

AbkUrzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Zusammenfassung

Die Zusammenfassung dient einer kurzen Ubersicht liber den wesentlichen Inhalt dieser Ausarbeitung Entwurf und Implementierung einer webbasierten GlS-Projekt- management- und Visualisierungs-Systemschnittstelle am Beispiel von Moskito GIS.

Die nachfolgende Masterarbeit beinhaltet die Konzipierung und Implementierung ei­ner Visualisierungs-System-Schnittstelle. Die Implementierung der Visualisierungs- System-Schnittstelle erfolgt in einer strukturierten, zukunftsorientierten und mo­dular aufgebauten Groupware-Losung. Zentraler Kern der Visualisierungs-System-- Schnittstelle ist es, die Inhalte von Moskito GIS Planen dynamisch auszulesen und diese in einer Graphik wiederzugeben. Aufgrund der zur Verfugung stehenden Zeit wird lediglich ein Prototyp des Visualisierungs-Moduls entwickelt und in das hier angepasste GIS PM-Modul der eGroupWare implementiert. Durch die autonome Haltung des Moduls GIS PM wird die Anpassungsfahigkeit der Visualisierungs-Sys- tem-Schnittstelle gewahrleistet.

Kapitel 1

Einfuhrung

„Internet-Anwendungen und Geographische Informationssysteme sind aktuelle The- men, die sowohl im Bereich der Informatik als auch im Bereich der Geographie einen intensiven explorations Gegenstand bilden."(Kappas 2001, S.209)

1.1 Hintergrund, Motivation und Problemdefinition

Bei meiner Tatigkeit in einem Landschafts-Planungsbtiro ist mir aufgefallen, dass auf dem internen Server des Unternehmens ein Datenchaos herrscht. Aus Daten- schutzgrunden wird auf das Benennen des Unternehmens oder auf Inhalte, die mit diesem Unternehmen in Verbindung gebracht werden konnten, verzichtet.

Das Grundgerust und somit die Verzeichnisstruktur ist oberflachlich klar struktu- riert. Der innere Aufbau, das Gefuge aus voneinander abhangigen und sich gegen- seitig bedingenden Teilen ist jedoch unstrukturiert. Fur jedes einzelne Projekt ist ein Verzeichnis vorhanden in dem weitere Unterordner abgelegt sind, die entweder das Stadium der Projekte mit den entsprechenden Daten beinhalten oder/und unter- schiedliche Projektzeitraume. In vielfaltiger Hinsicht kommt es zu Daten-Redundanzen und Inkonsistenzen, da jeder Nutzer die Moglichkeit hat, Daten ungehindert zu ko- pieren, zu verschieben und umzubenennen. Ein weiterer Nachteil der aus der vor- handenen Datenhaltung resultiert ist, dass keine Metadaten gefuhrt werden. Es lasst sich nicht feststellen, welche Person und wann eine Person an einem entsprechenden Projekt gearbeitet hat.

Die Koordination von Projekten die mit dem Sammeln, Erfassen, Beschreiben, Ord- nen, Speichern, Bereitstellen und Nutzbarmachen von Daten zusammenhangt, konn- te in dieser Hinsicht effizient und okonomisch optimiert werden. Besonderes wenn ein Unternehmen an zwei oder mehreren Standorten niedergelassen ist, ist es von Vorteil, anfallende Daten zentral auf einem oder mehreren Servern zu verwalten und einen standortunabhangigen Zugang zu den Daten zu ermoglichen. Dabei sollten Daten-Redundanzen und Inkosistenzen vermieden werden.

Als Hilfsmittel fur die Koordination von Projekten und somit fur die Projekt- Verwaltung und -Dokumentation kann ein umfassendes Projektmanagement-System oder viel mehr eine Groupware-Losung eingesetzt werden. Hierzu stehen Werkzeuge zur Kommunikation zwischen Gruppen und Gruppenmitgliedern sowie Systeme fur die Verwaltung gemeinsamer Dokumente bereit.(Claus u. Schwill 2003, S. 274)

Besonderes interessant sind Open Source-Produkte. Da der Quelltext der Open Source-Produkte frei verfugbar ist, ist es moglich, neue Funktionalitaten hinzuzufu- gen. In unterschiedlichen ’Foren’ und ’Groups’ werden Fragen und Antworten aus- getauscht, wobei hier die Programmierer oder auch Nutzer voneinander lernen und gemeinsam etwas ’Grofieres’ schaffen als die Summe der einzelnen Teile. Da es viel mehr darum geht sich gegenseitig Denkanstofie und Hilfestellungen zu geben, ist das Folgen starrer Strukturen bei den Open Source-Produkten abgeschwachter als bei proprietaren Systemen. Dabei unterliegt jedes Open Source-Produkt genau wie ein proprietares Systeme einem bestimten Lizenzierungsmodell, welches durch den Entwickler unter ein bestimmtes Copyright gestellt wird und spezifische Nutzungs- freiheiten festschreibt.(Grassmuck 2004, S.279)

Zentrale Punkte freier Software, die von den Lizenz-Modellen geregelt werden, zie- len auf „[...]die Beifugung des Quellcodes zum Binarcode der Software, das Recht, Kopien anzufertigen und weiterzugeben sowie das Recht, die ursprungliche Softwa­re zu modifizieren und die abgeleitete Software zu verbreiten”.(Grassmuck 2004, S. 279) Weitere Inhalte zu dieser Thematik kaonnen in der Literatur von z.B. Grassmuck (2004) oder der Internetseite der ’Open Source Initiative’ (http ://www.opensource. org/licenses/gpl-license.php) nachgelesen werden, da die allgemeine Behand- lung dieser Thematik den Rahmen dieser Ausarbeitung sprengen wuarde.

1.1.1 Ziel der GIS-Projektmanagement- und Visualisierungs-Systemschnittstelle

Bevor die explizite Lasungsstrategie der uniiberschaubaren Datenhaltung konkreti- siert werden kann, ist es wichtig, einzelne Begriffe des Inhalts der zu entwickelnden System-Schnittstelle zu klaren. Hierzu wird eine mOglichst eindeutige Bestimmung des Begriffes GIS durchgefuhrt.

Das Akronym GIS setzt sich aus den Anfangsbuchstaben der Worte Geo, das fur Geographie steht, Information und System zusammen. Die Geographie ist die be- schreibung der Erde. (dtv Brockhaus Lexikon 1984a, S. 281) Der Begriff Information kommt aus dem lateinischen und bezieht sich auf die Auskunft, auf den Inhalt ei- ner Nachricht, Mitteilung, Belehrung und die formulierte Unterrichtung.(dtv Brock­haus Lexikon 1984c, S. 285) Ein System stellt einen regelhaften strukturierten Zu- sammenhang von Einzelheiten, Dingen oder Vorgangen dar.(dtv Brockhaus Lexikon 1984d, S. 56)

Im Bereich der Computertechnik wird innerhalb eines Informationssystem Auskunft uber einen regelhaften und strukturierten Zusammenhang von Einzelheiten, Din­gen oder Vorgangen erteilt. Im Allgemeinen zielen Informationssysteme darauf ab, Menschen bei der Arbeit mit Informationen zu unterstuatzen.

In der Abbildung 1.1 wird verdeutlicht, dass ein Informationssystem auf Daten auf- baut. Diese Daten werden vorzuglich in einem DBMS verwaltet. Das DBMS nutzt Methoden der Datenverarbeitung fur das Abspeichern von Daten. Die Methoden der Datenverarbeitung werden aber auch fur eine Kommunikation zwischen Anwender und den Daten genutzt. Die Aufnahme, Verwaltung, Analyse und Prasentation von Informationen wird somit unkomplizierter, da die einzelnen Prozesse einer klaren Struktur folgen.

Handelt es sich bei dem Informationssystem um ein spezielles Informationssystem wie beispielsweise dem Moskito GIS (s. Kapitel 2.3), werden spezifische Inhalte ver- arbeitet. Die Spezialisierung basiert im Vergleich zu alphanumerischen Daten in einem beliebigen GIS besonderes auf raumliche Daten.(Brinkhoff 2005, S. 2) Inner­halb von GIS-Projekten wird mit der Geometrie einzelner Objekte, die naturgemafi eine starke Verflechtung zu weiteren Objekten aufweisen, operiert.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1.1: Aufbau und Funktion eines allgemeinen Informationssystems

Da es sich bei einem GIS um ein spezielles Informationssystem handelt, werden spezifische Inhalte verarbeitet. Diese spezifischen Inhalte sind raumbezogene Daten. In unserer Kultur in der heutigen Zeit werden raumbezogene Daten mit Hilfe ei­nes GIS digital erfasst, modelliert, analysiert sowie alphanumerisch und graphisch prasentiert. Ein GIS ist somit ein System, das rechnergesttitzt arbeitet und aus Hard­ware, Software, Daten und den Anwendungen selbst besteht.(Kappas 2001, S.44) Als Werkzeug lasst sich ein GIS fur verschiedene Raumuntersuchungen auf unterschied- lichen Anwendungsfeldern einsetzen (z.B. Raum- und Bebauungsplanung, Umwelt- schutz, Telekommunikation).(Brinkhoff 2005, S. 3) Ein rechnergestutzt arbeitendes Geographisches-Informations-System laasst sich in drei Gruppen von Basisfunktio- nalitaten einteilen. Die erste Gruppe umfasst die Erfassung und Modellierung der Daten, die zweite Gruppe beinhaltet die Analyse der Daten und die dritte Gruppe umfasst die Visualisierung der Daten.

Basisfunktionalitaten eines GIS (Quelle:(Klein u. Fischer-Stabel 2005, S.134 bis 137))

- Erfassung und Modellierung der Daten: Erfasst werden geometrische Objekte die auf Objektbeschreibungen von Punkt, Linie und Flache beruhen. Die Er­fassung der Daten kann direkt am realen Objekt erfolgen (primare Erfassung) oder an bereits vorhandenen digitalen Daten (sekundare Erfassung).
- Analyse der Daten: Die Flachenverschneidung mit der ein zusatzlicher Infor- mationsgewinn moglich ist, ist ein Beispiel fur die Analysemoglichkeit raum- bezogener Daten.
- Visualisierung der Daten: Mit der Visualisierung der Daten werden numeri- sche Daten zum besseren Verstandnis graphisch dargestellt. Werden die Daten nicht auf einen analogen Trager (z.B. Papier) graphisch dargestellt sondern beispielsweise auf einem Bildschirm, konnen Interaktionen wie Pan, Zoom, das Aus- bzw. Einschalten von Ebenen, einen zunehmenden Informationsgewinn mit sich tragen, da Objektvielfalt innerhalb einer Datei auf ein Minimum redu- ziert werden kann. Eine Struktur die aufgrund der Objektvielfalt nicht sichtbar ist, kann durch eine Interaktion sichtbar werden und somit intensivere Daten- exploration ermoglichen.

Genau wie ein allgemeines Informationssystem bildet somit auch das spezifische GIS kein in sich geschlossenes, zentrales System von Hard- und Softwarekomponenten sondern stellt eher ein Netzwerk von Teilsystemen dar. Innerhalb dieses Netzwerkes kommunizieren die einzelnen Teilsysteme untereinander uber kompatible System-- Schnittstellen. Wie viele Teilsysteme notwendig sind, um als GIS entsprechende Loasungen anzubieten, ist von den einsetzenden Techniken sowie von dem Inhalt, der darzustellen ist, abhangig. Dabei sollten Teilsysteme offen gegenuber kunfti- gen Entwicklungen und Veraanderungen sein. Eine allgemeingualtig ausgerichtete und nicht zu sehr auf eine spezifische Problemstellung bezogene System-Schnittstelle zu entwickeln sollte das Ziel sein.

Ziel des Teil-Systems

Ziel der System-Schnittstelle ist als eine Teilfunktion alphanumerische Daten zum besseren Verstandniss graphisch auf unterschiedlichen Visualisierungsebenen dar- zustellen. Die entsprechende System-Schnittstelle wird in ein bereits vorhandenes System integriert. Ziel des Projektmanagement-Systems in dem die Visualisierungs- System-Schnittstelle integriert wird, ist es, auf instrumentaler Ebene die Erreichung eines jeweiligen Projektziels durch eine optimierte Verwaltung zu rationalisieren. Der Programmquellcode der Groupware-Losung, in dem das Projektmanagement integriert ist, muss somit offen sein, so dass Veranderungen und Anpassungen durch jeden der im Besitz entsprechender Kenntnisse und Berechtigung ist, vollzogen wer- den konnen.

Die System-Schnittstelle soll als ein Kommunikationswerkzeug zwischen einer Group­ware-Losung und Moskito GIS dienen. Das Projektmanagement der Groupware- Losung soll fahig sein, mit Hilfe seiner Werkzeuge vorhandene Kausalitaten zwischen den einzelnen Projekten, die sich negativ auf die Unternehmenstruktur auswirken konnen, numerisch oder visuell zu verdeutlichen. Des Weiteren soll das Projekt- management-System eine standardisierte, personenunabhoangige Darstellung der Er- gebnisse ermoglichen, so dass bei Ausfall eines Mitarbeiters ein Projekt ohne weitere Komplikationen fortgefuhrt werden kann.

Die zu verwendenden Techniken sollen mUglichst standardisiert sein, da eine Stan- dardisierung die FlexibilitUt, FunktionalitUt und ProduktivitUt anschliefiender Ent- wicklungen begunstigt.(Behr 2000, S.172 bis 175) Die Normung des Datenaustau- sches zwischen unterschiedlichen Systemen ist sinnvoll und auch notwendig, wenn der Interessenkreis entsprechend grofi ist oder ein Netz von Beziehungen besteht, welches zu umfangreich fur mehrseitige LUsungen ist. Ein weiteres Kriterium fur den Einsatz von Normen ist eine bindende Vorschrift, an die sich ein Entwickler richtet, wenn dies notwendig ist.(Bartelme 2005, S.366 bis 370) Handelt es sich um einen Datenaustausch zwischen zwei Systemen, ist der Aufwand uberschaubar. Die bilaterale Festlegung bedient sich somit einer spezifischen Beziehung mit der eine Schnittstelle konzipiert und umgesetzt wird.

1.2 Aufbau der Arbeit

Diese Ausarbeitung beinhaltet spezifische typographische Konventionen. Diese Kon- ventionen sollen Besonderheiten der Inhalte verdeutlichen.

- Die Kursivschrift in ,,Anfuhrungsstrichen” wird bei Zitaten verwendet.
- Die fett gedruckte Schrift wird fur besondere Hervorhebungen innerhalb eines Textes verwendet.
- Die Nichtproportionalschrift innerhalb eines Textes wird verwendet fur:
— Dateinamen — Inhalte einer Anwendung
— alle Inhalte die in einem Programm vorkommen (Schlusselworter, Opera- toren und Methodennamen)
— Link-Angaben

Struktur der Arbeit

Die Mastererbeit gliedert sich grob in vier Teile. Im ersten Teil (Kapitel 2, ab Sei- te 11) wird die Anforderungsanalyse und Anforderungsdefinition behandelt. Da die Anforderungen nicht gestellt sind, sondern nach und nach erarbeitet werden mussen, nimmt dieser Teil der Arbeit den meisten Umfang ein. Innerhalb der Anforderungs­analyse wird eine Problemanalyse durchgefuhrt in der die Anforderungen gesammelt werden, die auf der ausgearbeiteten Problemstellung in diesem Kapitel basieren. An- schliefiend wird eine Anforderungsspezifikation sowie die Validierung der Anforde­rungen, die dazu dient Anforderungen auf Korrektheit zu tiberprtifen, durchgefuhrt. Der erhebliche Teil der Masterarbeit befasst sich notwendigerweise mit der Analy­se der Anforderungen und der einzusetzenden Techniken sowie der Festlegung der Gesamtvorgehensweise.

Teil Zwei (Kapitel 3, ab Seite 39) befasst sich mit der Diskussion moglicher Techni- ken die zur Auswahl stehen, um die gestellten Anforderungen zu erfullen. Es erfolgt die Recherche nach Groupware-Losungen, die sich als Basissystem zur Implementie- rung der Visualisierungs-System-Schnittstelle eignen. Die Auseinandersetzung mit Visualisierungsmoglichkeiten raumbezogener Daten im Internet, die als moglicher Losungsansatz, Anwendungsbereich oder/und Funktionalitat in Betracht kommen, um HDF-Datei-Inhalte der Moskito GIS-Anwendung zu visualisieren, bilden den zweiten Teil des Kapitels. Im dritten Teil des Kapitels erfolgt schliefilich die Zusam- menfassung der Ergebnisse.

Teil Drei (Kapitel 4, ab Seite 67) befasst sich mit Zielsetzungen und Kriterien, die ei- ne bislang noch unbekannte Organisation von Objekten und Sachverhalten besafi. Im ersten Kapitelteil wird die Konzipierung der gesamten GIS-Projektmanagement- und Visualisierungs-Systemschnittstelle vorgenommen, die in der eGroupWare-Losungen einzubetten ist. Im Anschluss erfolgt die Konzipierung der Visualisierungs-System- Schnittstelle und eine Beschreibung des modularen Aufbaus des GIS PM-Moduls so- wie eine abschliefiende Zusammenfassung der Ergebnisse.

Im vierten Teil (Kapitel 5, ab Seite 87) erfolgt die Umsetzung von festgelegten Strukturen. Das Kapitel untergliedert sich in vier einzelne Teile. Im ersten Teil er­folgt die Anpassung des Projektmanagement-System der eGroupWare. Im zweiten Teil erfolgt die Installation der Umgebung. Im Anschluss erfolgt schliefilich die Im- plementierung des Moduls zum Visualisieren der HDF-Datei-Inhalte. Abschliefiend erfolgt die Evaluierung in der die Analyse, des entwickelten Visualisierungs-Moduls, durch Tests erfolgt.

Im letzten Teil (Kapitel 6, ab Seite 100) werden die Kernpunkte der Masterarbeit in einem Fazit zusammengefasst. Abschliefiend wird das Glossar, das Literaturver- zeichnis sowie die verwendeten Hilfsmittel, die zur Erstellung dieser Ausarbeitung verwendet wurden, aufgelistet.

Kapitel 2

Anforderungsanalyse / Anforderungsdefinition

Innerhalb der Anforderungsanalyse werden Inhalte der Losungsstrategie festgestellt. (Neumann 2005, S. 98)

Die Anforderungsanalyse untergliedert sich in drei einzelne Phasen. Die erste Phase ist die Problemanalyse, in der die Losungsstrategie aufgedeckt wird. In der zwei- ten Phase ist die Anforderungsspezifikation, in der die Anforderungen dokumentiert werden, zu erstellen. In der dritten Phase erfolgt die Validierung der Anforderungen, in der die Anforderungen auf ihre Korrektheit uberpruft werden.

2.1 Anforderungen an das Projektmanagement-System

Landschafts-Planungsunternehmen, die mit raumlichen Daten operieren, stellen be- sondere Anforderungen an die Datenhaltung und an die System-Schnittstellen uber die verschiedene Systeme miteinander gekoppelt werden konnen. Der Umfang zu be- handelnder Anforderungen kann aus pragmatischen Grtinden ausschliefilich auf ein Minimum beschrankt werden.

Ein Bestandteil der Planung ist die Findung einer geeigneten Methode fur das Sam- meln und Aufzeichnen von Daten.(Hake u. a. 2002, S. 293 bis 295) Ein weiteres Kriterium wird von der Mooglichkeit der Datenverarbeitung und deren permanenten Speicherung abhangig gemacht. Steht die geeignete Methode fest, ist ein Datenmo- dell und ein Datenkatalog (Objektkatalog) aufzustellen der nach der Aufbauphase Moglichkeiten zum weiteren Aufbau bereit stellt. Die Simulation von Eingriffen in die Landschaft mit entscheidungsunterstutzenden Systemen, die im Rahmen einer Planung fur transparente Planungsentscheidungen eingesetzt werden, ermoglicht es den Konsens der Auswirkungen von Mafinahmen auf die Umwelt intersubjektiv zu beurteilen und zu bewerten.(Blaschke u. Lang 2007, S. 292 bis 308) Der simulier- te Sachverhalt der Modelle kann als Ergebnis nachvollzogen werden und bildet eine Entscheidungshilfe innerhalb eines Projekts. Die Entscheidungshilfe ist somit bedeu- tend fur das Projekt selbst und ist ein Bestandteil des Projektes.

Im Allgemeinen entstehen im Rahmen einer Planung weitere Daten, die analysiert und miteinander in Beziehung gebracht werden. Diese bestehen nicht nur aus reinen Geodaten, die in klar definierten Modellen (s. Kapitel 2.2 (Geometrische Eigenschaf- ten raumlicher Modelle) S. 17) vorgehalten werden, sondern konnen aus Literatur, Gesetzestexten und weiteren Materialien, die einem Projekt zugeordnet werden, zu- sammengesetzt sein.(Hosenfeld 1999, S. 143 bis 149) Um ein Austausch innerhalb verschiedener Applikationen zu ermoglichen, sind eindeutige Schnittstellen und Da- teiformate festzulegen.

2.1.1 Eigenschaften von Projekten

Die Findung geeigneter Methoden, die Aufstellung von Datenmodellen und Daten- katalogen sowie die Verarbeitung, Beschreibung und Entstehung von Daten und Modellen sind wichtige Bestandteile der Landschaftsplanug. Die Eigenschaften von Projekten, die sich aus der Morphologie jedes einzelnen Projektes bilden, sind durch gleichzusetzende Eigenschaften wie z.B. die zeitliche Begrenzung gekennzeichnet.

Eigenschaften von Projekten (Quelle: (Behr 2000, S. 5 bis 6))

1. Einzigartigkeit der Aufgabe: Die Einzigartigkeit eines Projektes ist weitest- gehend von der Planungsregion abhangig sowie von dem Zeitraum des Pla- nungsereignisses.
2. Zeitliche Begrenzung: Kein Projekt stellt eine Daueraufgabe dar, sondern muss in einem klar definierten Zeitrahmen abgeschlossen werden.
3. Bedeutung: Neben personellen und finanziellen Auswirkungen wirkt sich ein Projekt auf die Arbeitsorganisation und Informationsverarbeitung in einem Unternehmen aus.
4. Umfang: Planung des einzusetzenden Personals fur ein Projekt.
5. Risiko: Die Durchftihrung eines Projektes kann auf technischer und personeller Ebene fehleingeschatzt werden. Des Weiteren besteht ein hoheres Risikopo- tential, das sich aus der Abhangigkeit ergibt. Werden z.B. Simulationsmodelle durch ein anderes Unternehmen berechnet, entsteht eine Abhangigkeit von Dritten. Falls das Lieferdatum fur die Simulationsmodelle nicht eingehalten werden kann, ist es moglich, dass das gesamte Projekt fur eine Zeit nicht be- arbeitet werden kann.

Es reicht somit nicht aus, dokumentierte Informationen einzeln zu behandeln. Das gesammelte und erstellte Informationsmaterial sollte vielmehr zusammenhangend verwaltet werden. Die Verwaltung sollte jedoch nicht auf einer monologischen Basis existieren sondern fur spezifische Anwendungen uber eine System-Schnittstelle wie z.B. ein Datenbanksystem eine Kommunikationsebene bieten.(Herter u. Koos 2006, S. 160 bis 162)

Ein Projektmanagement-System stellt einen regelhaften strukturierten Zusammen- hang von Projekten, deren Inhalten oder Vorgangen dar.(dtv Brockhaus Lexikon 1984d, S. 56) Ein Projekt, deren Planung und Durchfuhrung, wird dabei in die institutionelle-, funktionale- und instrumentale Sichtweise unterteilt. Innerhalb der institutionellen Ebene, wird ein Projekt in die Aufbauorganisation (Kommunikations- und Machtstruktur) des Unternehmens eingeordnet. Auf der funktionalen Ebene wird ein Projekt in den Ablauf und in die Organisation (d.h. Planung, Steuerung und Kontrolle der einzelnen zum Projekt gehuorenden Arbeitsschritte) des Unterneh- mens integriert. Die instrumentale Ebene beinhaltet die Methoden und Verfahren, die der Erreichung eines Projektziels dienen.(Zingel 2005, S. 4)

Groupware-Losungen die ein Projektmanagement-System beinhalten, stellen die Me­thoden und Verfahren zur Verfugung, die auf funktionaler Ebene die Organisation von Unternehmensinhalten untersttitzen und das kooperative Arbeiten fordern. Die Koordination von Projekten auf instrumentaler Ebene, kann die Erreichung eines Projektziels durch eine optimierte Verwaltung und Visualisierung raumbezogener Daten untersttitzen. Standardisierte, personenunabhangige Darstellungen der Er- gebnisse sowie das Aufdecken vorhandener Kausalitiaten zwischen den einzelnen Projekten werden durch einen regelhaften strukturierten Zusammenhang verdeut- licht.

2.1.2 Stufen der Planungsdurchfuhrung unter dem Einsatz eines Projektmanagement-Systems

In der Vorstufe der Planung, der Situationsanalyse, werden Bedingungen durch den Projektleiter untersucht, die ftr die Realisierung eins Projektes und derer Randbe- dingungen unabdingbar sind.

Bedingungen zur Realisierung eines Projektes und derer Randbedingun- gen (Quelle: (Behr 2000, S. 95 bis 97)(verandert))

1. Ziel Konkretisierung: Ein Auftraggeber hat konkrete Vorstellungen tber das Endergebnis. Die Aktivitaten des Auftragnehmers richten sich somit nach dem Auftraggeber.

2. Inhaltliche Beschreibung: Eine inhaltliche Beschreibung der geforderten Ziele ist der Kernbestandteil strategischer Planung.

3. Erwartete Resultate: Mit konkretisierten Zielen, die innerhalb eines Projekts ausgearbeitet werden und derer inhaltlichen Beschreibung, ist eine Erwar- tungshaltung verbunden, die tber Ergebnisse schlussfolgern lasst.

4. Abgrenzung: Jedes Projekt ist einzigartig und wird gegentber parallel und nachfolgend ablaufender Aktivitat abgegrenzt.

5. Kapazitat und Mitarbeiter: Die Kapazitat ist des Weiteren von der Kosten- planung abhangig. Es treten vorrangig Kosten fur das Personal sowie deren Qualifizierung, Materialkosten und Fremdleistungskosten auf. Somit ist es not wendig eine Festlegung der zustandigen Mitarbeiter fur ein Projekt sowie die zur Verfugung stehende Kapazitat zu treffen.

6. Zeitplanung: Start- und Endtermin des Projektes

Die vorangestellten Bedingungen zur Realisierung eines Projektes und derer Rand- bedingungen werden durch einen Planer oder ein Planungs-Team erfasst und auf- einander abgestimmt. Innerhalb eines Projektmanagement-System sollten aufgrund dessen die Bedingungen zur Realisierung eines Projektes und derer Randbedingun- gen grofitenteils abgedeckt werden.

In der funktionalen Arbeits- und Kostenplanung soll das Projektmanagement-System als ein Instrument zu Dokumentationszwecken dienen und somit die Kontrolle be- stehender Projekte unterstutzen. Die in dem Projektmanagement-System erfassten Dokumentationen konnen als Hilfsmittel zur Erreichung interner und/oder externer sowie gesetzlicher Vorschriften dienen. Die dokumentierten Inhalte koannen ebenfalls zur Projektsteuerung und zur Projektuberwachung mit den dazugehorenden Pro- jektfortschritten und -ergebnissen genutzt werden.(Behr 2000, S. 95 bis 97) ”Die Nutzung solcher Projektmanagementwerkzeuge unterstutzt die systematische Pla- nung der Projektschritte.”(Behr 2000, S.100) Vorhandene Kausalitiaten zwischen den einzelnen Projekten (z.B. Unterschatzung oder Uberschreitung der Projektdau- er) werden in einem Projektmanagement-System erkennbar. Ebenfalls bietet der Einsatz datenbankgestutzter Projektmanagement-Systeme eine standardisierte, per- sonenunabhangige Darstellung der Ergebnisse.(Behr 2000, S.100 bis 101)

Aus der vorangestellten Analyse sind folgende Funktionalitaten von einem Projekt­management-System zu erwarten.

Funktionalitaten eines Projektmanagement-Systems / Dokumentation der Anforderungen

1. Inhalte: Das Sammeln, Erfassen, Beschreiben und Ordnen von Dokumenten sowie ihre Bereitstellung und Nutzbarmachung fur Informationszwecke soll von weiteren Funktionalitaaten und Projekten getrennt sein.

2. Daten: Durch das Sammeln, Erfassen, Beschreiben und Ordnen von Dokumen- ten anfallende Daten, sowie deren Metadaten sollten zentral auf einem Server verwaltet werden.

3. Redundanzen: Redundanzen sollten vermieden werden, da diese u.a. ein unno- tiges Speichervolumen auf der Festplatte des Servers belegen und zur Inkonsi- stenz fuhren.

4. Zugriff auf Daten: Uber einen Web-Client soll ein Zugriff auf einen Intranet oder Internetbasierten Web-Server erfolgen, auf den die gesammelten, erfas- sten, beschriebenen und geordneten Dokumente sowie deren Metadaten gela- gert sind. Fur den Klient soll dabei kein Installationsaufwand entstehen.

Nur in dem Fall eines offenen Programmquellcodes der Groupware konnen die Funk- tionalitaten der Groupware-Losung erweitert und angepasst werden. Um einer lan- gen Entwicklungszeit entgegen zu wirken, ist eine Groupware-Losung einzusetzen, die nach Moglichkeit deckungsgleiche Funktionalitaten beinhaltet. Eine schnelle Ein- arbeitung in das entsprechende Open Source-Produkt wird durch unterschiedliche ’Foren’ und ’Groups’ unterstutzt. Die Kopplung einer Groupware-Losung mit der im folgenden Kapitel 2.3 beschriebenen Applikation Moskito GIS, erfolgt uber eine System-Schnittstelle.

2.1.3 Anforderungen an die Groupware-Losung deren Funktionsumfang und Ziel-Ablauf

Ziel der Arbeit ist es, auf bereits existierende und erprobte Teilsoftwaresysteme zu- ruckzugreifen um innerhalb des zeitlich begrenzten Rahmens der Masterarbeit ein bestmogliches und zufriedenstellendes System zu entwickeln. Bei der Wahl dieser ex- ternen Komponenten sollte darauf geachtet werden, dass die Komponenten bereits erprobt und in einer stabilen Version vorliegen. Zur Auswahl werden zwei unter­schiedliche Groupware-Systeme herangezogen, die modular aufgebaut sind. In beiden Groupware-Systemen ist ein PM-Modul implementiert. Neben der Korrektheit ei- ner auszuwaohlenden Groupware-Loosung, welche als selbstverstaondlich vorausgesetzt wird, ist die Erweiterbarkeit des Systems dufierst von Bedeutung.

Die auszuwahlende Groupware-Losung soil eine Mehrbenutzerumgebung darstellen, mit der Unternehmensablaufe wie z.B. Zusammenarbeit, Abstimmung und Koopera- tion unterstutzt werden. Bezugnehmend auf die Bedingungen zur Realisierung eines Projektes und derer Randbedingungen, die durch einen Planer oder ein Planungs- Team erfasst und aufeinander abgestimmt werden, ist die Unterteilung in mehre- re Administrationsebenen erforderlich. Diese Zugangsberechtigungen sollen in der Groupware-Laosung geregelt werden. Der Zugang zu den einzelnen Administrations- bereichen sollte uber die Authentifizierung des Benutzernamen so wie dem zugeho- rigen Passwort erfolgen. Zusatzlich zu den individuellen Funktionen sollte allgemein die Anderungsmoglichkeit des eigenen Passwortes sowie eine sichere Abmeldefunkti- on zur Verfugung gestellt werden. Samtliche Administrationsfunktionen sollten uber eine Web-Client-System-Schnittstelle erreichbar sein. Des Weiteren ist es erforder- lich, Module unkompliziert in der Groupware integrieren zu konnen.

2.2 Geometrische Eigenschaften raumlicher Modelle

Beim Prozess der Modellbildung werden geographische Sachverhalte und Erschei- nungen und somit ihre Beziehungen und Geometrie vereinfacht. Die Generalisierung bezieht sich damit auf die Objekte, ihre Beziehungen und kartographische Darstel- lung.(Hake u. a. 2002, S. 168) Die Notwendigkeit der Vereinfachung von geographi- schen Sachverhalten ergibt sich einerseits aus den Beschrankungen der Hardware (Verarbeitungsgeschwindigkeit, Speicherplatzverbrauch, etc.) andererseits aus der Komplexitat des realen Modells der Welt. (Brinkhoff 2005, S. 59 bis 60) Sowohl bei der Datenerfassung geographischer Sachverhalte als auch bei der Modellbildung gehen Informationen verloren bzw. werden verfalscht. Es ist dennoch notwendig, die Komplexitat der realen Welt mittels geeigneter Modelle zu vereinfachen und zu verallgemeinern, um diese rechnergestuatzt verarbeiten und speichern zu kaonnen.

Modelle eigen sich, um raaumliche Zusammenhaange zu erklaaren und zu visualisie- ren.(Blaschke u. Lang 2007, S. 40) Die Eigenschaften jedes einzelnen Modelles lassen sich dabei in die Geometrie, Topologie, Thematik sowie Tempora zerlegen.(Brinkhoff 2005, S. 59 bis 60)

Digitale Geodaten, die abstrakte Objekte der realen Umwelt mit derer Geometrie beschreiben, bilden durch den Raumbezug einen zentralen Teil jedes GIS. (Bartelme 2005, S. 379)

Die Geometrie der Objekte, mit dem entsprechenden Raumbezug, kann dabei mit einem Arealem- oder einem Vektor-Modell beschrieben werden.(Hake u. a. 2002, S. 244 bis 248)

Innerhalb eines arealen Modells stellt eine Rasterzelle, die durch ein Koordinaten- Paar identifizierbar ist, den atomaren Bestandteil eines Objektes oder ein Objekt in seiner Gesamtheit dar.(Bartelme 2005, S. 131) Als eine Folge angehangter und zu- sammengesetzter Koordinate wird sowohl in einem Vektormodell als auch in einem Rastermodell eine Linie oder eine Flache gebildet. Innerhalb eines arealen Modells wird auf diese Weise eine Bildmatrix erzeugt. Die Geometrie der Objekte innerhalb eines Raster-Modells wird somit durch eine Summe bestimmter Raster-Farbwerte (Matrizenzellen) beschrieben. (Klein u. Fischer-Stabel 2005, S. 135) In der gesam- ten Bildmatrix kaonnen alle Rasterzellen der gleichen Ausdehnung und einer regelmaa- fiigen Anordung unterliegen. Aufgrund von Berechnung eines dreiecksvermaschten Hohenmodells ist die Anordnung des Rasters jedoch verzehrt (Bartelme 2005, S. 127 bis 128) und die Rasterzellen besitzen keine regelmafiigen Anordung mehr.

Vektorobjekte (Punkte, Linien, Flachen) werden mittels eines einzelnen Koordina- ten oder Koordinaten-Tupel (Entities) gebildet und eignen sich fur die Abbildung raumlich diskreter Objekte. Raumliche Kontinua hingegen wie beispielsweise Gelan- dehaohen koannen nur unzureichend dargestellt werden.

Ein weiterer Unterschied zwischen Raster- und Vektor-Daten ist in der Nutzung der Speicherressourcen zu sehen, die sich aus der Eigenmorphologie der Modelle ergeben. Wird eine durch die Zeilen- und Spaltennummer definierte Position (Koordinate) durch ein rechteckiges oder quadratisches Pixel belegt, handelt es sich um Raster- Daten, die als zweidimensionale Matrizen gespeichert werden.(Hake u. a. 2002, S. 244 bis 248) Jeder einzelne Pixel besitzt dabei einen Farb-Wert der ressourcenlastend abgespeichert wird. (Brinkhoff 2005, S. 127) Diese Modelbildung belastet die Spei- cherressourcen im Vergleich zu Vektormodellen erheblich. Da die durch Koordinate beschriebene Linie die fundamentale geometrische Einheit eines Vektormodells ist (Hake u. a. 2002, S. 157 bis 159) werden geometrische und semantische Informatio- nen uber Objekte auf eine grundlegend andere Weise beschrieben.(Hake u. a. 2002, S. 244 bis 248) Wo innerhalb arealer-Modelle flachige Basiselemente zur Modellierung gebraucht werden, kommt das Vektorenmodell mit der Angabe von Koordinaten fur ein Objekt zurecht. Die Datenorganisation vektorialer Modellbildung ist hierbei un- terschiedlich und hangt von dem jeweiligen kartographischen Modell ab. (Klein u. Fischer-Stabel 2005, S. 135)

Im Allgemeinen wird zwischen dem Spaghetti-Datenmodell, dem topologischen Da- tenmodell und als Weiterentwicklung des topologischen Datenmodells dem hierar- chischen Vektor-Datenmodell unterschieden.

Werden Nachbarschaftsbeziehungen aus redundanten gespeicherten Koordinaten er- rechnet, handelt es sich um ein Spaghetti-Datenmodell (s. Abb. 2.1.(Hake u. a. 2002, S. 157 bis 159) Hierbei entsteht eine lange Auflistung von Koordinatentupeln, die im Gegensatz zu dem topologischen Datenmodell (s. Abb. 2.2) keine topologische Strukturierung somit aber auch keine Nachbarschaftsbeziehungen aufweisen.(Klein u. Fischer-Stabel 2005, S. 135)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1: Unstrukturiertes Datenmodell („Spaghetti-Modell”) (Quelle: (Hake u. a. 2002, S. 158)

Werden Nachbarschaftsbeziehungen durch Kanten identifiziert, ist darunter das to­pologische Datenmodell (s. Abb. 2.2)zu verstehen.

In dem hierarchischen Vektor-Datenmodell (s. Abb.2.3) bildet eine Kette, die durch einen Anfangsknoten und einen Endknoten begrenzt ist, das entsprechende Ele- ment.(Hake u. a. 2002, S. 157 bis 159)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2: Topologisches Datenmodell (Quelle: (Hake u. a. 2002, S. 158))

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.3: Hierarchisches Vektormodell (Quelle: (Hake u. a. 2002, S. 159)

Strukturelle, thematische und temporale Eigenschaften

Geodaten geben, wie bereits im oberen Abschnitt aufgezeigt, weitere Eigenschaften der zu beschreibenden Objekte wieder (Bartelme 2005, S. 26). Unterschieden werden neben den bereits behandelten geometrischen Eigenschaften, die strukturellen, die thematischen und temporalen Eigenschaften.

Die Struktur der Daten wird durch die Morphologie der einzelnen Objekte gebildet. Ist ein Objekt aus mehreren Bestandteilen (Punkten) zusammengesetzt, wird ein Komplex gebildet. Jedes Objekt, d.h. jedes Komplex, besitzt eine eigene Geometrie. Innerhalb eines Raumbezugs lasst sich sowohl die Lage als auch die Ausdehnung jeder einzelnen atomaren Einheit verifizieren. Benachbarte oder iiberschneidende Objekte und deren Beziehungen untereinander lassen sich jedoch nicht ausschliefi- lich uber Koordinatenangaben lOsen, wie beispielsweise in dem ,,Spaghetti-Modell” (s. Abb. 2.1), sondern mit topologischen Eigenschaften (s. Abb. 2.2), die es ermag- lichen, Nachbarschaftsbeziehungen durch Kanten, Objektnamen oder -nummern zu identifizieren.

Die thematische Eigenschaft geht aus dem Charakteristikum jedes Objekts hervor und bildet sich aus der Semantik. Die Unterscheidung findet zwischen den nomina- len Eigenschaften, die die Bezeichnung eines Objektes wiedergeben, den qualitati- ven Eigenschaften, die den vorhandenen Status wiedergeben und den quantitativen Eigenschaften, die eine Menge wiedergeben, statt. (Brinkhoff 2005, S. 60) Sowohl in- nerhalb der nominalen als auch innerhalb der quantitativen Eigenschaften der Ob­jekte darf es nicht zu Uberlappungen oder Uberschneidungen kommen. Innerhalb qualitativer Eigenschaften ist eine Uberlappung oder Uberschneidung innerhalb von Landschaftsanalysen sogar notwendig, um die Komplexitat der realen Welt zu ab- strahieren.

Die Thematik der Geoinformation gibt wiederum Aufschluss uber die semantische Bedeutung der einzelnen geometrischen Objekte. Einerseits stellen beide Inhalte starke Kontraste dar, andererseits wirken sie jedoch wie in einer Symbiose, ergan- zen einander und werden in der Gesamtheit als georelationales Modell bezeichnet. (Bartelme 2005, S. 179) Die Speicherung jedes einzelnen Modells kann sowohl in Datenbanken wie in einzelnen Dateien erfolgen. Die Speicherung der Inhalte in al- phanumerischer und geometrischer Attribute in einzelnen Dateien weisen jedoch auf altere GIS hin.(Brinkhoff 2005, S.27) Die Tabellen in einer relationalen Datenbank eines Datenbank-System setzen sich aus Zeilen (Rows) und Spalten (Columns) zu- sammen. Innerhalb relationaler Tabellen werden Tabellen durch einen Schltissel in Beziehung (Relation) gesetzt. Auf diesem Weg ist es maglich, Redundanzen, Fehler in der Datenhaltung und Inkonsistenz der Daten zu vermeiden. Uber eine festgelegte Sprache, die von dem DBMS interpretiert werden kann, erfolgt eine Verbindung zu einer Datenbank aus einer beliebigen Anwendung, sofern diese fahig ist mit Daten- banken uber eine System-Schnittstelle zu kommunizieren. Erfolgt die Speicherung der einzelnen Modelle in einzelnen Dateien, wird das Modell in einer strukturierten Abfolge hinterlegt, so dass eine Datenbank, die in einer Anwendung integriert ist, diese auslesen kann.

2.2.1 Konzepte geographischer Sachverhalte

Die Gegebenheit, in der sich Objekte auf oder unter der Erdoberflache befinden, lassen sich in konzeptionellen Sachverhalte einteilen. Einerseits ist jedes einzelne ge- gebene Objekte auf der Erdoberflache ein komplexes Gebilde, da es sich aus Punkten zusammensetzt, die durch Linien miteinander verbunden sind. Andererseits lasst sich die Gesamtheit der Objekte in unterschiedliche Interessenspharen einteilen, wobei sich jede einzelne Interessensphare aus beliebig vielen komplexen Objekten zusam- men setzen kann.

Das Ebenen-Konzept

Mit der Trennung der Interessenspharen geographischer Sachverhalte wird eine Grob- sortierung vollzogen. Fur einige Kombinationen von Entitaten erscheint die Daten- struktur unterschiedliche Sachverhalte des gleichen Raumausschnittes (wie Beispiel- weise das Gewasser, die Gebaude und Parkplatze) in getrennten Dateien oder Tabel- len als sinnvoll. (Bartelme 2005, S. 57 bis 60) In einem GIS lassen sich so je nach den Anforderungen, die Ebenen miteinander kombinieren. Eine entsprechende Graphik wird so nicht in ihrer Gesamtheit neu gezeichnet, wenn eine Ebene neu aktiviert wird, sondern es muss lediglich nur ein Teil der Graphik visualisiert werden.

Voraussetzungen zur Trennung von Interessenspharen geographischer Sach­verhalte

1. Es muss ein definierter Zustand eines Raumes vorhanden sein. (Existiert ein Phanomen einer bestimmten Art oder nicht?)
2. Die Metrik, der Mafistab und die Genauigkeit (Generalisierungsgrad) mussen mit allen darzustellenden Inhalten uabereinstimmen.

Mit einer Layerstuktur wird eine vereinfachte Zuweisung der Zugriffsrechte innerhalb eines Systems ermoglicht.(Bartelme 2005, S. 58 bis 59) Fur jede einzelne Ebene wird eine eigene Datei oder Tabelle erstellt, der spezifische Zugriffsrechte zugeordnet werden koannen.

Das objektorientierte Konzept

Im Gegensatz zu dem Ebenen-Konzept, das auf einer Auffacherung des Datenbestan- des eines gleichen Raumausschnittes basiert, werden im objektorientierten Konzept komplexe Gebilde (Objekte) verwaltet. Jedes Objekt stellt dabei einen gesamten Komplex dar. (Bartelme 2005, S. 60) Diese Objekte sind wie bereits im voran- gehenden Kapitel beschrieben, aus Linien zusammengesetzt, wobei die Linien aus der Verbindung von Punkten (Koordinaten) entstehen. Das objektorientierte Prin- zip erlaubt die Definition von Abfrage-, Analyse-, Bearbeitungs- und Darstellungs- Methoden ausgewahlter Objektklassen.(Bartelme 2005, S. 61)

2.3 Funktionen und Struktur von Moskito GIS

Die Software Moskito GIS hat sich aus der Anwendung GRADIS entwickelt, die in einem Energieversorgungsunternehmen konzipiert und verwendet wurde. Aufgrund dessen ist diese Software auf die Beduarfnisse von Energieversorgungsunternehmen spezialisiert. Das Moskito GIS, in dem raumbezogene Daten eine bedeutende Beruack- sichtigung erhalten, basiert auf einer alteren Struktur. Wie jedes andere bekannte GIS bietet das Moskito GIS verschiedene Funktionalitaten der Datenverarbeitung.

Die Erfassung von Objekten erfolgt liber eine freie Konstruktion neuer graphischer Objekte. Konstruierte Objekte werden in einer Datei des Typs HDF gesichert. Die HDF-Datei beinhaltet Referenzen zu anderen Datensatzen mit denen diese verknupft ist und stellt somit einen Plan dar. Die Software selbst liest die realen oder abstrakten Objekte unserer Umwelt aus einem HDF-Plan mit samtlichen Verknupfungen aus und reflektiert diese innerhalb der Anzeige der Applikation.

Innerhalb des Moskito GIS sind Analysefunktionen wie Rechenoperationen (Summe, Differenz), Selektion (nach Objekttyp, Objektgruppen), Auswahl (nach dem Inhalt eines oder mehrerer Attribute) und Berechnungen (von Flachen, Langen, Schwer- punkte und Positionen) der Elemente moglich.

Die Praasentation erfasster und analysierter Daten in Form eines objektorientier- ten Konzepts erfolgt fur ein Planungsunternehmen zur Zeit der aktuellen Version

(Moskito GIS 4.01) auf einem niedrigen Niveau. Eine Layout-Einrichtung mit ent- sprechenden Inhalten (Karten-, Mafistab, Titel, Legende, Ausrichtung) auf einem direkten Weg ist nicht moglich. Die Zuordnung des Verhaltens ausgewahlter Objek-

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.4: Die Arbeitsstation von Moskito GIS

te, ist beispielsweise mittels einer entsprechenden Batch-Datei, die Befehle enthalt, moglich. Beim Aufruf der Datei werden die Befehle abgearbeitet und den Objektklas- sen ein Verhalten zugewiesen. Diese Kapselung ermoglicht eine getrennte Haltung der Dateien und deren Eigenschaften.

2.3.1 Verzeichnis-Struktur von Moskito GIS

Die Moskito GIS-Arbeitsstation ist eine universell einsetzbare klassische GIS-Software. (Klein u. Fischer-Stabel 2005, S. 139) Die Software arbeitet mit Anwendungsmodu- len (z.B. Gas, Wasser, Strom, Kataster), die die entsprechenden Fachschalen bil- den.(Bartelme 2005, S. 19) Die Struktur der Anwendungsmodule spiegelt sich in der Verzeichnisstruktur des Moskito GIS wieder (s. Abb. 2.5). In der Abbildung 2.5 ist eine beispielhafte Darstellung der Ordnerstruktur visualisiert, die sich auf die wesentlichen Inhalte beschrankt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.5: Beispiel einer Ordner-Struktur einer Moskito GIS Komponente

In dem Applikations-Verzeichnis werden die Fachschalen mit entsprechenden Fach- schalen-Inhalten abgelegt. Als Inhalte einer beispielhaften Fachschale werden folgen- dene Verzeichnisinhalte aufgelistet.

Verzeichnisinhalte einer beispielhaften Fachschale CMD: Unter diesem Daten- Typ werden Batch-Dateien abgespeichert, die nach dem Aufruf die eingetragenen Befehle nacheinander abarbeiten.

MDB: In der Datenbank Datei der Datenbank Microsoft Access mit der Endung .mdb werden thematische Eigenschften eines Plans gesichert.

DOC: In dem Microsoft Word-Dokument werden fachschalenspezifische Informatio- nen abgelegt.

DAT: In dem Datei-Format werden Fachschalen bezogene Daten gehalten.

SIC: Innerhalb dieser Datei werden Signaturen fur unterschiedliche DKA- und DKY- Nummern vergeben.

SYM: Diese Datei beinhaltet die zu einer Fachschale gehorende Symbole sowie deren Formatierung und Farbzuweisung.

Das Schema des Verzeichnisses ApplicationData, das in der Abbildung 2.5) dar- gestellt wird, beinhaltet die Daten, die einer bestimmten Applikation (Fachschale) zugeordnet werden. Am Beispiel der Demo-Daten des Moskito GIS ist in der Fach­schale Kanal das Verzeichnis Dbb abgelegt, in dem der Inhalt in unterschiedlichen Planarten strukturiert gehalten wird. Die Plane Haltung, Schaden und Schacht beinhalten mindestens einen HDF-Dateityp. Der HDF-Dateityp stellt im typischen Sinn keine einzelne Ebene dar, sondern einen Plan. Sind jedoch Daten aus einem anderen auf Ebenen beruhenden Konzept eines GIS z.B. ArcGIS importiert, stellt der HDF-Dateityp eine einzelne Ebene dar.

2.3.2 Datenstruktur eines HDF-Plans

Um Daten effektiv nutzen zu konnen, muss ein Wissen dartiber vorhanden sein, welches Format und in welcher Struktur dieses Format vorliegt.(Mitchell 2008, S. 21)

Die im vorherigen Abschnitt analysierte Struktur weist auf eine getrennte Speiche- rung alphanumerischer- und geometrischer Attribute hin, wobei die geometrischen Attribute in einer alphanumerischen Form in der HDF-Datei hierarchisch abgelegt werden und die Komplexitat der Objekte wiedergeben.

Am Anfang der HDF-Datei (Zeile 3 bis 6) wird die Ausdehnung des darzustellenden Gebietes in Form von Koordinatenangaben mittels Xlow, Ylow, Xhigh und Yhigh vorgenommen.

[...]