Automatisierte Generierung von Styled Layer Descriptor

Transcription

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
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
i
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
ii
Vorwort
Diese Arbeit wurde ermöglicht durch eine Zusammenarbeit des Hessischen Landesamtes für Umwelt und Geologie (HLUG) in Wiesbaden mit der Fachhochschule
Mainz, bzw. dem angegliederten Institut für Raumbezogene Informations- und Messtechnik, 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 verbinden, 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 Standards erstellt werden kann.
Diese Anforderung wurde mit meiner Diplomarbeit umgesetzt in Form eines Programms mit dem Namen "ArcGIS-map to SLD Converter".
iii
1 Definition der Aufgabenstellung
-1-
1.1 Der Titel der Arbeit im Klartext
„Automatisierte Generierung von Styled Layer Descriptor-Dateien aus ESRI ArcGISProjekten 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 "Automatisierte 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 Geoinformationssystem (GIS) der Firma ESRI erstellt wurden.
Zur Erstellung von Karten mit GI-Systemen werden prinzipiell (mindestens) zwei Komponenten benötigt:
1. Eine Datengrundlage, welche die darzustellenden räumlichen Daten beinhaltet
2. Eine Abbildungsvorschrift, wie diese Daten auf einem optischen Endausgabegerät präsentiert werden sollen
SLD ist eine solche Abbildungsvorschrift für Karten, die von internetbasierten (und intranetbasierten) OGC-konformen1 Mapservern2 erzeugt werden.
Auf die genaue Bedeutung der einzelnen Begriffe wird im Kapitel 3 „Theoretische
Grundlagen und Begriffsbestimmungen“ näher eingegangen.
1
2
OGC= Open Geospatial Consortium (auch: Open GIS Consortium)
[GUR], Eintrag: Unter einem Internet Map Server (oder kurz: Map Server)
versteht man eine www-Anwendung im Internet, die auf Anfrage Kartenausschnitte auf einem Server erzeugt und über das Internet an einen Client
sendet, der diesen Kartenausschnitt dann im Browser visualisiert. Hierbei kommen unterschiedlichste Konzepte zum Einsatz, von clickable maps
bis zu komplexen DB-gestützten GIS-Angeboten über das Internet.
-2-
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 OGCkonformen 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 „Anforderungen 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 Kartendienste 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, diese 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 Monate. Ein halbes Personenjahr4 ist jedoch i. Allg. nicht genug Zeit, um eine Aufgabe
dieser Größenordnung als "Komplettlösung" abzuliefern. Deshalb gelten folgende Einschrä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 beschrie3
4
[Wikipedia], Eintrag: WMS= Im Rahmen der Spezifikationen des Open GIS
Consortium (OGC) kann ein WMS-server Karten aus Rasterdaten und Vektordaten visualisieren.
[Wikipedia], Eintrag: Ein Personenjahr (früher: Mannjahr) bezeichnet
die Arbeitsleistung, die eine Person während eines Jahres (im Schnitt
220 Arbeitstage) leistet.
-3-
benen Weise umzusetzen.
2. Die Testszenarien werden auf zwei ausgesuchten Test-Map-Servern durchgeführt. Die Kriterien für die Auswahl der Server werden im Kapitel 4.3 und 4.4 beleuchtet. Die Tests indes sollen kein komplettes Nachschlagewerk für die Tauglichkeit der Map-Server in Bezug auf SLD-Implementierungen bieten, sondern
Basis für die Umsetzung der Referenzkarte GÜK 300 mit einer sinnvollen Symbolisierung per SLD sein.
2 Motivation
-4-
2 Motivation
Worin liegt der Sinn einer zusätzlichen Abbildungsvorschrift für Kartenserver, die (zumindest 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 publizieren? 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 DesktopProjekts 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 ArcMapProjekte 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 Erhebungen von Geodaten stattgefunden oder vorhandene Geodaten wurden in elektronische Datenträger eingespeist. Doch gleich der babylonischen Sprachenvielfalt existierte auf dem Markt für elektronische Datenverarbeitung im Allgemeinen und dem
der Geodatenverarbeitung im Speziellen eine Menge an Formaten und unterschiedlichen Technologien, von denen viele nicht untereinander kompatibel waren und bis
heute nicht sind. Eine Zeitlang spielte das keine Rolle, da vor der Nutzung der Daten 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 Informationssystem, mit dem raumbezogene Daten digital erfasst und redigiert,
gespeichert und reorganisiert, modelliert und analysiert sowie alphanumerisch 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, indem man eine Vernetzung der vorhandenen Daten über zentrale Stellen vorantreibt.
Man spricht hierbei von sog. "Geodateninfrastrukturen" (kurz GDI). Solche GDI werden z. Zt. auf allen Verwaltungsebenen7 aufgebaut.
Man erreicht dadurch Synergieeffekte, die z.B. redundanter Datenerhebung und Datenerfassung, der lückenhaften Verfügbarkeit und der Zersplitterung von Datenbeständen entgegenwirken.
Aber die gemeinsame Nutzung von Daten setzt auch eine Verständigung über gemeinsam nutzbare Datenformate und Schnittstellen voraus.
Ein Beispiel zur Verdeutlichung: Nehmen wir an, mehrere Gelehrte aus unterschiedlichen Ländern wollen sich auf einem Kongress treffen. Sie beschließen, ihr jeweiliges 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 Darstellungsanweisungen 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 Informationen 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
7
[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 Daten der Vermessungsverwaltung (ATKIS, ALK), die als Grundlage für viele
Anwendungen geeignet sind
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 durchschnittlich 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 Konfigurationsdateien 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 Kartendienst mit einbinden. Dann müsste eine zweite Konfigurationsdatei für den UMNMapserver mit dem gleichen Aufwand erstellt werden.
Aber dieser Aufwand kann minimiert werden, wenn WMS-SLD als Darstellungsvorschrift 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 angeschnitten.
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 SourceProjekte 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 Entwicklungen.
Somit lassen sich langfristige Entwicklungen planen und kostspielige Neuentwicklungen 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öglicht wird, Einblick in den Quelltext eines Programmes zu haben.
3 Grundlagen und Begriffsbestimmungen
-7-
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 geospatial and location based services. Through our member-driven consensus programs,
OGC works with government, private industry, and academia to create open and extensible software application programming interfaces for geographic information systems
(GIS) and other mainstream technologies. Adopted specifications are available for the
9
public's use at no cost. “
Das heißt mit anderen Worten:
Die OGC ist eine nicht gewinnorientierte internationale, unter gemeinsamem freiwilligen 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 Zustimmung aller Mitglieder beschlossen wurden, arbeitet die OGC mit Regierungen,
Privatunternehmen und akademischen Betrieben zusammen, um offene und erweiterbare Software-Anwendungsschnittstellen für Geographische Informationssysteme zu
entwickeln. Spezifikationen10, die vom Mitgliedergremium akzeptiert wurden, sind unentgeltlich 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 Privatfirmen.
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 Standardisierungsorganisa9
10
Homepage OGC
[DUD] Spezifikation: Einzelaufzählung, Komplette Liste
-8-
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 defines three WMS operations: GetCapabilities returns service-level metadata, which is a
description of the service's information content and acceptable request parameters; GetMap returns a map image whose geospatial and dimensional parameters are well defined; 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 Lan13
guage (XML) encoding is defined for service-level metadata.”
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 Bitmap in verschiedenen möglichen Formaten (je nach Implementierung des Mapservers). Die derzeit gängigsten Formate sind jpeg14, gif und png.
Diese Bitmap wird mithilfe der in der Spezifikation fest definierten Parameter von einer
11
12
13
14
W3C: World Wide Web Consortium. Vereinigung diverser Organisationen zur
Erarbeitung von Web-Standards
ISO: International Organization for Standardization. Organisation für
die Erarbeitung Internationaler Industriestandards
Homepage OGC
jpeg: Joint Photographic Experts Group: im Internet am weitesten verbreitetes Format; gif: Graphics Interchange Format: 1987 von USOnlinedienst Compuserve entwickelt; png: Portable Network Graphics: Ersatz für das proprietäre Format gif
-9-
CGI-Anwendung15 oder einer anderen Scriptanwendung generiert. Die Parameter dienen der CGI-Anwendung als Steuerbefehle. Sie werden in einer Aufruf-URL16 übergeben (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 anbieterspezifische 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 UMNMapserver 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öglichkeit der Symbolisierung mit SLD zur Verfügung. Mit der SLD-Syntax können die
Layer klassifiziert und den einzelnen Klassen unterschiedliche Symbolisierungen zugewiesen werden. Bei diesen sog. "SLD-WMS" können zusätzlich die Parameter „DescribeLayer, 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 Protokoll unterstützt zwei Abfrage-Methoden:
1. GET
2. POST
Die http-GET-Methode besteht aus der URL des Webdienstes und verschiedenen Parametern, die mit bestimmten Trenn- und Verbindungszeichen an die URL angehängt
15
16
17
CGI: Common Gateway Interface- Ein Programmscript, das Routinen auf einem Server abarbeitet und HTML-Clients mit anderen Programmen verbindet
(z.B. Perl, PHP)
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
[Wiki], Eintrag: Das Hypertext Transfer Protocol (HTTP) ist ein zustandsloses Datenaustausch-Protokoll zur Übertragung von Daten. Es ist
eines der Protokolle, die der TCP/IP-Protokollstapel bereitstellt. Primär wird es im Rahmen des World Wide Web zur Übertragung von Webseiten
verwendet.
-10-
werden. Das "?" z.B. signalisiert das Ende der URL. Die notwendigen Parameter werden als Namen/Wert-Paare in der Form "Name=Wert&“ angegeben, wobei das "Kaufmanns-und" das Ende des Paares anzeigt. Somit können beliebig viele Namen/WertPaare angehängt werden. Gibt es Parameternamen, die mehrere Werte übernehmen
können, wie z.B. "LAYER", werden diese durch Kommata separiert. Bei den Parameternamen soll Groß-/ Kleinschreibung keine Rolle spielen; die Parameterwerte hingegen 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=get
map&srs=EPSG:31467&bbox=3447309,5542994,3450522,5545762&layers=GEOLOG
IE.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 eingebettet, 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 Karte 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 sowohl 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.
-11-
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 (Response):
Namen, Titel der Layer
Allgemeine Dienst-Metadaten (Diverse URL’s, Schlüsselbegriffliste, Kontaktinformationen etc.)
Capability-Metadaten (Auflistung der möglichen Operationen, die von der DienstInstanz 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 Reprä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
19
der Bounding Box
WIDTH
E
Ausgabe-Breite
Die Breite der die Karte repräsentierenden Ausgabe-Bitmap
HEIGHT
E
Ausgabe-Höhe
Die Höhe der die Karte repräsentierenden 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
-12-
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. Dimension 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 gegen 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 Feature. 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 generieren 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 OGCStandards 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ürfnisse 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 MapServer anderer Anbieter werden hier lediglich kurz angesprochen.
-13-
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 oder interaktiver Anwendungen zentral aufbereiten können und für andere Nutzer sowohl
innerhalb Ihrer Organisation (Intranet) als auch über das Internet zugänglich machen
20
können.“
Der ArcIMS ist Teil einer ganzen GIS-Infrastruktur mit integrierten Server- und Clientfunktionen. 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 Verschneidung 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 Datenerfassung) internetbasiertes GIS-System und unterscheidet sich dadurch von anderen gängigen 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
21
Homepage ESRI Deutschland
Multi-tier: 3- und mehrschichtig
-14-
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, HTMLViewer 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
-15-
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 Webserver 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 kommunizieren 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" bearbeiten. Typische Prozesse, die auf dem Spatial Server laufen können, sind: ImageRendering, Geocodierungen, Feature Streaming (das Versenden von Shapefiles und
ArcSDE-Daten in einem gepackten Format als Datenstrom), Queries (also Datenbankabfragen) und räumliche Verschneidungen. Kartendienste, die mit dem ArcIMS aufgesetzt werden, laufen letztlich auf dem Application Server.
Die Virtual Server des ArcIMS sind dazu da, mehrere laufende Application ServerInstanzen 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 ArcIMS.
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 Konfigurationsdatei für Kartendienste mit der Dateiendung *.axl ist in diesem XML-Derivat verfasst (ein Auszug aus einer axl-Datei wird in Kap. 4.4 vorgestellt).
ArcIMS von ESRI ist WMS-kompatibel, unterstützt aber nicht alle OGCImplementationen bedingungslos (wie in Kap. 5.2.1 dargestellt wird).
-16-
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 Minnesota 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 konnte, die an das WWW angeknüpft wurden. Die NASA arbeitete seit 1995 an dem Projekt, da sie eine Plattform suchte, mit der Satellitenbilder als Internetkarte präsentiert
werden konnten. Das daraus entstandene Projekt nannte sich "ForNet“ und das Ergebnis war ein CGI-Script, das in der Lage war, Erdas IMAGINE-Daten zu veröffentlichen. 1997 wurde die erste Version 1.0 des heute bekannten UMN-Mapservers veröffentlicht. 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 Minnesota. 23
„Die UMN MapServer Software ist eine OpenSource Entwicklungsumgebung für die Erstellung 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 kompilieren. 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 Anwendergemeinschaft.
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 An24
wendungen und Fachschalen für unterschiedlichste Daten.“
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 GISInfrastruktur 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 WebGIS.
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
24
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)
Homepage des UMN-DE
-17-
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 („stateless“), d.h. es ist nicht in der Lage, eine vorher getätigte Anfrage zu speichern. Als Folge 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
-18-
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 werden. 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 Datenbankerweiterungen wie PostGIS und ESRI ArcSDE einbinden. Die Daten werden
über die OGR-SimpleFeatures-Schnittstellen importiert, welche durch die OGRBibliotheken zur Verfügung gestellt werden.
Rasterdaten werden über die GDAL-Schnittstelle zur Verfügung gestellt (GDAL= Geospatial Data Abstraction Library).
Zur Erstellung eines Kartendienstes mit dem UMN Mapserver muss eine Konfigurationsdatei 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 Fachbereichs Geographie der Universität Bonn. Deegree stellt die offizielle Referenzimplementierung 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
25
of the deegree initiative.”
The deegree approach may be best characterized by attributes like interoperable, component-based, plattform independent, pattern-oriented”
Die Produktpalette des deegree umfasst neben dem WMS-Modul noch weitere Module, 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 Service, 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
-19-
Sammlung wird als deegree-Framework bezeichnet und bietet als solches die Möglichkeit 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 Datenbankerweiterungen 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 KartendienstParameter 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
26
ever offered, …”
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 verarbeiten:
Oracle9i™, Microsoft® SQL Server, Microsoft AccessMGE, MGE Segment Manager,
MGE GeoData Manager, FRAMME™, ArcInfo, ArcView, Shape files, MapInfo, AutoCAD, 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
-20-
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 Eigenarten 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 Inhaltsbeschreibungssprache.
Entgegen des weit verbreiteten Irrglaubens ist XML, wie HTML auch, keine Programmiersprache, 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 Generalized Markup Language) zur Hand, aber leider war SGML mit einer Standarddefinition 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 Standarddefinition von ca. 30 Seiten konnte sich aufgrund der Einfachheit seiner Struktur
durchsetzen. Der Vorteil von XML gegenüber HTML, dem wesentlich älteren Abkömmling 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 weiterer 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ültigkeit von XML-Dateien definieren. Das sind entweder sog. "Document Type Definitions"
27
[Adobe Go Live CS], Tag: Ein von spitzen Klammern umschlossener Elementname, 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.
-21-
(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 inzwischen 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 Programmsteuerung benutzt. Der Nachteil bei diesen Dateien ist jedoch, dass hier keine 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: Datenbanken werden dadurch direkt "internetfähig", da auf XML direkt über das httpProtokoll (ohne Umwege über Skriptanwendungen) zugegriffen werden kann (das
spielt eine zunehmende Rolle bei E-Commerce). Häufig werden komplette Datenbanken 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 Softwarehersteller 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 Schema - notwendig); aber es kann von Programm Y gelesen werden (wenn dieses XML
implementiert hat), was in der Tat ein beachtlicher Fortschritt bezüglich Kompatibilität bedeutet.
3.4.2 Aufbau von XML
Der Aufbau von XML-Dokumenten ist zwar im Vergleich zu SGML wesentlich einfacher, 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:
-22-
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 entstehen. 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 Endtag. In Abb. 5 sind alle Elementknoten dunkelrot markiert.
Attributknoten
Die zusätzliche Information innerhalb des Tags besteht aus dem Attributnamen 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 Beispiel wird der Namespace "xlink“ eingebunden.
Verarbeitungsanweisungsknoten
Sie enthalten Verarbeitungsanweisungen wie Versionsinformation (augenblicklich 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 werden und haben folgendes Format: ()
Tab. 3 Knotentypen in XML
Zur Vereinfachung der Benennung von Beziehungen der einzelnen Strukturelemente
-23-
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 umschließt den Kindknoten. Besitzt ein Knoten keine Kindelemente, so hat er dieses Format:
<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 Zeichen, 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 Targetnamespace ein Attribut namens xmlns. Der Attributname ist die Abkürzung für XMLNamespace. 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 Namensraumkürzel (Namespaceprefix) "xsd:".
Das bedeutet, dass die URL "http://www.w3.org/2001/XMLSchema“ des XMLNamespace "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 "simplen" 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
-24-
seiner Syntax28 und seiner Semantik29 definiert. Anhand der vorliegenden Namensraum-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 komplexere 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 gedacht, weshalb wird die Navigation im nächsten Kapitel lediglich kurze Erwähnung finden wird.
Eine Möglichkeit der Navigation und Adressierung, die vom W3C als solche 1999 vorgeschlagen wurde, bietet die Hilfssprache XPATH.
XPATH (= XML Path Language) ist jedoch nur eine Adressierungsanweisung und benötigt einen prozessierenden Kontext, der die Anweisungen ausführt und die Ergebnisse auswertet. Dafür ist im Normalfall ein XSLT-Prozessor31 zuständig; aber auch manche Programmierschnittstellen wie das DOM oder SAX arbeiten mit XPATHUnterstützung.
28
29
30
31
Syntax: Die korrekte Schreibweise eines Elements oder Attributs
Semantik: definiert, wo in der Hierarchie ein bestimmtes Element oder
Attribut auftauchen darf und wie oft
[Wiki], Eintrag: BLOB= Binary Large Objects- große binäre, und damit
nicht weiter strukturierbare Objekte oder Felddaten
XSLT= Extensible Stylesheet Language Transformation
-25-
„XML-gerechte Dokumente sind wie die Verzeichnis- und Dateistruktur auf einem Datenträger aufgebaut. Dort gibt es ein Wurzelverzeichnis, das Verzeichnisse (Ordner) und Dateien enthalten kann. Jedes untergeordnete Verzeichnis kann wiederum andere Unter32
verzeichnisse und Dateien enthalten usw. Man spricht dabei auch von Baumstruktur.“
XPath stellt daher eine Reihe an Schlüsselbegriffen bereit, die ein bestimmtes Verhältnis 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. "sprechende" 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 Namespaces 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ültige) Schreibweise für obiges Beispiel lautet:
„/ xsd:schema/ xsd:element/ name”. Sie erinnert stark an die Adressierung eines Dateisystems und in der Tat ist die Struktur von XML stark an die eines Dateisystems angelehnt.
Die XPath-Syntax wird in Kap. 5.1.1.4 noch einmal von Interesse sein, wenn die Konfigurationsdatei 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ückbewegen 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 Arbeitsspeicher der Plattform abgebildet. Es entsteht sozusagen eine Kopie des XML-Dokuments,
32
33
[SEH], Eintrag
SAX= Simple API for XML
-26-
wobei diese Kopie nicht als eine Abfolge von Zeichen angesehen werden darf. Vielmehr wandelt DOM das textbasierte XML-Dokument in eine geordnete Menge von Objekten um.
Laut [HVO], 344, stellt DOM für alle Basiskomponenten (Knotentypen) abstrakte Objektklassen mit genau definierten Schnittstellen bereit, denen eine bestimmte Menge
von Methoden und Attributen eigen ist. So stellt z.B. die Klasse "Elements“ eine Methode 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 Dokumentteil den Arbeitsspeicher, den das vorige Dokumentteil belegt hat, wieder freirä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 Dokumentzugriff. Welche der beiden Schnittstellenfamilien im Einzelfall am günstigsten ist,
hängt somit von der Verwendung ab: Den Inhalt einer Datenbank mit einer sechsstelligen Zahl von Einträgen würde man sicherlich praktikabler mit SAX oder XMLReader/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 Reader/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 erweitern. Einem WMS ist es lediglich möglich, einen Datensatz in einer vordefinierten Weise 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. attributabhängig in verschiedene Klassen einteilen und diese dann auch unterschiedlich darstellen, benötigt man ein weiteres Werkzeug, das OGC jetzt mit der SLD Spezifikation bietet.
-27-
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 benutzt 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:
IE.GUEK300_POLY&styles=Style1&SLD=http://mapserver/website/wms_sld/SLD_valid
2.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 spezifizierter 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 vorliegen können.
-28-
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 Parameter "PutStyles" (wiederum nur, falls der Mapserver das unterstützt) laut [OGS], 64,
Symboldefinitionen aus einer vorhandenen SLD in eine Mapserverkonfiguration übernommen 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 Bedeutungen 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 StyledLayerDescriptor.
Ein NamedLayer-Element wird dann verwendet, wenn der Layername zuvor in der
Konfigurationsdatei des WMS festgelegt wurde. Man kann den Layernamen überprüfen, indem an den WMS eine GetCapabilities-Anfrage gestellt wird. In der auf die
Anfrage folgenden Antwort sind alle zur Verfügung stehenden NamedLayer aufgelistet.
Ein UserLayer hingegen wurde noch nicht vorab in der Konfiguration des WMS definiert. Das Element dient dazu, per SLD aus einer vorhandenen Datengrundlage einen neuen Layer zu definieren. Allerdings wird dieses Feature z.Zt. noch von weni36
Rendering der Kartenelemente nach dem Z-Buffer-Verfahren: Eine Weiterentwicklung 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.
-29-
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 Klassifizierung des Layers eingeleitet wird. Alle notwendigen Informationen, sowohl zur
Klassenbildung einer aktuellen Klasse als auch deren Symbolisierung, stehen innerhalb 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ühren, die der Funktion eines SQL-Statements gleichzusetzen sind. Es ist nicht unüblich, 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 Standardisierungen zeigen). Als Voraussetzung dafür muss im SLD-Dokument aber der Namespace der Partnerspezifikation mit eingebunden werden, damit das Dokument
seine Gültigkeit behalten kann.
Da ein Layer ohne Klassifizierung einheitlich dargestellt würde, muss dem Mapserver mitgeteilt werden, nach welchen Bedingungen er die aktuelle Klasse erstellen
soll. Diese Bedingung wird durch das Element Filter eingeleitet. Innerhalb des FilterElements können Vergleichsoperatoren wie PropertyIsEqualTo, PropertyIsNotEqualTo, PropertyIsLessThan, PropertyIsGreaterThan etc. sowie räumliche Operatoren 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 abzusetzen.
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.
-30-
Symboldefinitionen PointSymbolizer, LineSymbolizer, PolygonSymbolizer, TextSymbolizer, (RasterSymbolizer):
Unter den jeweiligen Symboldefinitionen sind alle zur Symbolisierung der jeweiligen
Klasse notwendigen Einstellungen und Eigenschaften festgelegt. Attribute wie Farbfü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 graphischen Füllelementen oder der Referenz auf ein hinterlegtes Bitmap) sowie das Aussehen 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 ArcGIS 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 beschieden, 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 DatenmanagementApplikation 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önnen die Geodaten analysiert und in ansprechender Weise dargestellt und nach
Wunsch gelayoutet werden. Im Folgenden wollen wir uns mit ArcMap etwas eingehender beschäftigen:
-31-
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 Erstellung 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öglichkeiten, 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 gleichen 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 darzustellen. Es besteht die Möglichkeit, mehrere Diagrammarten auszuwählen und damit jedes Objekt der Karte nach den Kriterien der ausgewählten Felder mit einem Diagramm zu versehen.
5. Multiple Attributes: Diese Einstellung vebindet die Funktionalitäten von Categories und Quantities.
ArcMap ist als Professional-GIS in der Lage sehr komplexe Symbolisierungen zu erstellen 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 Featureklasse39 sind als Symbolart außerdem so genannte Multilayersymbole verfügbar, in
denen die Grundsymbolarten in beliebig vielen Layern übereinander geschichtet werden können, um so sehr komplexe Symbolisierungen für jede einzelne Klasse zu ermöglichen.
38
39
Unique Values: Von einem bestimmten Feld werden aus allen vorkommenden
Werten die 'eindeutigen Werte' extrahiert und in einer Liste zusammengestellt. In SQL entspräche dieser Vorgang der Anweisung "SELECT DISTINCT …"
Featureklasse: Polygon, Linie, Punkt, Raster oder Text bilden die fünf
möglichen Featureklassen
-32-
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) eingebunden. Somit ist es möglich, die Punktsymbolpalette beinahe beliebig zu erweitern.
Flächenhafte Symbole können grundsätzlich Liniensymbole und Punktsymbole enthalten. 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 Objektmodell) wird durch die Klassenbibliothek "ArcObjects" von ESRI repräsentiert.
3.6.2 ArcObjects
ArcObjects ist die Entwicklungsplattform von ArcGIS. Man unterscheidet hier drei Komponentenfamilien:
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 Klassen 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 Programmierung 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 Programmcode möglich machen
-33-
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 Objektbibliothek bereit, die denselben Funktionsumfang bietet, aber nicht die Nachteile der
com-Technologie in Kauf nehmen muss. Das Schnittstellenmodell, wie es in der COMTechnologie ü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 Anwendungen 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 Klassenbibliotheken.
-34-
3.7 Visual Basic.NET
Will man erklären, was Visual Basic.NET ist, muss man sich dem Begriff von zwei Seiten 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 (sofern 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 Handanlegen überflüssig machte. Aus diesem geschichtlichen Hintergrund entstanden die ersten Sprachkonzepte für maschinenlesbare und –interpretierbare Programmsprachen.
Den Anforderungen entsprechend waren diese Sprachen dazu ausgelegt, eine Prozedur 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 Sprachen wie z.B. C von Borland Software Corp. kompiliert, d.h. vorab vom menschenlesbaren 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 Programmierung, denn sie genügten den Ansprüchen, die in der Vergangenheit an sie gestellt wurden. Mit der Verbreitung von Computern und dem stetig wachsenden Bedarf an Computerprogrammen stand bald fest, dass der Anspruch an Wiederverwendbarkeit von
Code zur Minimierung der Herstellungskosten von Software ein neues Konzept notwendig 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 Prozessorkapazitäten nicht gewachsen waren. Den ersten Durchbruch als objektorientierte Sprache
hatte 1983 C++ als objektorientierte Erweiterung von C (wobei in der Literatur durch42
[DUD], Eintrag: Algorithmus= Rechenvorgang, der nach einem bestimmten,
sich wiederholenden Vorgang abläuft
-35-
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 heranzukommen und sie zu ändern. Vier Hauptmerkmale kennzeichnen Objektorientierte Sprachen:
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 Programmiersprachen 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 Eigenschaften und Verhalten. Neue Eigenschaften und Fähigkeiten können hinzugefügt werden, um das vorhandene Objekt zu erweitern. Dies beschleunigt die Softwareentwicklung und macht den Code strukturierter und damit besser verständlich.
3. Abstraktion
Objekte können als abstrakte Modelle von realen Objekten (oder Subjekten) angesehen werden, die Eigenschaften und Handlungsweisen der realen Objekte nachempfinden 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 bestimmter Code nur einmal quasi als "Muster" erstellt werden muss und dann beliebig oft verwendet werden kann. Solch ein in sich abgeschlossenes Muster wird als "Klasse" bezeichnet. Um diese Klasse zu benutzen, muss eine sog. "Instanz" von ihr erstellt werden. 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 Allpurpose 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
-36-
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 Betriebssystemfunktionen durch die Klassenbibliothek (es sei denn, es werden Nicht-.NET-Module verwendet 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 erstellten 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 Lastenverteilung (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 vorliegenden Java-Sourcecode in .NET wiederzuverwerten.
-37-
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 ftpbasiertes Protokoll zur Verfügung stellen, welche normalerweise nur als Desktopapplikationen 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.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 TestMap-Servern erörtert werden.
Außer den in Kap. 1 genannten Zielen wurden an das Programm detailliertere Forderungen 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 vorhandenen 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 werden, 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 Themen 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 Gesteine unter Betrachtung aller ihrer anorganischer Merkmale und Inhalte
nach ihrer zeitlichen Bildungsfolge ordnet, und eine Zeitskala zur Datierung der geologischen Vorgänge und Ereignisse aufstellt. Lithostratigraphie: Die L. ist in der Lage, örtliche oder regional auftretende
Gesteinseinheiten zu beschreiben, und fazielle, räumliche, oder zeitliche Beziehungen der einzelnen Fundpunkte zueinander darzustellen.
-39-
graphie44, Faziesgrenzen45 und Störungen46, wobei laut [GAD], Bd.II, 91, Petrographie
und Faziesgrenzen einer geologischen Karte „sich einheitlich auf die obersten petrographisch 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 UMNMapserver wurden jedoch Shape-Dateien als Datengrundlage benutzt). Zusammen mit
weiteren Themen aus anderen Teilbereichen der Geologie (z.B. Hydrogeologie, Rohstoffe, Schwermetallkonzentrationen) bilden sie die Fachanwendung "Geowissenschaftliche Übersichtskarte von Hessen 1:300.000"
Abb. 7 Die GÜK 300 in 10-facher Verkleinerung
44
45
46
[Wiki], Eintrag: Die Petrographie (griech. auch Lithologie oder Gesteinskunde) ist das wissenschaftliche Fachgebiet, das sich mit der Beschaffenheit der Gesteine beschäftigt.
[GAD], Bd. I, 88: Unter Fazies (lat. Facies – Gesicht) wird die verschiedenartige Ausbildung gleichartiger Ablagerungen verstanden, die
von den physisch-geographischen und geologischen Verhältnissen des Abtragungs- und Ablagerungsraumes bestimmt werden.
[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.
-40-
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 (STRUKTUR_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 Tabellen 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 Hessen 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 Alphanumerischen Daten aus dem Feld GEO_TXT stehen. Diese wiederum stellen litho47
48
Ära: Begriff aus der relativen Einteilung geologischer Zeiträume. Unterteilt das Äon des Phanerozoikum (Zeitalter sichtbaren Lebens)in das
Paläozoikum (570 – 250 Mio A), Mesozoikum (250 – 65 Mio A) und Känozoikum (65 Mio A – rezent).
Periode: "Feinere" relative Zeiteinteilung in 12 Perioden, beginnend
bei Kambrium (570 – 510 Mio A), bis zum Quartär (1,6 Mio A – rezent).
-41-
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 Werte 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 klassifiziert. Die Daten aus den ID-Feldern stehen repräsentativ für die Bezeichnungen der
entsprechenden Ära, Periode oder den petrographischen Überbegriff, unter dem zusammengefasst 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. Feldes. 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 relationaler Datenbankmodelle). Das ist in diesem Fall jedoch beabsichtigt und entstand aus
einer Notwendigkeit, die einer separaten Erkärung bedarf:
49
50
Ein nicht veröffentlichter Standard zur Beschreibung von u.a. petrographischen und lithostratigraphischen Sachverhalten, angelehnt an
Standards wie der DIN 4021 und 4022.
ACID ist die Abkürzung für die englischen Begriffe "Atomicity", "Consistency", "Isolation" und "Durability". Sie bezeichnen die Anforderungen, die an das Modell einer relationalen Datenbank gestellt werden
sollten und wird durch drei sog. Normalformen repräsentiert. 1. Normalform: Ein Relationenschema ist dann in der 1. Normalform, wenn alle Attribute atomare Wertebereiche haben (d.h. nicht zusammengesetzt sind
aus mehreren Wertebereichen). Im Beispiel GÜK300 wäre ein Wertebereich
"Petrographie", ein anderer "Geologische Perioden".
-42-
Aus der Sicht der Informationstechnologie (IT) würde man beide Sachverhalte in gesonderten Tabellen aufführen, die durch eine Relation miteinander verbunden sind.
Damit wäre die Datenbank in dieser Hinsicht normiert. Dadurch ginge jedoch der "innere 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 geologischem Sinne nicht als zusammengesetzte Begriffe verstanden werden (es handelt
sich hier um eine historisch gewachsene Nomenklatur). Ein Beispiel zur Verdeutlichung:
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" beschreibt, 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 stratigraphisch gesehen entstand der "bunte Sandstein" zu vielen Erdzeitaltern. Zusammengenommen 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 diesem 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)
-43-
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 separates 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 Bedingungen 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 werden 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 eingebunden werden.
Die Analyse der Symbole muss dort stattfinden, wo ArcMap die Klassifizierungen und
die Erstellung der Symbole durchführt: bei den Renderer-Objekten. Die Rendererobjekte sind unter dem sog. "Carto"-Objektmodell zu finden. Es existieren gemäß den Möglichkeiten 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)
-44-
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 Objektmodell "Display" gefunden werden. Es gibt insgesamt fünf Hauptsymboltypen mit
unterschiedlicher Anzahl an Untersymbolen:
Knotentyp
Textsymbol
Bedeutung
Keine Untersymbole
MarkerSymbol
SimpleMarkerSymbol, CartographicMarkerSymbol (CharacterMarkerSymbol, PictureMarkerSymbol), ArrowMarkerSymbol, MultilayerMarkerSymbol
LineSymbol
CartographicLineSymbol (HashlineSymbol, MarkerLineSymbol), SimpleLineSymbol, 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 Symbolen 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, realisieren können.
-45-
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 benö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önnen:
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 SLDSpezifikation lassen sich am besten in dieser Klasse verwirklichen.
Wenn mögliche Syntaxänderungen der SLD-Spezifikation ohne Sourcecodeänderungen bedacht werden sollen, muss dies über eine Konfigurationsdatei geschehen. D.h.
SLD-Elemente, aus denen die Datei aufgebaut werden soll, müssen aus der Konfigurationsdatei gelesen werden. Diese Elemente können nach einer Änderung der Spezifikation ebenfalls angepasst werden, so dass die resultierende SLD aktuell bleibt.
Die Struktur der XML-Datei, welche die SLD repräsentiert, ist wegen der Unmittelbarkeit der Reaktion auf die gerade zu verarbeitenden Daten nur bedingt voraussehbar
(insbesondere die Tiefe der Verschachtelung und hierarchische Einordnung der jeweiligen 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
-46-
einer www-URL) und die programminterne Funktionalität prüft das entstandene SLDDokument gegen die Schemadatei von OGC (das Programm müsste hier nur Schemadateien 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 genauere Angaben über Art und Ort der SLD-Elemente, die den Verstoß verursacht haben.
4.2 Erforderliche Ressourcen
Zur Ausführung der Arbeit waren bestimmte Programmplattformen und weitere Ressourcen 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 beantwortet 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
-47-
• Klassifizierungen mit Filter und logischen Operatoren
4. Welche Möglichkeiten der Erweiterung des Programms (zum Beispiel Flächenfüllungen 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 Kenntnisse umgesetzt und der Aufbau der entsprechenden Teil-SLD im Programm
implementiert. Anschließend werden die vom Programm erzeugten SLD mit der gleichen 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 Peripherie 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 OGCMap-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 durchgefü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 vertriebene 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
-48-
kann das Paket auch an einem beliebigen anderen Ort entpackt werden). An der Laufwerksbezeichnung ist zu erkennen, dass als Serverplattform eine Windows-Umgebung
gewählt wurde (genauer: Windows XP, SP2), obwohl prinzipiell auch UNIX- oder LinuxPlattformen in Frage kommen. Nachfolgend sind die Komponenten des MS4W aufgelistet:
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, gdalinfo.exe, gdaltindex.exe, gdalwarp.exe, ogrinfo.exe, ogr2ogr.exe, ogrtindex.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 Mapinfo 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 ArcSDEDatenbank.
Für die Tests auf dem UMN-Mapserver wurde die GÜK 300 in mehrere Shapefiles exportiert.
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) abgekoppelt wurde (die map-Datei, auf die ich mich im Folgenden beziehe, wurde im An-
-49-
hang angefügt). Sie ist statisch, d.h. sie muss (im Gegensatz zu der automatisch generierten 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 LAYERObjekt 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 Verdeutlichung 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-
-50-
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 GetMap- Anfrage:
http://127.0.0.1/cgibin/mapserv.exe?map=C:/ms4w/Apache/htdocs/Maps/GUEK300.map&SERVICE=WM
S&VERSION=1.1.1&REQUEST=GetMap&Layers=Guek300_Poly&STYLES=&SLD=htt
p://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):
Clientsinin
Clients
Clients
in1 und 2
Gebäude
Gebäude11und
und22
Gebäude
GIS-Server
SUN E450, Solaris 7
Zentraler
Switch-Router
Spezialisierte
Server
Spezialisierte
Server
Spezialisierte
Server
Spezialisierte
Server
BK-Server
SUN E250, Solaris 7
DB-Server
SUN E450, Solaris 2.6
Oracle 8
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 Standardkomponenten des ArcIMS schematisch dargestellt:
-51-
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
Betriebssystem
ESRI-Licence-Manager
Produkt
Solaris 9
ArcSDE-Lizenz
Map-Server
ArcIMS 4.0.1
Geodatenbank-Middleware
ArcSDE 8.3
Webserver
Servlet-Engine
WMS Connector
Scriptsprachen
Entwicklungssoftware
Graphikbibliotheken
Datei- u. Druckdienste
Software für gesicherten https-Zugang
Hilfssoftware
Apache 1.3.27
Tomcat 4.0.6
WMS Connector 1.0 for ArcIMS 4.0.1
Perl 5.6.1
php – 4.3.2.tar.bz2
gcc-2.95.3-pkg.zip
gmake-3.79.1-pkg.zip
gcc-3.2.1 (64bit-fähig)
Java SDK 2
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
Samba
Openssl-0.9.6g-sol9-sparc-local.gz
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)
-52-
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- Dokument "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 dynamisch erzeugbar. Bei Änderungen der Kartensymbolisierungen wird lediglich aus dem
ArcMap-Projekt eine neue SLD erzeugt, ohne händisch Veränderungen an der Konfiguration 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 UMNMapserver 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 ArcSDEVerbindung. Darin gibt es ein Feature-Dataset mit den unter 4.1.1 genannten sechs
-53-
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:
IE.GUEK300_POLY&styles=Style1&SLD=http://gismo/website/wms_sld/SLD_valid2.sl
d&format=png&width=250&height=400
5 Ergebnisse der Arbeit
-54-
5.1 Das Programm "ArcGIS-map to SLD Converter"
Wie zuvor erwähnt dient dieses Programm zum Erstellen von Darstellungsanweisungen (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 spartanisch: 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 Automatisierung, 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 Visual 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).
-55-
Zur Steuerung des Programms werden zwei XML-Dateien benutzt:
1. Preconfigure_Converter.xml: Die Datei beinhaltet benutzerdefinierte
Einstellungen wie Maßstabszahlen, Dateispeicherort und Markierungszustände von Checkboxen, mit denen das Hauptformular konfiguriert
wird.
2. LUT_sld_mapping_file.xml: Diese Datei enthält Informationen über SLDSyntax 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"
-56-
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 einen eigenständig adressierbaren Klassenabschnitt bedeuten.
Auf Klassenebene gültige Variablen (Membervariablen) werden der eindeutigen Zuordnung wegen mit einem vorangestellten "m_" versehen. Auf Methoden- und Funktionsebene 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
Flag (Boolean)
Switch
Klassenebene
m_bSwitch
Object (z.B. IMxDocument)
MXDoc
m_objMXDoc
Methodenebene
bSwitch
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, Konstruktion und Dokumentation von Systemen. Die UML definiert eine Semantik
bestehend aus Modellierungselementen, Beziehungen, Diagrammtypen und
Erweiterbarkeitsmechanismen. Mit der UML als einem programmiersprachenunabhängigen, offenen Standard können Modelle und Artefakte standardi-
-57-
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 verdeutlichen, 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 Konfigurationsdaten für Steuerelemente des Motherform aus der XML- Datei Preconfigure_Converter.xml ausliest. Die Datei muss im Anwendungsverzeichnis stehen. Die
Klasse CommonXMLHandle kapselt allgemeine und einfache XML Lese- und Schreibfunktionen auf Grundlage des DOM.
Wenn alle Einstellungen auf dem Hauptformular getätigt wurden, wird das Schaltelement "SLD" betätigt, womit der Analyse- und Ausgabeprozess in Gang gesetzt wird.
Als Folge davon wird die Klasse Analize_ArcMap_Symbols initialisiert, welche die gesiert dargestellt werden. Die UML wurde von der Object Management Group
standardisiert.
-58-
öffnete ArcMap-Karte analysiert. In ArcMap durchläuft der Algorithmus den Featuredataset layerweise. Für jeden Layer werden die darin enthaltenen Symboltypen in Datenstrukturen 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 enthaltenen Rendererstrukturen (n mögliche Rendererstrukturen). Die Rendererstrukturen enthalten Daten auf Layerebene und die Symbolstrukturen alle in diesem Layer vorkommenden 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 stehen 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 erzeugte SLD anhand einer eingelesenen Schemadatei auf Gültigkeit überprüft. Wenn
die SLD-Datei laut den eingelesenen Schemadateien gültig ist, endet der Programmablauf an dieser Stelle. Ist sie nicht gültig, wird ein Formular initialisiert, das die Fehlermeldungen der Überprüfungen protokolliert und diese auf Wunsch in eine Textdatei
abspeichert.
Die nachfolgenden Unterkapitel beziehen sich teilweise auf Ausschnitte des Programmquellcodes, 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 beinhaltet darum wenig dem ursprünglichen Programmzweck dienende Programmlogik. Mit
relativ wenig Anpassungsaufwand in den nachfolgenden Klassen könnte das aufrufende Modul ebenfalls z.B. durch ein kommandozeilenorientiertes Modul ersetzt werden.
Die Klasse enthält darum weitestgehend die Steuerelementdefinitionen, einige Proper-
-59-
ties zum Setzen der Steuerelementattribute, Events zur Reaktion auf die Steuerelementbedienung 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 Verarbeitung der SLD eine Sicherheitsabfrage nach dem Speicherort ausgelöst. Der Dateispeichern-Dialog zeigt immer den Speicherort der zuletzt erzeugten SLD als Voreinstellung an. Differiert der momentan gewählte Speicherort zu dem aus der Konfigurationsdatei Preconfigure_Converter.xml, so wird der neue Speicherort in die Konfigurationsdatei ü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 Datenbankschema-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" aktiviert, 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 Darstellungsbereiches der SLD fest. In der SLD wird dies mit den Min- und MaxScaleDenominator umgesetzt, die Kindelemente des Elements Rule sind. Die Elemente der Combobox-Liste werden aus der Konfigurationsdatei eingelesen. Das Editieren der Konfigurationsdatei 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 aufgenommen 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 Programms. 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.
-60-
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 Kartenobjekt 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 NassiShneiderman-Diagrammen52 (für die sequentiellen Programmabläufe) dargestellt. Wegen 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 Entwurfsmethode für die strukturierte Programmierung (Struktogramm). Es ist genormt
nach DIN 66261.
-61-
StoreStructUVRenderer(1 Renderer)
n Renderer
UniqueValueRenderer
StoreStructUVRenderer(1Renderer)
ClassBreaksRenderer
…
SimpleRenderer
…
Speichert alle RendererStructs
In ProjectStruct
AnalyseLayerSymbology(n Renderer)
SimpleFillSymbol
MarkerFillSymbol
n Symbole
LineFillSymbol
…
…
StoreSimpleFill(SimpleFillSymbol)
…
…
…
…
Untersymbol
verzweigen
…
MarkerSymbol
New StructSimpleFillSymbol =
StoreSimpleFill(SimpleFillSymbol)
MultilayerFillSymbol
LineSymbol
…
Speichert alle SymbolStructs
In RendererStruct
FillSymbol
StoreSimpleLine(SimpleLineSymbol)
New StructSimpleLineSymbol
New StructSimpleFillSymbol
StructSimpleFillSymbol.Color=SimpleFillSymbol.Color
StructSimpleLineSymbol.Color=SimpleLineSymbol.Color
…
…
…
…
…
…
New StructSimpleLineSymbol =
StoreSimpleLine(SimpleLineSymbol)
SimpleLineSymbol
MarkerLineSymbol
MultiLineSymbol
Return StructSimpleLineSymbol
Return StructSimpleFillSymbol
Abb. 19 Sequenzdiagramm und Struktogramme der Klasse Analize_ArcMap_Symbols
-62-
I. Die Verweise:
Normalerweise werden Anwendungen, die auf ArcMap zugreifen als VBAApplikationen 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 importieren. Die Verweise sind alle schon innerhalb der laufenden Instanz gesetzt.
Die Methode hat jedoch auch Nachteile: Man ist auf VBA festgelegt, das als Programmiersprache 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 Visual 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 ArcMap ü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 CentralProzessingFunction. Sie wird direkt aus dem Konstruktor aufgerufen und verteilt die notwendigen 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 Anwendung fortgeführt werden. Falls nicht, muss der Anwender ArcMap starten (Sicherheitsabfrage). 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-RootObjekt IAppROT den Verweis auf die ArcMap-Session holt. Damit wird ein ApplicationObjekt MXApplication initialisiert, durch das man über IMXDocument an das aktive
Dokument kommt, das die Karte beherbergt. Auch hier gibt es eine Kontrolle, ob mehrere Kartenfenster geöffnet wurden. Wenn ja, erscheint auch hier eine Sicherheitsabfrage.
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 Layerebene 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
-63-
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ächstes von CentralProcessingFunction aufgerufen wird. Hier findet eine Mehrfachverzweigung nach den verschiedenen möglichen Renderertypen statt. Jede Verzweigung
ruft eine spezielle Funktion auf, die genau auf die Analyse dieses Renderertyps zugeschnitten ist. Diese Funktionen heißen StoreStructSimpleRenderer, StoreStructUVRenderer 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 Layerebene vorliegen (wie z.B. die klassifizierenden Tabellenfelder) unter jedem einzelnen
Symbolstruct abgespeichert werden, damit sie auch auf Symbolebene unmittelbar verfügbar sind.
Die komplexeste dieser Funktionen ist StoreStructUVRenderer (UV steht hier für UniqueValue). 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 Grundsymbolart 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 Argument wird in der "Select – Case"- Verzweigung getestet. Wenn der Ausdruck stimmt,
wird:
-64-
1. über die entsprechende Schnittstelle ein Verweis auf das aktuelle Symbol abgefragt,
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 vorgesehen 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 ihrer 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 Umgrenzungslinie:
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 LineSymbolScan) 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 beschrieben, beliebig viele Symbole der gleichen Grundsymbolart übereinander liegen
können. Diese Multilayersymbole werden in den entsprechenden StoreMultilayerFunktionen gespeichert. Dort wird in einer Schleife die komplette Anzahl an übereinandergeschichteten Untersymbolen dieser Grundsymbolart (Polygon, Linie, Punkt) verteilt
-65-
auf die Store-Funktionen ihrer entsprechenden Untersymbolart. Jedes dieser Untersymbole wird in einer ArrayList der Multilayer-Datenstruktur gespeichert. Für den Fall,
dass eines dieser Symbole ebenfalls wieder ein Multilayersymbol ist, findet ein rekursiver Aufruf dieser StoreMultilayer-Funktionen statt. Für jedes einzelne dieser Untersymbolarten gibt es selbstverständlich weitere mögliche Symbolstränge, wie vorher erläutert.
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 hierbei 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 ArcObjects-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
54
[KKI], Eintrag: Stack= Speicherverwaltung als Stapel. Die Stapelverarbeitung erfolgt nach dem Modelle LIFO (Last In, First Out): Daten werden »oben« aufgelegt und zuerst wieder heruntergeholt; oder FIFO: Der
zuerst abgelegte wird zuerst abgearbeitet.
[Wiki], Eintrag: Heap= Eine Speicherbereich, von dem Speicherabschnitte
unterschiedlicher Größe zugeteilt und in beliebiger Reihenfolge wieder
freigegeben werden können.
-66-
(Um den Bezug zu dem Beispiel aus Abb. 20 zu wahren, wird nachfolgend die Datenstruktur 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", "mittel" und "unten" im folgenden Abschnitt sind entsprechend der Leserichtung zu verstehen):
Der obere Bereich speichert die typischen Eigenschaften des Symbols. Im Bsp. von
StructSimpleFillSymbol sind das Color und Style; für andere Symbole werden weitere 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 Symbole 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 KindOfMarkerStruct 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:
-67-
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 Informationen wie z.B. Anzahl der Klassen (ValueCount), Layername und Datasetname gespeichert. Hilfreich für die spätere Auswertung ist die Enumeration FeatureClass, die als Lookup für die Information dient, welche Featureklasse der augenblickliche 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 Anwendung "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 Analize_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 CentralProcessingFunction, 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-
-68-
verarbeitung exemplarisch herausgegriffen.
WriteToSLD( )
Schreibe Projekt-SLD-Gerüst und Projekt-Daten
n RendererStructs
PolygonFeature
Schreibe Layer-SLD-Gerüst und Layer-Daten
LineFeature
StructUniqueValueRenderer
…
…
Featureklassen
verzweigen:
WritePolygonFeatures(SymbolStruct)
PointFeature
…
StructSimpleRenderer
WritePolygonFeatures(SymbolStruct)
StructClassBreaksRenderer
Schreibe SLDFilter-Regeln
…
n SymbolStructs
WriteSolidFill(SymbolStruct)
StructSimpleFillSymbol
Schreibe Symbol-SLD-Gerüst
StructLineFillSymbol
StructMarkerFillSymbol
Schreibe Symbol-Daten ( Hole Symbol-Daten:
…
…
…
…
…
WriteSolidFill(SymbolStruct)
GetValueFromSymbolStruct ( Symboleigenschaft, SymbolStruct ) )
GetValueFromSymbolStruct(Symboleigenschaft, SymbolStruct)
StructLineFillSymbol
…
…
StructSimpleMarkerSymbol
…
PolygonColor
…
…
…
…
…
…
PolygonBorderColor
Lese PolygonColor
aus
LinienStruct
verzweigen:
Lese BorderWidth
aus LinienStruct
Return Symbolwert (=String)
Abb. 23 Struktogramme der Klasse Output_SLD
LinienStruct
verzweigen:
…
…
Symboleigenschaften
verzweigen:
…
PolygonBorderW idth
Lese BorderColor
aus LinienStruct
-69-
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 SLDWurzelknotenelement 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 aufgesplittet.
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 Namen 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
-70-
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 Attribut "ogcTag". Wie man erkennen kann, heißt das Element nur "Name". Der Elementname bleibt immer gleich und ist folglich immer übereinstimmend mit dem im Code
benutzten Pseudonym. Der Attributwert hingegen kann nach Bedarf angepasst werden.
Der Vorteil dieser Vorgehensweise ist, dass man Anpassungen der Konfiguration durch
veränderte Spezifikationen in einer Datei durchführen kann und nicht den Programmcode ä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) dargestellt sind.
Der technische Ablauf des Mapping sowie alle weiteren Elemente der Konfigurationsdatei 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 enthaltenen 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 Klasse 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-
-71-
tig bei Pfeilen oder Kreuzen als Punktsymbole) umgesetzt wurden. Wesentlich komplexer 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 aufgerufen, 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 Vektorbasis 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 werden. 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 (PolygonSymbolizer) übereinandergelegt werden. Hierbei gibt es jedoch Einschränkungen:
Die Implementierungen mancher Mapserver lässt nur eine bestimmte Anzahl von
übereinanderliegenden Symbolen zu, deshalb habe ich in der Funktion WritePolygonFeatures 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 Tatsache, dass ein Layer eines Multilayersymbols immer aus einer dieser drei Grundsymbolarten 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.
-72-
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ültigen) Informationen aus den Datenstrukturen gesprochen. Im Folgenden geht es darum, 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 übergeben, muss vorab analysiert werden, um welche Art Symbol es sich handelt. Deshalb
wird jedes Mal, wenn diese Informationen gefragt sind, die Funktion GetValueFromSymbolstruct aufgerufen. Sie bekommt als Parameter die Symbolstruktur übergeben,
die es zu durchsuchen gilt, und einen String, der die Symbolinformation, die man bekommen will, repräsentiert (ValueNameOfValueYouWant).
Der Typ des Symbol-Structs wird über eine "IF-ELSEIF TYPEOF"- Verzweigung ermittelt. 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 Linienbreite ausgelesen werden kann. Wenn die betreffende Struktur eine Multilayerstruktur ist,
wird (egal bei welcher Featureklasse) ein rekursiver Aufruf von GetValueFromSymbolstruct getätigt, denn die Multilayerstrukturen haben wie üblich auch hier eine Sonderstellung:
In dem Teil der Funktion, wo die Multilayerstructs verzweigen, werden diese Symbollayer 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
-73-
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 orientierte) Überlegung voraus:
Ist der aktuelle Symbolstruct ein MultilayerFillSymbol-Struct, so wird der Symbol-Struct
schon in der Funktion WritePolygonFeatures in seine einzelnen Grundsymbole aufgeteilt. Bei einer Anfrage an die Funktion GetValueFromSymbolstruct wird also kein MultilayerFillSymbol-Struct mehr übergeben. Es bleiben nur MultilayerLine-Structs und MultilayerMarker-Structs als mögliche zu übergebende Multilayer-Structs. Diese sind jedoch 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 Eigenschaften 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 Klasse aus aktiviert werden. Man kann hier dennoch drei thematische Schwerpunkte setzen:
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 Konstruktor bekommt zwei Parameter übergeben: die Instanz der aufrufenden Klasse und
den Dateinamen und –pfad als String. Der andere Konstruktor bekommt nur die Instanz 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 aufgerufen. 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
-74-
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 aufgefü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 Namespaces und Prefixes der Elemente, die in der SLD benutzt werden. Dieser Eintrag
ist sehr wichtig, da damit der sog. Namespacemanager der .NET XML-Verwaltung initialisiert 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 Namespaces), 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 Elternelemente vorkommen können. Die Ausdrücke liegen in der verkürzten Schreibweise (vgl. 3.4.5), aber mit Namespacekürzeln vor.
-75-
Von der aufrufenden Klasse aus wird nun über die Property der SLD-Dateiname und
Dateipfad gesetzt und danach (ebenfalls von OutputSLD aus) die Funktion CreateNewFile aufgerufen. Die Funktion erstellt in der leeren XML-Datei (SLD) den Versionsknoten 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 initialisiert 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 Lebenszeit mit dem aktuellen Dokument verbunden. Danach werden dem Manager in
einer Schleife die URI und Prefixes übergeben. Hintergrund des .NET NamespaceManagers:
.NET besitzt eine komplexe Verwaltung von XML-Funktionalitäten. Will man nun XMLElemente 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 Namen" 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 weiteres verarbeiten können.
Es gibt jedoch eine Möglichkeit, die Elemente in der gewünschten Weise (mit Namespaceprefixes) zu schreiben: indem man mit der überladenen Methode CreateElement("ns",XMLElement,"ns-URI") zusätzlich zu dem zu schreibenden Element das
Namespaceprefix und die URI übergibt. Das geht allerdings nur dann, wenn Namespaces 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 erstellte 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. "einheitlicher Bezeichner für Ressourcen") ist eine Zeichenfolge, die zur Identifizierung einer abstrakten oder physikalischen Ressource dient. URIs
werden zur Bezeichnung von Ressourcen (wie Webseiten, sonstigen Dateien, Aufruf von Webservices, aber auch z.B. E-Mail-Empfängern) im Internet und dort vor allem im WWW eingesetzt. URI fassen URL und URN zusammen.
-76-
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 Verweis 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 XPathAusdrücken in eine eigene Collection eingelesen (zur Erinnerung: Die XPathAusdrü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 Kindelement 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 Collection getestet. Sind alle Ausdrücke der Collection getestet und keiner der Knoten hat
Übereinstimmung gefunden, ist klar, dass der aktuelle ActiveNode nicht der Elternknoten 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 XPathCollection ü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 Wertzuweisungen von Elementen und Attributen erfolgt ebenfalls für den jew. zuletzt erzeugten 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 auswerten, 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 SelectNodes-Operation des Navigators der Manager als Parameter mit übergeben.
-77-
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 Elemente 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 initialisiert wird, der die Schemadatei geladen hat. Mithilfe des XMLTextReader liest das
XMLSchemaCollection-Objekt die Schemadatei. Dieser Moment ist schon ein kritischer, 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 "TRYCATCH"-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 Add57
58
.NET-Help: XmlSchemaCollection kann vom XmlValidatingReader für die effiziente 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.
.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 XmlSchemaCollection zwischengespeichert sind, wird die Schemas-Eigenschaft
verwendet. Die ValidationType-Eigenschaft gibt an, welche Art der Überprüfung vom Reader durchgeführt werden soll.
-78-
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 Schemas.Add(Collection) hinzugefügt und im nächsten Zug die Art des Überprüfungsdokuments 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 Ausnahmebehandlung 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üfungsreport 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 Formular enthält eine Textbox, der beim Aufruf der globale Überprüfungsreport hinzugefügt wird.
Wird kein Verstoß registriert, so wird die erfolgreiche Überprüfung lediglich im Hinweisfeld des Hauptformulars angezeigt.
5.1.2 Implementierung der Sollkomponenten und darüber hinausgehende Implementierungen
Dieses Unterkapitel soll dokumentieren, was das Programm ArcGIS-map to SLD Converter zum derzeitigen Stand der Version 1.0.0 leistet. Teilweise wurden die Implementierungen 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.
59
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
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).
-79-
wurde und wird beim nächsten Mal automatisch markiert.
o
Die Maßstabszahlen in den Min- und Max-Bereichen sind über die Benutzeroberfläche editierbar (durch Eingabe in die Comboboxen), werden
in die Konfigurationsdatei übernommen und beim nächsten Programmaufruf angeboten.
Alle Bearbeitungsvorgänge können im Infofeld verfolgt werden, das bei Auslösen
der SLD-Funktion automatisch ausklappt und sich nach Abschluss der SLDGenerierung wieder automatisch zusammenklappt
Durch eine Auswahl des Zieldatenspeichers, den der Mapserver benutzt, wird
das korrekte Format für die PropertyName in der SLD eingetragen (Zieldatenspeicher 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 RendererTypen implementiert). Die gespeicherten Eigenschaften jedes einzelnen Symbols können in der Klasse Analize_ArcMap_Symbols unter der Region "Datenstrukturen" 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 StoreStructNeuerRenderer erstellt werden.
OutputSLD:
Für die Ausgabe in SLD-Dokumente sind folgende Renderer implementiert:
UniqueValueRenderer (incl. many fields)
SimpleRenderer
ClassBreaksRenderer
-80-
Um einen neuen Renderer zu implementieren, müsste dieser in die Funktion WriteToSLD aufgenommen werden.
Folgende Darstellungseigenschaften sind für die einzelnen Featureklassen implementiert:
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 Umrandung
Ebenfalls implementiert ist die Darstellung von Multilayersymbolen als zweilagige
Symbole (zweilagig, weil manche Mapserver z.Zt. nicht mehr Symbollagen prozessieren 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-ElementHierarchien 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 wechselt, muss das Element im Code entweder früher oder später an die schreibende XMLKlasse ü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 geprüft.
Assoziierte Schemadateien werden auf Erreichbarkeit und XML-Validität geprüft.
Bei ungültigen SLD-Fragmenten wird der Element- bzw. Attributname, Zeilennummer, Zeichennummer des verursachenden Elements bzw. Attributs sowie
-81-
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 gerechnet 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 Values) werden eben diese eindeutigen Werte des Datasets benötigt. Wenn die Klassifizierung nach einem Feld vorgenommen wurde, gibt es keine Schwierigkeiten, diese
eindeutigen Werte zu erhalten: Man liest einfach die Values(Symbol i) aus dem Renderer 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 Feldwerte selbst den Character des FieldDelimiter beinhalten.
Ein weiterer gangbarer Weg besteht darin, aus den vorliegenden Datensätzen "eigenhändig" die Unique Values jedes Feldes zu extrahieren und die Unique Values jedes
einzelnen Feldes einer Klasse über einen Vergleich mit den zusammengesetzten Unique 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 zusammengesetzten 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-
-82-
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 Klassifizierung 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 Voraussetzung für die vorgenannte Prozedur ist?
Eine Möglichkeit ist, den kompletten Datensatz Zeile um Zeile mit einem sog. CursorObjekt 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 klassifizierenden 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 GimmeUniqeValuesForFieldname 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 Bestandteil die Anweisung DISTINCT ist, initialisiert. Diese Funktion extrahiert die Unique Values 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 erzielt. Die Unique Value-Listen für zwei Felder wurden immerhin innerhalb von 5 Minuten 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 SLDElemente 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
-83-
jedoch die Methode matches des XPathNavigator keine XPath-Ausdrücke mehr auswerten, 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 ausgelesenen 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 XPathAusdruck ü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 .NETNamespaceManager bietet diesen XSLT-Kontext. Er kann Prefixes und URLs verwalten 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 Struktur 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 Unterstü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:
-84-
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 obligatorisch.
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 referenziert, 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 SLDSpezifikation) in Literal-Elemente eingeschlossen (s. Abb. 29)
Das Element Title entspricht dem Label in ArcMap. Es wird bei der Bildung von Legen-
-85-
den herangezogen zur Bezeichnung des Legendenelements.
Das Element Fill leitet alle Flächenfüllungen ein. In der Abb. 29 ist lediglich eine vollfarbige weiße Flächenfüllung definiert.
Stroke bezeichnet prinzipiell eine Linie. Als Kindelement von PolygonSymbolizer definiert es die Flächenumrandung.
Die unterschiedlichen CssParameter sind dem SVG/CSS-Standard entliehen und umschreiben 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 Featureklassen, 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 Darstellungsbandbreite von Flächenfüllungen mit SLD:
-86-
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 "Grundausstattung" 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örmige 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ächenfü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
61
SVG: Scalable Vector Graphics ist ein durch das W3C definierter XMLStandard zur Beschreibung zweidimensionaler Vektorgraphiken. Neben stufenloser Skalierbarkeit sind Filtereffekte wie z.B. Schattenwurf, Beleuchtung, Weichzeichnung oder Verzerrung möglich.
[Wiki], Eintrag: In der Computergraphik spricht man von Clipping, wenn
Figuren auf einen bestimmten Bereich begrenzt werden sollen.
-87-
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 innerhalb von PolygonSymbolizer die Flächenumrandung. Für die Darstellung der graphischen 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 ExternalGraphic als Kindelemente – keine Linie).
Um trotzdem eine deutliche Abgrenzung der schraffierten Klassen zu anderen Klassen
zu bewerkstelligen, habe ich mich eines "Tricks" bedient:
-88-
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 resultierenden Karte eine schräge Kreuzschraffur erzeugt:
Abb. 33 Schräge Kreuzschraffur
-89-
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 jeweiligen 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 "unbounded"62. Das bedeutet, dass beliebig viele Symbole der gleichen Featureklasse zu einem Multilayersymbol übereinander gelegt werden dürfen.
Der UMN-Mapserver ist jedoch nicht in der Lage mehr als zwei Symbollayer zu verarbeiten, 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 beschränkt.
Durch die Kombination zweier Symbole mit WellKnownNames kommt es zu interessanten 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".
-90-
Leider ist aus o.g. Gründen nicht möglich, hier einen vollflächigen Hintergrund zu generieren, 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-
-91-
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 Punkten, einer Leerstelle von 5 Punkten, einem Segment von 5 Punkten und einer Leerstelle 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 UMNMapserver 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 Punktsymbolen 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 vorigen 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
-92-
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ünschten Ressource benötigt werden, bereitgestellt. Das Attribut xlink:type="simple"63 besagt, 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 Verzeichnis 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 Rastersymbols 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 Hyperlink-Element <a>). Sie können jedoch auch Dokumente in zwei Richtungen
verbinden (das heißt von A nach B und ebenso zurück).
-93-
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 deutlich 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ßstabsbegrenzungen für den Anzeigemaßstab der Karte in das Programm implementiert.
-94-
Schraffuren:
Im Folgenden wurden horizontale, vertikale und Schrägschraffuren von mir getestet.
Die mit Punktfüllungen gemachten Erfahrungen bzgl. Skalierbarkeit gelten in der gleichen Weise für die Schraffuren.
Abb. 41 Bitmapgenerierte Horizontalschraffur
Abb. 42 Bitmapgenerierte Vertikalschraffur
-95-
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 Streifens 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.
-96-
5.2.1.3 Weitere getestete SLD-Elemente:
Des Weiteren wurden von mir die Maßstabsbegrenzungen sowie der Vergleichsoperator 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 Informationsgehalt mehr entnehmbar ist. Diese Grenzwerte können durch die Elemente Minund 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 werden 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 Programm 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 ArcObjects 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
-97-
Der Operator ist ein Nachkomme von Filter, und beinhaltet die Untergrenze des Wertebereichs (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 UMNMapserver 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, sondern mehrerer Felder klassifiziert werden soll, werden mehrere Vergleichsoperatoren
mit dem logischen Operator AND verkettet.
Abb. 48 Der logische Operator AND
-98-
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ältnisse der eingeschlossenen Elemente. In der Folge davon stehen die Kindelemente hierarchisch 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 PropertyIsEqualTo 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 vornimmt. Deshalb müssen in der Konfigurationsdatei die XPath-Ausdrücke für alle möglichen 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" klassifiziert 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 beschriebenen 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
-99-
-100-
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 Elemente und Attribute:
SLD-Element
unterstützt
NamedLayer
ja
UserLayer
nein
NamedStyle
ja
UserStyle
ja
FeatureTypeStyle
ja
SLD-Attribut
unterstützt
-101-
Rules
ja
Min-, MaxScaleDenominator
ja
Filter
ja
ElseFilter
ja
PropertyIsEqualTo
ja
PropertyIsBetween
ja
AND
ja
PointSymbolizer
ja
Fill
ja
Size
ja
Mark
ja
WellKnownName
ja
Rotation
nein
LineSymbolizer
ja
Stroke
ja
GraphicStroke
ja
PolygonSymbolizer
ja
Fill
ja
GraphicFill
ja
Graphic
ja
ExternalGraphic
ja
(im Folgenden CssParameter)
fill
ja
fill-opacity
nein
stroke
ja
stroke-width
ja
stroke-opacity
nein
stroke-dasharray
ja
(s. Stroke)
fill
ja
fill-opacity
nein
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).
-102-
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 UMNMapserver, 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
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
Size
nein
Mark
nein
WellKnownName
nein
Rotation
nein
LineSymbolizer
ja
Stroke
ja
SLD-Attribut
unterstützt
fill
nein
fill-opacity
nein
stroke
nein
stroke-width
nein
stroke-opacity
nein
stroke-dasharray
nein
-103-
GraphicStroke
nein
PolygonSymbolizer
ja
Fill
ja
GraphicFill
nein
Graphic
nein
ExternalGraphic
nein
(s. Stroke)
fill
ja
fill-opacity
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ärke, 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 Rasterbasis 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 beherrscht?
Um diese Frage zu beantworten, möchte ich einen Vergleich aufstellen zwischen einem 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 programmgenerierten SLD erstellt, während die nächste Karte als proprietärer Kartendienst generiert wurde:
-104-
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 AXLKonfigurationsdatei:
-105-
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 ArcMapOriginalkarte 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 wesentlich 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 Karteninformation 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 Darstellungsmöglichkeiten von ArcIMS auch mit SLD ausgeschöpft werden.
6 Zusammenfassung und Ausblick
-106-
Meine Diplomarbeit wurde mit dem Ziel erstellt, die Arbeit mit internetbasierten Kartendiensten 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 analysierte 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 eingeschrä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 Expandieren 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 internetbasierte 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 vorhanden. Ü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 abgeschlossen, 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 implementierten Renderern könnte dann beispielsweise der DotDensityRenderer implementiert 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
-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 kartographischen Gesichtspunkten zufriedenstellend darzustellen.
Verzeichnisse
Verzeichnisse
-I-
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: Galileo 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, WindowsAnwendungen. 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® Implementation Specification
[OGW]
Open GIS Consortium Inc. Web Map Service Implemantation Specification. Hrsg. OGC. RefNum. OGC 01-068r2.; Vers. 1.1.1; Date 2001-11-27; Cat. OpenGIS® Implementation Specification
Verzeichnisse
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
-III-
Verzeichnisse
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
-IV-
Verzeichnisse
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
-V-
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
Anhang
-a-
Anhang
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/cgibin/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/cgibin/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
-b-
Anhang
-c-
Workflow des Programms ArcGIS-map to SLD Converter
Schematischer Programmablauf
Sequentieller Ablauf. Im Wesentlichen 4 Klassen (ohne Validierung)
SLD-Datei
6
5
ArcMap
2
Steuerdatei
1
(LUT_sld_mapping_file.xml)
Aufrufklasse
XML-Funktionsklasse
(Motherform)
(XMLHandle)
4
3
Legende
Programmablauf
Datenströme
Ergebnis
Analyseklasse
(Analize_ArcMap_Symbols)
Ausgabeklasse
(Output_SLD)
Anhang
UML-Klassendiagramme
-d-
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:FeatureTypeSty
le</XPath>
</Rule>
<Title ogcTag="Title" Namespace="sld">
le/sld:Rule</XPath>
</Title>
<Filter ogcTag="Filter" Namespace="ogc">
le/sld:Rule</XPath>
</Filter>
<MinScale ogcTag="MinScaleDenominator" Namespace="sld">
Anhang
-h-
le/sld:Rule</XPath>
</MinScale>
<MaxScale ogcTag="MaxScaleDenominator" Namespace="sld">
le/sld:Rule</XPath>
</MaxScale>
<PolygonSymbolizer ogcTag="PolygonSymbolizer" Namespace="sld">
le/sld:Rule</XPath>
</PolygonSymbolizer>
<LineSymbolizer ogcTag="LineSymbolizer" Namespace="sld">
le/sld:Rule</XPath>
</LineSymbolizer>
<PointSymbolizer ogcTag="PointSymbolizer" Namespace="sld">
le/sld:Rule</XPath>
</PointSymbolizer>
<And ogcTag="AND" Namespace="ogc">
le/sld:Rule/ogc:Filter</XPath>
</And>
<PropertyIsEqualTo ogcTag="PropertyIsEqualTo" Namespace="ogc">
le/sld:Rule/ogc:Filter/ogc:AND</XPath>
</PropertyIsEqualTo>
<PropertyIsBetween ogcTag="PropertyIsBetween" Namespace="ogc">
</PropertyIsBetween>
<LowerBoundary ogcTag="LowerBoundary" Namespace="ogc">
le/sld:Rule/ogc:Filter/ogc:PropertyIsBetween</XPath>
</LowerBoundary>
<UpperBoundary
ogcTag="UpperBoundary" Namespace="ogc">
</UpperBoundary>
<PropertyName ogcTag="PropertyName" Namespace="ogc">
le/sld:Rule/ogc:Filter/ogc:PropertyIsEqualTo</XPath>
le/sld:Rule/ogc:Filter/ogc:AND/ogc:PropertyIsEqualTo</XPath>
</PropertyName>
<Fieldvalue ogcTag="Literal" Namespace="ogc">
le/sld:Rule/ogc:Filter/ogc:PropertyIsBetween/ogc:LowerBoundary</XPath>
le/sld:Rule/ogc:Filter/ogc:PropertyIsBetween/ogc:UpperBoundary</XPath>
le/sld:Rule/ogc:Filter/ogc:PropertyIsEqualTo</XPath>
Anhang
-i-
le/sld:Rule/ogc:Filter/ogc:AND/ogc:PropertyIsEqualTo</XPath>
</Fieldvalue>
<PolygonGeometry ogcTag="Geometry" Namespace="sld">
le/sld:Rule/sld:PolygonSymbolizer</XPath>
</PolygonGeometry>
<PolygonPropertyName ogcTag="PropertyName" Namespace="ogc">
le/sld:Rule/sld:PolygonSymbolizer/sld:Geometry</XPath>
</PolygonPropertyName>
<Fill ogcTag="Fill" Namespace="sld">
</Fill>
<PolygonStroke ogcTag="Stroke" Namespace="sld">
</PolygonStroke>
<PolyCssParameter ogcTag="CssParameter" Namespace="sld">
le/sld:Rule/sld:PolygonSymbolizer/sld:Fill</XPath>
le/sld:Rule/sld:PolygonSymbolizer/sld:Stroke</XPath>
</PolyCssParameter>
<LineStroke ogcTag="Stroke" Namespace="sld">
le/sld:Rule/sld:LineSymbolizer</XPath>
</LineStroke>
<LineCssParameter ogcTag="CssParameter" Namespace="sld">
le/sld:Rule/sld:LineSymbolizer/sld:Stroke</XPath>
</LineCssParameter>
<PointGraphic ogcTag="Graphic" Namespace="sld">
le/sld:Rule/sld:PointSymbolizer</XPath>
</PointGraphic>
<Mark ogcTag="Mark" Namespace="sld">
le/sld:Rule/sld:PointSymbolizer/sld:Graphic</XPath>
</Mark>
<PointOpacity ogcTag="Opacity" Namespace="sld">
</PointOpacity>
<PointSize ogcTag="Size" Namespace="sld">
</PointSize>
<PointRotation ogcTag="Rotation" Namespace="sld">
</PointRotation>
<PointWellKnownName ogcTag="WellKnownName" Namespace="sld">
le/sld:Rule/sld:PointSymbolizer/sld:Graphic/sld:Mark</XPath>
</PointWellKnownName>
<PointFill ogcTag="Fill" Namespace="sld">
Anhang
-j-
le/sld:Rule/sld:PointSymbolizer/sld:Graphic/sld:Mark</XPath>
</PointFill>
<PointCssParameter ogcTag="CssParameter" Namespace="sld">
le/sld:Rule/sld:PointSymbolizer/sld:Graphic/sld:Mark/sld:Fill</XPath>
</PointCssParameter>
<PolygonGraphicFill ogcTag="GraphicFill" Namespace="sld">
le/sld:Rule/sld:PolygonSymbolizer/sld:Fill</XPath>
</PolygonGraphicFill>
<PolygonGraphic ogcTag="Graphic" Namespace="sld">
le/sld:Rule/sld:PolygonSymbolizer/sld:Fill/sld:GraphicFill</XPath>
</PolygonGraphic>
<PolygonSize ogcTag="Size" Namespace="sld">
le/sld:Rule/sld:PolygonSymbolizer/sld:Fill/sld:GraphicFill/sld:Graphic</XPath>
</PolygonSize>
<PolygonMark ogcTag="Mark" Namespace="sld">
le/sld:Rule/sld:PolygonSymbolizer/sld:Fill/sld:GraphicFill/sld:Graphic</XPath>
</PolygonMark>
<PolygonWellKnownName ogcTag="WellKnownName" Namespace="sld">
le/sld:Rule/sld:PolygonSymbolizer/sld:Fill/sld:GraphicFill/sld:Graphic/sld:Mark</XPath>
</PolygonWellKnownName>
<PolygonGraphicParamFill ogcTag="Fill" Namespace="sld">
le/sld:Rule/sld:PolygonSymbolizer/sld:Fill/sld:GraphicFill/sld:Graphic/sld:Mark</XPath>
</PolygonGraphicParamFill>
<PolygonGraphicCssParameter ogcTag="CssParameter" Namespace="sld">
le/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 nachfolgend 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 kenntlich gemacht.
Die Arbeit wurde bisher in gleicher oder ähnlicher Form keiner anderen Prüfungskommission vorgelegt und auch nicht veröffentlicht.
Mainz,
Datum
Unterschrift

Automatisierte Generierung von Styled Layer Descriptor

Transcription

Similar documents

Inhalt - produktinfo.conrad.com

Folgende Autodesk Produkte sind ab sofort bei Peterschinegg

ERDAS APOLLO Server User Guide