Automatisierte Generierung von Styled Layer Descriptor ... · Consortium (OGC) kann ein WMS-server Karten aus Rasterdaten und Vektor- daten visualisieren. 4 [Wikipedia], Eintrag:

Automatisierte Generierung von Styled Layer

Descriptor-Dateien aus ESRI ArcGIS-Projekten

zur Publikation mit OGC-konformen Mapservern

Diplomarbeit

von

Albrecht Weiser

___

betreut von

Prof. Dr. Alexander Zipf

Fachhochschule Mainz / i3 Mainz

Partner

Hessisches Landesamt für Umwelt und Geologie, Wiesbaden

___

Fachbereich I / Geoinformatik und Vermessung

Fachhochschule Mainz

15. August 2005

Abkürzungen ................................................................................................................i

Vorwort .......................................................................................................................iii

1 Definition der Aufgabenstellung ..........................................................................1

1.1 Der Titel der Arbeit im Klartext .........................................................................1

1.2 Die Ziele der Arbeit ..........................................................................................2

1.3 Was ist nicht Ziel dieser Arbeit? .......................................................................2

2 Motivation ..............................................................................................................4

3 Grundlagen und Begriffsbestimmungen .............................................................7

3.1 OGC ................................................................................................................7

3.2 WMS................................................................................................................8

3.2.1 Die Aufruf-URL........................................................................................9

3.2.2 Die WMS-Operationen ..........................................................................10

3.3 Gängige Map-Server......................................................................................12

3.3.1 ArcIMS von ESRI ..................................................................................13

3.3.2 Der UMN-Mapserver .............................................................................16

3.3.3 Weitere gängige Internet Mapserver .....................................................18

3.3.3.1 Deegree.....................................................................................18

3.3.3.2 GeoMedia WebMap von Intergraph...........................................19

3.3.3.3 GeoServer und AEDGIS von AED SICAD .................................19

3.4 XML ...............................................................................................................20

3.4.1 Bedeutung von XML..............................................................................21

3.4.2 Aufbau von XML....................................................................................21

3.4.3 Die Gültigkeit von XML-Dokumenten.....................................................23

3.4.5 Navigation und Adressierung ................................................................24

3.4.6 Programmschnittstellen.........................................................................25

3.5 SLD................................................................................................................26

3.5.1 Einige spezielle SLD-Elemente .............................................................28

3.6 ArcGIS von ESRI ...........................................................................................30

3.6.1 ArcMap .................................................................................................31

3.6.2 ArcObjects ............................................................................................32

3.7 Visual Basic.NET ...........................................................................................34

3.7.1 Konzept der Objektorientierten Programmiersprachen (OOP)...............34

3.7.2 Visual Basic ..........................................................................................35

3.7.3 .NET Framework ...................................................................................36

4 Anforderungsdefinition und Planung ................................................................38

4.1 Anforderungen an das Programm ..................................................................38

4.1.1 Die Geologische Übersichtskarte von Hessen 1:300.000 ......................38

4.1.2 Vorüberlegungen zur Struktur des Programms......................................43

4.1.2.1 Das Analysemodul.....................................................................43

4.1.2.2 Das Ausgabemodul ...................................................................44

4.1.2.3 Die Flexibilität bei der XML-Ausgabe .........................................45

4.1.2.4 Die Validierung ..........................................................................45

4.2 Erforderliche Ressourcen...............................................................................46

4.3 Anforderungen an die SLD-Tests...................................................................46

4.4 Das Testbed für die SLD-Tests ......................................................................47

4.4.1 Konfiguration des UMN-Mapserver .......................................................47

4.4.2 Konfiguration des ArcIMS am HLUG.....................................................50

5 Ergebnisse der Arbeit .........................................................................................54

5.1 Das Programm "ArcGIS-map to SLD Converter"............................................54

5.1.1 Struktureller Aufbau des Programms.....................................................55

5.1.1.1 Die Haupt-Benutzeroberfläche "Motherform" .............................58

5.1.1.2 Das Analysemodul "Analize_ArcMap_Symbols" ........................60

5.1.1.3 Das Ausgabemodul "Output_SLD" ............................................67

5.1.1.4 Die auf XML-Aufgaben spezialisierte Klasse "XMLHandle"........73

5.1.1.5 Die Gültigkeitsüberprüfung mit der Klasse "ValidateSLD"..........77

5.1.2 Implementierung der Sollkomponenten und darüber hinausgehende

Implementierungen ...............................................................................78

5.1.3 Besondere Herausforderungen bei der Entwicklung..............................81

5.2 Die SLD Tests................................................................................................83

5.2.1 Test mit dem UMN Mapserver...............................................................85

5.2.1.1 Vektorbasierte Symbolisierung ..................................................86

5.2.1.2 Flächenfüllungen mit Bitmaps....................................................91

5.2.1.3 Weitere getestete SLD-Elemente:..............................................96

5.2.2 Test auf der ArcIMS-Plattform .............................................................102

6 Zusammenfassung und Ausblick.....................................................................106

Verzeichnisse ...............................................................................................................I

Literaturverzeichnis .................................................................................................II

Hyperlinkverzeichnis...............................................................................................III

Abbildungsverzeichnis........................................................................................... VI

Tabellenverzeichnis............................................................................................. VIII

Anhang.........................................................................................................................a

Map-Datei des UMN-Testservers ............................................................................b

Workflow des Programms ArcGIS-map to SLD Converter .......................................c

UML-Klassendiagramme .........................................................................................d

LUT-XML.................................................................................................................g

Inhaltsangabe der Begleit-CD..................................................................................k

Eidesstattliche Erklärung

i

Abkürzungen

ALK Automatisierte Liegenschafts Karte

API Application Programming Interface

ASP Active Server Pages

ATKIS Amtliches Topographische-Kartographisches Informationssystem

AXL Arc Extensible Language

BLOB Binary Large Object

CAD Computer Aided Design

CGI Common Gateway Interface

CLR Common Language Runtime

COM Component Object Model

DTD Document Type Definition

DOM Document Object Model

EPSG European Petroleum Survey Group

GI Geo-Informatik

GIS Geoinformationssystem

GIF Graphics Interchange Format

GDAL Geospatial Data Abstraction Library

GDI Geodaten Infrastruktur

GML Geography Markup Language

GSDI Global Spatial Data Infrastructure

GUI Graphical User Interface

GÜK Geowissenschaftliche Übersichtskarte

HLUG Hessisches Landesamt für Umwelt und Geologie

HTML Hyper Text Markup Language

HTTP Hyper Text Transfer Protocol

i3 Institut für Raumbezogene Informations- und Messtechnik

IIS Internet Information Server

ISO International Organization for Standardization

IT Informations Technologie

JPEG Joined Photographic Experts Group

J2RE Java 2 Runtime Environment

LAN Local Area Network

ii

MSDN Microsoft Developer Network

MS4W Map Server for Windows

NASA National Aeronautics and Space Administration

OGC Open Geospatial Consortium

OOP Objektorientierte Programmierung

PhD Philosophiae Doctor

PHP Hypertext Preprocessor

PNG Portable Network Graphics

RDBMS Relationales Datenbank Management System

SAX Simple API for XML

SFC Stream Flow Connection

SFS Simple Feature Specification

SFO Simple Features for OLE/COM

SGML Standard Generalized Markup Language

SDTS Spatial Data Transfer Standard

SLD Styled Layer Descriptor

SP2 Service Pack 2

SQL Structured Query Language

SVG Scalable Vector Graphics

UML Unified Modeling Language

UMN University of Minnesota

URI Uniform Resource Identifier

URL Uniform Resource Locator

VBA Visual Basic for Applications

W3C World Wide Web Consortium

WCS Web Coverage Service

WFS Web Feature Service

WMS Web Map Service

WWW World Wide Web

XML Extensible Markup Language

XPATH XML Path Language

XSLT Extensible Stylesheet Language Transformation

iii

Vorwort

Diese Arbeit wurde ermöglicht durch eine Zusammenarbeit des Hessischen Lan-desamtes für Umwelt und Geologie (HLUG) in Wiesbaden mit der Fachhochschule Mainz, bzw. dem angegliederten Institut für Raumbezogene Informations- und Mess-technik, i3 der FH Mainz. Getragen wird die Arbeit seitens des HLUG von Herrn Dipl. Geol. Achim Stärk und seitens der FH/ i3 von meinem betreuenden Professor, Herrn Prof. Dr. Alexander Zipf.

Das HLUG hat die Arbeit unterstützt, indem es den Arbeitsplatz sowie alle notwendigen Ressourcen zur Verfügung stellte und mit fachlichem Know-How beratend zur Seite stand.

Der Kontakt mit dem HLUG kam zustande durch das Anliegen, meine Vorkenntnisse in Geologie praktisch mit den im Studium erworbenen Geoinformatik-Kenntnissen zu ver-binden, wobei die Geologie in dieser Arbeit mit der exemplarisch umzusetzenden Geologischen Übersichtskarte von Hessen im Maßstab 1:300.000 ins Spiel kommt.

Die Idee zu der Arbeit entstand aus einem Erfordernis des HLUG, vorhandene Daten (wie zum Beispiel die vorgenannte Geologische Übersichtskarte), die intern am HLUG schon genutzt werden, einem breiteren Publikum zur Verfügung zu stellen.

Es sollte eine Möglichkeit entwickelt werden, diese Daten automatisiert aufzubereiten, so dass einfach und zügig ein Kartendienst auf Grundlage offizieller gängiger Stan-dards erstellt werden kann.

Diese Anforderung wurde mit meiner Diplomarbeit umgesetzt in Form eines Pro-gramms mit dem Namen "ArcGIS-map to SLD Converter".

1 Definition der Aufgabenstellung -1-

1 Definition der Aufgabenstellung

1.1 Der Titel der Arbeit im Klartext

„Automatisierte Generierung von Styled Layer Descriptor-Dateien aus ESRI ArcGIS-Projekten zur Publikation mit OGC-konformen Mapservern“

Wie so oft bei ähnlichen Arbeiten ist auch der Titel meiner Diplomarbeit kryptisch und nicht nur für Laien schwer verständlich. Auch Nichtlaien kann der eine oder andere spezielle Begriff aus der Geoinformatik unbekannt sein.

Ich will den Titel deshalb zunächst in eine allgemein verständlichere Form bringen.

Im Thema taucht der Begriff "Mapserver" auf. Das impliziert, dass es um Karten geht, und zwar um solche, die im Internet veröffentlicht werden sollen. Der Begriff "Automati-sierte Generierung" steht dafür, dass es hier um ein Programm gehen muss, das etwas erzeugt, nämlich diese "Styled Layer Descriptor-Dateien" (SLD), die offensichtlich dazu benötigt werden, besagte Internetkarten zu produzieren. Woraus werden die Dateien erzeugt? – Aus ArcGIS-Projekten, also Projekten bzw. Karten, die mit dem Geoinfor-mationssystem (GIS) der Firma ESRI erstellt wurden.

Zur Erstellung von Karten mit GI-Systemen werden prinzipiell (mindestens) zwei Kom-ponenten benötigt:

1. Eine Datengrundlage, welche die darzustellenden räumlichen Daten beinhaltet

2. Eine Abbildungsvorschrift, wie diese Daten auf einem optischen Endausgabege-rät präsentiert werden sollen

SLD ist eine solche Abbildungsvorschrift für Karten, die von internetbasierten (und in-tranetbasierten) OGC-konformen1 Mapservern2 erzeugt werden.

Auf die genaue Bedeutung der einzelnen Begriffe wird im Kapitel 3 „Theoretische Grundlagen und Begriffsbestimmungen“ näher eingegangen.

1 OGC= Open Geospatial Consortium (auch: Open GIS Consortium) 2 [GUR], Eintrag: Unter einem Internet Map Server (oder kurz: Map Server) versteht man eine www-Anwendung im Internet, die auf Anfrage Kartenaus-schnitte auf einem Server erzeugt und über das Internet an einen Client sendet, der diesen Kartenausschnitt dann im Browser visualisiert. Hier-bei kommen unterschiedlichste Konzepte zum Einsatz, von clickable maps bis zu komplexen DB-gestützten GIS-Angeboten über das Internet.


1.2 Die Ziele der Arbeit

Der Erfolg der Diplomarbeit soll durch das Erreichen zweier Ziele gekennzeichnet sein:

1. Die Entwicklung eines Programms, das in der Lage ist, korrekte, von OGC-konformen Mapservern interpretierbare SLD-Dateien aus ArcMap-Projekten zu erzeugen

2. SLD-Implementationen zu testen, mit denen die Geologische Übersichtskarte 1:300.000 von Hessen (kurz GÜK 300) brauchbar symbolisiert werden kann, damit alle in ihr enthaltenen Klassen in der WMS-basierten3 Version genauso gut unterscheidbar sind wie in der Originalkarte aus ArcMap (welche Rolle die GÜK 300 bei diesen Tests spielt, wird ausführlicher im Kapitel 4.1 „Anforderun-gen an das Programm“ behandelt werden).

Eine Karte ist dann lesbar, wenn ihre Themen durch verschiedenartige Darstellungen eindeutig voneinander abgegrenzt werden können (i.Allg. durch Farbe, Tonwert, Form, Größe, Füllung und Richtung).

Dies bedeutet: Die Symbolisierung ist das wichtigste Element einer Karte, denn durch sie werden die Karteninhalte erst interpretierbar.

Zu diesem Zweck wurde SLD von OGC entwickelt. Es soll für OGC-fähige Kartendien-ste die Darstellung der Karteninhalte nach o.g. Kriterien durchführen können.

Mit meiner Diplomarbeit soll also untersucht werden, ob SLD diese Kriterien mit den Möglichkeiten der derzeitigen Spezifikation erfüllen kann. Wenn ja, muss sich das von mir entwickelte Programm daran messen lassen, ob es auch dazu in der Lage ist, die-se entsprechend umzusetzen.

1.3 Was ist nicht Ziel dieser Arbeit?

Zieldefinitionen müssen immer im Zusammenhang mit dem verfügbaren Zeitrahmen betrachtet werden. Im Falle dieser Arbeit beläuft sich die Zeitspanne auf ca. sechs Mo-nate. Ein halbes Personenjahr4 ist jedoch i. Allg. nicht genug Zeit, um eine Aufgabe dieser Größenordnung als "Komplettlösung" abzuliefern. Deshalb gelten folgende Ein-schränkungen für die Arbeit:

1. Das zu entwickelnde Programm soll kein "fertiges" Produkt sein, welches alle in ArcMap möglichen Arten der Klassifizierung abdeckt, sondern zunächst in der Lage sein, die GÜK 300 als Referenzprojekt in der unter Kapitel 1.2 beschrie-

3 [Wikipedia], Eintrag: WMS= Im Rahmen der Spezifikationen des Open GIS Consortium (OGC) kann ein WMS-server Karten aus Rasterdaten und Vektor-daten visualisieren.

4 [Wikipedia], Eintrag: Ein Personenjahr (früher: Mannjahr) bezeichnet die Arbeitsleistung, die eine Person während eines Jahres (im Schnitt 220 Arbeitstage) leistet.


benen Weise umzusetzen.

2. Die Testszenarien werden auf zwei ausgesuchten Test-Map-Servern durchge-führt. Die Kriterien für die Auswahl der Server werden im Kapitel 4.3 und 4.4 be-leuchtet. Die Tests indes sollen kein komplettes Nachschlagewerk für die Taug-lichkeit der Map-Server in Bezug auf SLD-Implementierungen bieten, sondern Basis für die Umsetzung der Referenzkarte GÜK 300 mit einer sinnvollen Sym-bolisierung per SLD sein.

2 Motivation -4-

2 Motivation

Worin liegt der Sinn einer zusätzlichen Abbildungsvorschrift für Kartenserver, die (zu-mindest z. Zt.) weniger Darstellungsmöglichkeiten bietet als die vorhandener proprietä-rer Systeme?

Gibt es nicht schon genug Möglichkeiten, die Daten mit vorhandenen Mitteln zu publi-zieren? Meistens bieten die Hersteller der Desktop-GIS-Systeme5, die zur Erfassung und lokalen Bearbeitung der Daten von den Firmen, Kommunen und Behörden gekauft wurden, genügend Möglichkeiten um die Daten in entsprechender Qualität ins Internet oder Intranet zu bringen. Beispielsweise bieten ESRI und auch Intergraph (um nur zwei der marktführenden Unternehmen zu nennen) jeweils ein Produkt an, mit dem die Desktop-Projekte direkt im Internet veröffentlicht werden können. Außerdem gibt es von Drittanbietern Lösungen, um die Darstellungseigenschaften eines Desktop-Projekts zu extrahieren und als Kartendienst (WMS wird in Kapitel 2.2 näher erläutert) in einem proprietären Format abzuspeichern. Zu nennen wären in dieser Beziehung z.B. AveiN! und AmeiN! der Firma Terrestris GbR, Bonn, die ArcView- oder ArcMap-Projekte umwandeln in UMN-Kartendienste.

Alle diese vorgenannten Lösungen sind proprietäre Lösungen. WMS-SLD allerdings folgt einem internationalen Standard.

Die Antwort auf obige Fragen lautet deshalb: Es gibt drei gute Gründe, warum man proprietäre Lösungen zugunsten von Standards, wie z.B. OGC (wird im Kapitel 2.1 näher behandelt), W3C oder ISO sie erarbeiten, vermeiden sollte:

1. Das sicherlich wichtigste Argument für Standards ist die allgemeine Nutzbarkeit und die Austauschbarkeit von Daten.

In den letzten Jahren und Jahrzehnten haben überall auf der ganzen Welt Erhebun-gen von Geodaten stattgefunden oder vorhandene Geodaten wurden in elektroni-sche Datenträger eingespeist. Doch gleich der babylonischen Sprachenvielfalt exi-stierte auf dem Markt für elektronische Datenverarbeitung im Allgemeinen und dem der Geodatenverarbeitung im Speziellen eine Menge an Formaten und unterschied-lichen Technologien, von denen viele nicht untereinander kompatibel waren und bis heute nicht sind. Eine Zeitlang spielte das keine Rolle, da vor der Nutzung der Da-ten die Energien sowieso im Wesentlichen auf die Erhebung der Daten konzentriert waren.

Seit geraumer Zeit wurden enorme Mengen an Geodaten erfasst. Nun macht man sich mehr und mehr Gedanken darüber, wie die Daten sinnvoll verwendet werden

5 [Wikipedia], Eintrag: GIS (=Geoinformationssystem) ist ein Informati-onssystem, mit dem raumbezogene Daten digital erfasst und redigiert, gespeichert und reorganisiert, modelliert und analysiert sowie alphanu-merisch und graphisch präsentiert werden.

2 Motivation -5-

können, die man über Jahrzehnte gesammelt hat. So entstanden mit der Zeit immer mehr Dienste von Institutionen, die ihre Datenbestände der Öffentlichkeit in Form von Kartendiensten oder anderen Datendiensten zur Verfügung stellen.

In den letzten Jahren wird nun versucht, eine Bündelung der Energien zu erreichen, indem man größere Datenmengen (es geht hier hauptsächlich um Geobasisdaten6) einem breiteren Publikum zur Verfügung stellt. Man versucht das zu erreichen, in-dem man eine Vernetzung der vorhandenen Daten über zentrale Stellen vorantreibt. Man spricht hierbei von sog. "Geodateninfrastrukturen" (kurz GDI). Solche GDI wer-den z. Zt. auf allen Verwaltungsebenen7 aufgebaut.

Man erreicht dadurch Synergieeffekte, die z.B. redundanter Datenerhebung und Da-tenerfassung, der lückenhaften Verfügbarkeit und der Zersplitterung von Datenbe-ständen entgegenwirken.

Aber die gemeinsame Nutzung von Daten setzt auch eine Verständigung über ge-meinsam nutzbare Datenformate und Schnittstellen voraus.

Ein Beispiel zur Verdeutlichung: Nehmen wir an, mehrere Gelehrte aus unterschied-lichen Ländern wollen sich auf einem Kongress treffen. Sie beschließen, ihr jeweili-ges Fachwissen zusammenzulegen, um eine Aufgabe, die jeder einzeln zu lösen nicht in der Lage ist, gemeinschaftlich zu bewältigen. Bei dem Kongress stellen sie jedoch fest, dass keiner den anderen verstehen kann, weil keiner die Sprache des anderen spricht. Hätte man eine gemeinsame Sprache, wäre das Problem zu lösen gewesen.

WMS-SLD von OGC ist eine gemeinsame Sprache zur Erstellung von Darstellungs-anweisungen für Mapserver. Alternativ haben wir das Szenario, dass die Daten der Organisation X nicht auf dem Server der Organisation Y dargestellt werden können, weil beide Systeme von unterschiedlichen Anbietern sind und damit jeweils andere Datenformate und Schnittstellen benutzen.

2. Übertragbarkeit der Darstellungsvorschrift von einem Map-Server auf den anderen

Jeder Map-Server benötigt eine Konfigurationsdatei, in der die zentralen Informatio-nen enthalten sind, die notwendig sind, um einen Kartendienst zu errichten. Beim ArcIMS von ESRI beispielsweise heißt die Datei AXL-Datei und ist im XML-Format gehalten; beim UMN-Mapserver heißt sie Map-Datei und liegt im gewöhnlichen Textformat vor; beim Deegree-Server wiederum heißt die Datei wms_capabilities und ist auch eine XML-Datei (über die gängigsten Web-Map-Server wird im Kapitel

6 [GUR] Eintrag: Geobasisdaten sind eine Teilmenge der Geodaten, welche die Landschaft (Topographie) und die Liegenschaften der Erdoberfläche interessenneutral beschreiben. Zu ihnen zählen im Wesentlichen die Da-ten der Vermessungsverwaltung (ATKIS, ALK), die als Grundlage für viele Anwendungen geeignet sind

7 Auf Landesebene: z.B. Geodateninfrastruktur des Landes Hessen; GDI Nordrhein-Westfalen Auf Bundesebene: Deutsche Geodateninfrastruktur GDI-DE Europaweit: Europäische Geodateninfrastruktur INSPIRE International: Internationale Geodateninfrastruktur GSDI

2 Motivation -6-

3.5 referiert). In der Konfigurationsdatei sind Informationen über den Ort der Daten, Layernamen etc. enthalten (siehe Kap. 3.3). Aber auch die Symbolisierung der Klassen wird hier normalerweise in einem proprietären Format vorgenommen.

Ein Rechenbeispiel:

Nehmen wir ein Projekt wie die GÜK 300 als exemplarisches Projekt. Angenommen, die GÜK 300 ist aus 6 Layern zusammengesetzt. Jeder Layer enthält durchschnitt-lich 90 Klassen und für jede Klasse wird in der AXL-Datei des ArcIMS 6 Zeilen für eine Symboldefinition benötigt (ungefähr dieselbe Größenordnung wie in den Konfi-gurationsdateien bei UMN-Mapserver und Deegree auch). Das macht insgesamt 6 x 90 x 6 = 3240 Codezeilen, die händisch erstellt werden müssen, was natürlich sehr aufwendig ist.

Nehmen wir weiterhin an, man möchte aus Kostengründen einen UMN-Mapserver als alternativen Kartenserver betreiben und darauf dieselbe Datenbasis als Karten-dienst mit einbinden. Dann müsste eine zweite Konfigurationsdatei für den UMN-Mapserver mit dem gleichen Aufwand erstellt werden.

Aber dieser Aufwand kann minimiert werden, wenn WMS-SLD als Darstellungsvor-schrift benutzt wird, statt die komplette Symbolisierung in der Konfigurationsdatei zu erstellen. Das Aufsetzen einer Konfigurationsdatei wird einem dadurch zwar nicht erspart, aber der Umfang dieser Datei reduziert sich auf eine Größe von 20 bis 50 Zeilen (je nach Mapserver).

3. Die Kosten

Die Punkte 2 und 3 gehen Hand in Hand und sind deshalb schwerlich zu trennen. Darum wurde ein Grund, warum SLD die Kosten senken kann, unter 2 schon ange-schnitten.

Für Lizenzen von Produkten der marktführenden Unternehmen kann ein größerer Lizenznehmer wie z.B. eine Landes- oder Bundesbehörde schnell eine Summe im 6-stelligen Euro-Bereich per annum veranschlagen. Eine Möglichkeit, hier Kosten zu senken, stellt die Benutzung von Open Source-Software8 dar, deren Verwendung meist kostenlos oder mit einem geringen Kostenfaktor verbunden ist.

Open Source-Produkte können jedoch nicht mit proprietärer Technologie hergestellt werden, da diese lizenzpflichtig, bzw. nicht offengelegt sind. D.h. Open Source-Projekte werden erst durch offene Standards wie SLD ermöglicht.

Proprietäre Technologien sind abhängig von Firmenpolitik und bieten somit wenig Planungssicherheit. Standards hingegen gewährleisten sichere Grundlagen für Ent-wicklungen.

Somit lassen sich langfristige Entwicklungen planen und kostspielige Neuentwick-lungen auf Basis einer veränderten Technologie vermeiden.

8 [Wikipedia], Eintrag: Der Ausdruck Open Source bzw. Quelloffenheit wird meist auf Computer-Software angewandt und meint, dass es jedem ermög-licht wird, Einblick in den Quelltext eines Programmes zu haben.

3 Grundlagen und Begriffsbestimmungen -7-

3 Grundlagen und Begriffsbestimmungen

Dieses Kapitel soll notwendige Grundlagen zum Verständnis der Diplomarbeit legen und Begriffe, auf die ich mich in der Arbeit häufig beziehe, erläutern. Die Unterkapitel sind aufeinander aufbauend gegliedert, so dass das jeweils vorangehende Kapitel die Voraussetzungen für die nachfolgenden Kapitel schafft (bis auf Kap. 3.6 und 3.7).

3.1 OGC

OGC ist eine Abkürzung für Open Geospatial Consortium. Eine frühere Bezeichnung für das OGC, die aber immer noch gültig ist, lautet auch: Open GIS Consortium.

OGC über sich:

„The Open Geospatial Consortium, Inc. (OGC) is a non-profit, international, voluntary consensus standards organization that is leading the development of standards for geo-spatial and location based services. Through our member-driven consensus programs, OGC works with government, private industry, and academia to create open and extensi-ble software application programming interfaces for geographic information systems (GIS) and other mainstream technologies. Adopted specifications are available for the public's use at no cost. “ 9

Das heißt mit anderen Worten:

Die OGC ist eine nicht gewinnorientierte internationale, unter gemeinsamem freiwilli-gen Einverständnis arbeitende Standardisierungs-Organisation, die führend ist in der Entwicklung von Standards für räumliche und ortsbasierte (Geo-) Dienste.

Durch ihre mitgliederbetriebenen Programme, die Ergebnisse liefern, welche mit Zu-stimmung aller Mitglieder beschlossen wurden, arbeitet die OGC mit Regierungen, Privatunternehmen und akademischen Betrieben zusammen, um offene und erweiter-bare Software-Anwendungsschnittstellen für Geographische Informationssysteme zu entwickeln. Spezifikationen10, die vom Mitgliedergremium akzeptiert wurden, sind un-entgeltlich für die Allgemeinheit erhältlich.

Das OGC wurde am 25. September 1994 von 20 Gründungsmitgliedern aus der Taufe gehoben und umfasst heute mehr als 250 Organisationen, Regierungen und Privatfir-men.

Im Jahre 2000 wurde die Europäische Ausgründung der OGC, das sog. OGCE ins Leben gerufen.

OGC versteht sich als Partnerorganisation anderer großer Standardisierungsorganisa-

9 Homepage OGC 10 [DUD] Spezifikation: Einzelaufzählung, Komplette Liste


tionen wie z.B. dem W3C11 und der ISO12.

Einige der bekanntesten Spezifikationen des OGC sind:

� GML (Geography Markup Language)

� Simple Features: SFC (CORBA), SFS (SQL), SFO (OLE/COM)

� SLD (Styled Layer Descriptor)

� WCS (Web Coverage Service)

� WFS (Web Feature Service)

� WMS (Web Map Service)

3.2 WMS

Der WMS ist wie unter 3.1 beschrieben eine Spezifikation des OGC, welche die Syntax für die Errichtung und den Betrieb von Kartendiensten definiert:

OGC über WMS:

„A Web Map Service (WMS) produces maps of georeferenced data. We define a "map" as a visual representation of geodata; a map is not the data itself. This specification de-fines three WMS operations: GetCapabilities returns service-level metadata, which is a description of the service's information content and acceptable request parameters; Get-Map returns a map image whose geospatial and dimensional parameters are well de-fined; GetFeatureInfo (optional) returns information about particular features shown on a map. This specification defines a syntax for World Wide Web (www) Uniform Resource Locators (URLs) that invoke each of these operations. Also, an Extensible Markup Lan-guage (XML) encoding is defined for service-level metadata.” 13

Mit anderen Worten:

Ein Kartendienst erzeugt Karten aus georeferenzierten Daten. OGC definiert eine Karte als eine visuelle Repräsentation der Geodaten. Die Karte erhält der Webclient als Bit-map in verschiedenen möglichen Formaten (je nach Implementierung des Mapser-vers). Die derzeit gängigsten Formate sind jpeg14, gif und png.

Diese Bitmap wird mithilfe der in der Spezifikation fest definierten Parameter von einer

11 W3C: World Wide Web Consortium. Vereinigung diverser Organisationen zur Erarbeitung von Web-Standards

12 ISO: International Organization for Standardization. Organisation für die Erarbeitung Internationaler Industriestandards

13 Homepage OGC

14 jpeg: Joint Photographic Experts Group: im Internet am weitesten ver-breitetes Format; gif: Graphics Interchange Format: 1987 von US-Onlinedienst Compuserve entwickelt; png: Portable Network Graphics: Er-satz für das proprietäre Format gif


CGI-Anwendung15 oder einer anderen Scriptanwendung generiert. Die Parameter die-nen der CGI-Anwendung als Steuerbefehle. Sie werden in einer Aufruf-URL16 überge-ben (auf die Aufruf-URL wird in Kap. 3.2.1 ausführlicher eingegangen). Mit der URL können 3 grundlegende WMS-Operationen aufgerufen werden:

1. GetCapabilities

2. GetMap

3. GetFeatureInfo

Auf die 3 WMS-Operationen wird in Kap. 3.2.2 genauer eingegangen.

Zusätzlich zu den OGC-konformen Parametern können in der Aufruf-URL anbieterspe-zifische Parameter der speziellen Mapserver vorkommen. Ein typischer Parameter, der allerdings bei jedem Mapserver eines anderen Anbieters unterschiedlich lautet, ist der Verweis auf die Konfigurationsdatei. Beim Aufruf eines Dienstes mit einem UMN-Mapserver z.B. wird deshalb noch der Parameter "&map=URL_der_Konfigurationsdatei" in der Aufruf-URL aufgeführt.

Ein einfacher WMS (basic-WMS) benutzt zur Darstellung eine begrenzte Anzahl an vordefinierten Styles, die lediglich jeweils einem Layer zuweisbar sind. Komplexere Symbolisierungen sind auf diese Weise nicht möglich. Dafür steht dem WMS die Mög-lichkeit der Symbolisierung mit SLD zur Verfügung. Mit der SLD-Syntax können die Layer klassifiziert und den einzelnen Klassen unterschiedliche Symbolisierungen zu-gewiesen werden. Bei diesen sog. "SLD-WMS" können zusätzlich die Parameter „Des-cribeLayer, GetLegendGraphic, GetStyles und PutStyles“ eingebunden werden (auf SLD wird gesondert im Kapitel 3.5 eingegangen).

3.2.1 Die Aufruf-URL

Zur Kommunikation mit dem WMS sieht das OGC das http-Protokoll17 vor. Das Proto-koll unterstützt zwei Abfrage-Methoden:

1. GET

2. POST

Die http-GET-Methode besteht aus der URL des Webdienstes und verschiedenen Pa-rametern, die mit bestimmten Trenn- und Verbindungszeichen an die URL angehängt

15 CGI: Common Gateway Interface- Ein Programmscript, das Routinen auf ei-nem Server abarbeitet und HTML-Clients mit anderen Programmen verbindet (z.B. Perl, PHP)

16 URL: Uniform Resource Locator: eindeutige Adresse eines Dokuments im Internet; besteht aus dem Zugriffsverfahren (z.B. http), dem Hostnamen (z.B. www) und dem Dateipfad

17 [Wiki], Eintrag: Das Hypertext Transfer Protocol (HTTP) ist ein zu-standsloses Datenaustausch-Protokoll zur Übertragung von Daten. Es ist eines der Protokolle, die der TCP/IP-Protokollstapel bereitstellt. Pri-mär wird es im Rahmen des World Wide Web zur Übertragung von Webseiten verwendet.


werden. Das "?" z.B. signalisiert das Ende der URL. Die notwendigen Parameter wer-den als Namen/Wert-Paare in der Form "Name=Wert&“ angegeben, wobei das "Kauf-manns-und" das Ende des Paares anzeigt. Somit können beliebig viele Namen/Wert-Paare angehängt werden. Gibt es Parameternamen, die mehrere Werte übernehmen können, wie z.B. "LAYER", werden diese durch Kommata separiert. Bei den Parame-ternamen soll Groß-/ Kleinschreibung keine Rolle spielen; die Parameterwerte hinge-gen sind case-sensitive18.

Eine gültige Aufruf-URL nach der http-GET Methode wäre demnach z.B.:

http://mapserver:8080/wmsconnector/com.esri.wsit.WMSServlet/guek300?request=getmap&srs=EPSG:31467&bbox=3447309,5542994,3450522,5545762&layers=GEOLOGIE.GUEK300_POLY&styles=&format=png&width=250&height=400

Die http-POST-Methode:

Im Gegensatz zur GET-Methode werden hier im Body-Abschnitt der Webseite einge-bettet, welche die WMS-Anfrage abschickt. Die Daten werden üblicherweise mit einem "Senden"-Schaltelement an eine vorher festgelegte Webserver-Adresse verschickt. Nach entsprechender Verarbeitung der Daten wird wie bei der GET-Methode eine Kar-te an den Client zurückgesendet. Aber im Gegensatz zur GET-Methode können bei POST keine zusätzlichen Parameter mehr an die URL angehängt werden.

3.2.2 Die WMS-Operationen

I. GetCapabilities:

Die GetCapabilities-Operation liefert die Metadaten des WMS. Diese beinhalten so-wohl Informationen über die Art der unterstützten Operationen und Parameter als auch über die Anzahl und Art der Layer dieses WMS. Die möglichen Operationen sind in der nachfolgenden Tabelle aufgeführt:

Anfrage-Operation E/O * Parameter Beschreibung

VERSION O WMS-Version Version des WMS (z.B. 1.1.1)

SERVICE E WMS Service-Art (WMS, WCS, …)

REQUEST E GetCapabilities Anfrage-Operation

UPDATESEQUENCE O String Sequenznummer z. clientseitigen

Cacheverwaltung

Tab. 1 GetCapabilities-Operationen (* Erforderlich/Optional)

18 Case-sensitive: Die verarbeitende Anwendung unterscheidet zwischen Groß- und Kleinschreibung.


Das Antwortformat auf die Operation ist einstelllungsabhängig. Per Default ist XML als Format eingestellt. Die Antwort des WMS kann (abhängig vom Inhalt der im WMS aufgenommenen Metadaten) folgende Informationen zurückliefern (Respon-se):

� Namen, Titel der Layer

� Allgemeine Dienst-Metadaten (Diverse URL’s, Schlüsselbegriffliste, Kontaktin-formationen etc.)

� Capability-Metadaten (Auflistung der möglichen Operationen, die von der Dienst-Instanz geliefert werden können, Ausgabeformate etc.)

� Layers und Styles (Symboldefinitionen und Informationen über vererbte Layer werden laut [OGW], 24 augenblicklich noch nicht unterstützt)

II. GetMap:

Die GetMap-Operation liefert keine Daten als Information, sondern die Karte als Re-präsentation ihrer Daten. Die untergeordneten Operationen und ihre zugehörigen Parameter entscheiden über das Aussehen der resultierenden Karte:

Anfrage-Operation E/O * Parameter Beschreibung

VERSION E WMS-Version Version des WMS (z.B. 1.1.1)

REQUEST E GetMap Anfrage-Operation

LAYERS E Layer-Liste Kommagetrennte Liste eines oder

mehrerer Layer

STYLES E Style-Liste Kommagetrennte Liste vordefinierter

Styletypen

SRS E Namensraum:Bezeichner Koordinatensystem (z.B.

EPSG:4326)

BBOX E minX,minY,maxX,maxY Die Ecken links unten, rechts oben

der Bounding Box19

WIDTH E Ausgabe-Breite Die Breite der die Karte repräsentie-

renden Ausgabe-Bitmap

HEIGHT E Ausgabe-Höhe Die Höhe der die Karte repräsentie-

renden Ausgabe-Bitmap

FORMAT E Ausgabe-Format Das Ausgabeformat der die Karte

repräsentierenden Bitmap

TRANSPARENT O true/false Hintergrundtransparenz der Karte

(Defaultwert=false)

19 Bounding Box (auch: Minimum enclosing rectangle): Das kleinstmögliche Rechteck, das sich um ein bestimmtes Objekt legen lässt


BGCOLOR O Farbwert Hintergrundfarbe der Karten-Bitmap

in Hexadezimalschreibweise

EXCEPTIONS O Ausgabeformat Das Format, in dem Ausnahmen des

WMS ausgegeben werden

TIME O Zeit Datumsangabe für Layer, die sich

ändern können

ELEVATION O Höhenangaben Die Repräsentation der 3. Dimensi-

on Höhe (als unechte 2,5-D)

SLD ** O SLD-URL Die URL zu der zugehörigen SLD

WFS ** O WFS-URL URL zu einem WFS, der Features

beinhaltet, die SLD benutzen

Tab. 2 GetMap-Operationen (* Erforderlich/Optional; **diese Operationen nur für SLD-WMS)

Im Falle einer ungültigen Eingabe eines Parameterwerts oder eines Verstoßes ge-gen die case-sensitiven Vorgaben sollte der Kartendienst eine Fehlermeldung in dem vordefinierten Fehlerformat ausgeben.

III. GetFeatureInfo:

Im Gegensatz zu den beiden vorhergehenden Operationen ist GetFeatureInfo eine optionale Operation. Als Ausgabe liefert sie Sachdaten über das betreffende Fea-ture. Weil ein WMS "stateless“, d.h. zustandslos ist, müssen die Parameter aus der Kartenanfrage für die GetFeatureInfo-Operation wiederholt werden.

GetFeatureInfo wird im Augenblick noch nicht von allen Kartenservern unterstützt.

3.3 Gängige Map-Server

Map-Server sind die Instrumente der Darstellung von Karten im Internet. Sie generie-ren mithilfe von Darstellungsanweisungen wie SLD die gewünschten Karten und sind somit ein wesentlicher Bestandteil dieser Diplomarbeit; deshalb lohnt es sich, einige Map-Server eingehender zu betrachten und z.B. ihre Fähigkeiten in Bezug auf OGC-Standards zu beleuchten.

Den Markt für Internet-GIS und Web Mapping teilen sich eine Menge Anbieter, deren Produkte eine breite Palette der Aufgaben erledigen, die ein "herkömmlicher“ WMS erfüllen muss. Außerdem gibt es zahlreiche kleinere Unternehmen, die vorhandene Systeme übernehmen und diese im Rahmen eines "Customizing“ auf spezielle Bedürf-nisse hin optimieren.

Das Kapitel 3.3 soll einen Überblick über die gängigen Produkte liefern, wobei ich mich hier auf zwei spezielle Server konzentriere, die Bestandteil meiner Diplomarbeit sind: den ArcIMS von ESRI und als Open Source-Variante den UMN-Mapserver. Die Map-Server anderer Anbieter werden hier lediglich kurz angesprochen.


3.3.1 ArcIMS von ESRI

Der ArcIMS ist das internetbasierte Geoinformationswerkzeug von ESRI aus einer ganzen Produktpalette von GIS-Komponeneten, die eng miteinander verzahnt sind. Derzeit wird der ArcIMS in der Version 9.1. ausgeliefert.

ESRI über den ArcIMS:

„ArcIMS ist ein internetbasiertes GIS, mit dem Sie Geodaten in Form digitaler Karten o-der interaktiver Anwendungen zentral aufbereiten können und für andere Nutzer sowohl innerhalb Ihrer Organisation (Intranet) als auch über das Internet zugänglich machen können.“ 20

Der ArcIMS ist Teil einer ganzen GIS-Infrastruktur mit integrierten Server- und Client-funktionen. ArcIMS kann als reiner Kartenserver arbeiten, ist aber auch in der Lage andere Dienste wie z.B. GIS-Funktionen anzubieten (z.B. räumliche Abfragen und Ver-schneidung von Daten). ArcIMS kann vorliegende GIS-Daten und deren Metadaten und Anwendungen über das Internet bereitstellen. Der ArcIMS von ESRI ist somit ein umfangreiches und annähernd vollwertiges (keine Dateneditierung und Datenerfas-sung) internetbasiertes GIS-System und unterscheidet sich dadurch von anderen gän-gigen Systemen, die z.T. lediglich als reine Kartenserver fungieren.

Abb. 1 Verzahnung des ArcIMS mit anderen Modulen (Quelle: Website ESRI Germany)

Architektur des ArcIMS

Der Aufbau von ArcIMS ist als Multi-tier-Architektur21 ausgelegt (tatsächlich sind es augenblicklich nur drei Schichten).

20 Homepage ESRI Deutschland

21 Multi-tier: 3- und mehrschichtig


Abb. 2 ArcIMS-Architektur: Multi-tiers (Quelle: ESRI.com; s. Hyperlinkvz.)

Wie in der Abb. 2 zu erkennen ist, besteht die Architektur aus:

1. Der Clientschicht (hier werden verschiedene Clients wie ArcXML-Clients, HTML-Viewer und Java-Viewer zur Verfügung gestellt)

2. Der Diensteschicht (die nachfolgend genauer betrachtet wird)

3. Der Datenschicht (Shapefiles, ArcSDE, RDBMS22)

Die nachfolgende Abb. 3 beleuchtet die Diensteschicht etwas genauer:

Abb. 3 ArcIMS-Architektur: Client/Server-tier (Quelle: ESRI.com; s. Hyperlinkvz.)

Die Diensteschicht kann wiederum aufgegliedert werden nach den Komponenten und

22 RDBMS: Relationale Datenbank Management-Systeme. Datenbanksysteme, die über ein Zugriffsmanagement abgesichert sind vor Transaktionskonflikten


ihren Funktionen:

Der Web Server:

Der Webserver bildet die Verbindung zwischen den ArcIMS-Anwendungen und dem Internet. Er ist nicht Bestandteil des ArcIMS-Paketes. Hier kann jedweder übliche Web-server wie z.B. der Microsoft IIS, Apache oder Xitami-Webserver benutzt werden.

Die ArcIMS Application Server Connectors:

Die Connectors sind notwendig, damit der Webserver mit dem Application Server kom-munizieren kann. Verfügbare Connectors sind der Servlet Connector, Cold Fusion Connector, Active X Connector und der WMS Connector (der im Zusammenhang mit dem Testbed für die SLD-Tests in Kap. 4.4 noch einmal Erwähnung finden wird)

Der Application Server:

Der Application Server läuft als Hintergrundprozess und überwacht, welche Dienste auf welchem Spatial Server laufen. Er verteilt die Last der ankommenden Dienst-Anfragen.

Monitor und Tasker:

Sind Hilfsdienste, die den Zustand der Kartendienste überwachen.

Der Spatial Server und die Virtual Server:

Der Spatial Server bildet das Herzstück der ArcIMS-Anwendungen. Er muss mit dem Application Server kommunizieren, ArcXML-Anfragen in ihre Bestandteile zerlegen, Shapefiles, ArcSDE-Daten und Images einlesen und die aktuellen "Requests" bearbei-ten. Typische Prozesse, die auf dem Spatial Server laufen können, sind: Image-Rendering, Geocodierungen, Feature Streaming (das Versenden von Shapefiles und ArcSDE-Daten in einem gepackten Format als Datenstrom), Queries (also Datenbank-abfragen) und räumliche Verschneidungen. Kartendienste, die mit dem ArcIMS aufge-setzt werden, laufen letztlich auf dem Application Server.

Die Virtual Server des ArcIMS sind dazu da, mehrere laufende Application Server-Instanzen entsprechend ihrer gegenwärtigen Aufgabe zu gruppieren. Sie verwalten sozusagen die Anwendungslast zwischen den einzelnen Application Server-Instanzen.

Der Manager:

Ist eine Zusammenstellung von interaktiven Webseiten zum Administrieren von Ar-cIMS.

ArcXML:

ArcXML stellt wie der Name schon sagt eine XML-basierte Sprache dar, mit der sich die ArcIMS-Komponenten untereinander verständigen. Auch die proprietäre Konfigura-tionsdatei für Kartendienste mit der Dateiendung *.axl ist in diesem XML-Derivat ver-fasst (ein Auszug aus einer axl-Datei wird in Kap. 4.4 vorgestellt).

ArcIMS von ESRI ist WMS-kompatibel, unterstützt aber nicht alle OGC-Implementationen bedingungslos (wie in Kap. 5.2.1 dargestellt wird).


3.3.2 Der UMN-Mapserver

Der UMN-Mapserver ist eine Open Source-Entwicklung der University of Minnesota (UMN= University of Minnesota) und der NASA. Das UMN Mapserver-Projekt startete 1994 als Doktoranden-Projekt von Steve Lime, der damals an der Universität von Min-nesota beschäftigt war. Der Mapserver war aus der Taufe gehoben, als PhD Steve Lime ein CGI-Script entwickelte, das ArcInfo-AML-Dateien "on the fly“ generieren konn-te, die an das WWW angeknüpft wurden. Die NASA arbeitete seit 1995 an dem Pro-jekt, da sie eine Plattform suchte, mit der Satellitenbilder als Internetkarte präsentiert werden konnten. Das daraus entstandene Projekt nannte sich "ForNet“ und das Er-gebnis war ein CGI-Script, das in der Lage war, Erdas IMAGINE-Daten zu veröffentli-chen. 1997 wurde die erste Version 1.0 des heute bekannten UMN-Mapservers veröf-fentlicht. Aktuell ist z. Zt. die stabile Version 4.6, die seit 1997 wesentliche Fortschritte gemacht hat. Die Rechte an dem Projekt besitzt nach wie vor die University of Minne-sota. 23

„Die UMN MapServer Software ist eine OpenSource Entwicklungsumgebung für die Er-stellung von Internet Anwendungen mit dynamischen Karteninhalten. Die Software nutzt weitere bekannte Open Source und Freie Software Module wie z.B. Shapelib, FreeType, Proj.4, GDAL/OGR und viele weitere. UMN MapServer ist auf Betriebssystemen und in Umgebungen lauffähig in denen viele andere Systeme nicht verwendet werden können, gerne auch auf Linux/Apache Plattformen. UMN MapServer lässt sich für die meisten UNIX/Linux, Microsoft Windows und auch MacOS (ab OSX) Betriebssysteme kompilie-ren. Der UMN MapServer zeichnet sich durch hohe Stabilität und Geschwindigkeit aus und ist mit geringem Aufwand konfigurierbar. Der wahrscheinlich wichtigste Faktor für den Erfolg dieses Open Source Projektes ist die hervorragende weltweite Anwenderge-meinschaft.

Die Software beinhaltet das Modul MapScript, dass die MapServer C API Schnittstelle über die Skriptsprachen PHP, Perl, Python, und neuerdings auch Java öffnet. MapScript bietet ein reiches Sortiment an Methoden und Funktionen für die Entwicklung von An-wendungen und Fachschalen für unterschiedlichste Daten.“ 24

Der UMN-Mapserver ist laut [UMN] kein voll ausgestattetes GIS, sondern bildet eine Basiskomponente für die Erzeugung dynamischer Karten über das Internet. Da der UMN Mapserver aber ein Open Source-Projekt ist, existieren eine Vielzahl von Open Source und Freeware-Komponenten der Entwicklergemeinschaft, die als GIS-Infrastruktur dem UMN Web-GIS-Fähigkeiten verleihen können. Der Fokus des UMN liegt jedoch eindeutig auf der Funktion der Kartenanzeige und nicht auf der des Web-GIS.

Die Architektur des Mapservers:

Die Architektur des UMN Mapservers kann ebenfalls als 3-Schichtstruktur bezeichnet werden, wobei die Diensteschicht wesentlich einfacher strukturiert ist als beim ArcIMS (s. Abb. 4).

23 Die Informationen stammen aus einer Korrespondenz von PhD Steve Lime mit einem interessierten User von UMN-Mapserver und sind im offiziellen internationalen UMN-Forum gepostet (siehe Hyperlink-Verzeichnis)

24 Homepage des UMN-DE


Abb. 4 UMN Mapserver-Architektur (Quelle: sourcegraphics; s. Hyperlink-Vz.)

Der Mapserver benötigt einen http-Server als Webkomponente (z.B. den Apache oder den Xitami Webserver), das Mapserver-Script, eine Datenbasis, aus der die Geodaten bezogen werden, und einen Client, der die Anfrage an den Server stellt.

Das CGI-Script empfängt die Anfrage des Client, verarbeitet diese, rendert die Karte, und schickt diese als Bitmap an den Client zurück. Das Script ist zustandslos („state-less“), d.h. es ist nicht in der Lage, eine vorher getätigte Anfrage zu speichern. Als Fol-ge davon muss jede Anfrage an das Script neu gestellt werden, damit das Script die Karte neu prozessieren kann. Bei jeder neuen Anfrage müssen alle Aufrufparameter


immer wieder neu übergeben werden.

Der Mapserver besitzt eine Anwendungsschnittstelle, das sog. "Mapscript". Mit dieser Schnittstelle können Mapserver-Funktionen in ein externes Programm eingebaut wer-den. Verfügbare Schnittstellen existieren laut [UMN] zu den Sprachen PHP, Python, Ruby, TCL, Java und C#.

Die Datenbasis für den Mapserver kann dateibasiert sein (ESRI Shapefiles), auf einem Datenbankmanagementsystem (RDBMS) wie z.B. Oracle beruhen oder räumliche Da-tenbankerweiterungen wie PostGIS und ESRI ArcSDE einbinden. Die Daten werden über die OGR-SimpleFeatures-Schnittstellen importiert, welche durch die OGR-Bibliotheken zur Verfügung gestellt werden.

Rasterdaten werden über die GDAL-Schnittstelle zur Verfügung gestellt (GDAL= Ge-ospatial Data Abstraction Library).

Zur Erstellung eines Kartendienstes mit dem UMN Mapserver muss eine Konfigurati-onsdatei erstellt werden, eine sog. Map-Datei, in der grundlegende Informationen des Kartendienstes enthalten sind (die Map-Datei sowie weitere Konfigurationsdetails des UMN Mapservers werden im Kapitel 4.4.1 eingehender behandelt werden).

Der UMN Mapserver ist laut [UMN] weitestgehend OGC-WMS-kompatibel. Lediglich bei der SLD-Implementierung wurden während den SLD-Tests einige wenige Features entdeckt, die nicht unterstützt sind (s. Kap. 5.2.2).

3.3.3 Weitere gängige Internet Mapserver

3.3.3.1 Deegree

Deegree wurde 1997 als Forschungsarbeit entwickelt unter der Leitung des Fachbe-reichs Geographie der Universität Bonn. Deegree stellt die offizielle Referenzimple-mentierung für den WMS 1.1.1 von OGC dar. Aktuell ist derzeit die stabile Version 1.0.0.

“Implementation practice in the above mentioned projects showed that the functional overlap between different geospatial applications is much larger than simply the feature object model. The extension of the object model to a broader library was the starting point of the deegree initiative.” 25

The deegree approach may be best characterized by attributes like interoperable, com-ponent-based, plattform independent, pattern-oriented”

Die Produktpalette des deegree umfasst neben dem WMS-Modul noch weitere Modu-le, mit denen diverse Dienste angeboten werden könen. Dazu gehören neben dem bereits genannten Web Map Server ein Web Feature Server, ein Web Coverage Ser-vice, ein Web Gazetteer Service, ein Web Catalog Service, ein Web Terrain Server und ein Web Coordinate Transformation Service.

Prinzipiell ist deegree eine Sammlung aus Java-Servlets. Die Gesamtheit dieser

25 Von der deegree-hompage


Sammlung wird als deegree-Framework bezeichnet und bietet als solches die Möglich-keit des ständigen Erweiterns und Anpassens an gegebene Bedürfnisse.

Als Datenbasis kann deegree sowohl dateibasierte Daten wie ESRI Shapefiles als auch RDBMS wie z.B. ORACLE und MySQL sowie räumliche Datenbankerweiterun-gen wie ESRI ArcSDE und PostGIS einbinden.

Zur Konfiguration eines Kartendienstes werden insgesamt drei Dateien benötigt

1. wms_capabilities.xml: ist wichtigste Konfigurationsdatei, in der Kartendienst-Parameter und Metadaten aufgenommen werden.

2. localwfs_config.xml: Wie der Dateiname schon vermuten lässt, wird die Datei zur Konfiguration des Web Feature Service benötigt.

3. datasource_config.xml: Anhand dieser Datei wird die einzubindende Datenbasis beschrieben.

3.3.3.2 GeoMedia WebMap von Intergraph

Laut Intergraph ist GeoMedia Web Map das erste Web Mapping-Produkt, das auf dem Markt war:

“GeoMedia WebMap, the first Web-based map visualization and analysis software tool ever offered, …”26

GeoMedia Web Map kann laut eigenen Angaben als Map Server sowohl für gerasterte Karten als auch für Karten aus Vektorgraphiken fungieren.

Außer der Funktion als Kartenserver bietet GeoMedia Web Map GIS-Funktionalitäten wie Analysen (Querys), Verschneidungen und andere räumliche Operationen, die GeoMedia Web Map in den Rang eines "echten" Internet-GIS erheben.

GeoMedia Web Map ist an spezielle Aufgaben anpassbar (sog. customizing).

Laut Intergraph ist GeoMedia Web Map in der Lage folgende Eingabeformate zu ver-arbeiten:

Oracle9i™, Microsoft® SQL Server, Microsoft AccessMGE, MGE Segment Manager, MGE GeoData Manager, FRAMME™, ArcInfo, ArcView, Shape files, MapInfo, Auto-CAD, MicroStation® CAD, ODBC-compliant, OGC GML, OGC WFS.

Damit ist GeoMedia Web Map laut eigenen Angaben als OGC-konformer Kartendienst einsetzbar.

3.3.3.3 GeoServer und AEDGIS von AED SICAD

Die Web GIS-Lösung von SICAD heißt GeoServer. Die Anwendung ist laut eigenen Angaben in der Lage, außer Kartendienstfunktionen auch richtige GIS-Funktionalitäten zu bieten.

GeoServer unterstützt sowohl sowohl gerasterte als auch vektorielle Karten.

Die Fachschalen AEDGIS (oder @GIS) erweitern die Funktionalität von GeoServer.

26 Intergraph Homepage


Dabei konzentrieren sich die Fachanwendungen auf den Bereich ALK/ALB, ATKIS, Vermessung und Kataster. Zielkunden der Firma SICAD sind Kommunen, die ihren Einwohnern solche Dienste anbieten möchten.

GeoServer ist laut Angaben der Firma SICAD OGC-WMS-kompatibel und kann alle OGC-konformen Dienste integrieren.

3.4 XML

XML ist ein weiteres zentrales Element der Diplomarbeit, da SLD auf XML basiert. Deshalb zeigt dieses Kapitel ein Überblick über die wichtigsten Bestandteile und Ei-genarten von XML in Bezug auf das Verständnis von SLD.

Was ist XML? - Diese Frage ist nicht leicht zu beantworten. Man geht dies am besten von mehreren Seiten an:

Im eigentlichen Wortsinn ist XML zuallererst eine Auszeichnungssprache, wie sie uns am ehesten von HTML bekannt ist. Die Bedeutung von XML ist: "Extensible Markup Language", was soviel wie "erweiterbare Auszeichnungssprache" bedeutet. Laut [HVO], 29, ist XML vielmehr eine Metasprache oder auch Inhaltsbeschreibungsspra-che.

Entgegen des weit verbreiteten Irrglaubens ist XML, wie HTML auch, keine Program-miersprache, da ihr dazu die Elemente der Programmsteuerung fehlen.

Dabei ist XML entstanden, um den Bedarf nach einer Sprache zu decken, die sowohl von Mensch als auch Maschine gelesen und interpretiert werden kann. Eigentlich hatte man für diese Aufgabe schon ein entsprechendes Instrument mit SGML (Standard Ge-neralized Markup Language) zur Hand, aber leider war SGML mit einer Standarddefini-tion von über 500 Seiten [HVO], 30, viel zu unhandlich, als dass es sich als Standard in der Industrie durchgesetzt hätte. Erst XML als "SGML light" [HVO], 30, mit einer Stan-darddefinition von ca. 30 Seiten konnte sich aufgrund der Einfachheit seiner Struktur durchsetzen. Der Vorteil von XML gegenüber HTML, dem wesentlich älteren Abkömm-ling von SGML, lag in seiner Flexibilität:

HTML konnte lediglich mit ein paar Handvoll vordefinierter Tags27 aufwarten, während XML völlig frei in der Definition seiner Tags und somit beliebig erweiterbar ist. Ein wei-terer enormer Vorteil von XML gegenüber HTML bietet die Offenheit seiner Struktur: XML ist beliebig verschachtelbar, d.h., dass XML-Dokumente jederzeit frei erweiterbar bleiben.

Weil eine maschinenlesbare Sprache aber dennoch auf gewissen Regeln basieren muss, an die sich ein Algorithmus halten kann, gibt es Dokumente, welche die Gültig-keit von XML-Dateien definieren. Das sind entweder sog. "Document Type Definitions"

27 [Adobe Go Live CS], Tag: Ein von spitzen Klammern umschlossener Ele-mentname, der zur Auszeichnung eines Dokuments verwendet wird. In XML ist dabei die Wahl der Elementnamen prinzipiell frei, während HTML nur mit vorgegebenen Elementnamen arbeitet.


(DTD), deren Bedeutung für die Validierung von XML-Dokumenten schon im Rückgang begriffen ist, oder die XML-Schemadateien (*.xsd) (beide Arten der Gültigkeitsüberprü-fung werden im Kapitel 3.4.3 nochmals aufgegriffen).

3.4.1 Bedeutung von XML

XML hat seinen Siegeszug in vielen Bereichen der IT-Welt eingehalten und ist inzwi-schen zu einem industriellen Standard avanciert. Der Einsatz von XML ist vor allem in drei Kernbereichen zu finden:

I. Programmkonfiguration:

Vor XML wurden (und werden noch) sog. INI-Dateien (simple Textdateien) zur Pro-grammsteuerung benutzt. Der Nachteil bei diesen Dateien ist jedoch, dass hier kei-ne hierarchische Anordnung der Anweisungen und Parameter möglich ist, da der Aufbau lediglich dem Schema "Abschnitt/Wertepaare" folgt.

II. Datenspeicher:

XML besitzt eine hierarchische Struktur, ähnlich der eines Dateisystems. Aufgrund dieser Struktur kann man das Modell und den gesamten Inhalt von Datenbanken (auch relationalen Datenbanken) als XML-Dateien speichern. Der Vorteil dabei: Da-tenbanken werden dadurch direkt "internetfähig", da auf XML direkt über das http-Protokoll (ohne Umwege über Skriptanwendungen) zugegriffen werden kann (das spielt eine zunehmende Rolle bei E-Commerce). Häufig werden komplette Daten-banken in XML ausgelesen, wenn eine Datenbank mit einem bestimmten Format auf derjenigen eines anderen Herstellers abgebildet werden soll.

III. Allgemeingültige Schnittstelle zum Datenaustausch zwischen Programmen:

XML ist derzeit zu einer Art "Esperanto" des Datenaustauschs geworden (mit dem Unterschied, dass sich XML erfolgreich durchgesetzt hat). Immer mehr Software-hersteller entdecken XML als allgemeingültige Schnittstelle. Das heißt nicht, dass die Ausgabe des Programms X automatisch vom Programm Y verstanden werden kann (dazu ist nach wie vor eine Schnittstellenbeschreibung - gewöhnlich als Sche-ma - notwendig); aber es kann von Programm Y gelesen werden (wenn dieses XML implementiert hat), was in der Tat ein beachtlicher Fortschritt bezüglich Kompatibili-tät bedeutet.

3.4.2 Aufbau von XML

Der Aufbau von XML-Dokumenten ist zwar im Vergleich zu SGML wesentlich einfa-cher, aber dennoch gibt es ein paar Regeln und grundsätzliche Strukturelemente.

An der nachfolgenden Abbildung soll exemplarisch für alle XML-Dateien die Struktur sowie einige der wichtigsten Elemente von XML verdeutlicht werden:


Abb. 5 XML-Aufbau (Quelle: OGC, SLD Schema-xsd- Ausschnitt)

Die Strukturelemente in XML werden Knoten genannt, weil der Aufbau einer XML-Datei der einer Baumstruktur ist und überall da, wo der Baum sich verzweigt, Knoten entste-hen. Man unterscheidet insgesamt 7 Knotentypen:

Knotentyp Bedeutung

Wurzelknoten Die Wurzel eines XML-Dokuments. Sie umschließt alle weiteren Elemente

in dem Dokument. In Abb. 5 ist das Wurzelelement das Element

<xsd:schema>.

Elementknoten Ein Element besteht aus einem Anfangstag und seinem zugehörigen End-

tag. In Abb. 5 sind alle Elementknoten dunkelrot markiert.

Attributknoten Die zusätzliche Information innerhalb des Tags besteht aus dem Attribut-

namen links des Gleichheitszeichens und dem Attributwert rechts des

Gleichheitszeichens. In Abb. 5 sind alle Attributnamen hellrot markiert.

Textknoten Der Zeicheninhalt, der zwischen den Tags steht.

Namensraumknoten

Tags oder Attribute mit Namensraumangaben. Namensraumknoten können

sowohl Elemente als auch Attribute sein. Die Namensraumknoten werden

mit dem Namen Namespace oder TargetNamespace eingeleitet. Im Bei-

spiel wird der Namespace "xlink“ eingebunden.

Verarbeitungsanweisungs-knoten

Sie enthalten Verarbeitungsanweisungen wie Versionsinformation (augen-

blicklich Vers. 1.0), verwendetes Zeichenformat und die Information, ob es

andere Dokumente gibt, auf die sie sich beziehen (Standalone). Sie haben

folgendes Format: (<?....?>)

Kommentarknoten Sie enthalten Kommentare, die nicht vom XML-Prozessor verarbeitet wer-

den und haben folgendes Format: ()

Tab. 3 Knotentypen in XML

Zur Vereinfachung der Benennung von Beziehungen der einzelnen Strukturelemente


zueinander benutzt man Termini aus dem Familienleben. So heißt der Knoten, der sich in der Hierarchie direkt über dem aktuell betrachteten Knoten befindet (also der eine Knoten, von dem der aktuelle Knoten abhängt), Elternknoten. Entsprechend heißt der Knoten, der sich hierarchisch unter dem aktuellen Knoten befindet, Kindknoten. Alle Knoten, die sich auf derselben Hierarchiestufe mit dem aktuellen befinden, nennt man Geschwisterknoten. Somit können wir uns nun verbal in alle Richtungen innerhalb des XML-Baumes bewegen.

Besitzt ein Knoten in XML Kindknoten, hat er folgendes Format:

<Knoten>Kindknoten</Knoten>

D.h. der aktuelle Knoten besteht aus einem öffnenden und einem schließenden Tag (wobei dem schließenden Tag ein Schrägstrich - Slash - vorangestellt ist) und um-schließt den Kindknoten. Besitzt ein Knoten keine Kindelemente, so hat er dieses For-mat:

<Knoten/>

D.h., der aktuelle Knoten besteht nur aus einem einzigen Tag, aber der Slash steht jetzt am Ende des Tags. Der Slash am Tagende ist für den XML-Prozessor das Zei-chen, dass nach diesem Tag kein schließender Tag mehr folgt und somit auch kein Kindknoten mehr.

Diese Regel gilt nur für die Elementknoten (die allerdings die häufigste Knotenart eines XML-Dokuments ausmachen) und den Wurzelknoten (der streng genommen auch ein Elementknoten ist).

3.4.3 Die Gültigkeit von XML-Dokumenten

Die Namensraumknoten enthalten die Angaben der Namensräume, innerhalb derer die bestimmten Tags gültig sind. In Abb. 5 gibt es innerhalb des Elements Targetna-mespace ein Attribut namens xmlns. Der Attributname ist die Abkürzung für XML-Namespace. Der Attributwert ist die URL des Namensraumes, innerhalb dessen der Tag mit dem Namensraumkürzel dieses Namensraumes gültig ist. Ein Beispiel:

Die Elementknoten in Abb. 5 (z.B. das Element annotation) haben das Namensraum-kürzel (Namespaceprefix) "xsd:".

Das bedeutet, dass die URL "http://www.w3.org/2001/XMLSchema“ des XML-Namespace "xmlns:xsd" mit dem Namespaceprefix "xsd:" den Ort definiert, innerhalb dessen der Tag mit dem Namen annotation gültig ist.

Hinter der etwas umständlichen Erklärung steckt (meistens) die Tatsache einer "sim-plen" Validierungsdatei, die, wie in der Einführung schon erwähnt, aus einer DTD oder einem XML-Schema bestehen kann. D.h., diese Validierungsdatei ist unter o.g. URL erreichbar.

In beiden Dokumentarten ist der gültige Aufbau der vorliegenden XML-Datei bezüglich


seiner Syntax28 und seiner Semantik29 definiert. Anhand der vorliegenden Namens-raum-Informationen kann der XML-Prozessor die Validierungsdokumente aufsuchen (sofern der Prozessor darauf zugreifen kann) und mit der (den) verfügbaren Datei(en) die Gültigkeit des aktuellen XML-Dokumentes überprüfen.

Document Type Definitions, sog. DTD, sind keine XML-Dateien. Sie sind mit SGML geschrieben und können mit einem einfachen XML-Parser nicht gelesen werden. Mit DTD-Definitionen war es laut [HVO], 109, möglich,

„ein Vokabular für eine bestimmte Klasse von Dokumenten zu beschreiben und – ähnlich wie bei einer Grammatik – Regeln zu bestimmen, um zwischen gültigen und ungültigen ‚Sätzen’ unterscheiden zu können“.

Aber DTD’s haben Schwächen: Die Syntax ist nicht ausdrucksstark genug, um kom-plexere Aufgaben als reine Gültigkeitskontrollen übernehmen zu können.

XML-Schemata sind dazu in der Lage. Sie sind selbst gültige XML-Dateien, die auch von einem simplen XML-Parser gelesen werden können. Mit ihnen ist man nun auch in der Lage, sog. komplexe Datentypen (=Datentypen, die selbst aus diversen anderen Datentypen zusammengesetzt sind) zu definieren, Namensräume zu berücksichtigen, Vererbungsmechanismen einzubauen und unterschiedlichste Datentypen bis hin zu BLOB30 zu berücksichtigen.

Dies sind wohl auch die Gründe, weshalb man sich zur Gültigkeitsbestimmung von SLD für Schemadateien und nicht für DTD's entschieden hat.

3.4.5 Navigation und Adressierung

Es gibt mehrere Möglichkeiten, in einem XML-Baum zu navigieren. Eine grundsätzliche Möglichkeit bieten Programmierschnittstellen wie DOM, SAX oder XML-Reader/Writer. Diese Schnittstellen sind jedoch nicht in erster Linie zur Navigation im XML-Baum ge-dacht, weshalb wird die Navigation im nächsten Kapitel lediglich kurze Erwähnung fin-den wird.

Eine Möglichkeit der Navigation und Adressierung, die vom W3C als solche 1999 vor-geschlagen wurde, bietet die Hilfssprache XPATH.

XPATH (= XML Path Language) ist jedoch nur eine Adressierungsanweisung und be-nötigt einen prozessierenden Kontext, der die Anweisungen ausführt und die Ergebnis-se auswertet. Dafür ist im Normalfall ein XSLT-Prozessor31 zuständig; aber auch man-che Programmierschnittstellen wie das DOM oder SAX arbeiten mit XPATH-Unterstützung.

28 Syntax: Die korrekte Schreibweise eines Elements oder Attributs

29 Semantik: definiert, wo in der Hierarchie ein bestimmtes Element oder Attribut auftauchen darf und wie oft

30 [Wiki], Eintrag: BLOB= Binary Large Objects- große binäre, und damit nicht weiter strukturierbare Objekte oder Felddaten

31 XSLT= Extensible Stylesheet Language Transformation


„XML-gerechte Dokumente sind wie die Verzeichnis- und Dateistruktur auf einem Daten-träger aufgebaut. Dort gibt es ein Wurzelverzeichnis, das Verzeichnisse (Ordner) und Da-teien enthalten kann. Jedes untergeordnete Verzeichnis kann wiederum andere Unter-verzeichnisse und Dateien enthalten usw. Man spricht dabei auch von Baumstruktur.“ 32

XPath stellt daher eine Reihe an Schlüsselbegriffen bereit, die ein bestimmtes Verhält-nis der einzelnen Knoten untereinander definieren. Diese Schlüsselbegriffe lauten:

"child, parent, descendant, ancestor, following, preceding, following sibling, preceding sibling, attribute, namespace, self, descending-or-self und ancestor-or-self”.

Die Begriffe bedürfen keiner weitschweifigen Erklärung, denn es sind sog. "sprechen-de" Begriffe (d.h. ihr Sinn leitet sich aus ihrer Bezeichnung ab).

Des Weiteren kennt XPath zwei syntaktische Elemente zur Zuweisung und Trennung:

Der Slash „/“ und der doppelte Doppelpunkt „::“ (letzteres Element wurde wohl deshalb eingeführt, weil der einfache Doppelpunkt schon als Separierungszeichen für Na-mespaces belegt ist).

Z.B. würde man die Adressierung des Attributs „name“ aus Abb. 5 in folgender Weise schreiben (ohne Anführungszeichen):

„/child::xsd:schema/child::xsd:element/attribute::name”.

Der erste Slash steht für die abstrakte Dokumentenwurzel (Root). Danach folgt das Wurzelelement "xsd:schema”, darauf das Element "xsd:element“ und als letztes das Attribut "name“. Diese Schreibweise gilt als ausführlich. Die verkürzte (ebenfalls gülti-ge) Schreibweise für obiges Beispiel lautet:

„/ xsd:schema/ xsd:element/ name”. Sie erinnert stark an die Adressierung eines Datei-systems und in der Tat ist die Struktur von XML stark an die eines Dateisystems ange-lehnt.

Die XPath-Syntax wird in Kap. 5.1.1.4 noch einmal von Interesse sein, wenn die Konfi-gurationsdatei meines Programms vorgestellt wird, das zur Navigation XPath benutzt.

3.4.6 Programmschnittstellen

Die Programmschnittstellen von XML können in zwei grundlegend unterschiedliche Familien eingeteilt werden:

1. Die Familie, die durch das DOM (Document Object Model) repräsentiert wird

2. Die Familie, die durch SAX33 (für die Java Gemeinde) und XML-Reader/Writer (für die .NET-Gemeinde) repräsentiert wird.

Die erste Familie zeichnet sich dadurch aus, dass mit dem DOM ein Vor- und Zurück-bewegen in dem XML-Baum möglich ist. Mit DOM wird das komplette XML-Dokument (ob es nun aus 5 oder 5 Millionen Zeilen besteht) zunächst vollständig im Arbeitsspei-cher der Plattform abgebildet. Es entsteht sozusagen eine Kopie des XML-Dokuments,

32 [SEH], Eintrag

33 SAX= Simple API for XML


wobei diese Kopie nicht als eine Abfolge von Zeichen angesehen werden darf. Viel-mehr wandelt DOM das textbasierte XML-Dokument in eine geordnete Menge von Ob-jekten um.

Laut [HVO], 344, stellt DOM für alle Basiskomponenten (Knotentypen) abstrakte Ob-jektklassen mit genau definierten Schnittstellen bereit, denen eine bestimmte Menge von Methoden und Attributen eigen ist. So stellt z.B. die Klasse "Elements“ eine Me-thode zur Verfügung, mit der der Elementname extrahiert werden kann.

Mit all diesen Methoden ist man als Anwender in der Lage, sich nach Belieben vor, zurück und seitwärts in der XML-Hierarchie zu bewegen und die Elemente, Attribute oder Werte des jeweils interessierenden Knotens zu erhalten oder zu verändern.

Eine grundlegend unterschiedliche Philosophie zu der ersten Familie verfolgen SAX und XML Reader/Writer. Sie besitzen Streaming-Schnittstellen, die nur jeweils einen kleinen Teil des Dokuments in den Arbeitsspeicher laden, ihn dort in eine Abfolge von Methoden- und Attributaufrufen umwandeln und nach dem Schritt zum nächsten Do-kumentteil den Arbeitsspeicher, den das vorige Dokumentteil belegt hat, wieder frei-räumen. Die Einschränkung dieser Schnittstellen aber liegt gerade in der Natur des Streaming, weil dieses nur einen linearen vorwärtsgerichteten Dokumentzugriff zulässt.

Damit liegen die Vor- und Nachteile beider Schnittstellenfamilien auf der Hand:

DOM bietet hervorragende Navigationsmöglichkeiten, ist aber langsam im Zugriff; SAX und XML-Reader/Writer sind sehr schnell, bieten aber nur vorwärtsgerichteten Doku-mentzugriff. Welche der beiden Schnittstellenfamilien im Einzelfall am günstigsten ist, hängt somit von der Verwendung ab: Den Inhalt einer Datenbank mit einer sechsstelli-gen Zahl von Einträgen würde man sicherlich praktikabler mit SAX oder XML-Reader/Writer herausschreiben. Um bestimmte Einträge in einem XML-Dokument zu suchen/finden und davon Einträge an anderer Stelle abhängig zu machen, würde man eher DOM benutzen. Was die jeweiligen Schnittstellen nicht alleine schaffen, kann durch Kombinieren der beiden Familien erreicht werden.

Das von mir entwickelte Programm benutzt beide Schnittstellen: DOM und Rea-der/Writer.

3.5 SLD

Mit SLD bietet OGC die Grundlagen, die begrenzten Möglichkeiten eines gewöhnlichen WMS bezüglich der Darstellung von zu veröffentlichenden Daten wesentlich zu erwei-tern. Einem WMS ist es lediglich möglich, einen Datensatz in einer vordefinierten Wei-se durch eine begrenzte Anzahl von Styles "im Ganzen“ darzustellen. Das heißt, mit WMS allein ist keinerlei Klassenbildung der vorhandenen Daten möglich - einem Layer wird ein einziger Style zugeordnet. Will man die Daten klassifizieren, d.h. attributab-hängig in verschiedene Klassen einteilen und diese dann auch unterschiedlich darstel-len, benötigt man ein weiteres Werkzeug, das OGC jetzt mit der SLD Spezifikation bie-tet.


SLD liegt z.Zt. in der Version 1.0.0 mit der Spezifikation vom 19.08.2002 vor. Es ist ein XML-Derivat, d.h. eine Darstellungsanweisung, die auf Grundlage der gängigen XML Spezifikation erstellt wurde.

SLD ist nicht nur in der Lage, mit WMS zusammenzuarbeiten, sondern kann auch be-nutzt werden, um Inhalte von WCS34 oder WFS35 darzustellen und entsprechend zu symbolisieren.

Die SLD kann auf drei verschiedene Weisen in einen Dienst eingebunden werden:

1. mit einem http-GET Request "Inline“, wobei die SLD als Wert des CGI-Parameters SLD_BODY übergeben wird:

Abb. 6 Inline-SLD (Quelle: OGC, SLD Specification)

2. mit einem http-GET Request, auf ein externes SLD-Dokument über eine URL als Wert des CGI-Parameters SLD:

http://mapserver:8080/wmsconnector/com.esri.wsit.WMSServlet/guek300?request=get map&srs=EPSG:31467&bbox=3447309,5542994,3450522,5545762&layers=GEOLOGIE.GUEK300_POLY&styles=Style1&SLD=http://mapserver/website/wms_sld/SLD_valid2.xml&format=png&width=250&height=400

3. mit einem http-POST Request, im "body"- Element einer aufrufenden Website in XML codiert

34[GUR], Eintrag: WCS= Web Coverage Service- Ein von der OGC spezifizier-ter de facto Standard zum Zugriff auf Rasterdaten

35[GUR], Eintrag: WFS= Web Feature Service- Ein von der OGC spezifizierter de facto Standard zum Zugriff auf vektorielle Geodaten über HTTP als Netzwerkprotokoll, die in Datenbanken oder dateibasierten Formaten vor-liegen können.


Die 1. Methode kann leicht unübersichtlich werden und ist für sehr große SLD praktisch undurchführbar. Die 3. Methode ist laut [OGS], 8 technisch nicht einfach umzusetzen. Methode 2 ist ein guter Kompromiss zwischen 1 und 3 und wird in der Praxis am häufigsten verwendet.

Sowohl die Layers in einem SLD-Dokument, als auch die Rules (ein spezielles Element in SLD, dessen Bedeutung später erklärt wird) innerhalb eines Layers sind laut [OGS], 4 "Z-ordered“ 36; d.h. die Reihenfolge ihres Auftretens spielt für das Rendern eine Rolle. Das Element, welches im SLD-Dokument weiter "unten" liegt, wird später gerendert und befindet sich damit relativ zu dem im Dokument "darüberliegenden" Element im Vordergrund (die Begriffe "oben" und "unten" werden hier in Bezug auf den Lesefluss verwendet).

Eine interessante Möglichkeit, die SLD für einen WMS bietet, ist die Übernahme von Styles aus einer SLD in die Definitionsdatei des Mapservers. Wenn der Mapserver dies unterstützt, können mit dem CGI-Parameter "GetStyles" die in der Konfiguration des Mapservers definierten Styles abgefragt werden. Im Gegenzug können über den Pa-rameter "PutStyles" (wiederum nur, falls der Mapserver das unterstützt) laut [OGS], 64, Symboldefinitionen aus einer vorhandenen SLD in eine Mapserverkonfiguration über-nommen werden. Dazu werden in der Aufruf-URL besagte Parameter eingeflochten und als Parameterwert der zu übernehmende Style aus der SLD gesetzt.

3.5.1 Einige spezielle SLD-Elemente

Dieses Kapitel sieht nicht vor, alle Elemente der SLD Spezifikation und ihre Bedeutun-gen aufzulisten; aber dennoch möchte ich einige, von deren Wichtigkeit ich überzeugt bin, herausgreifen (u.a. weil sie in den SLD vorkommen, die zur Darstellung der GÜK 300 benutzt werden) und ihre Bedeutung kurz erläutern:

NamedLayer und UserLayer:

NamedLayer und UserLayer sind Kindelemente des SLD Root-Element StyledLay-erDescriptor.

Ein NamedLayer-Element wird dann verwendet, wenn der Layername zuvor in der Konfigurationsdatei des WMS festgelegt wurde. Man kann den Layernamen über-prüfen, indem an den WMS eine GetCapabilities-Anfrage gestellt wird. In der auf die Anfrage folgenden Antwort sind alle zur Verfügung stehenden NamedLayer aufgeli-stet.

Ein UserLayer hingegen wurde noch nicht vorab in der Konfiguration des WMS defi-niert. Das Element dient dazu, per SLD aus einer vorhandenen Datengrundlage ei-nen neuen Layer zu definieren. Allerdings wird dieses Feature z.Zt. noch von weni-

36 Rendering der Kartenelemente nach dem Z-Buffer-Verfahren: Eine Weiter-entwicklung des Painters-Algorithmus, bei dem wie bei der Farbe eines Malers eine Schicht über der anderen aufgetragen wird und die letzte Schicht, die vordeste, die alles überdeckende ist.


gen Mapservern unterstützt.

NamedStyle und UserStyle:

Äquivalent zu den oberen beiden Elementen erfüllen die Präfixe "Named" und "User" der Elemente NamedStyle und UserStyle hier dieselben Aufgaben:

Ein NamedStyle muss vorab als Style in der Definitionsdatei des WMS fixiert sein, damit er als solcher in der SLD deklariert werden kann.

Ein UserStyle hingegen ist ein "on the fly" in der SLD generierter Style, der sich nicht auf einen vorher festgelegten Style beziehen muss.37

Rule:

Das Rule-Element ist sehr wichtig, da mit ihm die Definition einer Regel zur Klassifi-zierung des Layers eingeleitet wird. Alle notwendigen Informationen, sowohl zur Klassenbildung einer aktuellen Klasse als auch deren Symbolisierung, stehen in-nerhalb des Elementes Rule.

Filter:

Das Element Filter ist eigentlich kein Element aus der SLD Spezifikation, sondern aus der "OGC Filter encoding Specification" der Version 1.1 vom 05.03.2005. In ihr sind alle Termini definiert, die notwendig sind, um logische Operationen auszufüh-ren, die der Funktion eines SQL-Statements gleichzusetzen sind. Es ist nicht unüb-lich, dass die Syntax der einen Spezifikation mit der einer anderen vermischt wird, um so eine höhere Funktionsvielfalt zu erreichen (wobei sich hier einmal mehr in der tatsächlichen Machbarkeit einer solchen Vermengung die Vorteile von Standardisie-rungen zeigen). Als Voraussetzung dafür muss im SLD-Dokument aber der Na-mespace der Partnerspezifikation mit eingebunden werden, damit das Dokument seine Gültigkeit behalten kann.

Da ein Layer ohne Klassifizierung einheitlich dargestellt würde, muss dem Mapser-ver mitgeteilt werden, nach welchen Bedingungen er die aktuelle Klasse erstellen soll. Diese Bedingung wird durch das Element Filter eingeleitet. Innerhalb des Filter-Elements können Vergleichsoperatoren wie PropertyIsEqualTo, PropertyIsNotE-qualTo, PropertyIsLessThan, PropertyIsGreaterThan etc. sowie räumliche Operato-ren wie Touches, Overlaps, Intersects u.v.a.m als auch logische Operatoren wie And, Or und Not enthalten sein. Diese modellieren SQL-Funktionalität in SLD nach, so dass es mit dem Element Filter möglich ist, regelrechte Querys wie in SQL abzu-setzen.

Außer dem Element Filter gibt es das verwandte Element ElseFilter, das in einer Klassifizierung dafür verwendet werden kann alle Werte, die mit Filter noch nicht klassifiziert wurden, einer alternativen Klasse zuzuweisen.

37 In dem von mir entwickelten Programm werden NamedLayer und UserStyle verwendet, weil sich mit dieser Kombination z.Zt. die größtmögliche Kompatibilität mit der höchstmöglichen Flexibilität verbinden lässt.


Symboldefinitionen PointSymbolizer, LineSymbolizer, PolygonSymbolizer, TextSymbo-lizer, (RasterSymbolizer):

Unter den jeweiligen Symboldefinitionen sind alle zur Symbolisierung der jeweiligen Klasse notwendigen Einstellungen und Eigenschaften festgelegt. Attribute wie Farb-füllung, Strich-, Text- und Punktfarbe, Strichstärke, Texthöhe, Punktgröße, Deckkraft der Farbe u.v.m., aber auch die Art von Flächenfüllungen (vollflächig, mit graphi-schen Füllelementen oder der Referenz auf ein hinterlegtes Bitmap) sowie das Aus-sehen von Linien (gestrichelt, gepunktet etc.) werden hier definiert.

3.6 ArcGIS von ESRI

ArcGIS von ESRI ist die neue Produktlinie für Professional GIS der Firma ESRI aus Redlands/Kalifornien. Seine Markteinführung war im Jahre 2000 und seither läuft Arc-GIS als Produktlinie parallel zu dem 1981 eingeführten ArcInfo, was bis dato das marktführende Professional-GIS weltweit darstellte. Inzwischen besitzt ArcGIS mehr Bedeutung in der GI-Branche als ArcInfo und wird das betagte GI-System in einigen Jahren wahrscheinlich vollständig abgelöst haben.

Laut den Zahlen von [BUW], 42 u. 46, ist ESRI Marktführer sowohl in D, A, CH (deutschsprachiges Gebiet) mit einer Summe von 18.000 Lizenzen als auch weltweit mit 240.000 Lizenzen für das Professional GI-System ArcGIS.

Die Marktführerschaft mit seinen GI-Systemen ist ESRI sicherlich u.a. deshalb be-schieden, weil es seit seinem Gründungsjahr 1969 eines der ersten Unternehmen ü-berhaupt war, das kommerzielle GI-Systeme anbieten konnte. Aber auch die Palette an verfügbaren Zusatzmodulen zu den GIS, die Erweiterbarkeit (Customizing) und die Kompatibilität der einzelnen GI-Produkte untereinander trugen zu diesem Erfolg bei. Das wiederum hatte zur Folge, dass proprietäre ESRI- Formate wie z.B. Shapefiles bei den vektorbasierten Daten oder Coverages bei den rasterbasierten Daten zu weltweit anerkannten Standardformaten avanciert sind.

Neben diversen Werkzeugen besteht ArcGIS hauptsächlich aus den Komponenten ArcMap und ArcCatalog. ArcCatalog ist die umfangreiche Datenmanagement-Applikation von ArcGIS, in der ähnlich dem Microsoft Explorer Daten kopiert, erstellt, verschoben und in sonstiger Weise verändert werden können.

ArcMap bildet die Anwendung, in der Karten aus den Daten erstellt werden. Hier kön-nen die Geodaten analysiert und in ansprechender Weise dargestellt und nach Wunsch gelayoutet werden. Im Folgenden wollen wir uns mit ArcMap etwas eingehen-der beschäftigen:


3.6.1 ArcMap

ArcMap ist ein mächtiges Werkzeug mit einer beeindruckenden Fülle an Möglichkeiten zur Bearbeitung von Kartendaten. Die Arbeit soll indes kein Leitfaden zur Handhabung von ArcMap werden; dazu gibt es genügend umfangreiche Literatur. Ich möchte mich stattdessen auf die Belange der Symbolisierung in ArcMap beschränken, die zur Er-stellung dieser Arbeit relevant waren.

Eine der wichtigsten Funktionen in ArcMap ist die Möglichkeit zur Klassifizierung der Daten. Unter dem Programmteil "Layer Properties" findet man alle Einstellungsmög-lichkeiten, mit denen die Anzeige der Daten editiert werden können. Unter dem Reiter "Symbology" sind alle Einstellungen zu finden, anhand derer die Daten klassifiziert und den Klassen entsprechende Symbole zugewiesen werden können.

Man findet hier fünf Hauptmethoden zur Klassifzierung:

1. Features: Die Daten werden alle als "Single Symbol" unklassifiziert mit der glei-chen Symbolisierung dargestellt

2. Categories: Mit dieser Einstellung können Daten nach einem oder maximal drei Datenbankfeldern klassifiziert werden, indem aus diesen Feldern die "Unique Values"38 gebildet werden.

3. Quantities: Hier werden die Daten aus einem bestimmten Feld in Wertebereiche eingeteilt und jedem Bereich eine bestimmte Symbolisierung zugewiesen. Die Bereiche können über mathematische Funktionen oder manuell zugewiesen werden.

4. Charts: Mit dieser Funktion können 0 bis maximal alle Felder einer Datenbank ausgewählt werden, um die darin enthaltenen Daten als Diagramm darzustel-len. Es besteht die Möglichkeit, mehrere Diagrammarten auszuwählen und da-mit jedes Objekt der Karte nach den Kriterien der ausgewählten Felder mit ei-nem Diagramm zu versehen.

5. Multiple Attributes: Diese Einstellung vebindet die Funktionalitäten von Catego-ries und Quantities.

ArcMap ist als Professional-GIS in der Lage sehr komplexe Symbolisierungen zu er-stellen und zu verwalten. Mit der Funktion "Properties" des "Symbol Selector" können die Symbole bearbeitet werden. Zur Auswahl stehen sieben Symbolarten für Polygone, fünf Symbolarten für Linien und fünf Symbolarten für Punktsymbole. Für jede Feature-klasse39 sind als Symbolart außerdem so genannte Multilayersymbole verfügbar, in denen die Grundsymbolarten in beliebig vielen Layern übereinander geschichtet wer-den können, um so sehr komplexe Symbolisierungen für jede einzelne Klasse zu er-möglichen.

38 Unique Values: Von einem bestimmten Feld werden aus allen vorkommenden Werten die 'eindeutigen Werte' extrahiert und in einer Liste zusammen-gestellt. In SQL entspräche dieser Vorgang der Anweisung "SELECT DI-STINCT …"

39 Featureklasse: Polygon, Linie, Punkt, Raster oder Text bilden die fünf möglichen Featureklassen


So ist es möglich Flächensymbole mit komplizierten Punktfüllungen und Schraffuren zu realisieren, die durch die Möglichkeit ein hinterlegtes Bitmap einzubinden zusätzlich erweitert werden können.

Punktsymbole werden als Typen diverser Schriftarten (sog. ESRI Truetype Fonts) ein-gebunden. Somit ist es möglich, die Punktsymbolpalette beinahe beliebig zu erweitern.

Flächenhafte Symbole können grundsätzlich Liniensymbole und Punktsymbole enthal-ten. Liniensymbole wiederum können beliebig viele Punktsymbole enthalten (z.B. für sog. kartographische Linien, die eine unterschiedliche Sequenz versch. Punkt- und Strichsymbole enthalten können).

Diese Vielfalt der Möglichkeiten setzt ein äußerst komplexes Datenmodell voraus, das in der Lage ist, alle diese Varianten zu prozessieren. Dieses Datenmodell (oder Ob-jektmodell) wird durch die Klassenbibliothek "ArcObjects" von ESRI repräsentiert.

3.6.2 ArcObjects

ArcObjects ist die Entwicklungsplattform von ArcGIS. Man unterscheidet hier drei Kom-ponentenfamilien:

1. ArcGIS Desktop: Objektfamilie zur Erweiterung und Anpassung der ArcGIS Desktop Familie (ArcCatalog, ArcMap, ArcToolbox, ArcScene, …)

2. ArcGIS Engine: Objektfamilie zur Nutzung von GIS-Funktionalität in eigenständig arbeitenden Applikationen

3. ArcGIS Server: Objektfamilie zur Erweiterung und Anpassung der ArcGIS- Server Familie.

ArcObjects ist somit eine Sammlung von Klassen und deren Schnittstellen. Es wurde mit der Microsoft COM-Technologie40 entwickelt, was bedeutet, dass die meisten Klas-sen als sog. "abstrakte" Klassen mit ihrer Funktionalität nicht direkt benutzt werden können um Objekte zu erzeugen, sondern über ihre Interfaces (Schnittstellen), von denen es für jede Klasse meist mehrere gibt, an andere Klassen angebunden werden.

Die Schnittstellen legen die Funktionalität der Klassen offen. Möglich wird damit das Setzen oder Abrufen von Eigenschaften einer implementierenden Klasse sowie der Benutzung ihrer öffentlichen Methoden.

Mit dieser Technologie können die meisten Möglichkeiten objektorientierter Program-mierung realisiert werden (mehr zu objektorientierter Programmierung im nächsten Kapitel).

40 [Wiki], Eintrag: Das Component Object Model (Abkürzung COM) ist eine von Microsoft entwickelte proprietäre Technologie, um unter Windows Klassen aus DLLs (Dynamic Link Libraries) zu exportieren. Somit soll COM eine leichte Wiederverwendung von bereits geschriebenem Programmco-de möglich machen


Der Nachteil von com-Technologie ist u.a., dass keine gemeinsam genutzte dll41 in unterschiedlichen Versionen vorliegen darf, da es ansonsten zu Versionskonflikten kommt. ArcObjects bietet allerdings inzwischen Alternativen zu COM:

Für die Benutzung der .NET-Technologie hält ESRI seit der Version 8.3 parallel zu der COM-basierten Objektbibliothek eine eigene, auf .NET-Technik basierende Objektbi-bliothek bereit, die denselben Funktionsumfang bietet, aber nicht die Nachteile der com-Technologie in Kauf nehmen muss. Das Schnittstellenmodell, wie es in der COM-Technologie üblich ist, wurde also in .NET nachempfunden, um die Konsistenz der Schnittstellenbeschreibungen in beiden Fällen zu wahren.

Mit ArcObjects kann der Entwickler alle Funktionen ansprechen, die auch in den An-wendungen von ArcGIS über die Benutzeroberfläche erreichbar sind, da ArcGIS genau dieselben Klassen aus der ArcObjects- Sammlung benutzt.

Nachfolgend die Auflistung aller Objektmodelle der ArcGIS-Kernanwendung:

Core

3DAnalyst DataSourcesSMUUI Maplex

3DAnalystUI Display NetworkAnalysis

ArcCatalog DisplayUI Output

ArcCatalogUI Editor OutputExtensions

ArcGlobe EditorExt OutputExtensionsUI

ArcMap Framework OutputUI

ArcMapUI GeoAnalyst Publisher

ArcScan GeoDatabase PublisherUI

ArcScene GeoDatabaseDistributed Server

Carto GeoDatabaseDistributedUI SpatialAnalyst

CartoUI GeoDatabaseUI SpatialAnalystUI

Catalog Geometry SurveyDataEx

CatalogUI Geoprocessing SurveyExt

Controls GeoprocessingUI SurveyPkgs

DataSourcesFile GISClient System

DataSourcesGDB GlobeCore SystemUI

DataSourcesOleDB GlobeCoreUI TrackingAnalyst

DataSourcesRaster Location TrackingAnalystUI

DataSourcesRasterUI LocationUI

Tab. 4 Objektmodelle der ArcGIS-Kernanwendung (Quelle: ArcGIS Developer Help)

41 dll: Dynamic Link Library - gemeinsam nutzbare Objekt- und Klassenbi-bliotheken.


3.7 Visual Basic.NET

Will man erklären, was Visual Basic.NET ist, muss man sich dem Begriff von zwei Sei-ten nähern, denn der Begriff beinhaltet zwei wesentlich differierende Modelle:

1. Das Sprachkonzept Visual Basic mit seiner speziellen Syntax

2. Die Objektbibliothek .NET, deren Klassen nicht nur für Visual Basic verfügbar sind, sondern auch für die Sprachkonzepte C++, C# (sprich: C sharp), Java (so-fern die Java-API mit eingebunden werden), J# und andere objektorientierte Sprachen.

3.7.1 Konzept der Objektorientierten Programmiersprachen (OOP)

Historie:

Die Programmiersprachen entstanden aus der Notwendigkeit, immer gleichförmige Arbeitsabläufe bei Maschinen durch einen Algorithmus42 zu ersetzen, der das Handan-legen überflüssig machte. Aus diesem geschichtlichen Hintergrund entstanden die er-sten Sprachkonzepte für maschinenlesbare und –interpretierbare Programmsprachen. Den Anforderungen entsprechend waren diese Sprachen dazu ausgelegt, eine Proze-dur vom Anfang bis zu ihrem Ende sequenziell durchzuarbeiten. Daher wird diese Art von Programmierkonzept als "prozedural" beschrieben.

Bekannte Vertreter solcher Sprachen sind z.B. BASIC, PASCAL, C, FORTRAN u.v.a.m. Viele dieser Sprachen waren außerdem sog. interpretierte Sprachen. D.h. ihr Quellcode wurde direkt beim Ausführen übersetzt in hexadezimale Maschinensprache, die dann wiederum in prozessierbaren Binärcode umgewandelt werden musste. Diese Zwischenschritte machen interpretierte Sprachen langsam. Als Abhilfe wurden Spra-chen wie z.B. C von Borland Software Corp. kompiliert, d.h. vorab vom menschenles-baren Quellcode in eine maschinenlesbare Hexadezimaldatei transformiert. Werden solche Dateien ausgeführt, müssen sie nur noch in einen binären Datenstrom umgewandelt werden, was einen enormen Zeitvorteil bringt.

Prozedurale Programmiersprachen beherrschten lange Zeit die Welt der Programmie-rung, denn sie genügten den Ansprüchen, die in der Vergangenheit an sie gestellt wur-den. Mit der Verbreitung von Computern und dem stetig wachsenden Bedarf an Com-puterprogrammen stand bald fest, dass der Anspruch an Wiederverwendbarkeit von Code zur Minimierung der Herstellungskosten von Software ein neues Konzept not-wendig machte. Das erste Sprachkonzept, das diesen Ansprüchen genügte, sich aber als objektorientierte Sprache nicht durchsetzte, war Smalltalk. Eine 1972 von Xerox entwickelte Sprache, der jedoch die damals verfügbaren Speicher- und Prozessorka-pazitäten nicht gewachsen waren. Den ersten Durchbruch als objektorientierte Sprache hatte 1983 C++ als objektorientierte Erweiterung von C (wobei in der Literatur durch-

42 [DUD], Eintrag: Algorithmus= Rechenvorgang, der nach einem bestimmten, sich wiederholenden Vorgang abläuft


aus widersprüchliche Zeitangaben diesbezüglich zu finden sind).

Technik:

Als objektorientierte Programmierung wird die Vorstellung eines Computerprogrammes als Kombination aus getrennten, aber interagierenden Objekten bezeichnet. Ein Objekt umfasst sowohl Informationen als auch die Möglichkeiten an die Information heranzu-kommen und sie zu ändern. Vier Hauptmerkmale kennzeichnen Objektorientierte Spra-chen:

1. Kapselung

Der Quellcode kann verborgen und Elemente des Codes somit vor unkontrolliertem Zugriff geschützt werden. Der Nutzer des Codes interagiert mit den gekapselten Funktionalitäten über definierte Schnittstellen (die in den meisten Programmierspra-chen mit den Schlüsselbegriffen "private" - für geschützt bzw. nur klassenintern nutzbar - und "public" - für öffentlich zugänglich - deklariert werden). Dies sorgt für ein klares Programmdesign und schützt vor Fehlern.

2. Vererbung

Neue Objekte lassen sich aus vorhandenen Objekten ableiten und erben deren Ei-genschaften und Verhalten. Neue Eigenschaften und Fähigkeiten können hinzuge-fügt werden, um das vorhandene Objekt zu erweitern. Dies beschleunigt die Soft-wareentwicklung und macht den Code strukturierter und damit besser verständlich.

3. Abstraktion

Objekte können als abstrakte Modelle von realen Objekten (oder Subjekten) ange-sehen werden, die Eigenschaften und Handlungsweisen der realen Objekte nach-empfinden können.

4. Polymorphie

Objekte können auf Nachrichten unterschiedlich reagieren. Im Code wird das als sog. "überladene" Funktionen und Methoden umgesetzt.

Die Philosophie objektorientierter Programmierung geht davon aus, dass ein bestimm-ter Code nur einmal quasi als "Muster" erstellt werden muss und dann beliebig oft ver-wendet werden kann. Solch ein in sich abgeschlossenes Muster wird als "Klasse" be-zeichnet. Um diese Klasse zu benutzen, muss eine sog. "Instanz" von ihr erstellt wer-den. Das ist eine nur zur Laufzeit vorhandene Kopie dieser Klasse. Der Vorteil dabei ist, dass beliebig viele Instanzen der Klasse erstellt werden können.

3.7.2 Visual Basic

Die Geschichte von Visual Basic beginnt mit der Erfindung von BASIC (Beginners All-purpose Symbolic Instruction Code) im Jahre 1964 als leicht erlernbare Sprache für Programmieranfänger. Sie war interpretiert und prozedural. Im Jahre 1975 entwickelte Microsoft auf deren Grundlage die Sprache Quick BASIC oder kurz QBASIC. Mit Visual Basic 1.0 war die erste Entwicklungsumgebung für die Entwicklung einer Graphischen


Benutzeroberfläche (GUI) für BASIC geboren. Bis Version 5.0 war Visual Basic immer noch eine interpretierte Sprache und insofern den kompilierten Konkurrenten bezüglich Prozessgeschwindigkeit weit unterlegen. Bis zur 6-er Version benutzte Visual Basic die COM-Technologie von Microsoft. Danach entschloss man sich, alles Alte über Bord zu werfen und eine völlig neue Sprache zu entwickeln, die zwar auf vorhandene Syntaxmodelle aufbaute, aber völlig neue Objekte und Mechanismen der Objektbibliothek .NET integrierte. Mit anderen Worten: Visual Basic.NET ist mitnichten der Nachfolger von Visual Basic 6, sondern eine völlig neue und vollwertige objektorientierte Programmiersprache.

3.7.3 .NET Framework

Das wohl hervorstechendste Merkmal von .NET ist: Es gibt keine sprachspezifische Laufzeitumgebung (Runtime) mehr, lediglich eine Runtime für viele unterschiedliche Sprachen. Die Sprache selbst wird auf die Funktion als bloßer Syntaxträger reduziert. Ein weiteres spezifisches .NET-Merkmal ist die Kapselung aller Betriebssystemfunktio-nen durch die Klassenbibliothek (es sei denn, es werden Nicht-.NET-Module verwen-det wie z.B. COM-Klassen).

.NET besteht aus drei Hauptkomponenten:

1. den .NET-Servern

2. dem .NET-Framework

3. den .NET-Diensten

Der .NET-Server liegt, vergleichbar einem Betriebssystem, als Schicht unter den er-stellten Programmen. Er bietet Funktionalitäten, die laut [MAS], 40, "das Erstellen von verteilten Systemen ersparen", d.h. für eine best. Aufgabe Betriebssystemfunktionen an verschiedenen Stellen ausführen, die ansonsten vom Programmierer alle für sich implementiert werden müssten. Dazu gehören Backend-Funktionen wie:

Das Microsoft Windows Server-Betriebssystem, Software für Clustering und Lastenver-teilung (z.B. die Garbage-Collection, die die flexible Speicherverwaltung managed), den Datenbankserver Microsoft SQL Server, Microsoft Exchange-Server (für E-Mail etc.) u.e.m.

Das .Net-Framework ist eine neue Klassenbibliothek, die einen Zugang zu fast allen Betriebssystemfunktionen bietet. Sie stellt zum einen die Basis-Laufzeitumgebung und zum anderen eine Reihe sog. Foundation Classes, die, wie der Name schon sagt, das Fundament des Frameworks bilden. In der Version 1.1 besitzt das .NET-Framework mehr als 4.500 Foundation Classes. Diese Klassen können beliebig erweitert werden. Microsoft bietet nämlich über die "Common Language Specification" Fremdanbietern einen Standard, anhand dessen deren Sprachen über die sog. Common Language Runtime (CLR) mit in .NET-Projekte eingebunden werden können. So ist es möglich, über die CLR z.B. Java-APIs von SUN Microsystems mit einzubinden und somit vorlie-genden Java-Sourcecode in .NET wiederzuverwerten.


Außer den oben genannten Sprachen werden z.Zt. folgende Sprachen unterstützt:

Dyalog APL/W Version 9, Fujitsu COBOL, Component Pascal, Eiffel, Haskell, Mercury, Perl, Python, Scheme, Standard ML.

Die .NET-Dienste sind webbasierte Dienste, die Funktionalitäten über ein http- oder ftp- basiertes Protokoll zur Verfügung stellen, welche normalerweise nur als Desktopappli-kationen laufen würden (z.B. über ASP - Active Server Pages).

Bei Leistungsvergleichen mit anderen Sprachen schneidet .NET gut ab und das trotz der hohen Funktionalitätsdichte, die hinter der Ausführung eines .NET-Codes steckt. Laut [VBN], die sich auf einen Leistungsbenchmark von "The Middleware Company" stützen, zeigte .NET bei einem Vergleich mit der J2RE einen Leistungsvorsprung von 50% mehr Prozessgeschwindigkeit als die Java-Engine.

4 Anforderungsdefinition und Planung -38-

4 Anforderungsdefinition und Planung

4.1 Anforderungen an das Programm

Dieses Kapitel soll erstens im Einzelnen festlegen, welche Funktionen das Programm beherrschen und wie es aufgebaut sein muss, um die in Kap. 1 definierten Vorgaben - nämlich eine valide SLD zu erzeugen - zu erfüllen.

Zweitens sollen die Voraussetzungen zum Testen der SLD auf den gewählten Test-Map-Servern erörtert werden.

Außer den in Kap. 1 genannten Zielen wurden an das Programm detailliertere Forde-rungen gestellt, welche die Stabilität und Bedienbarkeit verbessern:

Zum einen sollte es möglich sein, auf eventuelle Änderungen der SLD-Spezifikation bezüglich der Syntax reagieren zu können, ohne den Quellcode ändern zu müssen.

Zum anderen müsste eine Validierung (Gültigkeitsüberprüfung) der entstandenen SLD über eine Schemadatei möglich sein, um zu überprüfen, ob eventuelle Änderungen in der Spezifikation eine ungültige SLD zur Folge haben.

In erster Linie muss das Programm jedoch in der Lage sein, Kartendaten aus vorhan-denen ArcMap-Karten in SLD zu übersetzen.

4.1.1 Die Geologische Übersichtskarte von Hessen 1:300.000

Dazu soll an dieser Stelle zunächst die Struktur und die relevanten Besonderheiten der Geologischen Übersichtskarte von Hessen 1:300.000 (GÜK 300) hervorgehoben wer-den, die exemplarisch für die Umsetzung von ArcMap-Projekten in SLD als "Härtetest" gewählt wurde.

Exkurs in die Geologie:

Die GÜK ist eine Geologische Karte (herkömmlicherweise in Papierform), deren The-men Ergebnis einer Generalisierung der geologischen Grundkarten des Maßstabes 1:25.000 (oder kurz: GK 25) sind.

Die Themen der Geologischen Übersichtskarte sind Lithostratigraphie43, Petro-

43 [GMU], 195: Stratigraphie: Geologischer Wissenschaftszweig, der die Ge-steine unter Betrachtung aller ihrer anorganischer Merkmale und Inhalte nach ihrer zeitlichen Bildungsfolge ordnet, und eine Zeitskala zur Da-tierung der geologischen Vorgänge und Ereignisse aufstellt. Lithostra-tigraphie: Die L. ist in der Lage, örtliche oder regional auftretende Gesteinseinheiten zu beschreiben, und fazielle, räumliche, oder zeitli-che Beziehungen der einzelnen Fundpunkte zueinander darzustellen.


graphie44, Faziesgrenzen45 und Störungen46, wobei laut [GAD], Bd.II, 91, Petrographie und Faziesgrenzen einer geologischen Karte „sich einheitlich auf die obersten petro-graphisch definierbaren Gesteine, die unter dem Mutterboden, bzw. einer anderen Verwitterungsdecke bis in max. 2m Teufe anstehen, beziehen“ (Teufe: bergmännischer Ausdruck für Tiefe). Störungen hingegen können zwar an der Oberfläche sichtbar sein, ihr Erscheinungsbild in der Karte bezieht sich aber meistens auf Gesteinsformationen, die wesentlich tiefer lagern.

Im Falle der GÜK 300 Hessen wurden die analogen Themen digitalisiert und liegen jetzt als ArcGIS-Projekt auf Grundlage von ArcSDE-Daten vor (für den UMN-Mapserver wurden jedoch Shape-Dateien als Datengrundlage benutzt). Zusammen mit weiteren Themen aus anderen Teilbereichen der Geologie (z.B. Hydrogeologie, Roh-stoffe, Schwermetallkonzentrationen) bilden sie die Fachanwendung "Geowissen-schaftliche Übersichtskarte von Hessen 1:300.000"

Abb. 7 Die GÜK 300 in 10-facher Verkleinerung

44 [Wiki], Eintrag: Die Petrographie (griech. auch Lithologie oder Ge-steinskunde) ist das wissenschaftliche Fachgebiet, das sich mit der Be-schaffenheit der Gesteine beschäftigt.

45 [GAD], Bd. I, 88: Unter Fazies (lat. Facies – Gesicht) wird die ver-schiedenartige Ausbildung gleichartiger Ablagerungen verstanden, die von den physisch-geographischen und geologischen Verhältnissen des Ab-tragungs- und Ablagerungsraumes bestimmt werden.

46 [APS],217: „Eine Störung oder Verwerfung ist eine Bruchfläche, an der auf beiden Seiten eine relative Bewegung des Gesteins parallel zur Bruchfläche stattgefunden hat.


Wir haben es bei der GÜK 300 ausschließlich mit zwei Featureklassen zu tun:

1. Polygone: Petrographie, Strukturräume (regionale geologische Gliederung)

2. Linien: Faziesgrenzen, Störungen

Die Daten sind in sechs Layern organisiert:

GUEK300_ARC_HESSEN: enthält die Faziesgrenzen und die Störungen

GUEK300_POLY_HESSEN: enthält die Petrographie

STRUKTUR_POLY_1 - 4: weiträumige regionale geologische Strukturräume (STRUK-TUR_POLY_1 generalisiert die Geologie großräumig auf das Thema der geologischen Ära47; 2 – 4 untergliedern dieses Thema immer feiner, zuerst nach der geologischen Periode48, später zunehmend petrographisch).

Aus dem Datenmodell der GÜK 300, welches 34 Tabellen umfasst, sind die drei Tabel-len aus Abb. 8 relevant für die Darstellung der oben genannten geologischen Themen, weil diese Tabellen die Geometriedaten zur Darstellung der Themen beinhalten. Alle anderen Tabellen enthalten Sachdaten:

Abb. 8 Ausschnitt aus dem Datenmodell der Geowissenschaftlichen Übersichtskarte von Hes-sen 1:300.000

Für die Klassifizierung des Layers GUEK300_POLY_HESSEN wurden aus der Tabelle GUEK300_POLY die Daten aus dem Feld GEO_ID benutzt. Wie der Feldname schon vermuten lässt, handelt es sich dabei um ID-Nummern, die stellvertretend für die Al-phanumerischen Daten aus dem Feld GEO_TXT stehen. Diese wiederum stellen litho-

47 Ära: Begriff aus der relativen Einteilung geologischer Zeiträume. Un-terteilt das Äon des Phanerozoikum (Zeitalter sichtbaren Lebens)in das Paläozoikum (570 – 250 Mio A), Mesozoikum (250 – 65 Mio A) und Känozoi-kum (65 Mio A – rezent).

48 Periode: "Feinere" relative Zeiteinteilung in 12 Perioden, beginnend bei Kambrium (570 – 510 Mio A), bis zum Quartär (1,6 Mio A – rezent).


stratigraphische Kürzel aus dem sog. "Erfassungsstandard Geologie, Hessen"49 dar und werden benutzt, um Gesteinsarten zu bezeichnen.

Zur Klassifizierung der Linienthemen aus dem Layer GUEK300_ARC wurden die Wer-te aus dem Feld GEN_ID der gleichnamigen Tabelle benutzt.

Die Layer der Strukturräume STRUKTUR_POLY_1 – 4 wurden mit den Daten aus der Tabelle STRUKTURRAEUME und den Feldern EBENE1_ID bis EBENE4_ID klassifi-ziert. Die Daten aus den ID-Feldern stehen repräsentativ für die Bezeichnungen der entsprechenden Ära, Periode oder den petrographischen Überbegriff, unter dem zu-sammengefasst wurde.

Als repräsentativen Layer der GÜK 300 möchte ich den Layer GUEK300_POLY_HESSEN herausgreifen, um ein paar Eigenheiten der GÜK 300 zu verdeutlichen:

Abb. 9 Ausschnitt aus der Klassenliste der GÜK300 (Poly)

Der Layer wurde als "Unique Values" klassifiziert, also nach den Einzelwerten o.g. Fel-des. Nach der Klassifizierung besagten Layers entstehen 123 Klassen. Wie in Abb. 9 deutlich erkennbar, wurden nicht alle Klassen symbolisiert. Der Grund dafür ist: Im Feld GEO_ID (bzw. GEO_TXT) wurden sowohl petrographische Sachverhalte erfasst (die Klassen mit Symbolisierung) als auch historisch-geologische Sachverhalte wie z.B. Perioden (die Klassen ohne Symbolisierung). Damit erfüllt das Modell an dieser Stelle nicht die Anforderungen von ACID50 (d.h. es verstößt gegen die 1. Normalform relatio-naler Datenbankmodelle). Das ist in diesem Fall jedoch beabsichtigt und entstand aus einer Notwendigkeit, die einer separaten Erkärung bedarf:

49 Ein nicht veröffentlichter Standard zur Beschreibung von u.a. petro-graphischen und lithostratigraphischen Sachverhalten, angelehnt an Standards wie der DIN 4021 und 4022.

50 ACID ist die Abkürzung für die englischen Begriffe "Atomicity", "Consi-stency", "Isolation" und "Durability". Sie bezeichnen die Anforderun-gen, die an das Modell einer relationalen Datenbank gestellt werden sollten und wird durch drei sog. Normalformen repräsentiert. 1. Normal-form: Ein Relationenschema ist dann in der 1. Normalform, wenn alle At-tribute atomare Wertebereiche haben (d.h. nicht zusammengesetzt sind aus mehreren Wertebereichen). Im Beispiel GÜK300 wäre ein Wertebereich "Petrographie", ein anderer "Geologische Perioden".


Aus der Sicht der Informationstechnologie (IT) würde man beide Sachverhalte in ge-sonderten Tabellen aufführen, die durch eine Relation miteinander verbunden sind. Damit wäre die Datenbank in dieser Hinsicht normiert. Dadurch ginge jedoch der "inne-re geologische Zusammenhang" verloren, da die Bezeichnung für Gesteinsklassen in einer geologischen Karte aus einem lithostratigraphischen und einem petrographischen Bestandteil besteht. Diese Bestandteile sind eigentlich nicht trennbar, da sie in geolo-gischem Sinne nicht als zusammengesetzte Begriffe verstanden werden (es handelt sich hier um eine historisch gewachsene Nomenklatur). Ein Beispiel zur Verdeutli-chung:

Der Begriff "Buntsandstein" für sich alleine kann zweierlei bedeuten:

1. eine rein petrographische Bedeutung; die einen farbigen Sandstein bezeichnet.

2. ein stratigraphischer Begriff, der die unterste Epoche der Periode "Trias" be-schreibt, welche ungefähr den Zeitraum zwischen 240 und 250 Mio. Jahren (vor unserer Zeitrechnung) umfasst.

Beide Begriffe allein sagen geologisch nicht viel aus, denn petrographisch gesehen entstanden zur Epoche "Buntsandstein" viele unterschiedliche Gesteinsarten. Und stra-tigraphisch gesehen entstand der "bunte Sandstein" zu vielen Erdzeitaltern. Zusam-mengenommen entsteht aber ein lithostratigraphischer Begriff, der genau diesen Sandstein beschreibt, der zwischen 240 und 250 Mio. Jahren entstanden ist.

Insgesamt besitzt der Layer 76 petrographische Klassen mit Symbolisierung.

Wie in Abb. 9 zu sehen, kommen diverse Flächensymbole sowohl mit Punktfüllungen als auch Schraffuren vor. Dabei handelt es sich um Multilayer-Füllsymbole mit (in die-sem Fall) zwei Symbollayern.

In Abb. 10 wurden beispielhaft zwei Symbole aus der Klassenliste herausgegriffen, um den Aufbau der GÜK300-Symbole zu verdeutlichen (Oberes Symbol: Tonschiefer, Sandstein; unteres Symbol: Sandstein, Tonschiefer):

Abb. 10 Symbole der GÜK300 (Poly)


Bei beiden Symbolen ist zu erkennen, dass sie aus zwei übereinanderliegenden Flä-chensymbolen zusammengesetzt sind: Bei beiden ein vollflächiges Symbol unten, dar-über ein Linienfüllsymbol, bzw. ein Punktfüllsymbol.

Die Symbole sind modular aufgebaut, d.h. das Linienfüllsymbol wird durch ein separa-tes Liniensymbol definiert (äquivalent dazu das Punktfüllsymbol).

Die GÜK 300 wurde deshalb als Testprojekt für die Umsetzung von ArcGIS-Karten gewählt, weil sie mit ihren komplexen Symbolisierungen ausreichend schwierige Be-dingungen für ein Testszenario bietet. Im Verlauf der Entwicklung des Programms wurden jedoch zusätzlich noch andere Projekte getestet, die Features enthalten, die in der GÜK 300 nicht vorkommen (z.B. Punktfeatures).

4.1.2 Vorüberlegungen zur Struktur des Programms

Vor der "heißen" Phase der Programmierung sind zunächst Vorüberlegungen zu dem prinzipiellen Aufbau eines Programms zu tätigen.

Die Aufgabenstellung schreibt eine grundsätzlich zweigeteilte Struktur des Programms vor:

1. die Analyse des ArcMap-Projekts

2. die Ausgabe der gewonnenen Daten in SLD

Um die Kapselung logisch zusammenhängender Funktionen zu beachten, sollte auch die Validierung als eigenständiges Programmmodul konzipiert werden.

Des Weiteren ist eine Klasse denkbar, die nur für die XML-Aufgaben zuständig ist, da evtl. von verschiedenen Seiten des Programms auf XML-Funktionen zugegriffen wer-den muss.

Das wichtigste Modul des Programms ist die Analyseklasse. Diese Tatsache wird von der Komplexität der Symbolverwaltung von ArcGIS diktiert:

4.1.2.1 Das Analysemodul

Die Klasse, die ArcMap analysieren soll, muss in der Lage sein, mit der Anwendung zu interagieren. Das bedeutet, dass ein Zugriff auf COM-Objekte stattfinden wird, weil ArcMap auf COM-Technologie basiert. Dazu müssen sog. InteropServices eingebun-den werden.

Die Analyse der Symbole muss dort stattfinden, wo ArcMap die Klassifizierungen und die Erstellung der Symbole durchführt: bei den Renderer-Objekten. Die Rendererobjek-te sind unter dem sog. "Carto"-Objektmodell zu finden. Es existieren gemäß den Mög-lichkeiten der Klassifizierung in ArcMap 7 verschiedene Renderertypen [HÖM], 656:

1. SimpleRenderer ≈ Single symbol (Features)

2. UniqueValueRenderer ≈ Unique values (Categories)

3. ClassBreaksRenderer ≈ Graduated colors, Graduated symbols (Quantities)


4. ProportionalSymbolRenderer ≈ Proportional symbols (Quantities)

5. DotDensityRenderer ≈ Dot density (Quantities)

6. ChartRenderer ≈ Charts

7. BiUniqueValueRenderer ≈ Quantity by Category (Multiple Attributes)

Die ersten drei Renderer sind die wichtigsten und werden am häufigsten gebraucht. Alle anderen Renderer (Klassifizierungsmethoden) dürfen als "exotisch" angesehen werden und finden kartographisch selten Gebrauch.

Die Symbole sind über den benutzten Renderer erreichbar und können unter dem Ob-jektmodell "Display" gefunden werden. Es gibt insgesamt fünf Hauptsymboltypen mit unterschiedlicher Anzahl an Untersymbolen:

Knotentyp Bedeutung

Textsymbol Keine Untersymbole

MarkerSymbol SimpleMarkerSymbol, CartographicMarkerSymbol (CharacterMarkerSym-

bol, PictureMarkerSymbol), ArrowMarkerSymbol, MultilayerMarkerSymbol

LineSymbol CartographicLineSymbol (HashlineSymbol, MarkerLineSymbol), SimpleLi-

neSymbol, PictureLineSymbol, MultilayerLineSymbol.

FillSymbol SimpleFillSymbol, MarkerFillSymbol, LineFillSymbol, DotDensityFillSymbol,

PictureFillSymbol, GradientFillSymbol, MultilayerFillSymbol

3DChartSymbol BarChartSymbol, PieChartSymbol, StackedChartSymbol

Tab. 5 Hauptsymbolarten mit Untersymbolen (Quelle: [HÖM], 599 ff)

Wie vormals schon erwähnt, können Multilayersymbole eine beliebige Anzahl an Sym-bolen der gleichen Grundsymbolart beinhalten und jedes Symbol kann wiederum aus einer Anzahl anderer Grundsymbole zusammengesetzt sein (Polygone z.B. können Linien und Marker enthalten).

Das Programm muss also selbstständig und flexibel auf die Zusammensetzung der Symbole reagieren.

Jedes dieser Symbole besitzt eine Reihe an unterschiedlichen symbolspezifischen Eigenschaften und Parameter, die natürlich programmintern abgespeichert werden müssen, damit die Informationen bei der Ausgabe verfügbar sind. D.h. es muss eine Speichermöglichkeit für eine unbestimmte Zahl an unterschiedlichen Symboltypen und deren Eigenschaften zur Verfügung gestellt werden.

4.1.2.2 Das Ausgabemodul

Es soll die Ausgabe der gespeicherten Daten in SLD ermöglichen. Dazu sollte es alle Möglichkeiten, die mit SLD auf vektorbasierter Grundlage z.Zt. ausführbar sind, reali-sieren können.


Das Modul muss drei Aufgaben erfüllen:

1. Es muss die gespeicherten Daten analysieren und aufgrund der Analyse entscheiden, welcher SLD-Code (welche Klassifizierung, welche Featureklasse) aus den gespeicherten Daten zu generieren ist, um das analysierte Projekt am treffendsten widerzuspiegeln.

2. Analyseseitig wird ein Overhead an Daten gespeichert, der vielleicht einmal be-nötigt wird, in SLD im Augenblick aber nicht abgebildet werden kann, weil es z.Zt. noch nicht die Möglichkeiten zur Umsetzung bietet. Damit trotzdem eine sinnvolle Ausgabe möglich wird, muss eine Generalisierung der Daten von dem komplexen ArcMap-Symbol zu dem einfachen SLD-Symbol stattfinden.

3. Die aufbereiteten Daten müssen an ein Modul weitergegeben werden, das XML erzeugt. Dazu müssen die Daten sequenziell nach einem bestimmten Muster, das die zu erzeugende SLD widerspiegelt, zum Schreiben an das XML-Modul übergeben werden.

4.1.2.3 Die Flexibilität bei der XML-Ausgabe

Die eigenständige XML-Klasse des Programms soll folgende Aufgaben versehen kön-nen:

� Lesende Funktionen (Lesen von Konfigurations- und Steuerdateien)

� Schreibende Funktion (schreiben der SLD)

� Navigation innerhalb der SLD

Die Vorgabe nach der Möglichkeit einer flexiblen Reaktion auf Änderungen der SLD-Spezifikation lassen sich am besten in dieser Klasse verwirklichen.

Wenn mögliche Syntaxänderungen der SLD-Spezifikation ohne Sourcecodeänderun-gen bedacht werden sollen, muss dies über eine Konfigurationsdatei geschehen. D.h. SLD-Elemente, aus denen die Datei aufgebaut werden soll, müssen aus der Konfigura-tionsdatei gelesen werden. Diese Elemente können nach einer Änderung der Spezifi-kation ebenfalls angepasst werden, so dass die resultierende SLD aktuell bleibt.

Die Struktur der XML-Datei, welche die SLD repräsentiert, ist wegen der Unmittelbar-keit der Reaktion auf die gerade zu verarbeitenden Daten nur bedingt voraussehbar (insbesondere die Tiefe der Verschachtelung und hierarchische Einordnung der jewei-ligen Elemente und Attribute). Deshalb ist beim Schreiben der SLD eine Navigation vonnöten, die "weiß", wo ein bestimmtes Element, das gerade geschrieben werden soll, stehen darf, damit es innerhalb der SLD eine gültige Position einnimmt.

4.1.2.4 Die Validierung

Es sollte möglich sein, aktuelle XML-Schemadateien einzubinden, anhand derer die Gültigkeit der erzeugten SLD geprüft werden kann. Vorstellbar wäre hier eine Funktion ähnlich der, wie man sie von einigen XML-Editoren kennt:

Die Validierungsdateien werden geladen (entweder von einem lokalen Laufwerk oder


einer www-URL) und die programminterne Funktionalität prüft das entstandene SLD-Dokument gegen die Schemadatei von OGC (das Programm müsste hier nur Schema-dateien verwenden können, da OGC zur Validierung von SLD nur Schemadateien und keine DTD ausgibt).

Wünschenswert wären im Falle einer negativ beschiedenen Gültigkeitsprüfung ge-nauere Angaben über Art und Ort der SLD-Elemente, die den Verstoß verursacht ha-ben.

4.2 Erforderliche Ressourcen

Zur Ausführung der Arbeit waren bestimmte Programmplattformen und weitere Res-sourcen notwendig:

Entwicklungsumgebung:

� Visual Studio.Net 2003, Version 7.1.3

� Microsoft .NET Framework 1.1

� MSDN Library 2003

� Altova XMLSpy Home Edition Version 2005, rel. 3

GIS-Umgebung:

� ArcGIS 9.0 (ArcView 9.0) – ArcMap

� ArcGIS 9 Developer Help

� ArcSDE 8.3

4.3 Anforderungen an die SLD-Tests

Mit den SLD-Tests sollen die Umsetzungsmöglichkeiten der Karteneigenschaften der GÜK 300 in SLD überprüft werden. Damit sollen im Wesentlichen vier Fragen beant-wortet werden:

1. Welche Einstellungen müssen vorgenommen werden, damit die Testserver die SLD im Rahmen ihrer Möglichkeiten korrekt darstellen?

2. Wie gut unterstützen die eingesetzten Testserver z. Zt. SLD?

3. Welche Möglichkeiten der Darstellung von Karten gibt es grundsätzlich mit der gegenwärtigen Spezifikation? Das Hauptaugenmerk richtet sich dabei v.a. auf:

• Symbolizer (Point-, Line-, PolygonSymbolizer)

• Komplexe Flächenfüllungen wie Schraffuren und Punktfüllungen


• Klassifizierungen mit Filter und logischen Operatoren

4. Welche Möglichkeiten der Erweiterung des Programms (zum Beispiel Flächenfül-lungen mit Bitmaps) bieten sich an?

Die Tests werden zuerst als "Trockenübungen" durchgeführt mit händisch erstellten SLD. Nachdem die Konfiguration der Testserver erfolgreich abgeschlossen und die Darstellung der SLD auf den Mapservern gelungen ist, werden die gewonnenen Kennt-nisse umgesetzt und der Aufbau der entsprechenden Teil-SLD im Programm implementiert. Anschließend werden die vom Programm erzeugten SLD mit der glei-chen Konfiguration auf den Testservern geprüft.

4.4 Das Testbed für die SLD-Tests

Bei den SLD-Funktionstests wurden zwei Testserver verwendet:

1. ArcIMS von ESRI

2. UMN-Mapserver

Warum gerade diese beiden Server?

Der ArcIMS läuft am HLUG als Standard-Kartenserver. D.h. die Software und Periphe-rie des Servers war hier schon vorhanden und wird standardmäßig für Kartendienste am HLUG verwendet. Es ist von Interesse zu wissen, ob der ArcIMS auch als OGC-Map-Server dienen kann und wie weit er die SLD Spezifikation unterstützt.

Darüber hinaus sollten die Tests als Referenz auf einem Open Source-Server durchge-führt werden, u.a. als Entscheidungshilfe für einen möglichen Einsatz am HLUG. Ich habe mich hier aus mehreren Gründen für den UMN-Mapserver entschieden:

� Gute OGC-Kompatibilität

� Zuverlässigkeit

� Der UMN-Mapserver ist der am weitesten verbreitete nichtkommerziell vertriebe-ne Map-Server (wie ArcIMS auf dem kommerziellen Sektor)

� Vergleichsweise einfache Konfiguration

� Ausreichend für den vorgegebenen Zweck

Nachfolgend sollen die Konfigurationen der jeweiligen Server als Voraussetzung für die Tests dokumentiert werden.

4.4.1 Konfiguration des UMN-Mapserver

Für die Tests wurde der UMN-Mapserver in der Ausführung MS4W der Mapping Community "MapTools.org" benutzt. MS4W ist ein Installationspaket, das bereits alle notwendigen Komponenten versionskompatibel in kompilierter Form vorhält. Das Paket muss lediglich auf "C:\" entpackt werden (bzw. mit etwas mehr Konfigurationsaufwand


kann das Paket auch an einem beliebigen anderen Ort entpackt werden). An der Lauf-werksbezeichnung ist zu erkennen, dass als Serverplattform eine Windows-Umgebung gewählt wurde (genauer: Windows XP, SP2), obwohl prinzipiell auch UNIX- oder Linux-Plattformen in Frage kommen. Nachfolgend sind die Komponenten des MS4W aufgeli-stet:

� Apache version 2.0.54 (Webserver)

� PHP version 4.3.11 (PHP- Bibliotheken)

� MapServer CGI 4.4.2, 4.6.0 beta2 (CGI- Anwendung des Kartenserver)

� PHPMapScript 4.4.2, 4.6.0 beta2 (Kartenserver-Skript)

� GDAL/OGR utilities (gdal_contour.exe, gdal_translate.exe, gdaladdo.exe, gda-linfo.exe, gdaltindex.exe, gdalwarp.exe, ogrinfo.exe, ogr2ogr.exe, ogrtin-dex.exe)

� Mapserver utilities (legend.exe, scalebar.exe, shp2img.exe, shp2tile.exe, shptree.exe, shptreevis.exe, sortshp.exe, tile4ms.exe)

� OGR/PHP Extension 1.0.0 (C++ Bibliothek, die lesenden u. schreibenden Zugriff auf ESRI Shapefiles, ArcSDE, S-57, SDTS, PostGIS, Oracle Spatial, and Ma-pinfo mid/mif und TAB Formate bietet)

� OWTChart 1.2.0

Der Server-IP-Adresse lautet: 127.0.0.1 (localhost).

Mit dem MS-DOS Kommandozeilenparameter "mapserv –v" enthüllt der Mapserver seine CGI-Parameter sowie seine Input/Output-Fähigkeiten:

Abb. 11 Fähigkeiten des UMN-Mapserver

Wie in Abb. 11 zu erkennen ist, akzeptiert der Mapserver als Input sowohl Shapefiles als auch über die OGR-Bibliothek (Simple Features) die Anbindung einer ArcSDE-Datenbank.

Für die Tests auf dem UMN-Mapserver wurde die GÜK 300 in mehrere Shapefiles ex-portiert.

Für die Konfiguration des Kartendienstes wurde eine map-Datei aufgesetzt. Sie konnte äußerst einfach gehalten werden, da sie von der Darstellungsvorschrift (hier SLD) ab-gekoppelt wurde (die map-Datei, auf die ich mich im Folgenden beziehe, wurde im An-


hang angefügt). Sie ist statisch, d.h. sie muss (im Gegensatz zu der automatisch gene-rierten SLD) händisch erzeugt werden und ist z.Zt. noch Pflicht für die Erstellung eines Kartendienstes (da das Element UserLayer in SLD vom UMN-Mapserver derzeit noch nicht unterstützt wird).

Innerhalb des MAP-Objekts müssen bestimmte Grundkonfigurationsparameter gesetzt werden. So muss z.B. für SHAPEPATH der Ort der Shapedatei angegeben werden. Unbedingt vorhanden sein muss auch das METADATA-Objekt, das die Rückgabewerte eines GetCapabilities-Aufrufs beinhaltet. NAME, SIZE, IMAGETYPE, PROJECTION usw. sind Parameter, die auch in der Aufruf-URL gesetzt werden können.

Von allen Layern, die in dem Kartendienst verfügbar sein sollen, muss ein LAYER- Objekt angelegt werden. In diesem Objekt sind Layername (NAME), Ort der Daten (DATA) und ebenfalls ein METADATA- Objekt anzulegen.

Nachfolgend ein Ausschnitt aus der Verzeichnisstruktur des Mapservers zur Verdeutli-chung der Konfiguration:

Abb. 12 Verzeichnisstruktur des UMN-Mapserver

Die Shapedatei "Guek300_Poly.shp" liegt im Verzeichnis "C:\ms4w\Apache\htdocs\Maps\Shape".

Die SLD " GUEK300.sld " befindet sich unter "C:\ms4w\Apache\htdocs\Maps\SLD".

Zu beachten ist die Hierarchie aller für den Mapserver zugänglichen Verzeichnisse als Unterordner des Webverzeichnisses "htdocs", denn htdocs ist das freigegebene und dem Map-Server bekanntgemachte Verzeichnis, auf das er somit zugreifen kann. Folg-


lich kann der UMN-Mapserver auch auf alle Unterverzeichnisse von htdocs verwenden.

Für vorgenannte Einstellungen (mit SLD) erzeugt die folgende URL eine gültige Get-Map- Anfrage:

http://127.0.0.1/cgi-bin/mapserv.exe?map=C:/ms4w/Apache/htdocs/Maps/GUEK300.map&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&Layers=Guek300_Poly&STYLES=&SLD=http://127.0.0.1/Maps/SLD/GUEK300.sld&BBOX=3377854,5471076,3592188,5728258

4.4.2 Konfiguration des ArcIMS am HLUG

Der ArcIMS ist am HLUG eingebunden in eine Multiserver-Architektur auf Basis eines LAN mit Sterntopologie (s. Abb. 11):

ZentralerSwitch-Router

GIS-ServerSUN E450, Solaris 7

BK-ServerSUN E250, Solaris 7

Clients in Gebäude 1 und 2



DB-ServerSUN E450, Solaris 2.6

Oracle 8

SpezialisierteServerSpezialisierte

ServerSpezialisierteServerSpezialisierte

Server

Abb. 13 LAN-Aufbau am HLUG (Quelle: HLUG)

Auf dem GIS-Server sind die GIS-Daten des HLUG abgelegt. Außerdem laufen darauf GIS-Dienste wie der ArcIMS mit den peripheren Komponenten, die für seinen Betrieb erforderlich sind. In der Abb. 14 sind die von ESRI vorgegebenen Standardkomponen-ten des ArcIMS schematisch dargestellt:


Abb. 14 Notwendige ArcIMS Zusatzkomponenten (Quelle: ESRI.com)

Wie in der Abbildung zu erkennen, benötigt der ArcIMS für seinen Betrieb als proprietä-rer nicht-OGC-konformer Mapserver eine Java-Laufzeitumgebung (da ArcIMS zum größten Teil aus Java-Komponenten besteht), einen Webserver (dessen Funktion in Kap. 3.3.1 besprochen wurde) und eine Servlet-Engine. Die Servlet-Engine wird benö-tigt, um eine Verbindung zwischen der Java-Laufzeitumgebung und dem Webserver herzustellen.

In Tab. 6 sind alle für den Betrieb notwendigen Applikationen im Detail aufgelistet:

Applikation/Patch Produkt

Betriebssystem Solaris 9

ESRI-Licence-Manager ArcSDE-Lizenz

Map-Server ArcIMS 4.0.1

Geodatenbank-Middleware ArcSDE 8.3

Webserver Apache 1.3.27

Servlet-Engine Tomcat 4.0.6

WMS Connector WMS Connector 1.0 for ArcIMS 4.0.1

Scriptsprachen Perl 5.6.1

php – 4.3.2.tar.bz2

Entwicklungssoftware

gcc-2.95.3-pkg.zip

gmake-3.79.1-pkg.zip

gcc-3.2.1 (64bit-fähig)

Java SDK 2

Graphikbibliotheken

freetype-2.1.2-sol9-sparc-local.gz

jpeg-6b-sol9-sparc-local.gz

libpng-1.2.4-sol9-sparc-local.gz

Tiff-3.5.7-sol9-sparc-local.gz

zlib-1.1.4-sol9-sparc-local.gz

Datei- u. Druckdienste Samba

Software für gesicherten https-Zugang Openssl-0.9.6g-sol9-sparc-local.gz

Hilfssoftware vnc-3.3.3.2-pkg.zip (grafische Benutzeroberfläche)

cpustate-2.5-pkg.zip (Auslastungsüberwachung)

Tab. 6 Eingesetzte Software der ArcIMS-Maschine (Quelle: HLUG)


Die Tabelle beinhaltet eine Komponente, die in der Abb. 14 nicht aufgeführt ist: Den WMS-Connector. Der WMS-Connector ist ebenfalls eine Java Servlet-Anwendung und wird benutzt, um die Interoperabilität von unterschiedlichen Kartendiensten mit dem ArcIMS auf Grundlage von OGC-Standards zu gewährleisten. D.h. erst mit diesem Servlet werden die OGC WMS-Requests GetMap, GetCapabilities und GetFeatureInfo für den ArcIMS ermöglicht.

Der proprietäre ArcIMS-Kartendienst für die GÜK 300 wurde mit dem ArcXML- Doku-ment "GUEK300.axl" definiert:

Abb. 15 Ausschnitt aus der GUEK300.axl (Quelle: HLUG)

In diesem Dokument sind alle für den ArcIMS-Kartendienst notwendigen Parameter zur Datenreferenzierung, Klassifizierung und Darstellung der Daten im ArcXML-Format aufgeführt.

Diese proprietäre Konfigurationsdatei ist jedoch ebenfalls (wie die Map-Datei des UMN-Mapservers) ein statisches Dokument, d.h. es wird händisch erstellt und im Falle von Änderungen ebenfalls manuell modifiziert. Im Gegensatz dazu ist die SLD dyna-misch erzeugbar. Bei Änderungen der Kartensymbolisierungen wird lediglich aus dem ArcMap-Projekt eine neue SLD erzeugt, ohne händisch Veränderungen an der Konfi-guration vornehmen zu müssen.

Der SLD-unterstützte OGC-WMS benötigt die AXL-Datei des ArcIMS derzeit lediglich, um auf die Layerdefinitionen des Kartendienstes zuzugreifen (da ArcIMS, wie UMN-Mapserver auch, nicht das SLD-Element UserLayer unterstützt), ist aber ansonsten unabhängig von den Definitionen der AXL-Datei.

Der Zugriff auf die Daten für den Kartendienst "GUEK300" läuft über eine ArcSDE-Verbindung. Darin gibt es ein Feature-Dataset mit den unter 4.1.1 genannten sechs


Featureklassen: "GEOLOGIE.GUEK300_ARC", "GEOLOGIE.GUEK300_POLY", GEOLOGIE.GUEK300_STRUKTUR_POLY1-4.

Shapedateien wurden für die Tests auf dem ArcIMS-Server nicht benutzt (für den UMN-Mapserver wurden nur deshalb Shapedateien für die Tests verwendet, weil der UMN-Mapserver als lokaler Server nicht auf die ArcSDE-Daten im Netzwerk zugreifen kann und die Portierung der ArcSDE-Daten auf ein lokales Laufwerk für diesen Zweck zu aufwendig ist).

Die SLD zur Darstellung der GÜK300 mit dem OGC-WMS des ArcIMS befindet sich auf der Plattform "mapserver" unter dem Verzeichnis "H:\httpd\arcims\website\wms_sld\*.sld"

Damit erzeugt der folgende Aufruf auf dem ArcIMS eine SLD-generierte Karte der GUEK300:

http://mapserver:8080/wmsconnector/com.esri.wsit.WMSServlet/guek300?request=getmap&srs=EPSG:31467&bbox=3447309,5542994,3450522,5545762&layers=GEOLOGIE.GUEK300_POLY&styles=Style1&SLD=http://gismo/website/wms_sld/SLD_valid2.sld&format=png&width=250&height=400

5 Ergebnisse der Arbeit -54-

5 Ergebnisse der Arbeit

5.1 Das Programm "ArcGIS-map to SLD Converter"

Wie zuvor erwähnt dient dieses Programm zum Erstellen von Darstellungsanweisun-gen (in diesem Fall SLD von OGC) aus Informationen, die durch eine Analyse eines vorliegenden ArcGIS-Projektes gewonnen wurden. Die Voraussetzung für die Nutzung der Applikation ist deshalb ein installiertes ArcGIS und eine laufende ArcMap-Session mit einem geöffneten Projekt (wie die Verbindung zu ArcMap stattfindet, wird in Kap. 5.1.1 genauer beschrieben).

Abb. 16 Das Programm "ArcGIS-map to SLD Converter"

Das Programm ArcGIS-map to SLD Converter erscheint auf den ersten Blick sparta-nisch: ein Formular mit wenigen Bedienelementen und ohne Menü. Aber auch hier muss man eher die "inneren Werte" betrachten und die Äußerlichkeiten ignorieren. Die Applikation ist darauf ausgelegt, die anfallende Aufgabe automatisch und ohne viele Benutzerinteraktionen zu erfüllen. Dabei ist zu beachten: je höher der Grad der Auto-matisierung, desto geringer der Aufwand der Interaktion mit dem Benutzer und desto höher der Aufwand an erforderlichem Programmcode.

Das Programm besteht aus acht Klassen (plus Klasse "AssemblyInfo", die von der Vi-sual Studio-IDE erzeugt wird) mit nahezu insgesamt 7000 Zeilen Code. Dabei gibt es fünf Hauptklassen und drei Hilfsklassen (die ebenfalls in Kap. 5.1.1 näher beschrieben werden).


Zur Steuerung des Programms werden zwei XML-Dateien benutzt:

1. Preconfigure_Converter.xml: Die Datei beinhaltet benutzerdefinierte Einstellungen wie Maßstabszahlen, Dateispeicherort und Markierungs-zustände von Checkboxen, mit denen das Hauptformular konfiguriert wird.

2. LUT_sld_mapping_file.xml: Diese Datei enthält Informationen über SLD-Syntax und -Semantik.

5.1.1 Struktureller Aufbau des Programms

Im Folgenden werde ich den prinzipiellen Programmablauf erläutern, wobei ich mich auf die schematische Darstellung aus Abb. 17 beziehe.

Abb. 17 Schema Programmstruktur der Applikation "ArcGIS-map to SLD Converter"


Im Verlauf des Kapitels werden die Hauptklassen (in Abb. 17 in dunkelblauer Farbe) näher betrachtet werden. Die Hilfsklassen (hier in hellblau) sind für den Ablauf des Programms nicht unmittelbar entscheidend, weshalb hier von einer eingehenderen Erläuterung in Unterkapiteln abgesehen wird. Konfigurationsdateien erscheinen in Abb. 17 hellgrün und Ausgabedateien dunkelgrün (zur Verdeutlichung ist im Anhang ein vereinfachter Workflow abgebildet).

Programmkonventionen:

Die Klassen wurden intern in sog. "Regions" eingeteilt, die zum einen eine logische Gruppierung des Quellcodes nach Funktionen ermöglicht, zum anderen aber auch ei-nen eigenständig adressierbaren Klassenabschnitt bedeuten.

Auf Klassenebene gültige Variablen (Membervariablen) werden der eindeutigen Zu-ordnung wegen mit einem vorangestellten "m_" versehen. Auf Methoden- und Funkti-onsebene gültige Variablen besitzen kein Gruppenpräfix. Alle Variablen bekommen hingegen ein ihrem Datentyp entsprechendes Typenpräfix. Objekttypen werden hier (bis auf zwei Ausnahmen) nicht weiter unterschieden, Primitivdatentypen schon. Von dieser Konvention wurde nur innerhalb der Datenstrukturdeklarationen abgewichen, da hier die Notwendigkeit nach "sprechenden" Variablennamen überwiegt.

Primitives:

Integer: i

Double: d

String: c

Boolean: b

Objects:

ArrayList: al

Struct: str

Object: obj

Bsp.:

Datentyp Variablenname Klassenebene Methodenebene

Flag (Boolean) Switch m_bSwitch bSwitch

Object (z.B. IMxDocument) MXDoc m_objMXDoc objMXDoc

Tab. 7 Beispiel Variablennamenskonvention

Zur Unterstützung des Verständnisses für die Inhalte und Vorgänge innerhalb der Klassen wurden in den folgenden Unterkapiteln sog. UML-Diagramme51 verwendet.

51 [KKI], Eintrag: UML= Visuelle Sprache für die Spezifikation, Konstruk-tion und Dokumentation von Systemen. Die UML definiert eine Semantik bestehend aus Modellierungselementen, Beziehungen, Diagrammtypen und Erweiterbarkeitsmechanismen. Mit der UML als einem programmiersprache-nunabhängigen, offenen Standard können Modelle und Artefakte standardi-


Um die Inhalte der Klassen bzgl. Membervariablen, Methoden, Properties und Events widerzuspiegeln, werden sog. UML-Klassendiagramme verwendet, die im Anhang zu finden sind. Um den Ablauf der Programmsequenz innerhalb der Anwendung zu ver-deutlichen, wurde ein sog. UML-Sequenzdiagramm benutzt:

Abb. 18 Sequenzdiagramm der Applikation "ArcGIS-map to SLD Converter"

Abriss des Programmablaufs:

Beim Ausführen des Programms "ArcGIS-map to SLD Converter" wird zuerst die in Abb. 16 dargestellte Programmoberfläche Motherform aufgerufen. Beim Aufbau der Oberfläche wird die Klasse CommonXMLHandle initialisiert, welche die Konfigurations-daten für Steuerelemente des Motherform aus der XML- Datei Preconfigu-re_Converter.xml ausliest. Die Datei muss im Anwendungsverzeichnis stehen. Die Klasse CommonXMLHandle kapselt allgemeine und einfache XML Lese- und Schreib-funktionen auf Grundlage des DOM.

Wenn alle Einstellungen auf dem Hauptformular getätigt wurden, wird das Schaltele-ment "SLD" betätigt, womit der Analyse- und Ausgabeprozess in Gang gesetzt wird.

Als Folge davon wird die Klasse Analize_ArcMap_Symbols initialisiert, welche die ge-

siert dargestellt werden. Die UML wurde von der Object Management Group standardisiert.


öffnete ArcMap-Karte analysiert. In ArcMap durchläuft der Algorithmus den Featureda-taset layerweise. Für jeden Layer werden die darin enthaltenen Symboltypen in Daten-strukturen in Analize_ArcMap_Symbols abgelegt (für jeden Symboltyp ist eine eigene Symbolstruktur definiert). Bei abgeschlossener Analyse wird die Klasse OutputSLD initialisiert.

OutputSLD durchläuft die ineinander geschachtelten Datenstrukturen in mehreren Schleifen und analysiert ihren Inhalt. Folgende drei Arten von Datenstrukturen sind (in der Klasse Analize_ArcMap_Symbols) definiert:

1. Projektdatenstruktur

2. Rendererdatenstrukturen

3. Symboldatenstrukturen

Die Projektdatenstruktur enthält Daten auf Projektebene und alle im Projekt enthalte-nen Rendererstrukturen (n mögliche Rendererstrukturen). Die Rendererstrukturen ent-halten Daten auf Layerebene und die Symbolstrukturen alle in diesem Layer vorkom-menden Symbole (n mögliche Symbolstrukturen). Die Symbolstrukturen enthalten die Symboleigenschaften und können außerdem weitere Symbolstrukturen aufnehmen (Wenn z.B. ein Polygonsymbol eine Umrandung besitzt, enthält seine Datenstruktur eine weitere Linien-Datenstruktur, welche die Umrandung repräsentiert).

Gleich nach der Initialisierung von OutputSLD wird ein Objekt der Klasse XMLHandle erstellt. Je nach Inhalt der Strukturen wird eine bestimmte SLD-erzeugende Funktion aufgerufen, die den SLD-Rohcode an die Klasse XMLHandle weitergibt. Diese erstellt eine virtuelle SLD-Datei mithilfe von Steuerinformationen, die sie aus der Datei LUT_sld_mapping_file.xml ausliest, welche ebenfalls im Anwendungsverzeichnis ste-hen muss. Wenn OutputSLD die vorhandenen Datenstrukturen erfolgreich durchlaufen hat, gibt es XMLHandle das Signal zum Schreiben der SLD- Datei. Nach Beendigung des Schreibvorgangs initialisiert OutputSLD die Klasse ValidateSLD, welche die er-zeugte SLD anhand einer eingelesenen Schemadatei auf Gültigkeit überprüft. Wenn die SLD-Datei laut den eingelesenen Schemadateien gültig ist, endet der Programmab-lauf an dieser Stelle. Ist sie nicht gültig, wird ein Formular initialisiert, das die Fehler-meldungen der Überprüfungen protokolliert und diese auf Wunsch in eine Textdatei abspeichert.

Die nachfolgenden Unterkapitel beziehen sich teilweise auf Ausschnitte des Pro-grammquellcodes, der im Folgenden als bekannt vorausgesetzt wird (der Quellcode konnte nicht dem Anhang beigefügt werden, da er zu umfangreich für die schriftliche Ausarbeitung ist - er kann auf der Begleit-CD eingesehen werden).

5.1.1.1 Die Haupt-Benutzeroberfläche "Motherform"

Die Motherform ist lediglich der Initiator für den restlichen Programmablauf und bein-haltet darum wenig dem ursprünglichen Programmzweck dienende Programmlogik. Mit relativ wenig Anpassungsaufwand in den nachfolgenden Klassen könnte das aufrufen-de Modul ebenfalls z.B. durch ein kommandozeilenorientiertes Modul ersetzt werden.

Die Klasse enthält darum weitestgehend die Steuerelementdefinitionen, einige Proper-


ties zum Setzen der Steuerelementattribute, Events zur Reaktion auf die Steuerele-mentbedienung sowie einige Routinen für die benutzerdefinierten Einstellungen und Benutzerinformationen.

Das oberste Element ruft einen Datei-speichern-Dialog auf, der den Speicherort der SLD festlegt. Erfolgt dies nicht vor Auslösen der SLD-Schaltfläche, wird vor der Verar-beitung der SLD eine Sicherheitsabfrage nach dem Speicherort ausgelöst. Der Datei-speichern-Dialog zeigt immer den Speicherort der zuletzt erzeugten SLD als Vorein-stellung an. Differiert der momentan gewählte Speicherort zu dem aus der Konfigurati-onsdatei Preconfigure_Converter.xml, so wird der neue Speicherort in die Konfigurati-onsdatei übernommen.

Die Optionsschalter zu den Serverdatenspeichern haben folgenden Hintergrund:

Wenn die Datenquelle, aus welcher der Mapserver die Karte generiert, ein Shapefile ist, besteht der Layername, den man in der Ziel-SLD generieren muss, lediglich aus dem aus ArcMap extrahierten Layernamen. Handelt es sich bei der Datenquelle um eine SDE-Datenbank, so setzt sich der SLD-Layername zusammen aus dem Daten-bankschema-Namen, einem Punkt als Separator und dem nachgestellten Layernamen. Also "Datenbankschema.Layername". Dem Namen des Datenbankschemas entspricht in ArcMap der Dataset-Name. Wird also "ArcSDE" im Optionsfeld "Serverdaten" akti-viert, wird als Layername für die Ziel-SLD der "DatasetName.Layername" gespeichert. Analog dazu wird die PropertyName in SLD ebenfalls mit "DatasetName.Feldname" abgespeichert, wenn eine Datenbank als Datenspeicher benutz wird (und vorgenannte Option entsprechend aktiviert wurde).

Das Optionsfeld "Darstellungsbereich" legt die Ober- und Untergrenze des Darstel-lungsbereiches der SLD fest. In der SLD wird dies mit den Min- und MaxScaleDenomi-nator umgesetzt, die Kindelemente des Elements Rule sind. Die Elemente der Combo-box-Liste werden aus der Konfigurationsdatei eingelesen. Das Editieren der Konfigura-tionsdatei ist auch in diesem Fall einfach, da neue benutzerdefinierte Maßstäbe nur in die Combobox eingegeben werden müssen, und damit in die Konfigurationsdatei auf-genommen werden. Sie sind beim nächsten Aufruf des Programms wieder verfügbar. Eine Verwechslung der Termini "Großer Maßstab" und "Kleiner Maßstab" ist nicht möglich, da die Auswahl intern überprüft und ggf. ausgetauscht wird.

Mit Aktivieren der Checkbox SLD-Validierung wird ein Datei-öffnen-Menü aufgeklappt, in dem die Schemadatei zum Validieren ausgesucht werden kann. Die Schemadatei sollte möglichst vorher schon in einem XML-Editor wie z.B. XML Spy getestet werden (wenn sie lokal abgelegt wurde, müssen Pfade z.B. der assoziierten Schemadateien angepasst werden).

Das Infofeld informiert den Benutzer über die gerade ablaufende Aktion des Pro-gramms. Das ist sinnvoll, da die komplette Analyse mehrere Minuten dauert und der Anwender dadurch den Fortgang der Operationen verfolgen kann. Zu diesem Zweck wurde zusätzlich ein animiertes GIF in die Anwendung platziert.


5.1.1.2 Das Analysemodul "Analize_ArcMap_Symbols"

Das Analysemodul Analize_ArcMap_Symbols stellt eine der zwei zentralen Klassen der Anwendung dar. Sie kann im Wesentlichen in drei Teile gegliedert werden. Sie kann:

1. einen Verweis auf die laufende ArcMap-Instanz und das darin enthaltene Karten-objekt abfragen,

2. die Kartendaten analysieren,

3. die analysierten Daten speichern.

In der Abbildung 19 wird die Funktionalität der Klasse Analize_ArcMap_Symbols in einer Kombination aus UML-Sequenzdiagramm (Objektaufrufe) und Nassi-Shneiderman-Diagrammen52 (für die sequentiellen Programmabläufe) dargestellt. We-gen der Komplexität der Funktion müssen Diagramme stark vereinfacht werden und geben nur das Gerüst der Klasse wieder.

Die sechs Diagramme stellen einen Ablauf dar und müssen von links oben nach rechts unten gelesen werden. Bei dem Ablauf wird nur ein bestimmter Zweig verfolgt, bei dem angenommen wird, dass das zugrundeliegende Symbol ein SimpleFillSymbol ist, das eine Umrandung besitzt:

52 [Wiki], Eintrag: Ein Nassi-Shneiderman-Diagramm ist eine Entwurfsmetho-de für die strukturierte Programmierung (Struktogramm). Es ist genormt nach DIN 66261.


StoreStructUVRenderer(1 Renderer)

n Symbole

Sp

eich

ert

alle

Sym

bol

Str

ucts

In R

end

erer

Str

uct

FillSymbolLineSymbol

MarkerSymbol

Untersymbolverzweigen

AnalyseLayerSymbology(n Renderer)

n Renderer

Sp

eich

ert

alle

Ren

der

erS

truc

tsIn

Pro

ject

Str

uct

UniqueValueRenderer

ClassBreaksRenderer

SimpleRenderer

Sto

reS

truc

tUV

Ren

dere

r(1R

ende

rer)

… …

… … …

SimpleFillSymbol

MarkerFillSymbol

LineFillSymbol

MultilayerFillSymbol

… … … … …

New

Str

uctS

impl

eFill

Sym

bol =

Sto

reS

impl

eFill

(Sim

pleF

illS

ymbo

l)

StoreSimpleFill(SimpleFillSymbol)

New StructSimpleFillSymbol

StructSimpleFillSymbol.Color=SimpleFillSymbol.Color

SimpleLineSymbolMarkerLineSymbol

MultiLineSymbol

… … … … …

New

Str

uctS

impl

eLin

eSym

bol =

S

tore

Sim

pleL

ine(

Sim

pleL

ineS

ymbo

l)

Return StructSimpleFillSymbol

StoreSimpleLine(SimpleLineSymbol)

…

StructSimpleLineSymbol.Color=SimpleLineSymbol.Color

New StructSimpleLineSymbol

Return StructSimpleLineSymbol

Abb. 19 Sequenzdiagramm und Struktogramme der Klasse Analize_ArcMap_Symbols


I. Die Verweise:

Normalerweise werden Anwendungen, die auf ArcMap zugreifen als VBA-Applikationen innerhalb ArcMap entwickelt. Weil bei dieser Methode die Anwendung als Abkömmling der ArcMap-Instanz fungiert, muss der Entwickler weder Verweise auf diese Instanz setzen noch Umgebungsvariablen initialisieren oder Namensräume im-portieren. Die Verweise sind alle schon innerhalb der laufenden Instanz gesetzt.

Die Methode hat jedoch auch Nachteile: Man ist auf VBA festgelegt, das als Program-miersprache nur begrenzte Möglichkeiten bietet. Außerdem ist die Anwendung dann als projektabhängige Applikation in ArcGIS-Projekte eingebettet. Um das zu umgehen, habe ich die Applikation als eigenständig laufende, unabhängige Anwendung mit Visu-al Basic.NET entwickelt.

Das hingegen bringt die Notwendigkeit mit sich, einen "Haken" zu erschaffen, um sich in eine laufende ArcMap-Instanz "einzuhängen". Hat man diesen Verweis, kann Arc-Map über seine Objektbibliothek angesprochen und die volle ArcObjects-Funktionalität benutzt werden. Dazu laufen folgende Prozesse ab:

Den Einstieg in die Klasse Analize_ArcMap_Symbols bietet die Funktion CentralPro-zessingFunction. Sie wird direkt aus dem Konstruktor aufgerufen und verteilt die not-wendigen Schritte auf die ausführenden Funktionen:

Zuerst wird die Funktion GetProcesses aufgerufen, die alle laufenden Prozesse auf dem Rechner durchsucht. Wird ein Prozess gefunden, der ArcMap heißt, kann die An-wendung fortgeführt werden. Falls nicht, muss der Anwender ArcMap starten (Sicher-heitsabfrage). Sind mehrere ArcMap-Projekte geöffnet, wird der Benutzer aufgefordert, alle Projekte bis auf das zu analysierende zu schließen und die Anwendung neu zu starten.

Danach wird die Funktion GetApplication ausgeführt, die mit dem Application-Root-Objekt IAppROT den Verweis auf die ArcMap-Session holt. Damit wird ein Application- Objekt MXApplication initialisiert, durch das man über IMXDocument an das aktive Dokument kommt, das die Karte beherbergt. Auch hier gibt es eine Kontrolle, ob meh-rere Kartenfenster geöffnet wurden. Wenn ja, erscheint auch hier eine Sicherheitsab-frage.

II. Die Analyse:

Obwohl in der Gliederung so aufgeführt, konnten die Punkte Analyse und Ablage in Datenstrukturen nicht streng voneinander getrennt werden. So müssen Daten auf Lay-erebene natürlich schon vor der Zerlegung der Symbole abgelegt werden, weil sie im Programmablauf vor den Symboleigenschaften abgearbeitet werden.

Analyse von Kartendaten bedeutet im Kontext von ArcMap in erster Linie die Zerlegung von komplexen Symbolen in ihre Untersymbole. Das beginnt im Grunde schon bei der Zerlegung der Rendererobjekte, die, wie in Kap. 4.1.2.1 erwähnt, die Symbole eines Layers beinhalten.

Diesen Vorgang kann man sich am besten als das "Sieben" von lockerem Schüttgut


vorstellen, wobei die Siebe nach und nach immer feinmaschiger werden und das Schüttgut (von grob nach fein) das Projekt selbst, die Renderer als Repräsentanten der Layer, die Grundsymbole und deren Untersymbole darstellen.

Dieser Siebvorgang beginnt mit der Funktion AnalyseLayerSymbology, die als näch-stes von CentralProcessingFunction aufgerufen wird. Hier findet eine Mehrfachver-zweigung nach den verschiedenen möglichen Renderertypen statt. Jede Verzweigung ruft eine spezielle Funktion auf, die genau auf die Analyse dieses Renderertyps zuge-schnitten ist. Diese Funktionen heißen StoreStructSimpleRenderer, StoreStructU-VRenderer und StoreStructCBRenderer. Wie der Funktionsname schon verrät, dienen die Funktionen nicht ausschließlich der Analyse. An dieser Stelle vermischt sich die Funktionalität der Methoden, da hier teilweise Informationen, die in ArcMap auf Laye-rebene vorliegen (wie z.B. die klassifizierenden Tabellenfelder) unter jedem einzelnen Symbolstruct abgespeichert werden, damit sie auch auf Symbolebene unmittelbar ver-fügbar sind.

Die komplexeste dieser Funktionen ist StoreStructUVRenderer (UV steht hier für Uni-queValue). Zu Beginn der Funktion werden Informationen über die Klassifizierung des Layers gesammelt, während im anschließenden Teil die Fallunterscheidungen der Symbole vorgenommen werden.

Nachfolgend der Quellcode, auf den ich mich beziehen werde:

.Abb. 20 Beispielhafter Codeblock aus Funktion StoreStructUVRenderer

Die "If TypeOf…."- Abfrage teilt die Funktion grob auf nach den Grundsymboltypen IFillSymbol, IMarkerSymbol, ILineSymbol etc.

Im Folgenden wird das Symbol weiter aufgegliedert in seine Untersymbolarten (in dem Beispiel für FillSymbol sind das: SimpleFillSymbol, MarkerFillSymbol, LineFillSymbol …) durch eine "Select – Case"- Verzweigung. Dazu wird das aktuelle Symbolobjekt an eine Funktion namens FillSymbolScan übergeben (die es auch für jede andere Grund-symbolart gibt), die das Symbol auf seine Art hin untersucht und deren Rückgabewert ein String ist, der die Art des aktuellen Untersymbols repräsentiert. Auf dieses Argu-ment wird in der "Select – Case"- Verzweigung getestet. Wenn der Ausdruck stimmt, wird:


1. über die entsprechende Schnittstelle ein Verweis auf das aktuelle Symbol abge-fragt,

2. eine Datenstruktur erstellt, die speziell für diesen Symboltyp vorgesehen ist und die

3. das Symbol an eine Funktion übergibt, die nur dieses Symbol in seiner vorgese-hen Struktur speichert (im Bsp. heißt die Funktion StoreSimpleFill(SFS)). Solch eine Funktion existiert zu jedem möglichen Untersymbol.

Warum der Umweg über Punkt 1? - Warum kann man nicht das Symbolobjekt des Grundsymbols verwenden, das ja das Untersymbol sowieso beinhaltet?

Die Antwort liegt in der Struktur der COM-Philosophie, die ich anhand eines Beispiels verdeutlichen möchte:

Jeder kennt die ineinander verschachtelten russischen Holzpuppen namens "Matrjoschkas". Die COM-Objekte sind vergleichbar aufgebaut: Ein Objekt wird über seine spezielle Schnittstellenklasse erstellt. Auch wenn dieses Objekt weitere Objekte beinhaltet, sind aber nur die Eigenschaften und Methoden verfügbar, die innerhalb ih-rer Schnittstellendefinition vorhanden sind. Will man an das darin enthaltene Objekt und seine Eigenschaften gelangen, muss man erst die abstrakte Schnittstellenklasse des immanenten Objekts erstellen und dann den Verweis von dem beherbergenden Objekt abfragen.

Leider wird dadurch der Programmcode sehr aufgebläht, da man für jedes mögliche Objekt neue Schnittstellen schaffen muss.

Die Analyse ist jedoch an dieser Stelle noch nicht beendet. Angenommen, das aktuelle Flächensymbol hat eine Umgrenzungslinie, so müssen auch diese Symbole und ihre Eigenschaften gespeichert werden. Verfolgen wir exemplarisch den Strang der Um-grenzungslinie:

Jede "Store-Funktion" enthält, falls das Symbol weitere Untersymbole haben kann (was bei PolygonSymbols immer und bei LineSymbols meist der Fall ist), eine weitere Untergliederung der möglichen Symbole. Im Fall der Funktion StoreSimpleFill ist das die Umrandungslinie. Mit der bereits beschriebenen Scan-Funktion (in diesem Fall Li-neSymbolScan) wird die Art der Linie herausgefunden und in einer Case-Verzweigung die entsprechende Linienart erstellt. Angenommen, die Linie besteht aus einem sog. "MarkerLineSymbol", dann würde uns der Strang weiterführen, indem innerhalb der StoreMarkerLine-Funktion eine weitere Unterscheidung nach der Punktart stattfindet, die wiederum in einer entsprechenden "Store"-Funktion mündet.

Normalerweise ist hier das Ende des Stranges erreicht, da die Markersymbole keine weiteren Untersymbole besitzen können; aber auch hier gibt es Ausnahmen (die für die GÜK 300 zutreffen). Für die Grundsymbolarten "MarkerSymbol", "LineSymbol" und "PolygonSymbol" gibt es sog. "MultilayerSymbols", bei denen, wie in Kap. 4.1.1 be-schrieben, beliebig viele Symbole der gleichen Grundsymbolart übereinander liegen können. Diese Multilayersymbole werden in den entsprechenden StoreMultilayer- Funktionen gespeichert. Dort wird in einer Schleife die komplette Anzahl an übereinan-dergeschichteten Untersymbolen dieser Grundsymbolart (Polygon, Linie, Punkt) verteilt


auf die Store-Funktionen ihrer entsprechenden Untersymbolart. Jedes dieser Unter-symbole wird in einer ArrayList der Multilayer-Datenstruktur gespeichert. Für den Fall, dass eines dieser Symbole ebenfalls wieder ein Multilayersymbol ist, findet ein rekursi-ver Aufruf dieser StoreMultilayer-Funktionen statt. Für jedes einzelne dieser Untersym-bolarten gibt es selbstverständlich weitere mögliche Symbolstränge, wie vorher erläu-tert.

Die Codefragmente unter der wellenförmigen Begrenzungslinie, dargestellt in Abb. 20, werden zur Speicherung von Rendererinformationen auf Symbolebene benutzt (das Label eines Symbols und die Feldnamen, nach denen klassifiziert wurde).

Selbstverständlich gibt es eine Reihe weiterer Hilfsfunktionen in dieser Klasse, deren Arbeitsweise hier jedoch nicht explizit erklärt wird, da der Quellcode gut kommentiert ist und ihre Verwendung sich bei der Notwendigkeit einer Beschäftigung damit von alleine erschließt.

III. Die Speicherung in Datenstrukturen:

Über die Funktionen, welche die Speicherung der Renderer- und Symbolinformationen durchführen, wurde u.a. im vorigen Abschnitt referiert.

Dieser Abschnitt soll die Datenstrukturen, die ich zum Speichern der Daten verwende, etwas genauer untersuchen.

Laut [MIK], 242, werden Strukturen von Valuetype abgeleitet, d.h. es handelt sich hier-bei um Werttypen und nicht um Objekttypen. Als solche werden Datenstrukturen im sog. Stack53 gespeichert und nicht im Heap54 wie Objekte. Das macht sie im Vergleich zu Klassen wesentlich effizienter (solange die Datenmengen der einzelnen Strukturen nicht zu groß sind). Strukturen enthalten Deklarationen von Variablen, Prozeduren und Eigenschaften (im Gegensatz zu VB6 und vielen anderen Programmiersprachen kann die Datenstruktur in VB.NET auch abarbeitbaren Code beinhalten).

Die Datenstrukturen spiegeln als Speicher der Kartendaten die Struktur der ArcOb-jects-Symbolverwaltung wider. - Wie ist das zu verstehen?

ArcObjects verwaltet die kartenrelevanten Daten auf drei Ebenen:

1. Symbolebene (diverse Symboleigenschaften in jedem einzelnen Untersymbol)

2. Layerebene (im Rendererobjekt: Layername, Label, Fieldvalues etc.)

3. Projektebene (Datasetname etc.)

Entsprechend werden von mir 3 Datenstrukturebenen verwendet, um die Kartendaten sinngemäß abzulegen:

53 [KKI], Eintrag: Stack= Speicherverwaltung als Stapel. Die Stapelverar-beitung erfolgt nach dem Modelle LIFO (Last In, First Out): Daten wer-den »oben« aufgelegt und zuerst wieder heruntergeholt; oder FIFO: Der zuerst abgelegte wird zuerst abgearbeitet.

54 [Wiki], Eintrag: Heap= Eine Speicherbereich, von dem Speicherabschnitte unterschiedlicher Größe zugeteilt und in beliebiger Reihenfolge wieder freigegeben werden können.


(Um den Bezug zu dem Beispiel aus Abb. 20 zu wahren, wird nachfolgend die Daten-struktur des SimpleFillSymbol als Beispiel verwendet)

Abb. 21 Die Datenstruktur des Symbols SimpleFillSymbol: StructSimpleFillSymbol

Symbolebene:

Die erste Ebene speichert die Symbole bzw. ihre Eigenschaften. Um die Persistenz in der Nomenklatur zu wahren, habe ich für die Strukturnamen den Symbolnamen mit vorangestelltem "Struct" verwendet.

Wie die Abb. 21 verdeutlicht, besitzen die Symbolstrukturen drei Bereiche, in denen Sachverhalte unterschiedlicher Bedeutung erfasst werden (die Begriffe "oben", "mit-tel" und "unten" im folgenden Abschnitt sind entsprechend der Leserichtung zu ver-stehen):

Der obere Bereich speichert die typischen Eigenschaften des Symbols. Im Bsp. von StructSimpleFillSymbol sind das Color und Style; für andere Symbole werden weite-re spezielle Eigenschaften abgelegt.

Im mittleren Bereich sind alle möglichen Datenstrukturen von Symbolen definiert, die das betreffende Symbol beinhalten kann (auch hier spiegelt sich die Struktur der ArcObjects Symbolverwaltung wider, da ArcObjects-Symbole diverse andere Sym-bole integrieren können). Um später bei der Auswertung einfacher zu erkennen, ob und wenn ja, welche der Datenstrukturen verwendet wurde, ist in diesem Bereich eine Enumeration KindOfLineStruct als Lookup vorhanden (auch KindOfMarker-Struct möglich).

Der untere Bereich ist durchweg bei allen Datenstrukturen vorhanden und gleich, da hier Informationen gespeichert werden, die

1. auf Rendererebene abgefragt wurden

2. für alle Symbole gleichermaßen gelten:

Das Label des Symbols, die Feldnamen, nach denen klassifiziert wurde und jene Werte der Klassenobergrenze und -untergrenze, für welche dieses Symbol gültig ist (wird nur bei ClassBreaksRenderer benutzt).

Layerebene:


Die zweite Ebene der Datenstrukturen bilden die Renderer-Structs.

Abb. 22 Die Datenstruktur des Renderers UniqueValueRenderer: StructUniqueValueRenderer

Der Renderer-Struct beinhaltet wie schon erwähnt in der ArrayList SymbolList alle Symbolstrukturen, die für einen Layer abgespeichert wurden. Zusätzlich werden In-formationen wie z.B. Anzahl der Klassen (ValueCount), Layername und Datasetna-me gespeichert. Hilfreich für die spätere Auswertung ist die Enumeration Feature-Class, die als Lookup für die Information dient, welche Featureklasse der augen-blickliche Layer beinhaltet.

Projektebene:

Die oberste Ebene der Datenstrukturen wird durch die Struktur StructProject reprä-sentiert, die in einer ArrayList namens LayerList alle Renderer-Structs beinhaltet, welche bei der Analyse generiert wurden.

5.1.1.3 Das Ausgabemodul "Output_SLD"

Das Ausgabemodul Output_SLD ist die zweite der beiden zentralen Klassen der An-wendung "ArcGIS-map to SLD Converter".

Sie erfüllt die folgenden zwei Aufgaben:

1. Den Aufbau der SLD-Datei durch folgerichtige Übergabe der SLD-Elemente an die Klasse XMLHandle durchführen

2. Die gesammelten Daten analysieren und die Symbolinformationen generalisieren

Der Konstruktor der Klasse übernimmt die Instanz des Motherform (zur Darstellung des Prozessierungsstandes auf dem Motherform), die Instanz von Anali-ze_ArcMap_Symbols (um auf die analysierten Daten zugreifen zu können) und den Dateipfad und -namen der SLD-Datei als Parameter.

Wie auch bei Analize_ArcMap_Symbols gibt es hier eine Funktion namens CentralPro-cessingFunction, die direkt aus dem Konstruktor aufgerufen wird. Bei ihr laufen die Fäden in dieser Klasse zusammen.

Die nachfolgende Abb. 23 dokumentiert in mehreren Struktogrammen die prinzipielle Struktur der Klasse Output_SLD. Es wird wiederum ein möglicher Pfad der Programm-


verarbeitung exemplarisch herausgegriffen.

WriteToSLD( )

Schreibe Projekt-SLD-Gerüst und Projekt-Daten

n RendererStructs

n SymbolStructs

Schreibe Layer-SLD-Gerüst und Layer-Daten

StructUniqueValueRenderer

StructClassBreaksRenderer

StructSimpleRendererSchreibe SLD-Filter-Regeln

Featureklassenverzweigen:

PolygonFeature

LineFeature

PointFeature

… …

… …

Writ

ePol

ygon

Fea

ture

s(S

ymbo

lStruc

t)

WritePolygonFeatures(SymbolStruct)

StructSimpleFillSymbol

StructLineFillSymbolStructMarkerFillSymbol

… … … …

Writ

eSol

idFi

ll(S

ymbo

lStr

uct)

WriteSolidFill(SymbolStruct)

Schreibe Symbol-SLD-Gerüst

Schreibe Symbol-Daten ( Hole Symbol-Daten:

GetValueFromSymbolStruct ( Symboleigenschaft, SymbolStruct ) )

…

GetValueFromSymbolStruct(Symboleigenschaft, SymbolStruct)

StructSimpleFillSymbolStructLineFillSymbol

……

StructSimpleMarkerSymbol…

… … … … … … …Symbol-eigenschaftenverzweigen:

Return Symbolwert (=String)

PolygonColor

PolygonBorderWidth

PolygonBorderColor

LinienStructverzweigen:

LinienStructverzweigen:

Lese BorderWidthaus LinienStruct

Lese BorderColoraus LinienStruct

Lese PolygonColoraus StructSimpleFillSymbol

…

…

Abb. 23 Struktogramme der Klasse Output_SLD


I. Der Aufbau der SLD:

CentralProcessingFunction ruft die Funktion CreateSLD auf, welche die Klasse XMLHandle dazu auffordert, eine neue SLD-Datei zu erstellen, in der lediglich die XML-Deklaration (Verarbeitungsanweisungsknoten) und das SLD-Wurzelknotenelement stehen.

Darauf wird die Funktion WriteToSLD aufgerufen, die den Aufbau der SLD vornimmt. In einer Schleife werden hier die Inhalte der Projekt-Datenstruktur ausgelesen und auf-gesplittet.

Zuerst werden ein paar einleitende SLD-Elemente geschrieben, die für jeden Layer gleich lauten. Daran möchte ich beispielhaft das "Mapping" verdeutlichen, das die zu schreibenden SLD-Elemente an Veränderungen der SLD-Spezifikation anpassbar macht:

Abb. 24 Erste Elemente der Funktion WriteToSLD in der Klasse OutputSLD

Die ersten Anweisungen an die XML-Klasse sollen ein Element "NamedLayer" und danach das Element "LayerName" schreiben. Dies sind jedoch nicht die richtigen Na-men der SLD-Tags, die geschrieben werden sollen, sondern lediglich Pseudonyme der Elementnamen. Tatsächlich finden sich die Pseudonyme in der Datei LUT_sld_mapping_file.xml wieder, die beides beinhaltet: die Pseudonyme und ihre zugehörigen, gemäß der Spezifikation korrekten Elementnamen:

Abb. 25 entsprechende Elemente in der Konfigurationsdatei LUT_sld_mapping_file.xml


Der Elementname in der Konfigurationsdatei LUT_sld_mapping_file.xml stimmt mit dem im Code übergebenen Pseudonym überein. Das Pseudonym "LayerName" (das 2. übergebene Pseudonym in Abb. 24) findet sich in Abb. 25 in dem Element der 7. Zeile wieder. Die nach der Spezifikation korrekten Elementnamen stehen bei dem At-tribut "ogcTag". Wie man erkennen kann, heißt das Element nur "Name". Der Element-name bleibt immer gleich und ist folglich immer übereinstimmend mit dem im Code benutzten Pseudonym. Der Attributwert hingegen kann nach Bedarf angepasst wer-den.

Der Vorteil dieser Vorgehensweise ist, dass man Anpassungen der Konfiguration durch veränderte Spezifikationen in einer Datei durchführen kann und nicht den Programm-code ändern muss.

Abb. 26 Elemente in der resultierenden SLD

Als Resultat entsteht eine nach Maßgaben der aktuellen Spezifikation gültige SLD (Abb. 26), in der die in Abb. 24 enthaltenen Elemente (samt Namespacekürzel) darge-stellt sind.

Der technische Ablauf des Mapping sowie alle weiteren Elemente der Konfigurations-datei werden später mit der Präsentation der Klasse XMLHandle erläutert.

Nach dem Schreiben der für alle Layer gleichen Elemente werden die Daten jetzt in einer "IF-ELSEIF"-Mehrfachverzweigung aufgesplittet nach den im Project-Struct ent-haltenen Renderer-Structs. Vorher befanden wir uns auf Layerebene, im Folgenden bewegen wir uns auf der Ebene von Symboltypen.

Im Gegensatz zu ArcMap werden in SLD die Regeln zur Klassifizierung auf der Ebene der Symbole gehandhabt. Folglich werden jetzt für jedes Symbol die Elemente für die Regeln geschrieben (Rule), denn diese Elemente machen die Klassifizierung in SLD aus. Sie stellen somit das Äquivalent zu der Klassifizierung durch Renderer in ArcMap dar. Im Falle der Klassifizierung nach Einzelwerten (in ArcMap "UniqueValue") wird die Rule mit dem Vergleichsoperator IsEqualTo als Filterelement geschrieben. Im Falle einer Klassifizierung nach Wertebereichen (in ArcMap "ClassBreaks") würde an dieser Stelle der Operator IsBetween mit einer Angabe von Ober- und Untergrenze der Klas-se stehen.

Als nächstes findet durch eine "SELECT-CASE"-Verzweigung eine Differenzierung in die drei Featureklassen Punkt (PointSymbolizer), Linie (LineSymbolizer) und Polygon (PolygonSymbolizer) statt.

Die Punkt- und Linienübersetzungen in SLD sind z.Zt. noch recht einfach gehalten, obwohl auch hier Attribute wie Farbe, Linienstärke, Punktgröße und Punktwinkel (wich-


tig bei Pfeilen oder Kreuzen als Punktsymbole) umgesetzt wurden. Wesentlich komple-xer ist dagegen die Darstellung von Polygonsymbolen (auch im Hinblick darauf, dass die GÜK 300 hauptsächlich Polygonthemen enthält), deren Verarbeitung ausgelagert wurde in mehrere unterschiedliche Funktionen:

Bei einem PolygonFeature wird die Funktion WritePolygonFeatures aufgerufen, welche zunächst einmal die Art der aktuellen Datenstruktur auf eine der sieben möglichen Strukturen von FillSymbol untersucht. Im Augenblick sind wegen der beschränkten Möglichkeit in SLD jedoch nur vier Strukturarten implementiert:

SimpleFillSymbol:

Bei einer SimpleFillSymbol-Structure wird die Funktion WriteSolidFill aufgerufen, die ein vollflächig gefärbtes Symbol in SLD erzeugt.

MarkerFillSymbol:

Liegt eine MarkerFillSymbol-Struktur vor, wird die Funktion WriteMarkerFill aufgeru-fen, die eine farbige Punktfüllung mit transparentem Hintergrund erzeugt.

LineFillSymbol:

Bei einer LineFillSymbol-Struktur wird entweder die Funktion WriteSlopedHatching oder WritePerpendicularHatching aufgerufen, die eine Schraffur simuliert. Hier wird bewusst das Wort "simulieren" verwendet, weil eine richtige Schraffur auf Vektorba-sis bei den derzeitigen Möglichkeiten von SLD nicht realisierbar ist. Stattdessen wird eine Kreuzschraffur auf Grundlage einer Punktfüllung erzeugt. Die Punktsymbole stellen hierbei gleichschenkelige und orthogonale Kreuze (für eine horizontale Kreuzschraffur) und X-Symbole (für eine schräge Kreuzschraffur) dar, die sich an den Enden berühren. Die Schraffurbreite kann durch die Symbolgröße variiert wer-den. Welche der beiden Funktionen aufgerufen wird, hängt vom Schraffurwinkel des ArcMap-Symbols ab.

Mit dem rekursiven Aufruf auf die Verteilerfunktion WritePolygonFeatures ist es möglich, Schraffuren (Kreuzschraffuren, wie o.g.) und Punktfüllungen mit unterlegter vollfarbiger Flächenfüllung zu realisieren, indem hier mehrere Flächensymbole (Po-lygonSymbolizer) übereinandergelegt werden. Hierbei gibt es jedoch Einschränkun-gen:

Die Implementierungen mancher Mapserver lässt nur eine bestimmte Anzahl von übereinanderliegenden Symbolen zu, deshalb habe ich in der Funktion WritePoly-gonFeatures die Anzahl der übereinanderliegenden Symbole auf zwei begrenzt.

MultilayerFill:

Im Falle einer MultilayerFill-Struktur wird ebenfalls ein rekursiver Aufruf auf die Funktion WritePolygonFeatures getätigt. Hinter dieser Maßnahme steckt die Tatsa-che, dass ein Layer eines Multilayersymbols immer aus einer dieser drei Grund-symbolarten bestehen muss. Also ist hier keine zusätzliche Funktion notwendig, da die einzelnen Layer des Multilayersymbols einfach in einer Schleife nacheinander der eigenen Funktion übergeben und korrekt abgearbeitet werden können.


Der Aufbau der SLD beschränkt sich nicht allein auf die Entwicklung des SLD-Gerüsts. Bislang wurde nur über die Extraktion von allgemein verfügbaren (und allgemein gülti-gen) Informationen aus den Datenstrukturen gesprochen. Im Folgenden geht es dar-um, symbolspezifische Informationen zu erlangen, womit wir zur 2. wichtigen Aufgabe dieser Klasse kommen:

II. Analysieren und Generalisieren der Symbolinformationen:

Wollen die vorgenannten Funktionen Symbolinformationen, d.h. Symboleigenschaften wie Farbe, Größe, Breite etc. haben, um sie der XML-Klasse zum Schreiben zu über-geben, muss vorab analysiert werden, um welche Art Symbol es sich handelt. Deshalb wird jedes Mal, wenn diese Informationen gefragt sind, die Funktion GetValueFrom-Symbolstruct aufgerufen. Sie bekommt als Parameter die Symbolstruktur übergeben, die es zu durchsuchen gilt, und einen String, der die Symbolinformation, die man be-kommen will, repräsentiert (ValueNameOfValueYouWant).

Der Typ des Symbol-Structs wird über eine "IF-ELSEIF TYPEOF"- Verzweigung ermit-telt. Innerhalb des IF-Blocks wird in einer "SELECT-CASE"- Abfrage weiter verzweigt nach dem übergebenen Parameter ValueNameOfValueYouWant.

Abb. 27 Verzweigung der Funktion GetValueFromSymbolstruct zur Analyse

Entsprechend des übergebenen Strings werden die gewünschten Parameter extrahiert. Im Bsp. der Abb. 27 wird für das wohlbekannte StructSimpleFillSymbol die Abfrage nach der Flächenfüllung und der Breite der Flächenumrandung angeboten. Bei der Flächenumrandung sind Liniensymbole als Co-Symbole möglich, darum muss auch hier die entsprechende Liniensymbolstruktur erst ermittelt werden, bevor die Linienbrei-te ausgelesen werden kann. Wenn die betreffende Struktur eine Multilayerstruktur ist, wird (egal bei welcher Featureklasse) ein rekursiver Aufruf von GetValueFromSymbol-struct getätigt, denn die Multilayerstrukturen haben wie üblich auch hier eine Sonder-stellung:

In dem Teil der Funktion, wo die Multilayerstructs verzweigen, werden diese Symbol-layer in einer Schleife durchlaufen und auf den Typ der Symbolstruktur überprüft. Wird unter den Symbolen ein Simple-Symbol gefunden, so wird aus diesem die gewünschte


Symboleigenschaft herausgezogen. Falls in dem Symbolpaket kein Simple-Symbol vorkommt, wird die Eigenschaft des obenliegenden Symbols benutzt.

Der Implementierung der Funktion in dieser Weise geht folgende (ökonomisch orien-tierte) Überlegung voraus:

Ist der aktuelle Symbolstruct ein MultilayerFillSymbol-Struct, so wird der Symbol-Struct schon in der Funktion WritePolygonFeatures in seine einzelnen Grundsymbole aufge-teilt. Bei einer Anfrage an die Funktion GetValueFromSymbolstruct wird also kein Multi-layerFillSymbol-Struct mehr übergeben. Es bleiben nur MultilayerLine-Structs und Mul-tilayerMarker-Structs als mögliche zu übergebende Multilayer-Structs. Diese sind je-doch eher selten und daher von mir vorerst nicht implementiert. Wenn dieser Fall doch einmal eintreten sollte, extrahiert die Funktion an dieser Stelle die Eigenschaft des Simple-Symbols (oder falls dieses nicht vorhanden ist, die entsprechenden Eigenschaf-ten des obenliegenden Symbols) des Layerpakets, damit überhaupt eine Information zurückgegeben wird.

Welche Symboleigenschaften implementiert sind, wird in Kap. 5.1.2 behandelt.

5.1.1.4 Die auf XML-Aufgaben spezialisierte Klasse "XMLHandle"

XMLHandle ist eine abhängige Klasse, d.h. sie wird komplett von einer aufrufenden Klasse aus gesteuert. Ihr wichtigstes Element ist die Funktion NavigateElement, die wie der Name schon vermuten lässt, die Navigation innerhalb der entstehenden SLD übernimmt. Ihre genaue Funktionsweise wird später erklärt werden.

Abhängig heißt in Bezug auf die Klasse, dass es keinen sequentiellen beschreibbaren Programmablauf gibt, da lediglich die benötigten Funktionen von der aufrufenden Klas-se aus aktiviert werden. Man kann hier dennoch drei thematische Schwerpunkte set-zen:

1. Initialisierung und Konfiguration

2. Verwaltung der XML-Namespaces

3. Die Navigation in der SLD (Funktion NavigateElement)

I. Initialisierung und Konfiguration (Die Datei LUT_sld_mapping_file.xml)

Die Instanz von XMLHandle wird von der aufrufenden Klasse erzeugt (in diesem Fall ist das natürlich OutputSLD). Es gibt zwei überladene Konstruktoren: Der eine Kon-struktor bekommt zwei Parameter übergeben: die Instanz der aufrufenden Klasse und den Dateinamen und –pfad als String. Der andere Konstruktor bekommt nur die In-stanz der aufrufenden Klasse. SLD Dateinamen und –pfad kann auch später noch über die Property XMLFilename übergeben werden.

Als nächstes wird von OutputSLD aus die Funktion Start aufgerufen, die eine neue leere XML-Datei (die spätere SLD) anlegt. Danach wird die Funktion ReadLUT aufge-rufen. Die Funktion liest alle Inhalte der Konfigurationsdatei LUT_sld_mapping_file.xml in programminterne Datenspeicher (hierfür wird u.a. die KlasseStore2Fields benutzt), damit die Daten unmittelbar zur Verfügung stehen und nicht ständig ein Zugriff auf die


Konfigurationsdatei notwendig ist (die Bezeichnung LUT in der Datei steht für 'Lookup Table'). In Abb. 28 ist ein Ausschnitt aus der Datei mit den wichtigsten Elementen auf-geführt (die komplette Datei wurde dem Anhang beigefügt).

Abb. 28 Ausschnitt aus der Datei LUT_sld_mapping_file.xml

Die XML-Datei ist in zwei Sektionen eingeteilt:

1. sldConfiguration

2. sldSyntax

Sektion 1 enthält die Inhalte des Verarbeitungsanweisungs-Knotens sowie die Na-mespaces und Prefixes der Elemente, die in der SLD benutzt werden. Dieser Eintrag ist sehr wichtig, da damit der sog. Namespacemanager der .NET XML-Verwaltung in-itialisiert wird (darauf werde ich später zu sprechen kommen). Es ist wichtig, dass alle Namespaces und die zugehörigen Kürzel (die Kindelemente des Elements Namespa-ces), die später in der SLD verwendet werden, hier aufgeführt sind, da ansonsten der Namespacemanager im Verlaufe der Verarbeitung einen Fehler erzeugt.

Sektion 2 enthält die SLD-Pseudonyme als Entries (die Bezeichnung Sektion und Entry wurde hier in Anlehnung an die Hierarchie-Gliederung von inf-Konfigurationsdateien gewählt). Der nach der Syntax der aktuellen Spezifikation gültige SLD Elementname ist der Wert des Attributs ogcTag. Der Wert des Attributs Namespace ist der zum Element zugehörige Namespace (vgl. 5.1.1.3/I).

Die Subentries namens XPath beinhalten die XPathanweisungen, mit deren Hilfe in der entstehenden SLD navigiert wird. Wie man Abb. 28 entnehmen kann, ist die gültige Anzahl von XPath-Einträgen "unbounded" (beliebig viele). Das kommt daher, dass manche SLD-Ausdrücke durchaus als Kindelemente mehrerer unterschiedlicher El-ternelemente vorkommen können. Die Ausdrücke liegen in der verkürzten Schreibwei-se (vgl. 3.4.5), aber mit Namespacekürzeln vor.


Von der aufrufenden Klasse aus wird nun über die Property der SLD-Dateiname und Dateipfad gesetzt und danach (ebenfalls von OutputSLD aus) die Funktion Create-NewFile aufgerufen. Die Funktion erstellt in der leeren XML-Datei (SLD) den Versions-knoten und das Root-Element der SLD-Datei, den StyleLayerDescriptor-Knoten.

II. Verwaltung der XML-Namespaces (der .NET Namespacemanager)

In der o.g. Funktion CreateNewFile wird ebenfalls der .NET Namespace-Manager in-itialisiert mit den aus der Konfigurationsdatei ausgelesenen Namespace-URI55 und Namespaceprefixes: Dem Manager wird zur Initialisierung die Nametable des aktuellen XML-Dokuments übergeben. Darüber ist der Manager während seiner gesamten Le-benszeit mit dem aktuellen Dokument verbunden. Danach werden dem Manager in einer Schleife die URI und Prefixes übergeben. Hintergrund des .NET Namespace-Managers:

.NET besitzt eine komplexe Verwaltung von XML-Funktionalitäten. Will man nun XML-Elemente schreiben und übergibt der Methode CreateElement(ns:xmlElement) des Objekts XMLDocument ein zu schreibendes Element, das einen Doppelpunkt besitzt, so erkennt .NET dieses Zeichen als Steuerzeichen zur Separierung von Namespaces (vgl. 3.4.5 – Steuerzeichen in XPath). Es schreibt folglich nur den sog. "lokalen Na-men" des Elements rechts des Steuerzeichens und "verschluckt" das Namespaceprefix links davon. Das geschieht in diesem Fall mit Bedacht, da manche XML-Objekte in .NET XML-Dokumente, die Tags mit Namespacekürzeln enthalten, nicht ohne weite-res verarbeiten können.

Es gibt jedoch eine Möglichkeit, die Elemente in der gewünschten Weise (mit Na-mespaceprefixes) zu schreiben: indem man mit der überladenen Methode CreateEle-ment("ns",XMLElement,"ns-URI") zusätzlich zu dem zu schreibenden Element das Namespaceprefix und die URI übergibt. Das geht allerdings nur dann, wenn Namespa-ces und URI's vorher in den Namespacemanager aufgenommen wurden.

Ab diesem Zeitpunkt wartet die XMLHandle-Klasse auf Eingaben der aufrufenden Klasse. Diese Eingaben können mit den Funktionen CreateElement (Erstellen eines neuen XML-Elements), SetElementText (Einfügen des InnerText in das gerade erstell-te Element), CreateAttribute (Erstellen eines neuen Attributs) und SetAttributeValue (Setzen des Attributwertes des gerade gemachten Attributs) getätigt werden. Alle Funktionen der Klasse sind als "Public" deklariert, da sie einen Zugriff von außerhalb zulassen müssen.

Die Funktionen sind sehr flach gehalten. Ermöglicht wird dies durch die Verlagerung der Navigation in die Funktion NavigateElement.

55 [Wiki], Eintrag: Ein Uniform Resource Identifier (URI) (engl. "einheit-licher Bezeichner für Ressourcen") ist eine Zeichenfolge, die zur Iden-tifizierung einer abstrakten oder physikalischen Ressource dient. URIs werden zur Bezeichnung von Ressourcen (wie Webseiten, sonstigen Datei-en, Aufruf von Webservices, aber auch z.B. E-Mail-Empfängern) im Inter-net und dort vor allem im WWW eingesetzt. URI fassen URL und URN zusam-men.


III. Das Prinzip der Funktion NavigateElement:

Jedes Mal, wenn von der Funktion CreateElement ein neues Element erstellt wurde, wird dies "aktiv gesetzt" (d.h. es gibt einen Elementknoten ActiveNode, der einen Ver-weis auf das gerade erstellte neue Element erhält). Wenn ein Element zum Schreiben an die Funktion übergeben wird, "weiß" diese nicht, wo dieses neue Element erstellt werden soll. Also wird das neue Elementpseudonym an die Funktion NavigateElement weitergegeben.

In der Funktion wird zuerst die zu dem Element gehörende Sammlung an XPath-Ausdrücken in eine eigene Collection eingelesen (zur Erinnerung: Die XPath-Ausdrücke repräsentieren den Elternknoten des zu erstellenden Elements). Dann wird für den aktiven Knoten ein XPathNavigator-Element56 erstellt. In mehreren Schleifen werden nun verschiedene Bedingungen getestet:

Mit dem 1. XPath-Ausdruck der Sammlung wird (mit der Methode SelectNodes) eine Knotenliste erstellt, welche nur Knoten enthält, die mit dem getesteten XPath-Ausdruck übereinstimmen. Von dieser Liste kann jedoch nur der letzte Knoten der gesuchte sein, da die Datei seriell geschrieben wird. Der Knoten wird mit dem aktuellen ActiveNode verglichen. Stimmen beide überein, so ist das neu zu erstellende Element ein Kindele-ment des zuletzt erzeugten Elements und die Prozedur kehrt zur aufrufenden Funktion zurück, um das Element mit AppendChild in den ActiveNode einzuhängen.

Stimmen sie nicht überein, wird erst einmal der nächste XPath-Ausdruck aus der Col-lection getestet. Sind alle Ausdrücke der Collection getestet und keiner der Knoten hat Übereinstimmung gefunden, ist klar, dass der aktuelle ActiveNode nicht der Elternkno-ten des zu erstellenden Elements sein kann. Jetzt wird diese Prozedur für alle Knoten, die sich auf derselben Ebene wie der ActiveNode befinden, wiederholt. Ist diese Ebene getestet und keiner der Knoten auf dieser Ebene stimmt mit dem aus der XPath-Collection überein, wird eine Ebene zurück navigiert. Irgendwann stimmt ein Knoten mit einem der aus den XPathausdrücke generierten Knoten überein: Der Elternknoten des zu erstellenden Elements ist gefunden und wird aktiv gesetzt. Der Prozess kehrt, wie oben beschrieben, zur Funktion CreateElement zurück und das neue Element kann erzeugt werden.

Attribute werden grundsätzlich im zuletzt erzeugten Elementknoten erstellt. Die Wert-zuweisungen von Elementen und Attributen erfolgt ebenfalls für den jew. zuletzt er-zeugten Knoten.

Sind alle SLD-Elemente geschrieben, erwartet die Klasse XMLHandle das Signal zum Schreiben der Datei, das von OutputSLD mit Aufruf der Funktion SaveDoc geliefert

56 .Net-Help: XPathNavigator basiert auf dem XPath-Datenmodell und stellt die Methoden bereit, die zur Implementierung von XPath-Anfragen über einen beliebigen Datenspeicher benötigt werden.

Anmerkung: Der XPathNavigator kann zunächst nur XPath-Ausdrücke auswer-

ten, die kein Namespacekürzel besitzen. Wenn, wie im vorliegenden Fall, Ausdrücke mit Namespaceprefixes ausgewertet werden sollen, benötigt der XPathNavigator den XMLNamespaceManager. Darum wird bei jeder SelectNo-des-Operation des Navigators der Manager als Parameter mit übergeben.


wird.

Die Vorteile einer solchen Navigation machen sich bei der Implementierung von neuen SLD-Funktionen bemerkbar. Wenn die SLD-Elemente inclusive XPath-Anweisungen einmal in der Datei LUT_sld_mapping_file.xml aufgenommen sind, kann man die Ele-mente benutzen, ohne sich Gedanken über ihren korrekten Platz in der SLD machen zu müssen.

5.1.1.5 Die Gültigkeitsüberprüfung mit der Klasse "ValidateSLD"

Die Methode Run ist die zentrale Methode der Klasse ValidateSLD. Folgende zentrale Algorithmen laufen in der Methode ab:

Zuerst wird eine XMLSchemaCollection57 erstellt, die mit einem XMLTextReader initia-lisiert wird, der die Schemadatei geladen hat. Mithilfe des XMLTextReader liest das XMLSchemaCollection-Objekt die Schemadatei. Dieser Moment ist schon ein kriti-scher, da die Datei in diesem Augenblick nicht nur gelesen, sondern auch interpretiert wird. D.h. das Objekt überprüft:

1. ob die Schemadatei selbst nach XML-Syntax und –Semantik gültig ist

2. ob es assoziierte Schemadateien gibt; wenn ja

3. ob die assoziierten Schemadateien über die angegebene URL erreichbar sind

Wenn alle drei Bedingungen erfüllt sind, werden die assoziierten Schemadateien der Collection hinzugefügt und genauso geprüft wie die Hauptdatei.

Wenn eine der drei Bedingungen nicht erfüllt wird, so wird bei 1. eine XMLException und bei 2. und 3. eine XMLSchemaException ausgelöst, die von mir in einem "TRY-CATCH"-Block abgefangen und dem globalen Überprüfungsreport hinzugefügt werden. Tritt einer dieser drei Fälle ein, wird an dieser Stelle mangels gültigen Prüfarguments die Überprüfung abgebrochen.

Wenn die Überprüfung der Schemadateien erfolgreich beendet wurde, wird ein XMLValidatingReader-Objekt58 erstellt und dieses mit einem neuen XMLTextReader initialisiert, der das SLD-Dokument geladen hat.

Als nächstes wird ein ValidationEventHandler erstellt, der alle Überprüfungsereignisse des XMLValidatingReader abfängt. Der EventHandler wird initialisiert, indem ihm die "Adresse" der Methode übergeben wird, die die Ereignisbehandlung enthält. In diesem Fall heißt die Methode ValidationEvent. Der Handler muss jetzt mit dem Befehl Add-

57 .NET-Help: XmlSchemaCollection kann vom XmlValidatingReader für die ef-fiziente Datenüberprüfung verwendet werden. Sie enthält einen Cache mit XSD-Schemas. Schemas werden mit Hilfe der Add-Methode geladen. Dabei wird das Schema einem Namespace-URI zugeordnet. Bei XML-Schemas ist dies normalerweise die targetNamespace-Eigenschaft des Schemas.

58 .NET-Help: XmlValidatingReader implementiert die XmlReader-Klasse und bietet Unterstützung für die Datenüberprüfung. Wenn der Reader die Überprüfung mit Hilfe von Schemadateien vornehmen soll, die in XmlSche-maCollection zwischengespeichert sind, wird die Schemas-Eigenschaft verwendet. Die ValidationType-Eigenschaft gibt an, welche Art der Über-prüfung vom Reader durchgeführt werden soll.


Handler dem XMLValidatingReader bekannt gemacht werden59. Da die Überprüfung mit einem EventHandler überwacht wird, kann das gesamte Dokument geprüft werden, ohne dass bei einem Verstoß gegen das XML-Schema die Validierung abgebrochen werden muss.

Als nächstes wird dem XMLValidatingReader die XMLSchemaCollection mit Sche-mas.Add(Collection) hinzugefügt und im nächsten Zug die Art des Überprüfungsdoku-ments mit "ValidationType.Schema" mitgeteilt.

Der ValidatingReader hat nun alles, was er benötigt, um die SLD zu lesen, gegen das Schema zu prüfen und auf Gültigkeitsverstöße zu reagieren.

Der Lesevorgang läuft in einer while-Schleife mit der Anweisung "Reader.read" ab. Falls dabei ein Verstoß gegen die Regeln der Schemadatei(en) auftritt, wird dieser Verstoß von dem Eventhandler mit den Argumenten "ErrorID" und "args" an die Aus-nahmebehandlung ValidationEvent weitergegeben.

In ValidationEvent wird das "Arguments"-Objekt args weiter verzweigt, um den Fehler spezifizieren zu können. Kommt es zu einem Verstoß, wird hier die Art des Verstoßes ermittelt und mit einer entsprechenden Fehlermeldung dem globalen Überprüfungsre-port hinzugefügt.

Wenn die gesamte SLD überprüft wurde, wird im Falle eines Verstoßes ein Formular eingeblendet, das durch die Klasse Validation_Message repräsentiert wird. Das For-mular enthält eine Textbox, der beim Aufruf der globale Überprüfungsreport hinzuge-fügt wird.

Wird kein Verstoß registriert, so wird die erfolgreiche Überprüfung lediglich im Hinweis-feld des Hauptformulars angezeigt.

5.1.2 Implementierung der Sollkomponenten und darüber hinausge-

hende Implementierungen

Dieses Unterkapitel soll dokumentieren, was das Programm ArcGIS-map to SLD Con-verter zum derzeitigen Stand der Version 1.0.0 leistet. Teilweise wurden die Implemen-tierungen im Kap. 5.1.1 unter dem Gesichtspunkt der technischen Umsetzung schon angesprochen. Hier liegt der Schwerpunkt auf den Möglichkeiten der Anwendung.

Motherform:

� Das Programm bietet Unterstützung für benutzerdefinierte Einstellungen.

o Das Programm merkt sich letzten Speicherort der SLD und bietet ihn bei der nächsten Sitzung wieder an.

o Es wird registriert, ob der Darstellungsbereich in die SLD übernommen

59 Hier wird bewusst der Ausdruck "bekannt machen" verwendet, da es sich bei der Operation nicht wirklich um eine Initialisierung handelt, was sich in der Tatsache der ungewöhnlichen Syntax äußert (keine Klammer und lediglich ein Komma als Separator).


wurde und wird beim nächsten Mal automatisch markiert.

o Die Maßstabszahlen in den Min- und Max-Bereichen sind über die Be-nutzeroberfläche editierbar (durch Eingabe in die Comboboxen), werden in die Konfigurationsdatei übernommen und beim nächsten Programm-aufruf angeboten.

� Alle Bearbeitungsvorgänge können im Infofeld verfolgt werden, das bei Auslösen der SLD-Funktion automatisch ausklappt und sich nach Abschluss der SLD-Generierung wieder automatisch zusammenklappt

� Durch eine Auswahl des Zieldatenspeichers, den der Mapserver benutzt, wird das korrekte Format für die PropertyName in der SLD eingetragen (Zieldaten-speicher meint hier den Datenspeicher, der zum Generieren der Internetkarte vom Mapserver benutzt wird).

Analize_ArcMap_Symbols:

� Alle in ArcMap vorhandenen Symbole sind prinzipiell implementiert (prinzipiell: die Erfassung der Symbole ist implementiert, aber manche Symbole können nur von best. Renderer-Typen erzeugt werden; z.Zt. sind nicht alle Renderer-Typen implementiert). Die gespeicherten Eigenschaften jedes einzelnen Sym-bols können in der Klasse Analize_ArcMap_Symbols unter der Region "Daten-strukturen" eingesehen werden.

� In der Analyse wurden alle Renderer-Typen implementiert, die derzeit in SLD umsetzbar sind:

o UniqueValueRenderer (incl. many fields)

o SimpleRenderer

o ClassBreaksRenderer

� Nicht umgesetzt sind derzeit:

o ChartRenderer

o DotDensityRenderer

o ProportionalSymbolRenderer

o ScaleDependentRenderer

Wie in Kap. 5.1.1 erwähnt, ist die Erfassung der Daten in den Funktionen StoreStruct… organisiert. Für einen neuen Renderer müsste solch eine Funktion StoreStructNeuer-Renderer erstellt werden.

OutputSLD:

Für die Ausgabe in SLD-Dokumente sind folgende Renderer implementiert:

� UniqueValueRenderer (incl. many fields)

� SimpleRenderer

� ClassBreaksRenderer


Um einen neuen Renderer zu implementieren, müsste dieser in die Funktion Write-ToSLD aufgenommen werden.

Folgende Darstellungseigenschaften sind für die einzelnen Featureklassen implemen-tiert:

� Punkt-Feature: Farbe, Punktgröße, Drehwinkel

� Linien-Feature: Farbe, Linienstärke

� Polygon-Feature:

o Einfarbige Flächenfüllung: Flächenfarbe, Linienfarbe der Umrandung, Linienstärke der Umrandung

o Punktfüllung: Punktfarbe, Punktgröße, Linienfarbe und Linienstärke der Umrandung

o Kreuzschraffur: Linienfarbe und Linienbreite der Schraffur, senkrechter und schräger Schraffurwinkel, Linienfarbe und Linienstärke der Umran-dung

Ebenfalls implementiert ist die Darstellung von Multilayersymbolen als zweilagige Symbole (zweilagig, weil manche Mapserver z.Zt. nicht mehr Symbollagen prozessie-ren können – s. 5.2.1.1)

Für die Beschriftung der Symbole in einer Legende wurde für jede Regel (Rule) eines Symbols das Title-Element eingefügt. Als Elementwerte wurden die Klassen-Label der Symbol-Klassen aus der ArcMap-Karte benutzt.

Linienstrichlierung sowie Bitmaps als Flächenfüllung sind derzeit nicht im Programm implementiert.

XMLHandle:

Die XPath-Ausdrücke und die SLD-Elemente werden aus einer Datei gelesen und im Programm verwendet. Damit ist die SLD-Syntax anpassbar an kommende Änderungen der SLD-Spezifikation.

Über die XPath-Ausdrücke ist keine Anpassung an Veränderungen der SLD-Element-Hierarchien möglich, da die Abfolge der zu schreibenden Elemente und Attribute im Code festgelegt sind: D.h., wenn ein SLD-Element seinen Platz in der Hierarchie wech-selt, muss das Element im Code entweder früher oder später an die schreibende XML-Klasse übergeben werden, da es nun ein anderes Elternelement als vorher besitzt. Diese Tatsache kann die XPath-Navigation nicht kompensieren.

ValidateSLD und Validation_Message:

� Das Schema gegen das geprüft werden soll, wird selbst auf XML-Validität ge-prüft.

� Assoziierte Schemadateien werden auf Erreichbarkeit und XML-Validität geprüft.

� Bei ungültigen SLD-Fragmenten wird der Element- bzw. Attributname, Zeilen-nummer, Zeichennummer des verursachenden Elements bzw. Attributs sowie


die interne Fehlermeldung protokolliert.

� Das Fehlerprotokoll wird ausgegeben auf einer graphischen Oberfläche und kann bei Bedarf in einer Textdatei abgespeichert werden.

5.1.3 Besondere Herausforderungen bei der Entwicklung

Selbstverständlich tauchen im Laufe der Entwicklung eines Programms immer wieder spezifische Probleme auf, die jedoch meistens binnen weniger Stunden behoben sind. Manchmal gilt es jedoch Aufgaben zu meistern, mit denen man in dieser Art nicht ge-rechnet hätte. Drei besondere Herausforderungen möchte ich hier hervorheben:

I. Das Problem der Klassifizierung nach zwei oder mehr Feldern:

Für die Klassifizierung eines Datasets in SLD nach eindeutigen Werten (Unique Va-lues) werden eben diese eindeutigen Werte des Datasets benötigt. Wenn die Klassifi-zierung nach einem Feld vorgenommen wurde, gibt es keine Schwierigkeiten, diese eindeutigen Werte zu erhalten: Man liest einfach die Values(Symbol i) aus dem Rende-rer aus. Wenn die Klasse allerdings aus den Unique Values mehrerer Tabellenfelder zusammengesetzt wurde, funktioniert diese simple Methode nicht. Die für jede Klasse ausgelesenen Values bestehen dann nämlich aus einem String, der zusammengesetzt ist aus den Einzelwerten jedes Feldes, separiert durch ein Trennzeichen, den sog. FieldDelimiter. Für die Nachbildung der Klassifizierung in SLD wird aber jeder dieser Feldwerte einzeln benötigt, weil für jedes klassifizierende Tabellenfeld ein Element PropertyIsEqualTo geschrieben werden muß (s. Abb. 48 in Kap. 5.2.1.3).

Eine Möglichkeit, an diese einzelnen Werte zu kommen, wäre eine Stringoperation, die mit dem Delimiter als Argument den String in mehrere Einzelstrings aufteilt, welche die jeweiligen Einzelwerte der Felder repräsentieren.

Diese Variante scheidet hier jedoch aus, da die Möglichkeit besteht, dass die Feldwer-te selbst den Character des FieldDelimiter beinhalten.

Ein weiterer gangbarer Weg besteht darin, aus den vorliegenden Datensätzen "eigen-händig" die Unique Values jedes Feldes zu extrahieren und die Unique Values jedes einzelnen Feldes einer Klasse über einen Vergleich mit den zusammengesetzten Uni-que Values aus dem Renderer zu erhalten.

Der Vergleich wurde von mir in der Funktion GimmeSeperateFieldValues in folgender Weise umgesetzt:

Man nimmt einen Wert aus der Unique Values-Liste des einen Feldes, setzt diesen Wert plus den FieldDelimiter plus einen Wert aus der Unique Values-Liste des anderen Feldes zu einem String zusammen und vergleicht diesen String mit dem zusammenge-setzten String, der aus dem Renderer ausgelesen wurde. So werden nacheinander alle Werte der einen Liste mit denen der anderen Liste zusammengesetzt und mit dem ausgelesenen Renderer-Value verglichen. Bei einer Übereinstimmung hat man nun die Einzelwerte jedes Feldes für eine bestimmte Klasse.

Da im schlechtesten Fall jeder Wert aus einer Liste einmal mit jedem Wert aus der an-


deren Liste kombiniert werden muss, erhalten wir mit dieser Funktion einen Aufwand von n² Operationen, wobei n die Anzahl der Listenmitglieder darstellt (hierbei wird eine gleiche Anzahl von Listenmitgliedern beider Listen vorausgesetzt, was in der Praxis jedoch nicht zwangsläufig so sein muss).

Bei der vorherigen Überlegung wurde von einer Anzahl von zwei Feldern zur Klassifi-zierung ausgegangen. Bei max. drei möglichen Feldern der Klassifizierung bedeutet dies schon einen Aufwand von n³ Operationen (bei den gleichen Randbedingungen).

Durch den Vergleich konnte ich den Unique Value jedes beteiligten Feldes pro Klasse ermitteln. Aber wie kommt man an die UniqueValues-Liste für jedes Feld, die ja Vor-aussetzung für die vorgenannte Prozedur ist?

Eine Möglichkeit ist, den kompletten Datensatz Zeile um Zeile mit einem sog. Cursor-Objekt zu durchlaufen und jeweils neue Werte in einer Liste abzuspeichern. Bei der Datengrundlage der GÜK 300 mit knapp 15.000 Datensätzen und zwei klassifizieren-den Feldern benötigte diese Aktion ca. 15 Minuten. Der Test mit drei klassifizierenden Feldern wurde von mir nach 30 Minuten vorzeitig abgebrochen.

Eine weitere Möglichkeit bietet eine Prozedur, die ich in der Funktion GimmeUniqeVa-luesForFieldname umgesetzt habe:

Auf das aktuelle Dataset wird ein QueryDef-Objekt aufgesetzt. Das QueryDef-Objekt wird mit den zu untersuchenden Feldern und einem SQL-Fragment, dessen Bestand-teil die Anweisung DISTINCT ist, initialisiert. Diese Funktion extrahiert die Unique Va-lues zweier Felder binnen weniger Sekunden.

Wie sich herausstellte, ist diese Funktion aber nur für Datenbanken anwendbar.

Bei Shapefiles als Datengrundlage versagt diese Funktion (wahrscheinlich, weil intern eine SQL-Anweisung benutzt wird, die nur bei Datenbanken Anwendung findet).

Für Shapefiles habe ich die Funktion GimmeUniqueValuesFromShape implementiert.

In der Funktion war ich gezwungen (mangels Alternativen), mit einem Cursor-Objekt zu arbeiten, das jedoch mit einem Shapefile als Datengrundlage bessere Ergebnisse er-zielt. Die Unique Value-Listen für zwei Felder wurden immerhin innerhalb von 5 Minu-ten erzeugt.

II. Entwicklungsprozess der XML-Verarbeitung:

Erwähnenswert ist ebenfalls der Entwicklungsprozess der XML-Verarbeitung meines Programms. Die Herausforderung hierin bestand in der Einarbeitung in die spezielle Objektbibliothek der .NET XML-Objekte in mehreren Schritten.

Der erste Schritt bestand darin, die XML-Grundfunktionen zu implementieren. Etwas später entdeckte ich durch die SLD-Tests, dass der SLD-Code nur dann interpretiert werden konnte, wenn er die zugehörigen Namensraum-Kürzel enthielt.

Deshalb musste im nächsten Schritt eine Möglichkeit gefunden werden, die SLD-Elemente mit Namespace-Prefixes zu schreiben. Dies konnte durch die überladene .NET XML-Methode create erreicht werden, der man zusätzlich zum XML-Element den Namespaceprefix und die Namespace-URL übergibt.

Nachdem alle SLD-Elemente durch Namensraum-Kürzel ausgezeichnet waren, konnte


jedoch die Methode matches des XPathNavigator keine XPath-Ausdrücke mehr aus-werten, da der Navigator alleine nicht mit XML-Tags inklusive Namensraumkürzeln umgehen kann. Die Methode matches war leicht zu handhaben. Sie verglich den XPath-Ausdruck des aktiven Knotens mit dem aus der Konfiguretionsdatei ausgelese-nen XPath-Ausdruck und gab einen Bool'schen Wert, der die Übereinstimmung der Ausdrücke repräsentierte, zurück.

Leider musste für diese Methode aus o.g. Grund ein Ersatz gefunden werden (und das bedeutet meist, einen Umweg zu gehen).

Die Lösung des Problems wurde in Kap. 5.1.1.4 schon angesprochen: Man generiert mit der Methode selectNodes der Klasse XMLNode eine Liste aller mit dem XPath-Ausdruck übereinstimmenden Knoten, nimmt davon den letzten Knoten und verfährt weiter wie unter 5.1.1.4.

Diese Methode funktionierte aber nur innerhalb eines sog. "XSLT-Kontext". Der .NET- NamespaceManager bietet diesen XSLT-Kontext. Er kann Prefixes und URLs verwal-ten und wird dem aktuellen XPathNavigator-Objekt zugewiesen.

III. Die Navigationsfunktion:

Eine weitere Herausforderung bestand in der Entwicklung der Navigationsfunktion für die SLD.

Weil mir kein vergleichbarer Algorithmus zur Verfügung stand, musste ich ein Prinzip entwickeln, anhand dessen es möglich ist, XML-Dokumente zu schreiben, deren Struk-tur nicht vorab im Programmcode festgelegt sein darf.

Der Entwicklungsprozess begann bei grundlegenden Konzepten der Struktur. Wichtig war hierbei die Definition des Problems vorab, denn eine Verbalisierung des Problems ist oft der erste Schritt zu einer Lösung.

Der nächste Schritt lag im Finden der richtigen Technologie zur Lösung der Aufgabe.

Die Technik hierfür wurde weitestgehend in Kap. 5.1.1.4 behandelt.

5.2 Die SLD Tests

In diesem Kapitel können nur die Ergebnisse der Tests wiedergegeben werden. Die Zwischenschritte bis zum Erreichen der endgültigen Konfigurationen sind hier nicht Gegenstand der Betrachtung.

Wie sich bei den Tests herausstellte, gibt es gravierende Unterschiede bei der Unter-stützung von SLD-WMS durch die beiden Testserver. Die Unterschiede werden in den nachfolgenden beiden Unterkapiteln behandelt.

Wie vorab schon bemerkt, konzentrierten die Tests sich auf die Darstellung der GÜK 300, weshalb dem Testen von Flächenfüllungen die weitaus größte Aufmerksamkeit zuteil wurde.

Im Laufe der Tests hat sich eine bestimmtes SLD-Standardgerüst bewährt, das am folgenden Ausschnitt einer SLD gezeigt werden soll:


Abb. 29 Standardgerüst einer SLD

Grundsätzlich werden von dem Programm NamedLayer erzeugt, weil UserLayer von den meisten Mapservern noch nicht unterstützt werden. Wenn UserLayer unterstützt würden, wäre man selbst auf eine Layerdefinition in der Konfigurationsdatei des Mapservers nicht mehr angewiesen. Das Name-Element ist bei NamedLayern obligato-risch.

UserStyle hingegen wird von den meisten Mapservern unterstützt (beide Testserver unterstützen UserStyle). Der Stylename (Name) ist nur relevant, wenn man sich von anderer Stelle diesen Style noch einmal "leihen" möchte (d.h. von einer anderen SLD oder Konfigurationsdatei aus darauf zugreifen). In dem Dokument, das darauf referen-ziert, wird dieser Style dann allerdings zum NamedStyle. Wenn das der Fall ist, muss der Stylename einzigartig in der SLD sein.

Der FeatureTypeStyle signalisiert, dass man sich ab jetzt auf der Ebene der Features bewegt.

Die nachfolgenden Elemente mit dem Namespaceprefix "ogc" stammen alle aus der Filter Encoding-Spezifikation.

Die Elemente Rule und Filter sowie die Filteroperatoren wurden in Kap. 3.5.1 schon ausführlich behandelt. Gesagt sei lediglich, dass PropertyName das zu klassifizierende Feld bestimmt, während Literal den Feldwert bezeichnet, der dieser Klasse entspricht. Werte werden in der OGC Filter Encoding-Spezifikation (anders als in der SLD-Spezifikation) in Literal-Elemente eingeschlossen (s. Abb. 29)

Das Element Title entspricht dem Label in ArcMap. Es wird bei der Bildung von Legen-


den herangezogen zur Bezeichnung des Legendenelements.

Das Element Fill leitet alle Flächenfüllungen ein. In der Abb. 29 ist lediglich eine voll-farbige weiße Flächenfüllung definiert.

Stroke bezeichnet prinzipiell eine Linie. Als Kindelement von PolygonSymbolizer defi-niert es die Flächenumrandung.

Die unterschiedlichen CssParameter sind dem SVG/CSS-Standard entliehen und um-schreiben die graphische Formatierung von Features. Die Parameter werden durch ihre Name-Eigenschaften spezifiziert. In der Abb. 29 sind fill (Flächenfarbe), stroke (Linienfarbe), Stroke-width (Linienbreite) und die opacity-Eigenschaft beider Feature-klassen, die jeweils für die Transparenz steht, aufgeführt.

5.2.1 Test mit dem UMN Mapserver

Bei den SLD-Tests hat der UMN-Testserver besser abgeschnitten als ArcIMS. Mit ihm sind komplexere Flächenfüllungen sowohl auf Vektorbasis als auch auf Rasterbasis möglich.

Abb. 30 Punktfüllung in SLD mit transparentem Hintergrund

Abb. 30 zeigt den Ausschnitt aus einer SLD, die eine Flächenfüllung generiert, wie sie in dem Kartenausschnitt links daneben zu sehen ist.

Das entscheidende Element in dem SLD-Ausschnitt ist GraphicFill. Damit werden alle nachfolgenden Füllelemente für Polygone (sowohl die vektororientierten als auch die Bitmap-Füllungen) eingeleitet.

Das einzig mögliche Kindelement für GraphicFill ist Graphic. Die einzig möglichen Kindelemente für Graphic sind ExternalGraphic und Mark. Mit ExternalGraphic wird die Flächenfüllung über ein externes referenziertes Bitmap eingeleitet.

Die Tatsache, dass Mark (also Punkt) neben ExternalGraphic die einzige Möglichkeit für vektororientierte Füllmuster darstellt, hat Konsequenzen für die Darstellungsband-breite von Flächenfüllungen mit SLD:


5.2.1.1 Vektorbasierte Symbolisierung

In ArcMap gibt es zwei Arten von Flächenfüllungen, die es in SLD umzusetzen gilt: Punktfüllungen mit transparentem oder farbigem Hintergrund und Flächenschraffuren mit farbigem oder transparentem Hintergrund.

Punktfüllungen in SLD:

In Abb. 30 wurde eine einfache vektorbasierte Punktfüllung erzeugt. Ein mögliches Kindelement des Elements Mark ist WellKnownName. WellKnownNames sind SVG60 Elementar-Graphiken, die für WMS-kompatible Mapserver als vektorbasierte "Grund-ausstattung" mitgeliefert werden:

Graphik SLD-Syntax Unterstützt v. UMN

Kreis circle ja

Dreieck triangle ja

Kreuz cross ja

Stern star ja

X x ja

Quadrat square nein

Pfeil arrow nein

Tab. 8 SVG-Graphiken WellKnownNames

In Abbildung 30 wurde auf Grundlage des WellKnownNames star eine rote sternförmi-ge Füllung geschaffen. Zwei Dinge fallen dabei auf:

1. die Symbole scheinen "aneinanderzustoßen"

2. die Punktfarbe wird über die Farbe der Flächenfüllung definiert

Punkt 1 kann damit erklärt werden, dass das Symbol skriptintern auf die Größe der Bounding-Box geclippt61 wurde; denn unabhängig von der Größe der Symbole liegen diese an ihren "Minimum enclosing rectangles" aneinander.

Punkt 2 verdeutlicht, dass mit einer Symboldefinition allein keine graphische Flächen-füllung auf einem farbigen Untergrund realisierbar ist: Es gibt keine Möglichkeiten für die Farbdefinition des Hintergrunds!

Um graphische Flächenfüllungen auf einem farbigen Untergrund zu realisieren, muss

60 SVG: Scalable Vector Graphics ist ein durch das W3C definierter XML-Standard zur Beschreibung zweidimensionaler Vektorgraphiken. Neben stu-fenloser Skalierbarkeit sind Filtereffekte wie z.B. Schattenwurf, Be-leuchtung, Weichzeichnung oder Verzerrung möglich.

61 [Wiki], Eintrag: In der Computergraphik spricht man von Clipping, wenn Figuren auf einen bestimmten Bereich begrenzt werden sollen.


man zwei oder mehr Symbole "übereinanderlegen".

In Abb. 31 ist der bekannte Kartenausschnitt samt zugehöriger SLD dargestellt. Hier wurden zwei Polygonsymbole übereinandergelegt (ähnlich den Multilayersymbolen in ArcMap).

Das SLD-Dokument wird von oben nach unten verarbeitet. Bei einem Rendering mit dem Z-Buffer-Algorithmus muss das Symbol, das als oberstes abgebildet werden soll, weiter unten im Dokument liegen, damit es später verarbeitet und gerendert wird (s. Abb 31).

Abb. 31 2 Polygonsymbole in SLD übereinandergelegt

Wie in der Erläuterung zu Abb. 29 schon erwähnt, erzeugt das Element Stroke inner-halb von PolygonSymbolizer die Flächenumrandung. Für die Darstellung der graphi-schen Flächenfüllung hat das Element keine Relevanz.

Schraffuren in SLD:

Im Kapitel 5.2.1 wurde dargelegt, warum in SLD z.Zt. keine "echte" Linienschraffur auf Vektorbasis möglich ist (das Element Graphic kennt z.Zt. nur Mark und External-Graphic als Kindelemente – keine Linie).

Um trotzdem eine deutliche Abgrenzung der schraffierten Klassen zu anderen Klassen zu bewerkstelligen, habe ich mich eines "Tricks" bedient:


Man nehme eine quadratische Symbolfläche mit einem gleichschenkligen Kreuz als Symbol, dessen Schenkel bis an die Grenzen der Symbolfläche stoßen (in SLD als Vektorpunktsymbol cross). Legt man diese Symbole nun aneinander, ergibt sich eine durchgehende Linie:

UND ERGIBT

Wenn man sich nun eine ganze Fläche damit ausgefüllt vorstellt, ergibt sich eine Kreuzschraffur wie in Abb. 32:

Abb. 32 Senkrechte Kreuzschraffur

Statt dem Kreuz als Markersymbol kann man auch das X benutzen, was in der resultie-renden Karte eine schräge Kreuzschraffur erzeugt:

Abb. 33 Schräge Kreuzschraffur


Diese Variante eines Schraffurersatzes war möglicherweise von den SLD-Entwicklern so geplant (als Übergangslösung, bis eine korrekte Schraffur implementiert werden kann).

Die Lösung ist zunächst nur gültig für den UMN-Mapserver, da die Art, wie ein Symbol gerendert wird, abhängt von der Implementierung der Rendereralgorithmen des jewei-ligen Mapservers.

Anmerkung:

Es gibt jedoch für den UMN-Mapserver eine Einschränkung, die aus den Symbolen "unechte" Multilayersymbole macht:

Laut [OGS], 78, sind die Symbolizer-Elemente als Kindelemente von Rule "unboun-ded"62. Das bedeutet, dass beliebig viele Symbole der gleichen Featureklasse zu ei-nem Multilayersymbol übereinander gelegt werden dürfen.

Der UMN-Mapserver ist jedoch nicht in der Lage mehr als zwei Symbollayer zu ver-arbeiten, da sonst ein Skriptfehler entsteht. Folgende Server-Fehlermeldung wird bei drei (oder >3) übereinanderliegenden Symbolen generiert:

“Internal Server Error – The server encountered an internal error or misconfiguration and was unable to complete your request”

Diese Einschränkung des UMN-Mapservers gilt für alle Multilayersymbole- nicht nur für Flächenfüllungen. Deshalb wurden von mir für die Umsetzung im Programm (wie in Kap. 5.1.2 schon angemerkt) Multilayersymbole z.Zt. auf zwei Symbollagen be-schränkt.

Durch die Kombination zweier Symbole mit WellKnownNames kommt es zu interes-santen Effekten, wie Abb. 34 verdeutlicht:

Abb. 34 2 SVG-Grundgraphiken übereinander

62 Angaben in den OGC-Spezifikationen (Schema) bzgl. der Relationen. In einer 1:n- Notation entspricht das Attribut "unbounded" der Relation "n".


Leider ist aus o.g. Gründen nicht möglich, hier einen vollflächigen Hintergrund zu gene-rieren, da hierzu mindestens drei Symbollagen notwendig wären.

Liniensymbole in SLD:

Die Liniensymbole wurden von mir in Hinsicht auf Unterstützung ihrer CssParameter (stroke und stroke-width) getestet:

Abb. 35 Liniensymbol mit angepassten CssParameter

Auch hier besteht die Möglichkeit, zwei Symbole übereinander zu platzieren:

Abb. 36 2 übereinanderliegende Liniensymbole

Gestrichelte Linien sind über den CssParameter stroke-dasharray möglich (in ArcMap: CartographicLineSymbol). Die einzelnen Bestandteile des Strichmusters werden in einem leerzeichenseparierten Array übergeben. Dabei steht der erste Wert immer für die Strichlänge und der darauffolgende Wert für die Leerstelle hinter dem Teilstrich. Es sind auch komplizierte Strichmuster möglich (abhängig vom übergebenen Strich-


Array). Wichtig dabei ist, dass die Anzahl der übergebenen Parameter gerade ist. Im nachfolgenden Beispiel der Abb. 37 wurde eine Linie mit einem Segment von 10 Punk-ten, einer Leerstelle von 5 Punkten, einem Segment von 5 Punkten und einer Leerstel-le von 10 Punkten erstellt:

Abb. 37 Strichlierte Linie

Punktsymbole in SLD:

Die Umsetzung von Punktsymbolen in SLD wurde ebenfalls getestet. Ihre Definition in SLD ist analog zu der von LineSymbolizer und PolygonSymbolizer. Auch hier können zwei Symbole übereinandergelegt und die CssParameter wie Farbe und Punktgröße variiert werden.

Von einer Darstellung wird hier abgesehen.

Der CssParameter opacity (Transparenz) wird für keines der Symbole vom UMN-Mapserver unterstützt. Er wurde dennoch von mir im Programm eingebaut, da die Möglichkeit der Unterstützung durch einen anderen Mapserver gegeben ist.

5.2.1.2 Flächenfüllungen mit Bitmaps

Bitmaps bieten derzeit die interessanteste Möglichkeit der Symbolisierung von Flä-chenfüllungen (natürlich ist ebenfalls die Symbolisierung von Linien- und Punktsymbo-len möglich).

Durch die Benutzung von Bitmaps zur Symbolisierung ergeben sich zwei Vorteile:

1. die Möglichkeit zur "freien" Symbolwahl

2. der Symbolabstand ist "frei" wählbar

Im Gegensatz zu vektorbasierten Punktsymbolen, die "aneinanderstoßen" (wie im vori-gen Kapitel angemerkt), weil sie auf ihre Bounding-Boxes geclippt wurden, kann bei Bitmaps der Abstand des Symbols zum Symbolflächenrand variiert werden.

Punkt 2 gilt jedoch strenggenommen nur für den UMN-Mapserver, da die Möglichkeit besteht, dass jeder Map-Server die Symbole etwas unterschiedlich darstellt, und auch


Punktsymbole anders clippt als der UMN-Mapserver.

Im Folgenden werde ich mich auf den Code aus Abb. 38 beziehen. Da sich in allen nachfolgenden Tests lediglich der Bitmap-Name in der URL verändert, wird für alle weiteren Beispiele auf eine Darstellung des SLD-Codes verzichtet.

Abb. 38 Der SLD-Code zur Darstellung von Bitmap-Flächenfüllungen

Auch hier sind es die Elemente GraphicFill und Graphic, die eine Flächenfüllung über ein graphisches Element einleiten. ExternalGraphic signalisiert, dass hier eine Bitmap außerhalb der SLD eingebunden wird.

Mit OnlineResource werden alle Parameter, die für eine Verbindung zu der gewünsch-ten Ressource benötigt werden, bereitgestellt. Das Attribut xlink:type="simple"63 be-sagt, dass es sich hierbei um einen einfachen Verbindungstyp mit URL handelt. Die URL selbst wird in xlink:href übergeben. Der Wert von xlink:href muss eine gültige URL sein. Absolute oder relative Maschinen-Dateipfade werden hier nicht akzeptiert. Au-ßerdem müssen die Bitmaps, die zur Darstellung benutzt werden sollen, in einem Ver-zeichnis abgelegt werden, auf das der Webserver zugreifen kann.

Mit dem Tag Format wird das Format der Bitmap spezifiziert, wobei derzeit GIF, JPEG, PNG und SVG unterstützt werden.

Der Tag Size wird derzeit nicht von UMN-Mapserver unterstützt, d.h. die absolute Grö-ße der Bitmap in Pixeln ist der einzige Parameter, der über Darstellungsgröße des Ra-stersymbols in der Karte entscheidet.

Für die Darstellung wurden quadratische Bitmaps von 30x30 Pixeln Größe verwendet.

Die folgenden Abbildungen zeigen auf der linken Seite die Ausgangsbitmap und auf der rechten Seite die resultierende Karte:

63 [Wiki], Eintrag: XLink ist eine attributbasierte Syntax zur Definition von Links in XML-Dokumenten. Ein XLink kann eine Verbindung von einem Punkt A zu einem Punkt B sein (ähnlich dem aus HTML bekanntem Hyper-link-Element <a>). Sie können jedoch auch Dokumente in zwei Richtungen verbinden (das heißt von A nach B und ebenso zurück).


Punktfüllungen:

Abb. 39 Bitmapgenerierte Punktfüllung

In der nächsten Abbildung wird die Schwachstelle der Darstellung von Karteninhalten durch Bitmaps verdeutlicht:

Abb. 40 Bitmapgenerierte Punktfüllung in Übersichts-Zoomstufe

Das rote Rechteck in der Abb. 40 symbolisiert den Ausschnitt von Abb. 39. Es ist deut-lich erkennbar, dass die Bitmap ihre Größe bei einem kleineren Maßstab derselben Karte beibehält. Ab einer gewissen Übersichts-Zoomstufe sind die Symbole für kleine Flächen nicht mehr erkennbar. Aus diesem Grund wurden von mir mit den Max- und MinScaleDenominator-Elementen (vgl. Kap. 5.1.1.1 und 5.2.1.3) die Maßstabsbegren-zungen für den Anzeigemaßstab der Karte in das Programm implementiert.


Schraffuren:

Im Folgenden wurden horizontale, vertikale und Schrägschraffuren von mir getestet. Die mit Punktfüllungen gemachten Erfahrungen bzgl. Skalierbarkeit gelten in der glei-chen Weise für die Schraffuren.

Abb. 41 Bitmapgenerierte Horizontalschraffur

Abb. 42 Bitmapgenerierte Vertikalschraffur


Abb. 43 Bitmapgenerierte Schrägschraffur (fehlerhaft)

Die Schrägschraffur in Abb. 43 ist fehlerhaft. Wenn man die Bitmaps aneinanderlegt, fehlen die Pixel in den Eckbereichen, wo der Schraffurstreifen anstößt.

Diese Besonderheit der Schrägschraffur gilt natürlich nur für Schraffurstreifen mit einer Breite > 1 Pixel.

Abb. 44 Bitmapgenerierte Schrägschraffur (korrekt)

Die korrigierte Schraffur beinhaltet eine Bitmap, welche die fehlenden Teile des Strei-fens in den dem Streifen orthogonal gegenüberliegenden Ecken enthält.

Wenn Bitmaps für Flächenfüllungen zukünftig automatisch generiert werden sollen, muss die Implementierung dieser Eigenheit berücksichtigt werden.


5.2.1.3 Weitere getestete SLD-Elemente:

Des Weiteren wurden von mir die Maßstabsbegrenzungen sowie der Vergleichsopera-tor PropertyIsBetween und der logische Operator AND getestet:

Die Maßstabsbegrenzungen:

Wie im vorigen Kapitel schon kurz erwähnt, gibt es sowohl für vektorbasierte als auch für Bitmap-Darstellungen Grenzwerte des Maßstabs, ab denen der Karte kein Informa-tionsgehalt mehr entnehmbar ist. Diese Grenzwerte können durch die Elemente Min- und MaxScaleDenominator gesetzt werden.

Abb. 45 Die Maßstabsbegrenzer in SLD

Min- und MaxScaleDenominator sind Kindelemente des Elements Rule und treffen eine Aussage darüber, ab (und bis zu) welchem Maßstab diese Regel angewandt wer-den darf. Als Kindelemente von Rule sind sie auf Symbolebene gültig. Damit kann für jedes Symbol ein eigener Anzeige-Maßstabsbereich definiert werden (in meinem Pro-gramm ist derzeit ein Maßstabsbereich für alle Symbole auswählbar).

Die Denominatoren werden von UMN-Mapserver unterstützt.

Der Vergleichsoperator PropertyIsBetween:

Zur Einteilung der Daten in Wertebereichsklassen (in ArcMap: Quantities; in ArcOb-jects umgesetzt durch ClassBreaksRenderer) ist ein neuer Vergleichsoperator vonnö-ten: PropertyIsBetween, der wie PropertyIsEqualTo ebenfalls aus der Spezifikation des Filter Encoding von OGC stammt.

Abb. 46 Der Vergleichsoperator PropertyIsBetween


Der Operator ist ein Nachkomme von Filter, und beinhaltet die Untergrenze des Werte-bereichs (LowerBoundary) und die Obergrenze (UpperBoundary).

Abb. 47 Klassifizierung mit dem Vergleichsoperator PropertyIsBetween

Der linkeTeil der Abb. 47 zeigt einen Auschnitt aus der ArcMap-Originalkarte, die über Quantities in fünf Wertebereiche klassifiziert wurde.

Der rechte Teil der Abbildung zeigt die Darstellung der Karte auf dem UMN-Mapserver (in einer anderen Projektion), die mit einer SLD symbolisiert wurde, welche auf einer Klassenbildung mit PropertyIsBetween beruht. Wie zu sehen ist, unterstützt der UMN-Mapserver den Operator PropertyIsBetween.

Der logische Operator AND:

Zur Klassifizierung nach eindeutigen Werten (in ArcMap: Categories; in ArcObjects umgesetzt durch UniqueValueRenderer) eines Feldes wird der Vergleichsoperator PropertyIsEqualTo benutzt. Wenn nicht nur nach den eindeutigen Werten eines, son-dern mehrerer Felder klassifiziert werden soll, werden mehrere Vergleichsoperatoren mit dem logischen Operator AND verkettet.

Abb. 48 Der logische Operator AND


Wie seine Eltern- und Kindelemente ist das Element AND Bestandteil der OGC Filter Encoding-Spezifikation.

Dieses Element (und sein Schwesterelement OR) besitzt eine spezielle Eigenart: Durch seinen Einsatz verschieben sich die ansonsten fixen Verwandschaftsverhältnis-se der eingeschlossenen Elemente. In der Folge davon stehen die Kindelemente hier-archisch auf einer anderen Stufe als zuvor. Will sagen: das Element PropertyIsEqualTo stand bisher hierarchisch auf der Ebene x im SLD-Dokument, seine Kindknoten auf der Ebene x+1 usw. Nach Einsatz der Elemente AND oder OR steht das Element Proper-tyIsEqualTo hierarchisch auf der Ebene x+1 und seine Kindknoten auf der Ebene x+2 usw.

Dies hat Konsequenzen für die Navigationsfunktion des Programms ArcGIS-map to SLD Converter, da dieses die Zuordnung der einzelnen Elemente ebenenweise vor-nimmt. Deshalb müssen in der Konfigurationsdatei die XPath-Ausdrücke für alle mögli-chen Nachfolgeelemente des Operators sowohl für den Fall mit vorangestelltem AND als auch ohne das AND aufgeführt sein.

Abb. 49 Klassifizierung nach Unique Values, many fields

Auch in dieser Abbildung befindet sich links ein Ausschnitt aus der Originalkarte in ArcMap, die nach zwei Feldern mit dem Befehl "Unique Values, many fields" klassifi-ziert wurde.

Auf der rechten Seite der Abbildung 49 ist die Darstellung der Karte mithilfe einer SLD auf dem UMN-Mapserver zu sehen. Die Klassifizierung wurde hier in der beschriebe-nen Weise mit dem AND-Operator vorgenommen und korrekt von dem Map-Server wiedergegeben.

Zum Abschluss des Kapitels 5.2.1 folgt eine Gegenüberstellung von Ausschnitten der GÜK 300. Die erste Abbildung ist aus der ArcMap-Originalkarte, die andere Abbildung ist mit einer programmgenerierten SLD auf dem UMN-Mapserver erzeugt:


Abb. 50 Ausschnitt der GÜK 300 aus der ArcMap-Originalkarte


Abb. 51 Die GÜK 300 auf dem UMN-Mapserver, erzeugt aus einer programmgenerierten SLD

Die Darstellung der Karte aus Abb. 51 wurde mit Vektorgraphik ohne Unterstützung von Bitmaps erzeugt.

Die folgende Tabelle zeigt eine Übersicht der auf dem UMN-Mapserver getesteten E-lemente und Attribute:

SLD-Element unterstützt SLD-Attribut unterstützt

NamedLayer ja

UserLayer nein

NamedStyle ja

UserStyle ja

FeatureTypeStyle ja


Rules ja

Min-, MaxScaleDenominator ja

Filter ja

ElseFilter ja

PropertyIsEqualTo ja

PropertyIsBetween ja

AND ja

PointSymbolizer ja

Fill ja (im Folgenden CssParameter)

fill ja

fill-opacity nein

Size ja

Mark ja

WellKnownName ja

Rotation nein

LineSymbolizer ja

Stroke ja (im Folgenden CssParameter)

stroke ja

stroke-width ja

stroke-opacity nein

stroke-dasharray ja

GraphicStroke ja (s. Stroke)

PolygonSymbolizer ja


fill ja

fill-opacity nein

GraphicFill ja

Graphic ja

ExternalGraphic ja

Tab. 9 Auf UMN-Mapserver in Hinsicht auf GÜK 300-Darstellung getestete Elemente/Attribute

Für eine komplette Auflistung aller SLD-Elemente und deren Unterstützung durch den UMN-Mapserver wird die offizielle UMN-Mapserver-Homepage empfohlen. Dort gibt es ein spezielles Kapitel zur SLD-Unterstützung (SLD HOWTO 4.6 - s. Linkverzeichnis).


5.2.2 Test auf der ArcIMS-Plattform

Alle für den UMN-Mapserver durchgeführten Tests wurden ebenso für den ArcIMS umgesetzt. Da wesentlich weniger SLD-Funktionen unterstützt sind als bei dem UMN-Mapserver, wird an dieser Stelle auf eine umfangreiche Darstellung von Abbildungen verzichtet. Die folgende Tabelle zeigt die von mir auf dem ArcIMS getesteten Elemente und Attribute. Sie stellt keine vollständige Übersicht der SLD-Tauglichkeit von ArcIMS dar, sondern konzentriert sich hauptsächlich auf die Elemente, die zur Darstellung der GÜK 300 wichtig sind:

SLD-Element unterstützt SLD-Attribut unterstützt

NamedLayer ja

UserLayer nein

NamedStyle ja

UserStyle ja

FeatureTypeStyle ja

Rules ja

Min-, MaxScaleDenominator ja

Filter ja

ElseFilter ja

PropertyIsEqualTo ja

PropertyIsBetween ja

AND ja

PointSymbolizer ja

Fill nein (im Folgenden CssParameter)

fill nein

fill-opacity nein

Size nein

Mark nein

WellKnownName nein

Rotation nein

LineSymbolizer ja

Stroke ja (im Folgenden CssParameter)

stroke nein

stroke-width nein

stroke-opacity nein

stroke-dasharray nein


GraphicStroke nein (s. Stroke)

PolygonSymbolizer ja


fill ja

fill-opacity nein

GraphicFill nein

Graphic nein

ExternalGraphic nein

Tab. 10 Auf dem ArcIMS in Hinsicht auf GÜK 300-Darstellung getestete Elemente/Attribute

Welche Konsequenzen hat diese Unterstützung für die Darstellung von Karten?

� Es können die Klassifizierungen "Simple Symbol", "Unique Values" und "Class Breaks" vorgenommen werden.

� Der Anzeigemaßstab kann begrenzt werden.

� Die Darstellung von Linien ist sehr begrenzt (keine Linienfarbe, keine Strichstär-ke, keine strichlierten Linien).

� Die Elemente Graphic und GraphicFill sind für Punkte, Linien und Polygone nicht unterstützt. D.h. es können weder Füllmuster auf Vektorbasis noch auf Raster-basis angezeigt werden. Lediglich vollfarbige Flächenfüllungen sind mit dem ArcIMS derzeit möglich.

Woran liegt es, dass der ArcIMS wesentliche Darstellungselemente von SLD nicht be-herrscht?

Um diese Frage zu beantworten, möchte ich einen Vergleich aufstellen zwischen ei-nem proprietären Kartendienst, der auf herkömmliche Weise für den ArcIMS aufgesetzt wurde und dem SLD-generierten OGC-WMS.

Zu diesem Zweck sind nachfolgend zwei Abbildungen der GÜK 300 (Ausschnitte) auf dem ArcIMS dargestellt. Die erste Karte wurde als OGC-WMS mit einer programmge-nerierten SLD erstellt, während die nächste Karte als proprietärer Kartendienst gene-riert wurde:


Abb. 52 SLD-WMS für die GÜK 300 auf dem ArcIMS

(Die SLD, mit der die Karte aus Abb. 52 generiert wurde, ist dieselbe, welche auch zur Darstellung der GÜK 300 auf dem UMN-Mapserver benutzt wurde.)

Zum Vergleich der proprietäre ArcIMS-Kartendienst auf Basis der AXL-Konfigurationsdatei:


Abb. 53 Proprietärer Kartendienst der GÜK 300 auf dem ArcIMS

Zu beachten sind hier die Unterschiede zum SLD-WMS in der Flächenfüllung und in den Linieneigenschaften (zum Vergleich sind Ausschnitte aus der ArcMap-Originalkarte und die SLD-generierte Darstellung auf dem UMN am Ende des vorigen Kapitels zu finden). Hier sind Flächenschraffuren auf Vektorbasis und Flächenfüllungen auf Rasterbasis möglich. Das bedeutet, dass der ArcIMS diese Möglichkeiten bietet.

Beide Karten werden von demselben Programm erzeugt und liefern dennoch wesent-lich unterschiedliche Ergebnisse. Die logische Folgerung daraus ist, dass nicht ArcIMS dafür verantwortlich ist, dass so wenig der SLD-Funktionalität umgesetzt wird, sondern ein anderes Modul.

Die Vermutung liegt nahe, dass der WMS-Connector, der benutzt wird, um den ArcIMS OGC-kompatibel zu machen, dafür verantwortlich zeichnet. Hier wird die Karteninfor-mation von OGC-Syntax in AXL übersetzt. Durch diese Schnittstelle gehen wesentliche Informationen zur Kartendarstellung verloren. Wenn mit einer neuen Version des WMS-Connectors die SLD-Unterstützung ausgebaut werden sollte, könnten die Dar-stellungsmöglichkeiten von ArcIMS auch mit SLD ausgeschöpft werden.

6 Zusammenfassung und Ausblick -106-

6 Zusammenfassung und Ausblick

Meine Diplomarbeit wurde mit dem Ziel erstellt, die Arbeit mit internetbasierten Karten-diensten zu erleichtern.

Das Programm "ArcGIS-map to SLD Converter" nimmt dem Benutzer die aufwendige Symbolisierung ab, indem es vorliegende ArcGIS-Karten auf ihre Symbole analysiert und die gewonnenen Daten in der OGC-Symbolisierungsvorschrift SLD ausgibt. Diese Vorschrift kann auf jedem OGC-konformen Kartenserver benutzt werden, um die ana-lysierte Karte mit einem WMS im Internet zu veröffentlichen.

Weiterhin habe ich mit diversen Tests auf zwei unterschiedlichen Test-Kartenservern die Möglichkeiten von SLD erprobt. Diese sind zwar augenblicklich noch einge-schränkt, aber dennoch in der Praxis schon nutzbar.

SLD ist noch eine junge Technologie. Aber die Möglichkeiten werden zukünftig immer vielfältiger, je weiter die Spezifikation ausgebaut wird. Dass dies geschehen wird, ist absehbar, denn der Markt für internetbasierte (Geo-) Informationssysteme ist am Ex-pandieren und die Nachfrage nach verlässlichen (standardisierten) Technologien, die diesen Markt bedienen, ist groß.

Wenn die Spezifikation mehr Möglichkeiten bietet, wird auch die Unterstützung von SLD-WMS durch Firmen und Organisationen, welche Kartenserver und internetbasier-te GIS-Systeme anbieten, wachsen. Denn dieser Prozess ist iterativ und entwickelt, einmal initiiert, eine Eigendynamik.

Wenn die Technologie etabliert und umfangreiche Unterstützung der Syntax durch die Kartenserver erreicht ist, wird es vielleicht möglich sein, gänzlich auf die Erstellung von Konfigurationsdateien für Kartendienste zu verzichten.

Die Möglichkeiten dazu sind derzeit mit dem SLD-Element UserLayer schon vorhan-den. Über dessen Kindelement RemoteOWS (und zugehörige Parameter) können die Geodaten mit eingebunden werden, ohne den Umweg über eine Konfigurationsdatei nehmen zu müssen.

Ein Programm wie das von mir erstellte ArcGIS-map to SLD Converter ist, einmal ab-geschlossen, kein unveränderliches "Programmzeilengrab". Es ist dynamisch und wandelbar wie die SLD-Spezifikation, die ihm zugrunde liegt.

Es können beispielsweise nach einer Erweiterung der SLD-Spezifikation Renderer, die bisher ignoriert wurden, implementiert werden. Eventuell ist in Zukunft eine Darstellung von Dichteverteilungen mit SLD möglich. Unter den in Kap. 5.1.2 genannten nicht im-plementierten Renderern könnte dann beispielsweise der DotDensityRenderer imple-mentiert werden.

Es gibt jedoch auch Möglichkeiten, die derzeit schon umsetzbar sind:

Kleinere Funktionen wie die Generierung von gestrichelten Linien oder auch größere Funktionen wie die der Unterstützung von Bitmaps. - Möglicherweise können Symbole

6 Zusammenfassung und Ausblick -107-

in ArcMap geclippt (quasi abfotographiert) und danach in die SLD-Struktur eingefügt werden. Dies würde die Fähigkeiten des Programms wesentlich erhöhen.

Die Elemente TextSymbolizer und RasterSymbolizer der aktuellen SLD-Spezifikation haben in dieser Arbeit keine Betrachtung gefunden, da der Fokus bei der Darstellung der drei Featureklassen Punkt, Linie und Polygon lag. Ebenfalls keine Betrachtung fand die Generierung von Legenden zur Karte.

Laut [OGS], 61, wird die Erzeugung von Kartenlegenden entweder clientseitig mittels JavaScript durchgeführt, oder serverseitig mit der GetLegendGraphic-Operation, die ebenfalls wie z.B. die GetMap-Operation einen WMS-Request darstellt. Im ersten Fall spielt SLD keine Rolle. Im Falle der serverseitigen Legendenerzeugung bietet SLD ein Element namens LegendGraphic, das jedoch laut [OGS], 63, nur eine untergeordnete Rolle bei der Erzeugung von Legenden-Graphiken spielt (es bietet eine Referenz für Darstellungsgraphiken von z.B. digitalen Geländemodellen).

SLD schafft die Grundlagen für eine Vereinheitlichung der Darstellungsmöglichkeiten von Karten im Internet.

Mit der Diplomarbeit konnte u.a. bewiesen werden, dass SLD schon mit der aktuellen Spezifikation in der Lage ist, auch komplex symbolisierte Karten nach kartographi-schen Gesichtspunkten zufriedenstellend darzustellen.

Verzeichnisse -I-

Verzeichnisse

Verzeichnisse -II-

Literaturverzeichnis

[APS] Frank Press, Raymond Siever. Allgemeine Geologie. Hrsg. Spektrum Akademischer Verlag GmbH, Heidelberg, Berlin, Oxford. Würzburg: Konrad Triltsch, Druck- und Verlagsanstalt GmbH

[BUW] Buhmann/Wiesel. GIS Report 2004. Hrsg. Bernhard Harzer Verlag GmbH, Karlsruhe. Rastatt: Greiserdruck GmbH, 2005

[DUD] Duden. Das große Fremdwörterbuch. Hrsg. Wissenschaftlicher Rat der Dudenredaktion. Mannheim: Dudenverlag, 2000

[EAO] Div. Exploring ArcObjects. . Hrsg. ESRI. USA: ESRI Press, 2002

[GAG] Tim Ormsby, Eileen Napoleon, Robert Burke, Carolyn Groess, Laura Feaster. Getting to know ArcGIS desktop. Hrsg. ESRI. USA: ESRI Press, 2004

[GAD] Paul-Heinz Düring. Geologisches Arbeiten. Hrsg. Ministerium für Geologie der DDR. Leipzig: VEB Deutscher Verlag für Grundstoffindustrie, 1985

[GAO] Robert Burke. Getting to know ArcObjects. Hrsg. ESRI. USA: ESRI Press, 2003

[GMU] Hans Murawski, Wilhelm Meyer. Geologisches Wörterbuch. Hrsg. Elsevier GmbH. München: Spektrum Akademischer Verlag, 2004, 11. Auflage

[HÖM] Michael Höck, Jochen Manegold. ArcMap Programmierung mit VBA. Hrsg. UISMEDIA Lang & Müller GbR. Legoprint S.p.A., Lavis (TN) 2001

[HVO] Helmut Vonhoegen. Einstieg in XML. Hrsg. Galileo Computing. Bonn: Galileo Press GmbH, 2002

[KKI] Sascha Kersken. Kompendium der Informationstechnik. Hrsg. Galileo Computing. Bonn: Gali-leo Press GmbH, 2003. (Ausgabe: E-Book)

[MAS] Duncan Mackenzie, Kent Sharkey. Visual Basic.NET in 21 Tagen. Hrsg. SAMS. München: Markt und Technik-Verlag 2002

[MIK] Michael Kofler. Visual Basic.NET, Grundlagen, Programmiertechniken, Windows-Anwendungen. Hrsg. Pearson Education. München: Addison Wesley-Verlag, 2002

[OGS] Open GIS Consortium Inc. Styled Layer Descriptor Implemantation Specification. Hrsg. OGC. RefNum. OGC 02-070.; Vers. 1.0.0; Date 2002-08-19; Cat. Proposed OpenGIS® Implementa-tion Specification

[OGW] Open GIS Consortium Inc. Web Map Service Implemantation Specification. Hrsg. OGC. Ref-Num. OGC 01-068r2.; Vers. 1.1.1; Date 2001-11-27; Cat. OpenGIS® Implementation Specifi-cation

Verzeichnisse -III-

Hyperlinkverzeichnis

GDI:

Internationale Geodateninfrastruktur GSDI:

http://www.gsdi.org/

Europäische Geodateninfrastruktur INSPIRE:

http://inspire.jrc.it

Deutsche Geodateninfrastruktur GDI-DE:

http://www.imagi.de/de/gdi_de/f_gdi_de.html

Geodateninfrastruktur des Landes Hessen:

http://www.geoportal.hessen.de

Geodateninfrastruktur des Landes Nordrhein-Westfalen:

http://www.gdi-nrw.org/

Geoportale:

http://www.geoportal.de/geoportal/index.jsp

Standardisierung:

International Organization for Standardization:

http://www.iso.org/iso/en/ISOOnline.frontpage

World Wide Web Consortium:

http://www.w3.org/

Open Geospatial Consortium OGC:

http://www.opengeospatial.org/

Mapserver:

ArcIMS von ESRI:

http://www.esri-germany.de/products/arcims/

http://www.esri.com/software/arcgis/arcims/about/overview.html

Verzeichnisse -IV-

http://downloads.esri.com/support/whitepapers/ims_/arcims4_architecture.pdf

http://www.sourcegraphics.com/giscadsoftware/esri/arcims.html

[UMN] UMN Mapserver:

http://www.umn-mapserver.de/

http://mapserver.gis.umn.edu/data2/wilma/mapserver-users/0402/msg00601.html

http://ms.gis.umn.edu/new_users/msappdiagram/view

http://maptools.org/index.html

deegree:

http://deegree.sourceforge.net/

GeoMedia Web Map von Intergraph:

http://imgs.intergraph.de/

GeoServer und AEDGIS von SICAD:

http://www.aed-sicad.de/pages/produkte/plattformen/aed_gis/geoserver/index.html

SLD:

SLD-Spezifikation (OGC):

http://www.opengeospatial.org/docs/02-070.pdf

SLD HOWTO UMN-Mapserver Homepage:

http://mapserver.gis.umn.edu/doc46/sld-howto.html

Canadian Geospatial Data Infrastructure homepage:

http://www.geoconnections.org

Geo-Connections:

http://www.geoconnections.org/publications/training_manual/e/06/06_03/06-03-01.htm

Geotools:

http://www.geotools.org/

Terrestris Homepage:

http://www.terrestris.de

Verzeichnisse -V-

Terrestris: Praxishandbuch WebGIS mit freier Software:

http://www.terrestris.de/hp/shared/downloads/Praxishandbuch_WebGIS_Freie_Software.pdf

Allgemein:

[GUR] Geoinformatiklexikon der Universität Rostock:

http://www.geoinformatik.uni-rostock.de/lexikon.asp

[ITI] IT-Lexikon:

http://www.it-infothek.de/fhtw/progr_03.html

[SEH] Selfhtml, Stefan Münz:

http://de.selfhtml.org/

[VBN] VB.NET:

http://www.activevb.de/rubriken/kolumne/kol_2/dotnetvsjava.html

[Wiki] Wikipedia online-Lexikon:

http://de.wikipedia.org/wiki/Hauptseite

Verzeichnisse -VI-

Abbildungsverzeichnis

Abb. 1 Verzahnung des ArcIMS mit anderen Modulen (Quelle: Website ESRI

Germany) .....................................................................................................13

Abb. 2 ArcIMS-Architektur: Multi-tiers (Quelle: ESRI.com; s. Hyperlinkvz.) ..............14

Abb. 3 ArcIMS-Architektur: Client/Server-tier (Quelle: ESRI.com; s. Hyperlinkvz.) ...14

Abb. 4 UMN Mapserver-Architektur (Quelle: sourcegraphics; s. Hyperlink-Vz.)........17

Abb. 5 XML-Aufbau (Quelle: OGC, SLD Schema-xsd- Ausschnitt)...........................22

Abb. 6 Inline-SLD (Quelle: OGC, SLD Specification)................................................27

Abb. 7 Die GÜK 300 in 10-facher Verkleinerung ......................................................39

Abb. 8 Ausschnitt aus dem Datenmodell der Geowissenschaftlichen

Übersichtskarte von Hessen 1:300.000 ........................................................40

Abb. 9 Ausschnitt aus der Klassenliste der GÜK300 (Poly) ......................................41

Abb. 10 Symbole der GÜK300 (Poly) .........................................................................42

Abb. 11 Fähigkeiten des UMN-Mapserver..................................................................48

Abb. 12 Verzeichnisstruktur des UMN-Mapserver ......................................................49

Abb. 13 LAN-Aufbau am HLUG (Quelle: HLUG) ........................................................50

Abb. 14 Notwendige ArcIMS Zusatzkomponenten (Quelle: ESRI.com) ......................51

Abb. 15 Ausschnitt aus der GUEK300.axl (Quelle: HLUG).........................................52

Abb. 16 Das Programm "ArcGIS-map to SLD Converter"...........................................54

Abb. 17 Schema Programmstruktur der Applikation "ArcGIS-map to SLD Converter" 55

Abb. 18 Sequenzdiagramm der Applikation "ArcGIS-map to SLD Converter".............57

Abb. 19 Sequenzdiagramm und Struktogramme der Klasse

Analize_ArcMap_Symbols ............................................................................61

Abb. 20 Beispielhafter Codeblock aus Funktion StoreStructUVRenderer ...................63

Abb. 21 Die Datenstruktur des Symbols SimpleFillSymbol: StructSimpleFillSymbol...66

Abb. 22 Die Datenstruktur des Renderers UniqueValueRenderer:

StructUniqueValueRenderer .........................................................................67

Abb. 23 Struktogramme der Klasse Output_SLD .......................................................68

Abb. 24 Erste Elemente der Funktion WriteToSLD in der Klasse OutputSLD.............69

Abb. 25 Entsprechende Elemente in der Konfigurationsdatei

LUT_sld_mapping_file.xml............................................................................69

Abb. 26 Elemente in der resultierenden SLD..............................................................70

Abb. 27 Verzweigung der Funktion GetValueFromSymbolstruct zur Analyse.............72

Abb. 28 Ausschnitt aus der Datei LUT_sld_mapping_file.xml.....................................74

Verzeichnisse -VII-

Abb. 29 Standardgerüst einer SLD.............................................................................84

Abb. 30 Punktfüllung in SLD mit transparentem Hintergrund......................................85

Abb. 31 2 Polygonsymbole in SLD übereinandergelegt..............................................87

Abb. 32 Senkrechte Kreuzschraffur............................................................................88

Abb. 33 Schräge Kreuzschraffur ................................................................................88

Abb. 34 2 SVG-Grundgraphiken übereinander...........................................................89

Abb. 35 Liniensymbol mit angepassten CssParameter...............................................90

Abb. 36 2 übereinanderliegende Liniensymbole .........................................................90

Abb. 37 Strichlierte Linie ............................................................................................91

Abb. 38 Der SLD-Code zur Darstellung von Bitmap-Flächenfüllungen .......................92

Abb. 39 Bitmapgenerierte Punktfüllung ......................................................................93

Abb. 40 Bitmapgenerierte Punktfüllung in Übersichts-Zoomstufe ...............................93

Abb. 41 Bitmapgenerierte Horizontalschraffur ............................................................94

Abb. 42 Bitmapgenerierte Vertikalschraffur ................................................................94

Abb. 43 Bitmapgenerierte Schrägschraffur (fehlerhaft)...............................................95

Abb. 44 Bitmapgenerierte Schrägschraffur (korrekt)...................................................95

Abb. 45 Die Maßstabsbegrenzer in SLD ....................................................................96

Abb. 46 Der Vergleichsoperator PropertyIsBetween...................................................96

Abb. 47 Klassifizierung mit dem Vergleichsoperator PropertyIsBetween....................97

Abb. 48 Der logische Operator AND...........................................................................97

Abb. 49 Klassifizierung nach Unique Values, many fields ..........................................98

Abb. 50 Ausschnitt der GÜK 300 aus der ArcMap-Originalkarte.................................99

Abb. 51 Die GÜK 300 auf dem UMN-Mapserver, erzeugt aus einer

programmgenerierten SLD .........................................................................100

Abb. 52 SLD-WMS für die GÜK 300 auf dem ArcIMS ..............................................104

Abb. 53 Proprietärer Kartendienst der GÜK 300 auf dem ArcIMS ............................105

Verzeichnisse -VIII-

Tabellenverzeichnis

Tab. 1 GetCapabilities-Operationen (* Erforderlich/Optional).....................................10

Tab. 2 GetMap-Operationen (* Erforderlich/Optional; **diese Operationen nur für

SLD-WMS) .....................................................................................................12

Tab. 3 Knotentypen in XML .......................................................................................22

Tab. 4 Objektmodelle der ArcGIS-Kernanwendung (Quelle: ArcGIS Developer

Help) ..............................................................................................................33

Tab. 5 Hauptsymbolarten mit Untersymbolen (Quelle: [HÖM], 599 ff) .......................44

Tab. 6 Eingesetzte Software der ArcIMS-Maschine (Quelle: HLUG) .........................51

Tab. 7 Beispiel Variablennamenskonvention .............................................................56

Tab. 8 SVG-Graphiken WellKnownNames ................................................................86

Tab. 9 Auf UMN-Mapserver in Hinsicht auf GÜK 300-Darstellung getestete

Elemente/Attribute........................................................................................101

Tab. 10 Auf dem ArcIMS in Hinsicht auf GÜK 300-Darstellung getestete

Elemente/Attribute........................................................................................103

Anhang -a-

Anhang

Anhang -b-

Map-Datei des UMN-Testservers

MAP NAME "GUEK300" STATUS ON SIZE 800 800 IMAGETYPE PNG IMAGECOLOR 240 240 240 SHAPEPATH "http://127.0.0.1/htdocs/Maps/Shape" EXTENT 3377854 5450000 3592188 5730000 UNITS METERS PROJECTION "init=epsg:4326" END WEB IMAGEPATH "C:/ms4w/Apache/htdocs/tmp/" IMAGEURL "http://localhost/tmp/" METADATA "wms_title" "GUEK300_POLY" "wms_onlineresource" "http://127.0.0.1/cgi-bin/mapserv.exe?map=C:/ms4w/Apache/htdocs/Maps/GUEK300.map&" "wms_srs" "EPSG:4326" "WMS_FEATURE_INFO_MIME_TYPE" "text/html" END END LAYER NAME "GUEK300_POLY" TYPE POLYGON STATUS ON DATA "Shape/Guek300_Poly.shp" #PROJECTION # "init=epsg:4326" #END METADATA "wms_title" "GUEK300_POLY" "wms_onlineresource" "http://127.0.0.1/cgi-bin/mapserv.exe?map=C:/ms4w/Apache/htdocs/Maps/GUEK300.map&" "wms_srs" "EPSG:4326" "WMS_FEATURE_INFO_MIME_TYPE" "text/html" END CLASS NAME "All Polygones" OUTLINECOLOR 160 160 160 COLOR 255 255 255 SYMBOL 0 END END END

Anhang -c-

Workflow des Programms ArcGIS-map to SLD Converter

Schematischer Programmablauf

Sequentieller Ablauf. Im Wesentlichen 4 Klassen (ohne Validierung)

Aufrufklasse(Motherform)

Analyseklasse(Analize_ArcMap_Symbols) Ausgabeklasse

(Output_SLD)

XML-Funktionsklasse(XMLHandle)

Steuerdatei(LUT_sld_mapping_file.xml)

SLD-Datei

ArcMap

Legende

Programmablauf

Datenströme

Ergebnis

1

2

3

4

5

6

Anhang -d-

UML-Klassendiagramme

Anhang -e-

Anhang -f-

Anhang -g-

LUT XML

<?xml version="1.0" encoding="ISO-8859-1"?>              <LUT> <sldConfiguration> <xmlVersion>1.0</xmlVersion> <sldVersion>1.0.0</sldVersion> <xmlEncoding>ISO-8859-1</xmlEncoding> <Namespaces> <sld>http://www.opengis.net/sld</sld> <ogc>http://www.opengis.net/ogc</ogc> <xlink>http://www.w3.org/1999/xlink</xlink> </Namespaces> </sldConfiguration> <sldSyntax> <StyledLayerDescriptor ogcTag="StyledLayerDescriptor" Namespace="sld"> <XPath>/</XPath> </StyledLayerDescriptor> <NamedLayer ogcTag="NamedLayer" Namespace="sld"> <XPath>/sld:StyledLayerDescriptor</XPath> </NamedLayer> <LayerName ogcTag="Name" Namespace="sld"> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer</XPath> </LayerName> <UserStyle ogcTag="UserStyle" Namespace="sld"> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer</XPath> </UserStyle> <FeatureTypeStyle ogcTag="FeatureTypeStyle" Namespace="sld"> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle</XPath> </FeatureTypeStyle> <StyleName ogcTag="Name" Namespace="sld"> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle</XPath> </StyleName> <Rule ogcTag="Rule" Namespace="sld"> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle</XPath> </Rule> <Title ogcTag="Title" Namespace="sld"> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle/sld:Rule</XPath> </Title> <Filter ogcTag="Filter" Namespace="ogc"> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle/sld:Rule</XPath> </Filter> <MinScale ogcTag="MinScaleDenominator" Namespace="sld">

Anhang -h-

<XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle/sld:Rule</XPath> </MinScale> <MaxScale ogcTag="MaxScaleDenominator" Namespace="sld"> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle/sld:Rule</XPath> </MaxScale> <PolygonSymbolizer ogcTag="PolygonSymbolizer" Namespace="sld"> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle/sld:Rule</XPath> </PolygonSymbolizer> <LineSymbolizer ogcTag="LineSymbolizer" Namespace="sld"> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle/sld:Rule</XPath> </LineSymbolizer> <PointSymbolizer ogcTag="PointSymbolizer" Namespace="sld"> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle/sld:Rule</XPath> </PointSymbolizer> <And ogcTag="AND" Namespace="ogc"> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle/sld:Rule/ogc:Filter</XPath> </And> <PropertyIsEqualTo ogcTag="PropertyIsEqualTo" Namespace="ogc"> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle/sld:Rule/ogc:Filter</XPath> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle/sld:Rule/ogc:Filter/ogc:AND</XPath> </PropertyIsEqualTo> <PropertyIsBetween ogcTag="PropertyIsBetween" Namespace="ogc"> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle/sld:Rule/ogc:Filter</XPath> </PropertyIsBetween> <LowerBoundary ogcTag="LowerBoundary" Namespace="ogc"> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle/sld:Rule/ogc:Filter/ogc:PropertyIsBetween</XPath> </LowerBoundary> <UpperBoundary ogcTag="UpperBoundary" Namespace="ogc"> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle/sld:Rule/ogc:Filter/ogc:PropertyIsBetween</XPath> </UpperBoundary> <PropertyName ogcTag="PropertyName" Namespace="ogc"> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle/sld:Rule/ogc:Filter/ogc:PropertyIsBetween</XPath> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle/sld:Rule/ogc:Filter/ogc:PropertyIsEqualTo</XPath> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle/sld:Rule/ogc:Filter/ogc:AND/ogc:PropertyIsEqualTo</XPath> </PropertyName> <Fieldvalue ogcTag="Literal" Namespace="ogc"> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle/sld:Rule/ogc:Filter/ogc:PropertyIsBetween/ogc:LowerBoundary</XPath> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle/sld:Rule/ogc:Filter/ogc:PropertyIsBetween/ogc:UpperBoundary</XPath> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle/sld:Rule/ogc:Filter/ogc:PropertyIsEqualTo</XPath>

Anhang -i-

<XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle/sld:Rule/ogc:Filter/ogc:AND/ogc:PropertyIsEqualTo</XPath> </Fieldvalue> <PolygonGeometry ogcTag="Geometry" Namespace="sld"> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle/sld:Rule/sld:PolygonSymbolizer</XPath> </PolygonGeometry> <PolygonPropertyName ogcTag="PropertyName" Namespace="ogc"> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle/sld:Rule/sld:PolygonSymbolizer/sld:Geometry</XPath> </PolygonPropertyName> <Fill ogcTag="Fill" Namespace="sld"> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle/sld:Rule/sld:PolygonSymbolizer</XPath> </Fill> <PolygonStroke ogcTag="Stroke" Namespace="sld"> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle/sld:Rule/sld:PolygonSymbolizer</XPath> </PolygonStroke> <PolyCssParameter ogcTag="CssParameter" Namespace="sld"> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle/sld:Rule/sld:PolygonSymbolizer/sld:Fill</XPath> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle/sld:Rule/sld:PolygonSymbolizer/sld:Stroke</XPath> </PolyCssParameter> <LineStroke ogcTag="Stroke" Namespace="sld"> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle/sld:Rule/sld:LineSymbolizer</XPath> </LineStroke> <LineCssParameter ogcTag="CssParameter" Namespace="sld"> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle/sld:Rule/sld:LineSymbolizer/sld:Stroke</XPath> </LineCssParameter> <PointGraphic ogcTag="Graphic" Namespace="sld"> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle/sld:Rule/sld:PointSymbolizer</XPath> </PointGraphic> <Mark ogcTag="Mark" Namespace="sld"> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle/sld:Rule/sld:PointSymbolizer/sld:Graphic</XPath> </Mark> <PointOpacity ogcTag="Opacity" Namespace="sld"> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle/sld:Rule/sld:PointSymbolizer/sld:Graphic</XPath> </PointOpacity> <PointSize ogcTag="Size" Namespace="sld"> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle/sld:Rule/sld:PointSymbolizer/sld:Graphic</XPath> </PointSize> <PointRotation ogcTag="Rotation" Namespace="sld"> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle/sld:Rule/sld:PointSymbolizer/sld:Graphic</XPath> </PointRotation> <PointWellKnownName ogcTag="WellKnownName" Namespace="sld"> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle/sld:Rule/sld:PointSymbolizer/sld:Graphic/sld:Mark</XPath> </PointWellKnownName> <PointFill ogcTag="Fill" Namespace="sld">

Anhang -j-

<XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle/sld:Rule/sld:PointSymbolizer/sld:Graphic/sld:Mark</XPath> </PointFill> <PointCssParameter ogcTag="CssParameter" Namespace="sld"> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle/sld:Rule/sld:PointSymbolizer/sld:Graphic/sld:Mark/sld:Fill</XPath> </PointCssParameter> <PolygonGraphicFill ogcTag="GraphicFill" Namespace="sld"> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle/sld:Rule/sld:PolygonSymbolizer/sld:Fill</XPath> </PolygonGraphicFill> <PolygonGraphic ogcTag="Graphic" Namespace="sld"> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle/sld:Rule/sld:PolygonSymbolizer/sld:Fill/sld:GraphicFill</XPath> </PolygonGraphic> <PolygonSize ogcTag="Size" Namespace="sld"> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle/sld:Rule/sld:PolygonSymbolizer/sld:Fill/sld:GraphicFill/sld:Graphic</XPath> </PolygonSize> <PolygonMark ogcTag="Mark" Namespace="sld"> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle/sld:Rule/sld:PolygonSymbolizer/sld:Fill/sld:GraphicFill/sld:Graphic</XPath> </PolygonMark> <PolygonWellKnownName ogcTag="WellKnownName" Namespace="sld"> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle/sld:Rule/sld:PolygonSymbolizer/sld:Fill/sld:GraphicFill/sld:Graphic/sld:Mark</XPath> </PolygonWellKnownName> <PolygonGraphicParamFill ogcTag="Fill" Namespace="sld"> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle/sld:Rule/sld:PolygonSymbolizer/sld:Fill/sld:GraphicFill/sld:Graphic/sld:Mark</XPath> </PolygonGraphicParamFill> <PolygonGraphicCssParameter ogcTag="CssParameter" Namespace="sld"> <XPath>/sld:StyledLayerDescriptor/sld:NamedLayer/sld:UserStyle/sld:FeatureTypeStyle/sld:Rule/sld:PolygonSymbolizer/sld:Fill/sld:GraphicFill/sld:Graphic/sld:Mark/sld:Fill</XPath> </PolygonGraphicCssParameter> </sldSyntax> </LUT>

Anhang -k-

Inhaltsangabe der Begleit-CD

Die Begleit-CD ist selbststartend und mit einem HTML-Menü zum Aufruf der nachfol-gend aufgelisteten Inhalte ausgestattet.

Wenn die CD beim Einlegen in das CD-Laufwerk nicht automatisch starten sollte (z.B. weil die Funktion "Autoplay" der Laufwerkseigenschaften deaktiviert wurde), muss die Datei "autostart.exe" im Wurzelverzeichnis der CD doppelt angeklickt werden, damit der HTML-Viewer startet.

Begleit-CD Inhalte:

� Programmcode des Projekts "ArcGIS-map to SLD Converter"

� Installationsversion des Programms "ArcGIS-map to SLD Converter"

� .NET Framework 1.1

� Shapefiles der "Geowissenschaftliche Übersichtskarte von Hessen 1:300.000" (GÜK 300)

� Schriftliche Ausarbeitung der Diplomarbeit als Word-Dokument

� Schriftliche Ausarbeitung der Diplomarbeit als PDF-Dokument

� HTML Programmdokumentation des Programms "ArcGIS-map to SLD Converter" mit Klassenübersicht, Implementationen und Kommentaren

Eidesstattliche Erklärung

Ich erkläre hiermit an Eides Statt, dass ich die vorliegende Arbeit selbstständig und ohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe. Die aus fremden Quellen direkt oder indirekt übernommenen Gedanken sind als solche kennt-lich gemacht.

Die Arbeit wurde bisher in gleicher oder ähnlicher Form keiner anderen Prüfungskom-mission vorgelegt und auch nicht veröffentlicht.

Mainz,

Datum Unterschrift

Documents

Automatisierte Generierung von Styled Layer Descriptor ... · Consortium (OGC) kann ein WMS-server Karten aus Rasterdaten und Vektor- daten visualisieren. 4 [Wikipedia], Eintrag: