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

Transkript

1 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

2 Abkürzungen...i Vorwort...iii 1 Definition der Aufgabenstellung Der Titel der Arbeit im Klartext Die Ziele der Arbeit Was ist nicht Ziel dieser Arbeit? Motivation Grundlagen und Begriffsbestimmungen OGC WMS Die Aufruf-URL Die WMS-Operationen Gängige Map-Server ArcIMS von ESRI Der UMN-Mapserver Weitere gängige Internet Mapserver Deegree GeoMedia WebMap von Intergraph GeoServer und AEDGIS von AED SICAD XML Bedeutung von XML Aufbau von XML Die Gültigkeit von XML-Dokumenten Navigation und Adressierung Programmschnittstellen SLD Einige spezielle SLD-Elemente ArcGIS von ESRI ArcMap ArcObjects Visual Basic.NET Konzept der Objektorientierten Programmiersprachen (OOP) Visual Basic NET Framework Anforderungsdefinition und Planung Anforderungen an das Programm Die Geologische Übersichtskarte von Hessen 1: Vorüberlegungen zur Struktur des Programms Das Analysemodul...43

3 Das Ausgabemodul Die Flexibilität bei der XML-Ausgabe Die Validierung Erforderliche Ressourcen Anforderungen an die SLD-Tests Das Testbed für die SLD-Tests Konfiguration des UMN-Mapserver Konfiguration des ArcIMS am HLUG Ergebnisse der Arbeit Das Programm "ArcGIS-map to SLD Converter" Struktureller Aufbau des Programms Die Haupt-Benutzeroberfläche "Motherform" Das Analysemodul "Analize_ArcMap_Symbols" Das Ausgabemodul "Output_SLD" Die auf XML-Aufgaben spezialisierte Klasse "XMLHandle" Die Gültigkeitsüberprüfung mit der Klasse "ValidateSLD" Implementierung der Sollkomponenten und darüber hinausgehende Implementierungen Besondere Herausforderungen bei der Entwicklung Die SLD Tests Test mit dem UMN Mapserver Vektorbasierte Symbolisierung Flächenfüllungen mit Bitmaps Weitere getestete SLD-Elemente: Test auf der ArcIMS-Plattform Zusammenfassung und Ausblick 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

4 Abkürzungen ALK API ASP ATKIS AXL BLOB CAD CGI CLR COM DTD DOM EPSG GI GIS GIF GDAL GDI GML GSDI GUI GÜK HLUG HTML HTTP i3 IIS ISO IT JPEG J2RE LAN Automatisierte Liegenschafts Karte Application Programming Interface Active Server Pages Amtliches Topographische-Kartographisches Informationssystem Arc Extensible Language Binary Large Object Computer Aided Design Common Gateway Interface Common Language Runtime Component Object Model Document Type Definition Document Object Model European Petroleum Survey Group Geo-Informatik Geoinformationssystem Graphics Interchange Format Geospatial Data Abstraction Library Geodaten Infrastruktur Geography Markup Language Global Spatial Data Infrastructure Graphical User Interface Geowissenschaftliche Übersichtskarte Hessisches Landesamt für Umwelt und Geologie Hyper Text Markup Language Hyper Text Transfer Protocol Institut für Raumbezogene Informations- und Messtechnik Internet Information Server International Organization for Standardization Informations Technologie Joined Photographic Experts Group Java 2 Runtime Environment Local Area Network i

5 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

6 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: 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

7 1 Definition der Aufgabenstellung -1-1 Definition der Aufgabenstellung 1.1 Der Titel der Arbeit im Klartext Automatisierte Generierung von Styled Layer Descriptor-Dateien aus ESRI ArcGIS- Projekten zur Publikation mit OGC-konformen Mapservern Wie so oft bei ähnlichen Arbeiten ist auch der Titel meiner Diplomarbeit kryptisch und nicht nur für Laien schwer verständlich. Auch Nichtlaien kann der eine oder andere spezielle Begriff aus der Geoinformatik unbekannt sein. Ich will den Titel deshalb zunächst in eine allgemein verständlichere Form bringen. Im Thema taucht der Begriff "Mapserver" auf. Das impliziert, dass es um Karten geht, und zwar um solche, die im Internet veröffentlicht werden sollen. Der Begriff "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-konformen 1 Mapservern 2 erzeugt werden. Auf die genaue Bedeutung der einzelnen Begriffe wird im Kapitel 3 Theoretische Grundlagen und Begriffsbestimmungen näher eingegangen. 1 OGC= Open Geospatial Consortium (auch: Open GIS Consortium) 2 [GUR], Eintrag: Unter einem Internet Map Server (oder kurz: Map Server) versteht man eine www-anwendung im Internet, die auf Anfrage 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.

8 1 Definition der Aufgabenstellung 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: von Hessen (kurz GÜK 300) brauchbar symbolisiert werden kann, damit alle in ihr enthaltenen Klassen in der WMS-basierten 3 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 Personenjahr 4 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 beschrie- 3 [Wikipedia], Eintrag: WMS= Im Rahmen der Spezifikationen des Open GIS Consortium (OGC) kann ein WMS-server Karten aus Rasterdaten und Vektordaten visualisieren. 4 [Wikipedia], Eintrag: Ein Personenjahr (früher: Mannjahr) bezeichnet die Arbeitsleistung, die eine Person während eines Jahres (im Schnitt 220 Arbeitstage) leistet.

9 1 Definition der Aufgabenstellung -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.

10 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-Systeme 5, die zur Erfassung und lokalen Bearbeitung der Daten von den Firmen, Kommunen und Behörden gekauft wurden, genügend Möglichkeiten um die Daten in entsprechender Qualität ins Internet oder Intranet zu bringen. Beispielsweise bieten ESRI und auch Intergraph (um nur zwei der marktführenden Unternehmen zu nennen) jeweils ein Produkt an, mit dem die Desktop-Projekte direkt im Internet veröffentlicht werden können. Außerdem gibt es von Drittanbietern Lösungen, um die Darstellungseigenschaften eines Desktop- Projekts zu extrahieren und als Kartendienst (WMS wird in Kapitel 2.2 näher erläutert) in einem proprietären Format abzuspeichern. Zu nennen wären in dieser Beziehung z.b. AveiN! und AmeiN! der Firma Terrestris GbR, Bonn, die ArcView- oder ArcMap- Projekte umwandeln in UMN-Kartendienste. Alle diese vorgenannten Lösungen sind proprietäre Lösungen. WMS-SLD allerdings folgt einem internationalen Standard. Die Antwort auf obige Fragen lautet deshalb: Es gibt drei gute Gründe, warum man proprietäre Lösungen zugunsten von Standards, wie z.b. OGC (wird im Kapitel 2.1 näher behandelt), W3C oder ISO sie erarbeiten, vermeiden sollte: 1. Das sicherlich wichtigste Argument für Standards ist die allgemeine Nutzbarkeit und die Austauschbarkeit von Daten. In den letzten Jahren und Jahrzehnten haben überall auf der ganzen Welt 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.

11 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 Geobasisdaten 6 ) 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 Verwaltungsebenen 7 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 [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 7 Auf Landesebene: z.b. Geodateninfrastruktur des Landes Hessen; GDI Nordrhein-Westfalen Auf Bundesebene: Deutsche Geodateninfrastruktur GDI-DE Europaweit: Europäische Geodateninfrastruktur INSPIRE International: Internationale Geodateninfrastruktur GSDI

12 2 Motivation 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 UMN- Mapserver 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-Software 8 dar, deren Verwendung meist kostenlos oder mit einem geringen Kostenfaktor verbunden ist. Open Source-Produkte können jedoch nicht mit proprietärer Technologie hergestellt werden, da diese lizenzpflichtig, bzw. nicht offengelegt sind. D.h. Open Source- Projekte werden erst durch offene Standards wie SLD ermöglicht. Proprietäre Technologien sind abhängig von Firmenpolitik und bieten somit wenig Planungssicherheit. Standards hingegen gewährleisten sichere Grundlagen für 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.

13 3 Grundlagen und Begriffsbestimmungen -7-3 Grundlagen und Begriffsbestimmungen Dieses Kapitel soll notwendige Grundlagen zum Verständnis der Diplomarbeit legen und Begriffe, auf die ich mich in der Arbeit häufig beziehe, erläutern. Die Unterkapitel sind aufeinander aufbauend gegliedert, so dass das jeweils vorangehende Kapitel die Voraussetzungen für die nachfolgenden Kapitel schafft (bis auf Kap. 3.6 und 3.7). 3.1 OGC OGC ist eine Abkürzung für Open Geospatial Consortium. Eine frühere Bezeichnung für das OGC, die aber immer noch gültig ist, lautet auch: Open GIS Consortium. OGC über sich: The Open Geospatial Consortium, Inc. (OGC) is a non-profit, international, voluntary consensus standards organization that is leading the development of standards for 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 public's use at no cost. 9 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. Spezifikationen 10, 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 Standardisierungsorganisa- 9 Homepage OGC 10 [DUD] Spezifikation: Einzelaufzählung, Komplette Liste

14 3 Grundlagen und Begriffsbestimmungen -8- tionen wie z.b. dem W3C 11 und der ISO 12. 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; Get- Map 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 Language (XML) encoding is defined for service-level metadata. 13 Mit anderen Worten: Ein Kartendienst erzeugt Karten aus georeferenzierten Daten. OGC definiert eine Karte als eine visuelle Repräsentation der Geodaten. Die Karte erhält der Webclient als Bitmap in verschiedenen möglichen Formaten (je nach Implementierung des Mapservers). Die derzeit gängigsten Formate sind jpeg 14, gif und png. Diese Bitmap wird mithilfe der in der Spezifikation fest definierten Parameter von einer 11 W3C: World Wide Web Consortium. Vereinigung diverser Organisationen zur Erarbeitung von Web-Standards 12 ISO: International Organization for Standardization. Organisation für die Erarbeitung Internationaler Industriestandards 13 Homepage OGC 14 jpeg: Joint Photographic Experts Group: im Internet am weitesten verbreitetes Format; gif: Graphics Interchange Format: 1987 von US- Onlinedienst Compuserve entwickelt; png: Portable Network Graphics: Ersatz für das proprietäre Format gif

15 3 Grundlagen und Begriffsbestimmungen -9- CGI-Anwendung 15 oder einer anderen Scriptanwendung generiert. Die Parameter dienen der CGI-Anwendung als Steuerbefehle. Sie werden in einer Aufruf-URL 16 übergeben (auf die Aufruf-URL wird in Kap 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 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 UMN- Mapserver z.b. wird deshalb noch der Parameter "&map=url_der_konfigurationsdatei" in der Aufruf-URL aufgeführt. Ein einfacher WMS (basic-wms) benutzt zur Darstellung eine begrenzte Anzahl an vordefinierten Styles, die lediglich jeweils einem Layer zuweisbar sind. Komplexere Symbolisierungen sind auf diese Weise nicht möglich. Dafür steht dem WMS die Mö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) Die Aufruf-URL Zur Kommunikation mit dem WMS sieht das OGC das http-protokoll 17 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 CGI: Common Gateway Interface- Ein Programmscript, das Routinen auf einem Server abarbeitet und HTML-Clients mit anderen Programmen verbindet (z.b. Perl, PHP) 16 URL: Uniform Resource Locator: eindeutige Adresse eines Dokuments im Internet; besteht aus dem Zugriffsverfahren (z.b. http), dem Hostnamen (z.b. www) und dem Dateipfad 17 [Wiki], Eintrag: Das Hypertext Transfer Protocol (HTTP) ist ein 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.

16 3 Grundlagen und Begriffsbestimmungen -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/Wert- Paare angehängt werden. Gibt es Parameternamen, die mehrere Werte übernehmen können, wie z.b. "LAYER", werden diese durch Kommata separiert. Bei den Parameternamen soll Groß-/ Kleinschreibung keine Rolle spielen; die Parameterwerte hingegen sind case-sensitive 18. Eine gültige Aufruf-URL nach der http-get Methode wäre demnach z.b.: map&srs=epsg:31467&bbox= , , , &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 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 ) 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.

17 3 Grundlagen und Begriffsbestimmungen -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 Dienst- Instanz geliefert werden können, Ausgabeformate etc.) Layers und Styles (Symboldefinitionen und Informationen über vererbte Layer werden laut [OGW], 24 augenblicklich noch nicht unterstützt) II. GetMap: Die GetMap-Operation liefert keine Daten als Information, sondern die Karte als 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 ) REQUEST E GetMap Anfrage-Operation LAYERS E Layer-Liste STYLES E Style-Liste SRS E Namensraum:Bezeichner BBOX E minx,miny,maxx,maxy WIDTH E Ausgabe-Breite HEIGHT E Ausgabe-Höhe FORMAT E Ausgabe-Format TRANSPARENT O true/false Kommagetrennte Liste eines oder mehrerer Layer Kommagetrennte Liste vordefinierter Styletypen Koordinatensystem (z.b. EPSG:4326) Die Ecken links unten, rechts oben der Bounding Box 19 Die Breite der die Karte repräsentierenden Ausgabe-Bitmap Die Höhe der die Karte repräsentierenden Ausgabe-Bitmap Das Ausgabeformat der die Karte repräsentierenden Bitmap 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

18 3 Grundlagen und Begriffsbestimmungen -12- BGCOLOR O Farbwert EXCEPTIONS O Ausgabeformat TIME O Zeit ELEVATION O Höhenangaben Hintergrundfarbe der Karten-Bitmap in Hexadezimalschreibweise Das Format, in dem Ausnahmen des WMS ausgegeben werden Datumsangabe für Layer, die sich ändern können 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 OGC- Standards zu beleuchten. Den Markt für Internet-GIS und Web Mapping teilen sich eine Menge Anbieter, deren Produkte eine breite Palette der Aufgaben erledigen, die ein "herkömmlicher WMS erfüllen muss. Außerdem gibt es zahlreiche kleinere Unternehmen, die vorhandene Systeme übernehmen und diese im Rahmen eines "Customizing auf spezielle Bedü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 Map- Server anderer Anbieter werden hier lediglich kurz angesprochen.

19 3 Grundlagen und Begriffsbestimmungen ArcIMS von ESRI Der ArcIMS ist das internetbasierte Geoinformationswerkzeug von ESRI aus einer ganzen Produktpalette von GIS-Komponeneten, die eng miteinander verzahnt sind. Derzeit wird der ArcIMS in der Version 9.1. ausgeliefert. ESRI über den ArcIMS: ArcIMS ist ein internetbasiertes GIS, mit dem Sie Geodaten in Form digitaler Karten o- der interaktiver Anwendungen zentral aufbereiten können und für andere Nutzer sowohl innerhalb Ihrer Organisation (Intranet) als auch über das Internet zugänglich machen können. 20 Der ArcIMS ist Teil einer ganzen GIS-Infrastruktur mit integrierten Server- und 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-Architektur 21 ausgelegt (tatsächlich sind es augenblicklich nur drei Schichten). 20 Homepage ESRI Deutschland 21 Multi-tier: 3- und mehrschichtig

20 3 Grundlagen und Begriffsbestimmungen -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, HTML- Viewer und Java-Viewer zur Verfügung gestellt) 2. Der Diensteschicht (die nachfolgend genauer betrachtet wird) 3. Der Datenschicht (Shapefiles, ArcSDE, RDBMS 22 ) 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

21 3 Grundlagen und Begriffsbestimmungen -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: Image- Rendering, 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 Server- Instanzen entsprechend ihrer gegenwärtigen Aufgabe zu gruppieren. Sie verwalten sozusagen die Anwendungslast zwischen den einzelnen Application Server-Instanzen. Der Manager: Ist eine Zusammenstellung von interaktiven Webseiten zum Administrieren von 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 OGC- Implementationen bedingungslos (wie in Kap dargestellt wird).

22 3 Grundlagen und Begriffsbestimmungen 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 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 Anwendungen und Fachschalen für unterschiedlichste Daten. 24 Der UMN-Mapserver ist laut [UMN] kein voll ausgestattetes GIS, sondern bildet eine Basiskomponente für die Erzeugung dynamischer Karten über das Internet. Da der UMN Mapserver aber ein Open Source-Projekt ist, existieren eine Vielzahl von Open Source und Freeware-Komponenten der Entwicklergemeinschaft, die als GIS- Infrastruktur dem UMN Web-GIS-Fähigkeiten verleihen können. Der Fokus des UMN liegt jedoch eindeutig auf der Funktion der Kartenanzeige und nicht auf der des Web- GIS. Die Architektur des Mapservers: Die Architektur des UMN Mapservers kann ebenfalls als 3-Schichtstruktur bezeichnet werden, wobei die Diensteschicht wesentlich einfacher strukturiert ist als beim ArcIMS (s. Abb. 4). 23 Die Informationen stammen aus einer Korrespondenz von PhD Steve Lime mit einem interessierten User von UMN-Mapserver und sind im offiziellen internationalen UMN-Forum gepostet (siehe Hyperlink-Verzeichnis) 24 Homepage des UMN-DE

23 3 Grundlagen und Begriffsbestimmungen -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

24 3 Grundlagen und Begriffsbestimmungen -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 OGR- Bibliotheken 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 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 ) Weitere gängige Internet Mapserver 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 von OGC dar. Aktuell ist derzeit die stabile Version Implementation practice in the above mentioned projects showed that the functional overlap between different geospatial applications is much larger than simply the feature object model. The extension of the object model to a broader library was the starting point of the deegree initiative. 25 The deegree approach may be best characterized by attributes like interoperable, 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

25 3 Grundlagen und Begriffsbestimmungen -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 Kartendienst- Parameter und Metadaten aufgenommen werden. 2. localwfs_config.xml: Wie der Dateiname schon vermuten lässt, wird die Datei zur Konfiguration des Web Feature Service benötigt. 3. datasource_config.xml: Anhand dieser Datei wird die einzubindende Datenbasis beschrieben GeoMedia WebMap von Intergraph Laut Intergraph ist GeoMedia Web Map das erste Web Mapping-Produkt, das auf dem Markt war: GeoMedia WebMap, the first Web-based map visualization and analysis software tool ever offered, 26 GeoMedia Web Map kann laut eigenen Angaben als Map Server sowohl für gerasterte Karten als auch für Karten aus Vektorgraphiken fungieren. Außer der Funktion als Kartenserver bietet GeoMedia Web Map GIS-Funktionalitäten wie Analysen (Querys), Verschneidungen und andere räumliche Operationen, die GeoMedia Web Map in den Rang eines "echten" Internet-GIS erheben. GeoMedia Web Map ist an spezielle Aufgaben anpassbar (sog. customizing). Laut Intergraph ist GeoMedia Web Map in der Lage folgende Eingabeformate zu verarbeiten: Oracle9i, Microsoft SQL Server, Microsoft AccessMGE, MGE Segment Manager, MGE GeoData Manager, FRAMME, ArcInfo, ArcView, Shape files, MapInfo, Auto- CAD, MicroStation CAD, ODBC-compliant, OGC GML, OGC WFS. Damit ist GeoMedia Web Map laut eigenen Angaben als OGC-konformer Kartendienst einsetzbar 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 erweitern die Funktionalität von GeoServer. 26 Intergraph Homepage

26 3 Grundlagen und Begriffsbestimmungen -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 Tags 27 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.

27 3 Grundlagen und Begriffsbestimmungen -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 nochmals aufgegriffen) 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 http- Protokoll (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 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:

28 3 Grundlagen und Begriffsbestimmungen -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 Wurzelknoten Elementknoten Attributknoten Textknoten Namensraumknoten Verarbeitungsanweisungsknoten Kommentarknoten Bedeutung Die Wurzel eines XML-Dokuments. Sie umschließt alle weiteren Elemente in dem Dokument. In Abb. 5 ist das Wurzelelement das Element <xsd:schema>. Ein Element besteht aus einem Anfangstag und seinem zugehörigen Endtag. In Abb. 5 sind alle Elementknoten dunkelrot markiert. 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. Der Zeicheninhalt, der zwischen den Tags steht. 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. 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: (<?...?>) 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

29 3 Grundlagen und Begriffsbestimmungen -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) 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 XML- Namespace. Der Attributwert ist die URL des Namensraumes, innerhalb dessen der Tag mit dem Namensraumkürzel dieses Namensraumes gültig ist. Ein Beispiel: Die Elementknoten in Abb. 5 (z.b. das Element annotation) haben das Namensraumkürzel (Namespaceprefix) "xsd:". Das bedeutet, dass die URL " des XML- Namespace "xmlns:xsd" mit dem Namespaceprefix "xsd:" den Ort definiert, innerhalb dessen der Tag mit dem Namen annotation gültig ist. Hinter der etwas umständlichen Erklärung steckt (meistens) die Tatsache einer "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

30 3 Grundlagen und Begriffsbestimmungen -24- seiner Syntax 28 und seiner Semantik 29 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 BLOB 30 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 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-Prozessor 31 zuständig; aber auch manche Programmierschnittstellen wie das DOM oder SAX arbeiten mit XPATH- Unterstützung. 28 Syntax: Die korrekte Schreibweise eines Elements oder Attributs 29 Semantik: definiert, wo in der Hierarchie ein bestimmtes Element oder Attribut auftauchen darf und wie oft 30 [Wiki], Eintrag: BLOB= Binary Large Objects- große binäre, und damit nicht weiter strukturierbare Objekte oder Felddaten 31 XSLT= Extensible Stylesheet Language Transformation

31 3 Grundlagen und Begriffsbestimmungen -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 Unterverzeichnisse und Dateien enthalten usw. Man spricht dabei auch von Baumstruktur. 32 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 noch einmal von Interesse sein, wenn die Konfigurationsdatei meines Programms vorgestellt wird, das zur Navigation XPath benutzt 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 SAX 33 (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 [SEH], Eintrag 33 SAX= Simple API for XML

32 3 Grundlagen und Begriffsbestimmungen -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 XML- Reader/Writer herausschreiben. Um bestimmte Einträge in einem XML-Dokument zu suchen/finden und davon Einträge an anderer Stelle abhängig zu machen, würde man eher DOM benutzen. Was die jeweiligen Schnittstellen nicht alleine schaffen, kann durch Kombinieren der beiden Familien erreicht werden. Das von mir entwickelte Programm benutzt beide Schnittstellen: DOM und 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.

33 3 Grundlagen und Begriffsbestimmungen -27- SLD liegt z.zt. in der Version mit der Spezifikation vom 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 WCS 34 oder WFS 35 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: map&srs=epsg:31467&bbox= , , , &layers=geolog IE.GUEK300_POLY&styles=Style1&SLD= 2.xml&format=png&width=250&height= 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.

34 3 Grundlagen und Begriffsbestimmungen -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 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 weni- 36 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.

35 3 Grundlagen und Begriffsbestimmungen -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 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 Filter- Elements 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.

36 3 Grundlagen und Begriffsbestimmungen -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 Arc- GIS als Produktlinie parallel zu dem 1981 eingeführten ArcInfo, was bis dato das marktführende Professional-GIS weltweit darstellte. Inzwischen besitzt ArcGIS mehr Bedeutung in der GI-Branche als ArcInfo und wird das betagte GI-System in einigen Jahren wahrscheinlich vollständig abgelöst haben. Laut den Zahlen von [BUW], 42 u. 46, ist ESRI Marktführer sowohl in D, A, CH (deutschsprachiges Gebiet) mit einer Summe von Lizenzen als auch weltweit mit 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 Datenmanagement- Applikation von ArcGIS, in der ähnlich dem Microsoft Explorer Daten kopiert, erstellt, verschoben und in sonstiger Weise verändert werden können. ArcMap bildet die Anwendung, in der Karten aus den Daten erstellt werden. Hier kö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:

37 3 Grundlagen und Begriffsbestimmungen 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 Featureklasse 39 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 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 DI- STINCT " 39 Featureklasse: Polygon, Linie, Punkt, Raster oder Text bilden die fünf möglichen Featureklassen

38 3 Grundlagen und Begriffsbestimmungen -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 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-Technologie 40 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

39 3 Grundlagen und Begriffsbestimmungen -33- Der Nachteil von com-technologie ist u.a., dass keine gemeinsam genutzte dll 41 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 COM- Technologie üblich ist, wurde also in.net nachempfunden, um die Konsistenz der Schnittstellenbeschreibungen in beiden Fällen zu wahren. Mit ArcObjects kann der Entwickler alle Funktionen ansprechen, die auch in den 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.

40 3 Grundlagen und Begriffsbestimmungen 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 Konzept der Objektorientierten Programmiersprachen (OOP) Historie: Die Programmiersprachen entstanden aus der Notwendigkeit, immer gleichförmige Arbeitsabläufe bei Maschinen durch einen Algorithmus 42 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 durch- 42 [DUD], Eintrag: Algorithmus= Rechenvorgang, der nach einem bestimmten, sich wiederholenden Vorgang abläuft

41 3 Grundlagen und Begriffsbestimmungen -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 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

42 3 Grundlagen und Begriffsbestimmungen -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 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 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 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.

43 3 Grundlagen und Begriffsbestimmungen -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.

44 4 Anforderungsdefinition und Planung Anforderungsdefinition und Planung 4.1 Anforderungen an das Programm Dieses Kapitel soll erstens im Einzelnen festlegen, welche Funktionen das Programm beherrschen und wie es aufgebaut sein muss, um die in Kap. 1 definierten Vorgaben - nämlich eine valide SLD zu erzeugen - zu erfüllen. Zweitens sollen die Voraussetzungen zum Testen der SLD auf den gewählten Test- Map-Servern erörtert werden. Außer den in Kap. 1 genannten Zielen wurden an das Programm detailliertere 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 Die Geologische Übersichtskarte von Hessen 1: Dazu soll an dieser Stelle zunächst die Struktur und die relevanten Besonderheiten der Geologischen Übersichtskarte von Hessen 1: (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: (oder kurz: GK 25) sind. Die Themen der Geologischen Übersichtskarte sind Lithostratigraphie 43, 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.

45 4 Anforderungsdefinition und Planung -39- graphie 44, Faziesgrenzen 45 und Störungen 46, 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 UMN- Mapserver 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: " Abb. 7 Die GÜK 300 in 10-facher Verkleinerung 44 [Wiki], Eintrag: Die Petrographie (griech. auch Lithologie oder Gesteinskunde) ist das wissenschaftliche Fachgebiet, das sich mit der Beschaffenheit der Gesteine beschäftigt. 45 [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. 46 [APS],217: Eine Störung oder Verwerfung ist eine Bruchfläche, an der auf beiden Seiten eine relative Bewegung des Gesteins parallel zur Bruchfläche stattgefunden hat.

46 4 Anforderungsdefinition und Planung -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 (STRUK- TUR_POLY_1 generalisiert die Geologie großräumig auf das Thema der geologischen Ära 47 ; 2 4 untergliedern dieses Thema immer feiner, zuerst nach der geologischen Periode 48, 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: 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 litho- 47 Ära: Begriff aus der relativen Einteilung geologischer Zeiträume. Unterteilt das Äon des Phanerozoikum (Zeitalter sichtbaren Lebens)in das Paläozoikum ( Mio A), Mesozoikum ( Mio A) und Känozoikum (65 Mio A rezent). 48 Periode: "Feinere" relative Zeiteinteilung in 12 Perioden, beginnend bei Kambrium ( Mio A), bis zum Quartär (1,6 Mio A rezent).

47 4 Anforderungsdefinition und Planung -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 ACID 50 (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 Ein nicht veröffentlichter Standard zur Beschreibung von u.a. petrographischen und lithostratigraphischen Sachverhalten, angelehnt an Standards wie der DIN 4021 und 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".

48 4 Anforderungsdefinition und Planung -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)

49 4 Anforderungsdefinition und Planung -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) 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: 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)

50 4 Anforderungsdefinition und Planung 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 Bedeutung Textsymbol MarkerSymbol LineSymbol FillSymbol 3DChartSymbol Keine Untersymbole SimpleMarkerSymbol, CartographicMarkerSymbol (CharacterMarkerSymbol, PictureMarkerSymbol), ArrowMarkerSymbol, MultilayerMarkerSymbol CartographicLineSymbol (HashlineSymbol, MarkerLineSymbol), SimpleLineSymbol, PictureLineSymbol, MultilayerLineSymbol. SimpleFillSymbol, MarkerFillSymbol, LineFillSymbol, DotDensityFillSymbol, PictureFillSymbol, GradientFillSymbol, MultilayerFillSymbol 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 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.

51 4 Anforderungsdefinition und Planung -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 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 SLD- Spezifikation 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 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

52 4 Anforderungsdefinition und Planung -46- einer www-url) und die programminterne Funktionalität prüft das entstandene SLD- Dokument gegen die Schemadatei von OGC (das Programm müsste hier nur 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 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 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

53 4 Anforderungsdefinition und Planung -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 OGC- Map-Server dienen kann und wie weit er die SLD Spezifikation unterstützt. Darüber hinaus sollten die Tests als Referenz auf einem Open Source-Server 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 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

54 4 Anforderungsdefinition und Planung -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 Linux- Plattformen in Frage kommen. Nachfolgend sind die Komponenten des MS4W aufgelistet: Apache version (Webserver) PHP version (PHP- Bibliotheken) MapServer CGI 4.4.2, beta2 (CGI- Anwendung des Kartenserver) PHPMapScript 4.4.2, 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 (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 Der Server-IP-Adresse lautet: (localhost). Mit dem MS-DOS Kommandozeilenparameter "mapserv v" enthüllt der Mapserver seine CGI-Parameter sowie seine Input/Output-Fähigkeiten: Abb. 11 Fähigkeiten des UMN-Mapserver Wie in Abb. 11 zu erkennen ist, akzeptiert der Mapserver als Input sowohl Shapefiles als auch über die OGR-Bibliothek (Simple Features) die Anbindung einer ArcSDE- Datenbank. Für die Tests auf dem UMN-Mapserver wurde die GÜK 300 in mehrere Shapefiles 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-

55 4 Anforderungsdefinition und Planung -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 LAYER- Objekt angelegt werden. In diesem Objekt sind Layername (NAME), Ort der Daten (DATA) und ebenfalls ein METADATA- Objekt anzulegen. Nachfolgend ein Ausschnitt aus der Verzeichnisstruktur des Mapservers zur 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-

56 4 Anforderungsdefinition und Planung -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 Get- Map- Anfrage: S&VERSION=1.1.1&REQUEST=GetMap&Layers=Guek300_Poly&STYLES=&SLD=htt p:// /maps/sld/guek300.sld&bbox= , , , Konfiguration des ArcIMS am HLUG Der ArcIMS ist am HLUG eingebunden in eine Multiserver-Architektur auf Basis eines LAN mit Sterntopologie (s. Abb. 11): Clients Clients Clients in in in Gebäude Gebäude Gebäude und und und GIS-Server SUN E450, Solaris 7 Zentraler Switch-Router BK-Server SUN E250, Solaris 7 Spezialisierte Server Spezialisierte Server Spezialisierte Server Spezialisierte Server 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:

57 4 Anforderungsdefinition und Planung -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 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 Solaris 9 ESRI-Licence-Manager ArcSDE-Lizenz Map-Server ArcIMS Produkt Geodatenbank-Middleware ArcSDE 8.3 Webserver Apache Servlet-Engine Tomcat WMS Connector WMS Connector 1.0 for ArcIMS Scriptsprachen Entwicklungssoftware Graphikbibliotheken Datei- u. Druckdienste Software für gesicherten https-zugang Hilfssoftware Perl php tar.bz2 gcc pkg.zip gmake pkg.zip gcc (64bit-fähig) Java SDK 2 freetype sol9-sparc-local.gz jpeg-6b-sol9-sparc-local.gz libpng sol9-sparc-local.gz Tiff sol9-sparc-local.gz zlib sol9-sparc-local.gz Samba Openssl-0.9.6g-sol9-sparc-local.gz vnc pkg.zip (grafische Benutzeroberfläche) cpustate-2.5-pkg.zip (Auslastungsüberwachung) Tab. 6 Eingesetzte Software der ArcIMS-Maschine (Quelle: HLUG)

58 4 Anforderungsdefinition und Planung -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 UMN- Mapserver auch, nicht das SLD-Element UserLayer unterstützt), ist aber ansonsten unabhängig von den Definitionen der AXL-Datei. Der Zugriff auf die Daten für den Kartendienst "GUEK300" läuft über eine ArcSDE- Verbindung. Darin gibt es ein Feature-Dataset mit den unter genannten sechs

59 4 Anforderungsdefinition und Planung -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: map&srs=epsg:31467&bbox= , , , &layers=geolog IE.GUEK300_POLY&styles=Style1&SLD= d&format=png&width=250&height=400

60 5 Ergebnisse der Arbeit Ergebnisse der Arbeit 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 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 näher beschrieben werden).

61 5 Ergebnisse der Arbeit -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 SLD- Syntax und -Semantik 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"

62 5 Ergebnisse der Arbeit -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: Double: String: Boolean: i d c b Objects: ArrayList: Struct: Object: al str obj Bsp.: Datentyp Variablenname Klassenebene Methodenebene Flag (Boolean) Switch m_bswitch bswitch Object (z.b. IMxDocument) MXDoc m_objmxdoc objmxdoc Tab. 7 Beispiel Variablennamenskonvention Zur Unterstützung des Verständnisses für die Inhalte und Vorgänge innerhalb der Klassen wurden in den folgenden Unterkapiteln sog. UML-Diagramme 51 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-

63 5 Ergebnisse der Arbeit -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.

64 5 Ergebnisse der Arbeit -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) 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-

65 5 Ergebnisse der Arbeit -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.

66 5 Ergebnisse der Arbeit 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 Nassi- Shneiderman-Diagrammen 52 (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

67 5 Ergebnisse der Arbeit -61- AnalyseLayerSymbology(n Renderer) Speichert alle RendererStructs In ProjectStruct n Renderer UniqueValueRenderer StoreStructUVRenderer(1Renderer) ClassBreaksRenderer SimpleRenderer StoreStructUVRenderer(1 Renderer) SimpleFillSymbol Speichert alle SymbolStructs In RendererStruct n Symbole FillSymbol Untersymbol verzweigen LineSymbol MarkerSymbol New StructSimpleFillSymbol = StoreSimpleFill(SimpleFillSymbol) MarkerFillSymbol LineFillSymbol MultilayerFillSymbol StoreSimpleFill(SimpleFillSymbol) New StructSimpleFillSymbol StructSimpleFillSymbol.Color=SimpleFillSymbol.Color SimpleLineSymbol MarkerLineSymbol MultiLineSymbol StoreSimpleLine(SimpleLineSymbol) New StructSimpleLineSymbol StructSimpleLineSymbol.Color=SimpleLineSymbol.Color New StructSimpleLineSymbol = StoreSimpleLine(SimpleLineSymbol) Return StructSimpleLineSymbol Return StructSimpleFillSymbol Abb. 19 Sequenzdiagramm und Struktogramme der Klasse Analize_ArcMap_Symbols

68 5 Ergebnisse der Arbeit -62- I. Die Verweise: Normalerweise werden Anwendungen, die auf ArcMap zugreifen als VBA- Applikationen innerhalb ArcMap entwickelt. Weil bei dieser Methode die Anwendung als Abkömmling der ArcMap-Instanz fungiert, muss der Entwickler weder Verweise auf diese Instanz setzen noch Umgebungsvariablen initialisieren oder Namensräume 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 Arc- Map über seine Objektbibliothek angesprochen und die volle ArcObjects-Funktionalität benutzt werden. Dazu laufen folgende Prozesse ab: Den Einstieg in die Klasse Analize_ArcMap_Symbols bietet die Funktion 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-Root- Objekt IAppROT den Verweis auf die ArcMap-Session holt. Damit wird ein Application- Objekt MXApplication initialisiert, durch das man über IMXDocument an das aktive Dokument kommt, das die Karte beherbergt. Auch hier gibt es eine Kontrolle, ob 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 erwähnt, die Symbole eines Layers beinhalten. Diesen Vorgang kann man sich am besten als das "Sieben" von lockerem Schüttgut

69 5 Ergebnisse der Arbeit -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, StoreStructU- VRenderer und StoreStructCBRenderer. Wie der Funktionsname schon verrät, dienen die Funktionen nicht ausschließlich der Analyse. An dieser Stelle vermischt sich die Funktionalität der Methoden, da hier teilweise Informationen, die in ArcMap auf 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:

70 5 Ergebnisse der Arbeit ü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 beschrieben, beliebig viele Symbole der gleichen Grundsymbolart übereinander liegen können. Diese Multilayersymbole werden in den entsprechenden StoreMultilayer- Funktionen gespeichert. Dort wird in einer Schleife die komplette Anzahl an übereinandergeschichteten Untersymbolen dieser Grundsymbolart (Polygon, Linie, Punkt) verteilt

71 5 Ergebnisse der Arbeit -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. Stack 53 gespeichert und nicht im Heap 54 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 [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. 54 [Wiki], Eintrag: Heap= Eine Speicherbereich, von dem Speicherabschnitte unterschiedlicher Größe zugeteilt und in beliebiger Reihenfolge wieder freigegeben werden können.

72 5 Ergebnisse der Arbeit -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 KindOfMarker- Struct möglich). Der untere Bereich ist durchweg bei allen Datenstrukturen vorhanden und gleich, da hier Informationen gespeichert werden, die 1. auf Rendererebene abgefragt wurden 2. für alle Symbole gleichermaßen gelten: Das Label des Symbols, die Feldnamen, nach denen klassifiziert wurde und jene Werte der Klassenobergrenze und -untergrenze, für welche dieses Symbol gültig ist (wird nur bei ClassBreaksRenderer benutzt). Layerebene:

73 5 Ergebnisse der Arbeit -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 Feature- Class, 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 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-

74 5 Ergebnisse der Arbeit -68- verarbeitung exemplarisch herausgegriffen. WriteToSLD( ) Schreibe Projekt-SLD-Gerüst und Projekt-Daten n RendererStructs n SymbolStructs PolygonFeature Schreibe Layer-SLD-Gerüst und Layer-Daten LineFeature StructUniqueValueRenderer Schreibe SLD- Filter-Regeln Featureklassen verzweigen: StructClassBreaksRenderer StructSimpleRenderer WritePolygonFeatures(SymbolStruct) PointFeature StructSimpleFillSymbol WritePolygonFeatures(SymbolStruct) StructLineFillSymbol StructMarkerFillSymbol WriteSolidFill(SymbolStruct) Schreibe Symbol-SLD-Gerüst Schreibe Symbol-Daten ( Hole Symbol-Daten: GetValueFromSymbolStruct ( Symboleigenschaft, SymbolStruct ) ) WriteSolidFill(SymbolStruct) GetValueFromSymbolStruct(Symboleigenschaft, SymbolStruct) StructSimpleFillSymbol StructLineFillSymbol StructSimpleMarkerSymbol PolygonColor PolygonBorderWidth Symboleigenschaften verzweigen: Lese PolygonColor aus StructSimpleFillSymbol LinienStruct verzweigen: PolygonBorderColor LinienStruct verzweigen: Return Symbolwert (=String) Lese BorderWidth aus LinienStruct Lese BorderColor aus LinienStruct Abb. 23 Struktogramme der Klasse Output_SLD

75 5 Ergebnisse der Arbeit -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 SLD- Wurzelknotenelement stehen. Darauf wird die Funktion WriteToSLD aufgerufen, die den Aufbau der SLD vornimmt. In einer Schleife werden hier die Inhalte der Projekt-Datenstruktur ausgelesen und 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

76 5 Ergebnisse der Arbeit -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-

77 5 Ergebnisse der Arbeit -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.

78 5 Ergebnisse der Arbeit -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 GetValueFrom- Symbolstruct 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

79 5 Ergebnisse der Arbeit -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 behandelt 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

80 5 Ergebnisse der Arbeit -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 /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 ), aber mit Namespacekürzeln vor.

81 5 Ergebnisse der Arbeit -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 Create- NewFile 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-URI 55 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 Namespace- Managers:.NET besitzt eine komplexe Verwaltung von XML-Funktionalitäten. Will man nun XML- Elemente schreiben und übergibt der Methode CreateElement(ns:xmlElement) des Objekts XMLDocument ein zu schreibendes Element, das einen Doppelpunkt besitzt, so erkennt.net dieses Zeichen als Steuerzeichen zur Separierung von Namespaces (vgl 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. -Empfängern) im Internet und dort vor allem im WWW eingesetzt. URI fassen URL und URN zusammen.

82 5 Ergebnisse der Arbeit -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 XPath- Ausdrücken in eine eigene Collection eingelesen (zur Erinnerung: Die XPath- Ausdrücke repräsentieren den Elternknoten des zu erstellenden Elements). Dann wird für den aktiven Knoten ein XPathNavigator-Element 56 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 XPath- Collection überein, wird eine Ebene zurück navigiert. Irgendwann stimmt ein Knoten mit einem der aus den XPathausdrücke generierten Knoten überein: Der Elternknoten des zu erstellenden Elements ist gefunden und wird aktiv gesetzt. Der Prozess kehrt, wie oben beschrieben, zur Funktion CreateElement zurück und das neue Element kann erzeugt werden. Attribute werden grundsätzlich im zuletzt erzeugten Elementknoten erstellt. Die 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.

83 5 Ergebnisse der Arbeit -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 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 XMLSchemaCollection 57 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 "TRY- CATCH"-Block abgefangen und dem globalen Überprüfungsreport hinzugefügt werden. Tritt einer dieser drei Fälle ein, wird an dieser Stelle mangels gültigen Prüfarguments die Überprüfung abgebrochen. Wenn die Überprüfung der Schemadateien erfolgreich beendet wurde, wird ein XMLValidatingReader-Objekt 58 erstellt und dieses mit einem neuen XMLTextReader initialisiert, der das SLD-Dokument geladen hat. Als nächstes wird ein ValidationEventHandler erstellt, der alle Überprüfungsereignisse des XMLValidatingReader abfängt. Der EventHandler wird initialisiert, indem ihm die "Adresse" der Methode übergeben wird, die die Ereignisbehandlung enthält. In diesem Fall heißt die Methode ValidationEvent. Der Handler muss jetzt mit dem Befehl Add- 57.NET-Help: XmlSchemaCollection kann vom XmlValidatingReader für die 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. 58.NET-Help: XmlValidatingReader implementiert die XmlReader-Klasse und bietet Unterstützung für die Datenüberprüfung. Wenn der Reader die Überprüfung mit Hilfe von Schemadateien vornehmen soll, die in XmlSchemaCollection zwischengespeichert sind, wird die Schemas-Eigenschaft verwendet. Die ValidationType-Eigenschaft gibt an, welche Art der Überprüfung vom Reader durchgeführt werden soll.

84 5 Ergebnisse der Arbeit -78- Handler dem XMLValidatingReader bekannt gemacht werden 59. 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 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 leistet. Teilweise wurden die Implementierungen im Kap unter dem Gesichtspunkt der technischen Umsetzung schon angesprochen. Hier liegt der Schwerpunkt auf den Möglichkeiten der Anwendung. Motherform: Das Programm bietet Unterstützung für benutzerdefinierte Einstellungen. o Das Programm merkt sich letzten Speicherort der SLD und bietet ihn bei der nächsten Sitzung wieder an. o Es wird registriert, ob der Darstellungsbereich in die SLD übernommen 59 Hier wird bewusst der Ausdruck "bekannt machen" verwendet, da es sich bei der Operation nicht wirklich um eine Initialisierung handelt, was sich in der Tatsache der ungewöhnlichen Syntax äußert (keine Klammer und lediglich ein Komma als Separator).

85 5 Ergebnisse der Arbeit -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 SLD- Generierung wieder automatisch zusammenklappt Durch eine Auswahl des Zieldatenspeichers, den der Mapserver benutzt, wird das korrekte Format für die PropertyName in der SLD eingetragen (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 Renderer- Typen 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 erwähnt, ist die Erfassung der Daten in den Funktionen StoreStruct organisiert. Für einen neuen Renderer müsste solch eine Funktion StoreStructNeuer- Renderer erstellt werden. OutputSLD: Für die Ausgabe in SLD-Dokumente sind folgende Renderer implementiert: UniqueValueRenderer (incl. many fields) SimpleRenderer ClassBreaksRenderer

86 5 Ergebnisse der Arbeit -80- Um einen neuen Renderer zu implementieren, müsste dieser in die Funktion Write- ToSLD 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 ) Für die Beschriftung der Symbole in einer Legende wurde für jede Regel (Rule) eines Symbols das Title-Element eingefügt. Als Elementwerte wurden die Klassen-Label der Symbol-Klassen aus der ArcMap-Karte benutzt. Linienstrichlierung sowie Bitmaps als Flächenfüllung sind derzeit nicht im Programm implementiert. XMLHandle: Die XPath-Ausdrücke und die SLD-Elemente werden aus einer Datei gelesen und im Programm verwendet. Damit ist die SLD-Syntax anpassbar an kommende Änderungen der SLD-Spezifikation. Über die XPath-Ausdrücke ist keine Anpassung an Veränderungen der SLD-Element- Hierarchien möglich, da die Abfolge der zu schreibenden Elemente und Attribute im Code festgelegt sind: D.h., wenn ein SLD-Element seinen Platz in der Hierarchie wechselt, muss das Element im Code entweder früher oder später an die schreibende XML- Klasse übergeben werden, da es nun ein anderes Elternelement als vorher besitzt. Diese Tatsache kann die XPath-Navigation nicht kompensieren. ValidateSLD und Validation_Message: Das Schema gegen das geprüft werden soll, wird selbst auf XML-Validität 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

87 5 Ergebnisse der Arbeit -81- die interne Fehlermeldung protokolliert. Das Fehlerprotokoll wird ausgegeben auf einer graphischen Oberfläche und kann bei Bedarf in einer Textdatei abgespeichert werden 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 ). 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-

88 5 Ergebnisse der Arbeit -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. Cursor- Objekt zu durchlaufen und jeweils neue Werte in einer Liste abzuspeichern. Bei der Datengrundlage der GÜK 300 mit knapp 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 SLD- Elemente mit Namespace-Prefixes zu schreiben. Dies konnte durch die überladene.net XML-Methode create erreicht werden, der man zusätzlich zum XML-Element den Namespaceprefix und die Namespace-URL übergibt. Nachdem alle SLD-Elemente durch Namensraum-Kürzel ausgezeichnet waren, konnte

89 5 Ergebnisse der Arbeit -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 schon angesprochen: Man generiert mit der Methode selectnodes der Klasse XMLNode eine Liste aller mit dem XPath- Ausdruck übereinstimmenden Knoten, nimmt davon den letzten Knoten und verfährt weiter wie unter Diese Methode funktionierte aber nur innerhalb eines sog. "XSLT-Kontext". Der.NET- NamespaceManager 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 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:

90 5 Ergebnisse der Arbeit -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 schon ausführlich behandelt. Gesagt sei lediglich, dass PropertyName das zu klassifizierende Feld bestimmt, während Literal den Feldwert bezeichnet, der dieser Klasse entspricht. Werte werden in der OGC Filter Encoding-Spezifikation (anders als in der SLD- Spezifikation) in Literal-Elemente eingeschlossen (s. Abb. 29) Das Element Title entspricht dem Label in ArcMap. Es wird bei der Bildung von Legen-

91 5 Ergebnisse der Arbeit -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 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:

92 5 Ergebnisse der Arbeit 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 SVG 60 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 geclippt 61 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 SVG: Scalable Vector Graphics ist ein durch das W3C definierter XML- Standard zur Beschreibung zweidimensionaler Vektorgraphiken. Neben stufenloser Skalierbarkeit sind Filtereffekte wie z.b. Schattenwurf, Beleuchtung, Weichzeichnung oder Verzerrung möglich. 61 [Wiki], Eintrag: In der Computergraphik spricht man von Clipping, wenn Figuren auf einen bestimmten Bereich begrenzt werden sollen.

93 5 Ergebnisse der Arbeit -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 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 wurde dargelegt, warum in SLD z.zt. keine "echte" Linienschraffur auf Vektorbasis möglich ist (das Element Graphic kennt z.zt. nur Mark und External- Graphic als Kindelemente keine Linie). Um trotzdem eine deutliche Abgrenzung der schraffierten Klassen zu anderen Klassen zu bewerkstelligen, habe ich mich eines "Tricks" bedient:

94 5 Ergebnisse der Arbeit -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

95 5 Ergebnisse der Arbeit -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 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 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".

96 5 Ergebnisse der Arbeit -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 ü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-

97 5 Ergebnisse der Arbeit -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 UMN- Mapserver unterstützt. Er wurde dennoch von mir im Programm eingebaut, da die Möglichkeit der Unterstützung durch einen anderen Mapserver gegeben ist 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

98 5 Ergebnisse der Arbeit -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).

99 5 Ergebnisse der Arbeit -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 und ) die Maßstabsbegrenzungen für den Anzeigemaßstab der Karte in das Programm implementiert.

100 5 Ergebnisse der Arbeit -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

101 5 Ergebnisse der Arbeit -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.

102 5 Ergebnisse der Arbeit 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

103 5 Ergebnisse der Arbeit -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 UMN- Mapserver den Operator PropertyIsBetween. Der logische Operator AND: Zur Klassifizierung nach eindeutigen Werten (in ArcMap: Categories; in ArcObjects umgesetzt durch UniqueValueRenderer) eines Feldes wird der Vergleichsoperator PropertyIsEqualTo benutzt. Wenn nicht nur nach den eindeutigen Werten eines, sondern mehrerer Felder klassifiziert werden soll, werden mehrere Vergleichsoperatoren mit dem logischen Operator AND verkettet. Abb. 48 Der logische Operator AND

104 5 Ergebnisse der Arbeit -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 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:

105 5 Ergebnisse der Arbeit -99- Abb. 50 Ausschnitt der GÜK 300 aus der ArcMap-Originalkarte

106 5 Ergebnisse der Arbeit Abb. 51 Die GÜK 300 auf dem UMN-Mapserver, erzeugt aus einer programmgenerierten SLD Die Darstellung der Karte aus Abb. 51 wurde mit Vektorgraphik ohne Unterstützung von Bitmaps erzeugt. Die folgende Tabelle zeigt eine Übersicht der auf dem UMN-Mapserver getesteten E- lemente und Attribute: SLD-Element unterstützt SLD-Attribut unterstützt NamedLayer UserLayer NamedStyle UserStyle FeatureTypeStyle ja nein ja ja ja

107 5 Ergebnisse der Arbeit Rules ja Min-, MaxScaleDenominator ja Filter ja ElseFilter ja PropertyIsEqualTo ja PropertyIsBetween ja AND ja PointSymbolizer ja Fill ja (im Folgenden CssParameter) fill fill-opacity Size ja Mark ja WellKnownName ja Rotation nein LineSymbolizer ja Stroke ja (im Folgenden CssParameter) stroke stroke-width stroke-opacity stroke-dasharray GraphicStroke ja (s. Stroke) PolygonSymbolizer ja Fill ja (im Folgenden CssParameter) fill fill-opacity GraphicFill ja Graphic ja ExternalGraphic ja ja nein ja ja nein ja ja 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 s. Linkverzeichnis).

108 5 Ergebnisse der Arbeit Test auf der ArcIMS-Plattform Alle für den UMN-Mapserver durchgeführten Tests wurden ebenso für den ArcIMS umgesetzt. Da wesentlich weniger SLD-Funktionen unterstützt sind als bei dem UMN- Mapserver, wird an dieser Stelle auf eine umfangreiche Darstellung von Abbildungen verzichtet. Die folgende Tabelle zeigt die von mir auf dem ArcIMS getesteten Elemente und Attribute. Sie stellt keine vollständige Übersicht der SLD-Tauglichkeit von ArcIMS dar, sondern konzentriert sich hauptsächlich auf die Elemente, die zur Darstellung der GÜK 300 wichtig sind: SLD-Element unterstützt SLD-Attribut unterstützt NamedLayer ja UserLayer nein NamedStyle ja UserStyle ja FeatureTypeStyle ja Rules ja Min-, MaxScaleDenominator ja Filter ja ElseFilter ja PropertyIsEqualTo ja PropertyIsBetween ja AND ja PointSymbolizer ja Fill nein (im Folgenden CssParameter) fill fill-opacity Size nein Mark nein WellKnownName nein Rotation nein LineSymbolizer ja Stroke ja (im Folgenden CssParameter) stroke stroke-width stroke-opacity stroke-dasharray nein nein nein nein nein nein

109 5 Ergebnisse der Arbeit GraphicStroke nein (s. Stroke) PolygonSymbolizer ja Fill ja (im Folgenden CssParameter) fill fill-opacity GraphicFill nein Graphic nein ExternalGraphic nein ja 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:

110 5 Ergebnisse der Arbeit Abb. 52 SLD-WMS für die GÜK 300 auf dem ArcIMS (Die SLD, mit der die Karte aus Abb. 52 generiert wurde, ist dieselbe, welche auch zur Darstellung der GÜK 300 auf dem UMN-Mapserver benutzt wurde.) Zum Vergleich der proprietäre ArcIMS-Kartendienst auf Basis der AXL- Konfigurationsdatei:

111 5 Ergebnisse der Arbeit Abb. 53 Proprietärer Kartendienst der GÜK 300 auf dem ArcIMS Zu beachten sind hier die Unterschiede zum SLD-WMS in der Flächenfüllung und in den Linieneigenschaften (zum Vergleich sind Ausschnitte aus der ArcMap- Originalkarte und die SLD-generierte Darstellung auf dem UMN am Ende des vorigen Kapitels zu finden). Hier sind Flächenschraffuren auf Vektorbasis und Flächenfüllungen auf Rasterbasis möglich. Das bedeutet, dass der ArcIMS diese Möglichkeiten bietet. Beide Karten werden von demselben Programm erzeugt und liefern dennoch 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.

112 6 Zusammenfassung und Ausblick Zusammenfassung und Ausblick 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 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

113 6 Zusammenfassung und Ausblick 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.

114 Verzeichnisse -I- Verzeichnisse

115 Verzeichnisse -II- Literaturverzeichnis [APS] [BUW] [DUD] Frank Press, Raymond Siever. Allgemeine Geologie. Hrsg. Spektrum Akademischer Verlag GmbH, Heidelberg, Berlin, Oxford. Würzburg: Konrad Triltsch, Druck- und Verlagsanstalt GmbH Buhmann/Wiesel. GIS Report Hrsg. Bernhard Harzer Verlag GmbH, Karlsruhe. Rastatt: Greiserdruck GmbH, 2005 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] [GAD] Tim Ormsby, Eileen Napoleon, Robert Burke, Carolyn Groess, Laura Feaster. Getting to know ArcGIS desktop. Hrsg. ESRI. USA: ESRI Press, 2004 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] [HÖM] [HVO] [KKI] [MAS] [MIK] [OGS] [OGW] Hans Murawski, Wilhelm Meyer. Geologisches Wörterbuch. Hrsg. Elsevier GmbH. München: Spektrum Akademischer Verlag, 2004, 11. Auflage Michael Höck, Jochen Manegold. ArcMap Programmierung mit VBA. Hrsg. UISMEDIA Lang & Müller GbR. Legoprint S.p.A., Lavis (TN) 2001 Helmut Vonhoegen. Einstieg in XML. Hrsg. Galileo Computing. Bonn: Galileo Press GmbH, 2002 Sascha Kersken. Kompendium der Informationstechnik. Hrsg. Galileo Computing. Bonn: Galileo Press GmbH, (Ausgabe: E-Book) Duncan Mackenzie, Kent Sharkey. Visual Basic.NET in 21 Tagen. Hrsg. SAMS. München: Markt und Technik-Verlag 2002 Michael Kofler. Visual Basic.NET, Grundlagen, Programmiertechniken, Windows- Anwendungen. Hrsg. Pearson Education. München: Addison Wesley-Verlag, 2002 Open GIS Consortium Inc. Styled Layer Descriptor Implemantation Specification. Hrsg. OGC. RefNum. OGC ; Vers ; Date ; Cat. Proposed OpenGIS Implementation Specification Open GIS Consortium Inc. Web Map Service Implemantation Specification. Hrsg. OGC. Ref- Num. OGC r2.; Vers ; Date ; Cat. OpenGIS Implementation Specification

116 Verzeichnisse -III- Hyperlinkverzeichnis GDI: Internationale Geodateninfrastruktur GSDI: Europäische Geodateninfrastruktur INSPIRE: Deutsche Geodateninfrastruktur GDI-DE: Geodateninfrastruktur des Landes Hessen: Geodateninfrastruktur des Landes Nordrhein-Westfalen: Geoportale: Standardisierung: International Organization for Standardization: World Wide Web Consortium: Open Geospatial Consortium OGC: Mapserver: ArcIMS von ESRI:

117 Verzeichnisse -IV- [UMN] UMN Mapserver: deegree: GeoMedia Web Map von Intergraph: GeoServer und AEDGIS von SICAD: SLD: SLD-Spezifikation (OGC): SLD HOWTO UMN-Mapserver Homepage: Canadian Geospatial Data Infrastructure homepage: Geo-Connections: Geotools: Terrestris Homepage:

118 Verzeichnisse -V- Terrestris: Praxishandbuch WebGIS mit freier Software: Allgemein: [GUR] Geoinformatiklexikon der Universität Rostock: [ITI] IT-Lexikon: [SEH] Selfhtml, Stefan Münz: [VBN] VB.NET: [Wiki] Wikipedia online-lexikon:

119 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: 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

120 Verzeichnisse -VII- Abb. 29 Standardgerüst einer SLD...84 Abb. 30 Punktfüllung in SLD mit transparentem Hintergrund...85 Abb Polygonsymbole in SLD übereinandergelegt...87 Abb. 32 Senkrechte Kreuzschraffur...88 Abb. 33 Schräge Kreuzschraffur...88 Abb SVG-Grundgraphiken übereinander...89 Abb. 35 Liniensymbol mit angepassten CssParameter...90 Abb ü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 Abb. 52 SLD-WMS für die GÜK 300 auf dem ArcIMS Abb. 53 Proprietärer Kartendienst der GÜK 300 auf dem ArcIMS...105

121 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 Tab. 10 Auf dem ArcIMS in Hinsicht auf GÜK 300-Darstellung getestete Elemente/Attribute...103

122 Anhang -a- Anhang

123 Anhang -b- Map-Datei des UMN-Testservers MAP NAME "GUEK300" STATUS ON SIZE IMAGETYPE PNG IMAGECOLOR SHAPEPATH " EXTENT UNITS METERS PROJECTION "init=epsg:4326" END WEB IMAGEPATH "C:/ms4w/Apache/htdocs/tmp/" IMAGEURL " METADATA "wms_title" "GUEK300_POLY" "wms_onlineresource" " END END LAYER "wms_srs" "EPSG:4326" "WMS_FEATURE_INFO_MIME_TYPE" NAME "GUEK300_POLY" TYPE POLYGON STATUS ON DATA "Shape/Guek300_Poly.shp" #PROJECTION # "init=epsg:4326" #END METADATA "wms_title" "text/html" "GUEK300_POLY" "wms_onlineresource" " END END END CLASS END "wms_srs" "EPSG:4326" "WMS_FEATURE_INFO_MIME_TYPE" NAME "All Polygones" OUTLINECOLOR COLOR SYMBOL 0 "text/html"

124 Anhang -c- Workflow des Programms ArcGIS-map to SLD Converter Schematischer Programmablauf Sequentieller Ablauf. Im Wesentlichen 4 Klassen (ohne Validierung) SLD-Datei 6 ArcMap 2 5 Aufrufklasse (Motherform) 1 Steuerdatei (LUT_sld_mapping_file.xml) XML-Funktionsklasse (XMLHandle) 4 3 Legende Programmablauf Datenströme Ergebnis Analyseklasse (Analize_ArcMap_Symbols) Ausgabeklasse (Output_SLD)