Erstellung einer prototypischen Darstellungskomponente für Raster- und Vektordaten

Inhaltsverzeichnis

Vorwort
1.1 Einleitung
1.2 Aufbau der Diplomarbeit

2 Verwendete Technologien
2.1 OpenGL
2.2 GLUT
2.3 glow
2.4 ImageMagick
2.5 omniORB
2.6 Xerces

3 Entwurfsphase
3.1 Besonderheiten bei einer Darstellungskomponente für die Luftbildauswertung
3.2 Kernanforderungen an die Darstellungskomponente
3.3 Designentscheidungen beim Softwareentwurf

4 Realisierungsphase

5 Zusammenfassung und Ausblick

A Literaturverzeichnis

B Glossar

C Stichwortverzeichnis
Konfigurationsmanagement
C.1 Systeme
C.1.1 Entwicklung
C.1.2 Zielsysteme beim Kunden
C.2 Entwicklungsumgebung
C.3 Installation OpenGL
C.3.1 OpenGL unter Windows
C.3.2 OpenGL unter Linux
C.4 Installation GLUT
C.4.1 GLUT unter Windows
C.4.2 GLUT unter Linux
C.5 Installation glow
C.5.1 glow unter Windows
C.5.2 glow unter Linux
C.6 Installation ImageMagick
C.6.1 ImageMagick unter Windows
C.6.2 ImageMagick unter Linux
C.7 Installation omniORB
C.7.1 omniORB unter Windows
C.7.2 omniORB unter Linux
C.8 Installation Xerces
C.8.1 Xerces unter Windows
C.8.2 Xerces unter Linux

D Demonstrationsprogramme – Übersicht

Abbildungsverzeichnis

Abbildung 1 - Übersicht V-Modell (siehe S.24 [VMOD95])

Abbildung 2 - Unabhängiges Konsortium von OpenGL - Architecture Review Board (ARB)

Abbildung 3 - Besonderheiten - Kombination von Raster- und Vektordaten [GUGL04]

Abbildung 4 - Besonderheiten - Bildauflösung

Abbildung 5 - Besonderheiten - Georeferenzierung [GEO04]

Abbildung 6 - Kernanforderungen - Konfigurierbarkeit

Abbildung 7 - Kernanforderungen - Verteiltes System / Portabilität

Abbildung 8 - Kernanforderungen - generische Nutzdatenschnittstelle

Abbildung 9 - Kernanforderungen - Kachelformat bei Bilddaten

Abbildung 10 - Kernanforderungen - Pufferung der Bilddaten

Abbildung 11 - Kernanforderungen - Ausprägung von Vektoren [CARD04]

Abbildung 12 - Kernanforderungen - Grundeigenschaften von Vektoren

Abbildung 13 - Kernanforderungen - Interaktion mit Georeferenzierung

Abbildung 14 - Designentscheidungen - Architektur

Abbildung 15 - Designentscheidungen - Standard Coding Idiom

Abbildung 16 - Designentscheidungen - Containerklassen

Abbildung 17 - Designentscheidungen - Observer-Muster [PAT98]

Abbildung 18 - Designentscheidungen - ICD Nachrichtenstruktur

Abbildung 19 - Designentscheidungen - Composite-Muster

Abbildung 20 - Designentscheidungen - Bridge-Muster

Abbildung 21 - Realisierung - Magick Ausnahmebehandlung [MAPI04]

Abbildung 22 - Realisierung - GUI der Prototyp Darstellungskomponente

Abbildung 23 - Realisierung - Darstellungskomponente als GlowSubwindow

Abbildung 24 - Realisierung - Strukturierung von OpenGL-Funktionen (siehe S.47 [WRIGHT04])

Abbildung 25 - Realisierung - Texture Mapping bei OpenGL (siehe S.382 [WRIGHT04])

Abbildung 26 - Realisierung - Dreidimensionales Texture Mapping (siehe S.390 [WRIGHT04])

Abbildung 27 - Realisierung - Quadrantenarchitektur und Zoomverhalten

Abbildung 28 - Dokumentenübersicht

Abbildung 29 - Realisierungsabdeckung des Prototyps

Abbildung 30 - OpenGL - Architektur unter Windows [SGL04]

Abbildung 31 - glow - Anlegen des neuen Projektes unter Visual Studio

Abbildung 32 - glow - Projekt mit zugewiesenen Quelldateien

Abbildung 33 - glow - Eintrag der Präprozessoranweisungen

Abbildung 34 - glow - Includeverzeichnisse bei Projekten

Abbildung 35 - glow - Bibliothekverzeichnisse bei Projekten

Abbildung 36 - ImageMagick - Einstellungen des Dialogs Target Setup

Abbildung 37 - ImageMagick - Einstellungen des Dialogs System Setup

Abbildung 38 - ImageMagick - Auswahl der aktiven Konfiguration

Abbildung 39 - omniORB - Eintrag des Namensdienstes in die Windowsregistrierung

Abbildung 40 - Demonstrationsprogramme

Unternehmen

Das Thema dieser Diplomarbeit wurde ausgegeben durch die

Abbildung in dieser Leseprobe nicht enthalten

EADS Deutschland GmbH

Defence and Communications Systems

IRGS3, Recce & UAV GS

D-88039 Friedrichshafen

Vorwort

1.1 Einleitung

Der Bereich Softwareentwicklung ist geprägt von Schnelllebigkeit und zunehmender Komplexität der Anforderungen. Auftraggeber legen demgegenüber bei Individuallösungen immer mehr Wert auf Eigenschaften wie Portabilität, Konfigurierbarkeit und Erweiterbarkeit. Die Gegenüberstellung des Marktverhaltens bei der Software- und Systemtechnik und Anforderungen der Kunden an solche Produkte macht deutlich, dass die Realisierung von Unikaten nicht mehr praktikabel ist. Daher steigt die Tendenz zur Entwicklung von universell einsetzbaren Modulen mit generischen Schnittstellen zunehmend. Der Einsatz universeller Module bei Kundenlösungen verkürzt die Entwicklungsdauer und erhöht trotzdem die Softwarequalität.

Dieser Ansatz soll als Motivation für das vorliegende Projekt dienen. Die Darstellungskomponente soll sich durch Eigenschaften wie Plattformunabhängigkeit, Konfigurierbarkeit, generische Schnittstellen und Erweiterbarkeit auszeichnen (vergleiche [STE05]).

Zielsetzung

Ziel der Diplomarbeit ist die „Erstellung einer prototypischen Darstellungskomponente für Raster- und Vektordaten, lauffähig unter Linux und

Windows“. Der Schwerpunkt bei der Durchführung liegt dabei auf der Entwurfsphase des Projektes. Nach der Entwurfsphase wird eine Prototypsoftware gemäß den zuvor erstellten technischen Dokumenten realisiert. Die Prototypsoftware erhebt keinerlei Anspruch auf Vollständigkeit. Der Prototyp soll als Bestätigung für den erstellten Entwurf dienen und die Designentscheidungen rechtfertigen.

Beim Entwurf und der Realisierung des Prototyps ist auf eine vollständige Dokumentation zu achten, damit bei der Fortführung dieses Projektes eine möglichst große Informationsbasis gegeben ist (vergleiche [STE05]). Die Ergebnisse der Diplomarbeit (Entwurf, Prototyp) sollen als Basis für die Entwicklung einer generischen Darstellungskomponente dienen, die als Modul in operationellen Systemen integriert werden kann.

1.2 Aufbau der Diplomarbeit

Im folgenden Kapitel wird zunächst auf das Vorgehensmodell bei der Durchführung der Diplomarbeit eingegangen. Im Anschluss werden die bei diesem Projekt verwendeten Technologien erläutert.

Das Kapitel 3 bildet den Hauptteil dieser Arbeit. In diesem Kapitel wird zunächst auf Besonderheiten eingegangen, die im Hinblick auf das Ergebnis zu berücksichtigen sind. Weiterhin werden in diesem Kapitel die entscheidenden Anforderungen erläutert. Ergänzt werden die Anforderungen durch die zentralen Designentscheidungen des Softwareentwurfs. Im Kapitel 4 sind die bei der Implementierung gesammelten Erfahrungen zusammengefasst. Kapitel 6 bietet dem Leser anschließend noch eine Zusammenfassung des Projektes und einen Ausblick für die Weiterentwicklung.

Abgerundet wird diese Arbeit durch einen ausführlichen Anhang, der besonders für Entwickler von Bedeutung ist, da er ein Kapitel über das Konfigurationsmanagement umfasst.

Vorgehensmodell

Die Vorgehensweise bei dieser Arbeit erfolgt gemäß V-Modell für Produktentwicklung. Da es sich um ein reines Softwareentwicklungsprojekt handelt, kommt an dieser Stelle das Submodell für Softwareentwicklung zum Einsatz (siehe Abbildung 1 - Übersicht V-Modell (siehe S.24 [VMOD95])).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1 - Übersicht V-Modell (siehe S.24 [VMOD95])

Bezogen auf das V-Modell (siehe Abbildung 1 - Übersicht V-Modell (siehe S.24 [VMOD95])) erfolgt an dieser Stelle die Einschränkung auf die Teilschritte SWE1 bis SWE6, da die Hauptaufgabe im Entwurf der Darstellungskomponente besteht.

Im Rahmen dieser Diplomarbeit gehen dabei aus der Entwurfsphase die folgenden Dokumente hervor:

- Afo (Anwenderforderungen)
- TAnf (Technische Anforderungen)
- Softwarearchitekturdokument
- ICD (Interface Control Document)
- CRC-Karten (Class-Responsibility-Collaborators)
- Softwareentwurfsdokument

Bei der Darstellungskomponente handelt es sich um eine Komponente und nicht um ein Gesamtsystem, weshalb die Erstellung einer Systemarchitektur an dieser Stelle entfällt.

Die Kernaussagen aller Entwurfsdokumente sind in Kapitel 3 zusammengefasst. Da durch ein Vorgehensmodell die Qualität einer Arbeit qualitativ erhöht werden soll, bietet der Anhang dieser Diplomarbeit zusätzlich noch ein Kapitel 0 über Konfigurationsmanagement. In diesem Kapitel wird die gesamte Entwicklungsumgebung festgehalten. Dies ermöglicht die Reproduzierbarkeit der während der Diplomarbeit verwendeten Umgebung und leistet somit ebenfalls einen Beitrag zur Qualitätssicherung.

Der Teilbereich SWE6 – Implementierung (siehe Abbildung 1 - Übersicht V-Modell (siehe S.24 [VMOD95])) erfolgt im Rahmen dieser Arbeit nur in Form einer Prototypanwendung zur Bestätigung und Demonstration des erstellten Entwurfs. Der Prototyp soll als Basis für die vollständige Implementierung dienen.

2 Verwendete Technologien

2.1 OpenGL

OpenGL gilt als die erste Umgebung zur Entwicklung von portablen und interaktiven 2D und 3D Grafikanwendungen [GL04]. Die Grafikbibliothek ist 1992 von dem Unternehmen Silicon Graphics, Inc. (SGI) in der Öffentlichkeit vorgestellt worden. Das Unternehmen nahm dabei die eigene Grafikbibliothek IRIS GL als Grundlage für die Realisierung von OpenGL. Ziel von SGI war es, einen neuen 3D Grafikstandard ins Leben zu rufen [WRIGHT04].

Die Bibliothek besteht derzeit aus ca. 250 unabhängigen Funktionen zur Spezifizierung von Objekten und Operationen. OpenGL stellt dabei jedoch keine Schnittstelle auf hohem Abstraktionsniveau bereit. Alle noch so komplexen Modelle müssen über die Verknüpfung von geometrischen Primitiven vom Anwender selbst erzeugt werden [SHR04].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2 - Unabhängiges Konsortium von OpenGL - Architecture Review Board (ARB)

Als Vorteile erweisen sich für den Anwendungsentwickler die im Folgenden aufgeführten Argumente [GL04]:

- OpenGL ist heute ein weit verbreiteter Industriestandard dessen Spezifikation durch ein unabhängiges Konsortium (siehe Abbildung 2 - Unabhängiges Konsortium von OpenGL - Architecture Review Board) gepflegt wird.
- OpenGL ist bereits seit über 7 Jahren für eine Vielzahl von Plattformen verfügbar.
- OpenGL ist immer abwärtskompatibel, weshalb bestehende Anwendungen trotz neuer Versionen einsatzbereit bleiben.
- Anwendungen produzieren konsistente grafische Resultate unabhängig von Betriebssystem oder Fenstersystem.
- Das Design von OpenGL erlaubt es, dass Hardwareinnovationen über den OpenGL Extension Mechanismus verfügbar werden.
- OpenGL ist bezüglich der Zielplattform skalierbar.
- OpenGL ist für eine Vielzahl von Programmiersprachen verfügbar wie z. B. Ada, C, C++, Fortran, Python, Perl und Java

2.2 GLUT

Das OpenGL Utility Toolkit (GLUT) ist ein fenstersystem- und plattformunabhängiges Toolkit zur Realisierung von OpenGL Anwendungen. Es ist darauf ausgelegt, schnell und einfach OpenGL Anwendungen zu erstellen. Daher stellt GLUT auch keine vollständige API für grafische Oberflächen bereit. Es sollte nur für Anwendungen mit kleinem und mittlerem Schwierigkeitsgrad verwendet werden. Bei Anwendungen mit aufwendiger grafischer Oberfläche sollte stattdessen auf ein zielsystembasiertes Toolkit zurückgegriffen werden [GLUT04].

Die Verwendung von GLUT bringt folgende Vorteile und Eigenschaften mit sich [GLUT04]:

- Fenstersystemunabhängig
- Plattformunabhängig
- Callback gesteuerte Ereignisbehandlung
- Idle-Routine und Timerfunktionalität
- Unterstützung von mehreren Fenstern beziehungsweise Grafikkontexten zur selben Zeit

2.3 glow

glow ist ein plattformunabhängiges Toolkit, das ein objektorientiertes Framework zur Erstellung von interaktiven Anwendungen bereitstellt. Unter interaktiven Anwendungen sind in diesem Fall Anwendungen zu verstehen, die für die Grafikdarstellung Bibliotheken wie OpenGL oder Mesa verwenden. Das Kernstück von glow bildet der Wrapper für GLUT.

Durch den objektorientierten Ansatz von glow bietet diese Bibliothek jedoch mehrere Vorteile gegenüber GLUT. glow bietet nicht nur Wrapper für GLUT Funktionalität an, sondern auch eine Reihe von konfigurierbaren GUI-Elementen. Durch Vererbungsmechanismen wird dem Anwender zusätzlich die Möglichkeit geboten, auf einfache Weise eigene GUI-Elemente zu erzeugen beziehungsweise bestehende GUI-Elemente für den eigenen Verwendungszweck zu spezialisieren [GLOW04].

Die Wrapperbibliothek ist für „write-once-compile-anywhere“ [GLOW04] Entwicklung konzipiert. Eine Anwendung, die auf glow basiert, sollte daher auf jedes System portabel sein, auf dem OpenGL und GLUT verfügbar sind.

Im Folgenden sind die Merkmale von glow laut Webseite aufgelistet (originalgetreu übernommen [GLOW04]):

- Object-oriented C++ API wrapper for GLUT

- Create windows, subwindows and menus with a single line of code by constructing objects.
- Operations on windows, subwindows and menus accomplished by method calls. (You do not need to juggle IDs.)
- Events reported directly to objects via virtual methods. (You do not need to keep track of callbacks.)
- Easy reference to fonts and colors via objects.
- Clean deletion of objects by object destructors.
- Typechecked sender-receiver object classes.

- Extensions to GLUT interfaces.

- Component hierarchy for organization and reuse of drawable objects.
- Recursive activation and deactivation of components. Automatically affects event delivery.
- Simulation of modal windows and non-resizable windows.
- Utility components, including a 3D manipulator based on the arcball algorithm.
- Additional menu manipulation capabilities, including inserting and marking items.
- Automatic computation of additional state, including font metrics, local window positions and menu status.

- Powerful, extensible widget system.

- Widgets may appear in any number of windows and subwindows.
- High-level API creates widgets with a single line of code and automatically lays widgets out.
- Low-level API allows precise control of widget placement and options.
- Predefined message windows and text entry windows for quick creation of alerts and user input dialogs with a single line of code.
- Hierarchical arrangement of widgets using panels and other containers.
- Recursive visibility and activation for widgets.
- Easy management of widget keyboard focus.
- Widget events may be reported via virtual methods or receiver objects.
- Widgets appear and behave the same across platforms.
- Custom widgets may be written and fully integrated into the system.

- Large widget library.

- Push buttons
- Check boxes, 3-state check boxes
- Radio buttons, radio button groups
- Menu buttons, popup menus
- Sliders, including linear and logarithmic scales
- Proportional scroll bars
- Text labels
- Editable text fields, protected text fields (for passwords, etc.)
- Organization panels, separator rules

- Source code compatible across platforms.

- Written in ANSI/ISO compliant C++.
- No platform-specific code. Supports write-once-compile-anywhere development.

2.4 ImageMagick

ImageMagick ist eine Framework, das Tools und Bibliotheken zum Lesen, Schreiben und Bearbeiten von Bildern bereitstellt. Insgesamt unterstützt das Framework über 90 Standardbildformate wie beispielsweise tiff, jpeg, gif u. a.. ImageMagick zeichnet sich aber nicht nur durch seine Vielzahl an unterstützten Bildformaten aus, es bietet auch aus programmiertechnischer Sicht eine breite Schnittstelle an. Bildoperationen können über die Kommandozeile, C, C++, Perl, Java, PHP, Python oder Ruby angesprochen werden [MAG04].

Auf der Webseite von ImageMagick wird die Funktionalität exemplarisch wie folgt charakterisiert (originalgetreu übernommen [MAG04]):

- Convert an image from one format to another (e.g. TIFF to JPEG)
- Resize, rotate, sharpen, color reduce, or add special effects ro an image
- Create a montage of image thumbnails
- Create a transparent image suitable for use on the Web
- Turn a group of images in a GIF animation sequence
- Create a composite image by combining several separate images
- Draw shapes or text on an image
- Decorate an image with a border or frame
- Describe the format an characteristics of an image

2.5 omniORB

omniORB ist eine Open Source CORBA Implementation. Das Toolkit wurde ursprünglich für den Einsatz in embedded systems bei der Olivetti Research Ltd. entwickelt. Der Einsatz von omniORB wurde aber ständig ausgeweitet, da dieser zu der Zeit besser war als viele kommerzielle ORBs. Am 12. Mai 1997 wurde die Version omniORB 2.2.0 unter der General Public License als Release herausgegeben. Die Weiterentwicklung erfolgte weiterhin durch die AT&T Laboratories (ehemals Olivetti). Durch deren Schließung am 24. April 2002 wurde omniORB zu einem offenen Projekt. Heute wird omniORB durch Apasphere Ltd. entwickelt und betreut [OMNI04].

omniORB besitzt laut der offiziellen Webseite in der Version 4.0.0 folgende Eigenschaften (originalgetreu übernommen [OMNI04]):

- C++ and Python language bindings.
- Adheres to the CORBA 2.6 specification.
- Support for GIOP and IIOP 1.0, 1.1 and 1.2.
- Fully multithreaded runtime.
- TypeCode and type Any.
- CORBA 2.6 DynAny interfaces.
- Dynamic Invocation and Dynamic Skeleton interfaces.
- Complete Naming Service, omniNames.
- Support for wchar, wstring and code set negotiation.
- Full long long, long double, fixed point support.
- PortableServer::Current.
- Unix domain socket transport.
- Bidirectional GIOP.
- Interoperable Secure Socket Layer transport.
- Flexible thread management.
- Interceptors.

- The following platforms are supported (although some have only been tested with earlier releases):

- Windows NT / XP / 9x with Visual C++ version 5.0 and above
- Linux / EGCS 2.91 or GCC 2.95 and above
- Solaris 2.{5,6,7,8} / Sun C++ version 4.2 and above, or GCC 2.95 and above
- HPUX 11.00/ aC++
- SGI Irix 6.x/ SGI C++ compiler 7.2
- Digital Unix 4.0D/ DEC C++ compiler version 6.0
- IBM AIX 4.2/ IBM C Set++ 3.1.4 and xlC 5.0 (Visual Age C++ 5.0)
- IBM AIX 4.3/ IBM C Set++ 3.6.6 and xlC 5.0 (Visual Age C++ 5.0)
- HPUX 10.20/ aC++ (B3910 A.01.04)
- OpenVMS Alpha 6.2/ DEC C++ compiler 6.2/5.5 (UCX 4.1 ECO 8)
- OpenVMS Vax 6.1/ DEC C++ compiler 5.5 (UCX 4.0 ECO 1)
- NextStep 3.3/ gcc-2.7.2
- Reliant Unix 5.43/CDS++
- Phar Lap’s Real Time ETS Kernel
- SCO Unixware 7
- Mac OS X
- Fujitsu Siemens BS2000 (with patch in the distribution)
- …and many others.

· Fully interoperable with other CORBA ORBs.

2.6 Xerces

Xerces ist ein XML-Parser, der für verschiedene Programmiersprachen wie C++, Java und Perl verfügbar ist. Neben der Vielzahl der Programmier-plattformen werden zahlreiche Plattformen und Compiler unterstützt.

Bei diesem Projekt soll die C++ Ausführung der Bibliothek zum Einsatz kommen. Xerces-C++ befindet sich zum Zeitpunkt der Erstellung dieser Arbeit in der Version 2.6.0. Diese Version unterstützt Betriebssysteme wie Windows, Solaris, HP-UX und Linux. Zu den unterstützten Compilern gehört das Visual Studio 6 Service Pack 3, aCC und gcc [XML04].

Die Bibliothek zeichnet sich laut der offiziellen Webseite durch folgende Eigenschaften aus (originalgetreu übernommen [XML04]):

- Conforms to

- XML 1.0 (Third Edition), W3C Recommendation
- XML 1.1 (First Edition), W3C Recommendation (Note: section 2.13 Normalization Checking has not been implemented)
- DOM Level 1 Specification, W3C Recommendation of October 1, 1998
- DOM Level 2 Core Specification, W3C Recommendation of November 13, 2000
- DOM Level 2 Traversal and Range Specification, W3C Recommendation of November 13, 2000
- SAX 1.0 and SAX 2.0
- Namespaces in XML, W3C Recommendation of January 14, 1999
- XML Schema Part 1: Structure, W3C Recommendation 2 May 2001
- XML Schema Part 2: Datatypes, W3C Recommendation 2 May 2001
- Full experimental implementation of Namespaces in XML 1.1, W3C Candidate Recommendation of 18 December 2002
- Contains a partial implementation of the DOM Level 3.0 Core Specification, Version 1.0 W3C Working Draft 26 February 2003 and Document Object Model (DOM) Level 3 Load and Save Specification, Version 1.0 W3C Working Draft 26 February 2003. This implementation is experimental. See DOM Level 3 Support for detail.
- Source code, samples, and documentation is provided
- Programmatic generation and validation of XML
- Pluggable catalogs, validators and encodings
- High performance
- Customizable error handling

3 Entwurfsphase

3.1 Besonderheiten bei einer Darstellungskomponente für die Luftbildauswertung

Um die Motivation für die Entwicklung einer speziellen Darstellungskomponente zu verdeutlichen, sollte zunächst ein Vergleich angestellt werden. Der Vergleich mit dem Bereich der Standardsoftware macht sehr schnell deutlich, dass bei einer Darstellungskomponente in der Luftbildauswertung andere Schwerpunkte und Anforderungen zum Tragen kommen. Zum Bereich Standardsoftware gehören Anwendungen wie IrfanView oder XnView, aber auch kommerzielle Produkte wie der Microsoft Photo Editor sind hier einzuordnen. Geschäftslösungen wie Adobe Photoshop oder Ulead PhotoImpact sollen an dieser Stelle nicht zum Vergleich herangezogen werden, da professionelle Bildverarbeitungsprogramme bedingt auch Anforderungen für die Luftbildauswertung erfüllen.

Neben Lösungen wie Adobe Photoshop gibt es auch kommerzielle Produkte speziell für die Luftbildauswertung. Produkte wie Erdas Imagine von Leica Geosystems stellen dem Anwender eine vollständige Umgebung für Luftbildauswertung zur Verfügung (siehe [GIS05]). Eine solche in sich geschlossene Lösung hat aber den Nachteil, dass sie einen festen Funktionsumfang besitzt. Derartige Produkte sind nicht für die Integration in ein Gesamtsystem konzipiert. Außerdem ist es in der Regel nicht möglich, die Funktionalität den Anwenderforderungen anzupassen. Einer solchen kommerziellen Lösung fehlen somit Eigenschaften wie Konfigurierbarkeit und Erweiterbarkeit. Da diese Eigenschaften bei dem hier vorliegenden Projekt zu den Anwenderforderungen gehören, ist der Einsatz eines fertigen Produktes somit nicht praktikabel.

Wie der Begriff Luftbildauswertung beinahe schon selbsterklärend aussagt, handelt es sich um die Auswertung von Bildmaterial. Um eine Auswertung durchführen zu können, müssen dem Anwender unter anderem Symbole und Vektoren zur Verfügung stehen. Diese dienen als Werkzeuge, um besondere Gegebenheiten kenntlich zu machen, die für den jeweiligen Zusammenhang von Bedeutung sind.

Bei der Abbildung 3 - Besonderheiten - Kombination von Raster- und Vektordaten [GUGL04] handelt es sich um ein Beispiel für eine Luftbildaufnahme, die im Rahmen der Auswertung mit roten und blauen Vektoren versehen wurde.

Bei der Kombination von Raster- und Vektordaten im Bereich Luftbildauswertung ist zusätzlich noch zu beachten, dass Vektordaten für die persistente Datenhaltung nicht in Rasterdaten überführt werden. Da diese auch über den Speichervorgang hinaus editierbar und selektierbar bleiben sollen, sind Vektordaten auch eigenständig und in Form von Vektoren abzulegen. Es ist daher außerdem eine Referenzierung zwischen den Raster- und Vektordaten notwendig. Im Gegensatz dazu bieten Produkte aus dem Bereich Standardsoftware entweder gar keine Kombination von Raster- und Vektordaten an oder die Daten werden letztlich vollständig in Rasterdaten überführt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3 - Besonderheiten - Kombination von Raster- und Vektordaten [GUGL04]

Auch die Größe der zu unterstützenden Bilddaten stellt bei der Luftbildauswertung eine Besonderheit dar. Die üblichen Bildformate im Konsumbereich und auch weite Bereiche des Geschäftslebens liegen im Bereich unter 10 Megapixel. Ein übliches Bildformat wäre beispielsweise 2048 x 1536 was einer Auflösung von 3,1 Megapixel entsprechen würde. Demgegenüber muss eine Anwendung im Bereich Luftbildauswertung Bilder mit einem Vielfachen dieser Auflösung verarbeiten können. Bildformate mit den Ausmaßen 12000 x 40000 stellen in diesem Umfeld keine Seltenheit dar (siehe Abbildung 4 - Besonderheiten - Bildauflösung). Die Unterstützung dieser Bilder stellt hohe Anforderungen an die Datenhaltung. Dabei ist das Verwaltungskonzept ebenso wichtig wie die Verarbeitungsgeschwindigkeit. Der Unterschied für den Benutzer beim Umgang mit Luftbildern soll dabei nur unwesentlich langsamer sein als der Umgang mit Bildern in allgemein gängigen Auflösungen.

[...]