deegree 3 Architektur und Anwendungsfelder

Transkript

1 deegree 3 Architektur und Anwendungsfelder Christian KIEHLE, Jens FITZKE und Markus SCHNEIDER Dieser Beitrag wurde nach Begutachtung durch das Programmkomitee als reviewed paper angenommen. Zusammenfassung Der Aufbau von Geodateninfrastrukturen (GDI) hat in den letzten fünf Jahren erheblich an Komplexität gewonnen. Dies liegt zum einen an der weiteren Ausdifferenzierung der zu Grunde liegenden Schnittstellen- und Datenspezifikationen und zum anderen an den steigenden Ansprüchen der Betreiber und Nutzer. Waren GDIs in Vergangenheit vor allem ein Werkzeug zur Datenbereitstellung über Netzwerkprotokolle, so ist heute eine deutliche Tendenz zur Ablösung traditioneller Geo-Informationssysteme (GIS) festzustellen. Dieser Trend stellt die Entwickler von GDI-Komponenten vor neue Herausforderungen, welche sich im Spannungsfeld von innovativen Technologien, hohen Nutzeranforderungen und komplexen (und zum Teil widersprüchlichen) Standardisierungsgrundlagen bewegen. Im Folgenden soll anhand der Weiterentwicklung des deegree-frameworks zur Version 3 dargestellt werden, wie ein weit verbreitetes Open Source-Projekt diese Herausforderungen angeht. Dabei wird insbesondere auf die Softwarearchitektur aber auch auf die organisatorischen Herausforderungen eingegangen, um eine stabile Arbeitsgrundlage zum Aufbau von GDI-Komponenten für die nächsten fünf Jahre bereitzustellen. 1 Einführung Das aus dem Forschungsprojekt EXSE (GIS Experimental Server) der Universität Bonn (Geographisches Institut, Arbeitsgruppe GIS) hervorgegangene deegree-projekt verfolgt seit zehn Jahren das Ziel, Standards des Open Geospatial Consortiums (OGC) sowie der ISO in Form eines Java-basierten Software-Frameworks umzusetzen (GREVE et al. 2007). Dabei ist deegree Freie Software im Sinne der GNU Lesser General Public License (LGPL) und kann somit kostenfrei bezogen und für beliebige Zwecke beliebig oft eingesetzt werden. Dies ist insbesondere für die Nutzung in Forschungs- und Entwicklungsprojekten sowie in Projekten mit geringem Budget für Softwarelizenzen (öffentliche Verwaltung, Nicht- Regierungs-Organisationen, etc.) von Vorteil. Aber auch im Rahmen von Produkten mit herkömmlichem Lizenzmodell ist deegree integrierbar. Der frei verfügbare Quelltext erlaubt es darüber hinaus einer breiten Entwicklergemeinde die Software zu nutzen, weiterzuentwickeln und qualitativ zu sichern. Während deegree in der Version 1 bereits in zahlreichen Produktivumgebungen zum Einsatz kam, konnte mit Erscheinen der Version 2 im Jahre 2005 vor allem im deutschsprachigem Raum eine Vielzahl von Installationen verzeichnet werden. Im Fokus standen vor allem öffentliche Geodateninfrastrukturen zum Aufbau von Raum- und Umweltinformationssystemen. Hier kam deegree als integrierte Programmierbibliothek zum Einsatz, welche die

2 deegree 3 Architektur und Anwendungsfelder 749 Verarbeitung, Integration, Erfassung, Verteilung und Visualisierung von Geodaten ermöglichte. Insbesondere wurden netzbasierte Dienste implementiert, welche den interoperablen Austausch von Geodaten über OGC-konforme Schnittstellen ermöglichten. Der vielfältige Einsatz des deegree-frameworks führte dazu, dass immer speziellere Nutzeranforderungen z.b. die Integration von Sicherheitsmechanismen, die Erzeugung großformatiger Druckvorlagen, die Verwaltung von Projektzuständen, etc. integriert werden mussten. Die ursprüngliche Softwarearchitektur war hierfür nicht ausgelegt. Darüber hinaus wuchsen die zu verarbeitenden Datenmengen in den vergangenen Jahren stark an, so dass die deegreeinterne Datenverarbeitung an ihre Grenzen stieß. Obwohl auch Standards und Diskussionspapiere des Open Geospatial Consortiums Änderungen unterworfen sind und obwohl diese zum Teil widersprüchlich definiert sind, ist eines der Ziele des deegree-frameworks die Konformität zu OGC-Schnittstellen. Aus fachlich-wissenschaftlicher Sicht ist es durchaus fraglich, ob jeder OGC-Standard seine Daseinsberechtigung hat, oder ob durch die Definition von Profilen manche Standards obsolet werden könnten (z.b. stellt ein Sensor Observation Service konzeptionell keine anderen Anforderungen als ein Web Feature Service). deegree strebt hier an, auf Ebene der Schnittstellen und Austauschformate OGC-konform zu sein. Die interne Datenverarbeitung ist in erster Linie an den Anforderungen Performanz, Stabilität und Wartbarkeit des Quelltextes ausgerichtet. Auch wenn die Implementierung vereinzelter OGC-Spezifikationen zum Teil fraglich erscheint, so ist diese auf Erfordernisse des Marktes zurückzuführen. Neben den technischen Randbedingungen wurde auch organisatorisch ein Paradigmenwechsel vollzogen. In der Vergangenheit wurde deegree vor allem von der Firma lat/lon GmbH in Kooperation mit der Universität Bonn entwickelt, vermarktet und für Kundenprojekte angepasst wurde. Die Beiträge aus der internationalen Entwicklergemeinde waren relativ gering, was nicht zuletzt an der hohen Komplexität des Frameworks lag. Seit 2007 ist die Organisationsstruktur verändert worden, was näher in Kapitel 4 beschrieben ist. 2 Softwarearchitektur Die Softwarearchitektur (GORTON 2006, TAYLOR et al. 2009) in deegree 3 basiert auf einem Geometriemodell entsprechend ISO Die Kernbibliothek dient der Verarbeitung raumbezogener Objekte. Diese wird erweitert durch eine Vielzahl von Kodierungen, welche den interoperablen Austausch dieser Geometrieobjekte ermöglichen. Zentrale Kodierung ist hierbei die Geography Markup Language (GML) in verschiedenen Versionen, aber auch Well Known Text (WKT) und Keyhole Markup Language (KML) sind verfügbar. Die Geometrien sowie im weiteren Verlauf die Geoobjekte (Geometrien mit räumlicher Verortung sowie zusätzlichen Attributdaten) werden über eine flexible Datenintegrationsschicht in das System eingefügt. Abbildung 1 gibt einen Überblick über die in deegree 3 verfügbaren Komponenten, welche sich in die Kategorien Dienste (Services), Anwendungen (Applications), Werkzeuge (Tools) und Untersysteme (Subsystems) aufteilen. Auf diesen Komponenten bauen die einzelnen Schichten des Frameworks auf, die im Folgenden beschrieben werden. Die Architektur von deegree 3 folgt stark vereinfacht einer Mehrschicht-Architektur, wie sie im klassischen Softwareengineering beschrieben ist (vgl. SOMMERVILLE 2009).

3 750 C. Kiehle, J. Fitzke und M. Schneider Abb. 1: deegree 3 Komponentenübersicht 2.1 Datenintegrationsschicht Die Datenintegrationsschicht ist in der Lage, direkt PostgreSQL/PostGIS, Shapefiles, Geography Markup Language und Well Known Text zu integrieren. Weitere Datenquellen wie Oracle Spatial, ArcSDE und MySQL sind in naher Zukunft geplant in deegree 2 sind entsprechende Adapter seit langem realisiert. Das flexible PlugIn-Konzept der deegree Datenquellenschicht erleichtert auch die Integration beliebiger alternativer Datenquellen. Neben dem Zugriff auf Dateien und Datenbanken ist auch der kaskadierende Zugriff auf externe OGC-Dienste möglich, was den Aufbau föderierter Geodateninfrastruktur-Komponenten ermöglicht. Ein populäres Beispiel hierfür ist die Integration von OpenStreetMap-Daten ( über diesen Mechanismus. Die interne Verwaltung dieser Datenquellen erfolgt in einem deegree-eigenen Objektmodell, welches an ISO Spatial Schema (ANDRAE 2008) angelehnt ist. Dabei erfolgt ein komplettes objektrelationales Mapping, d.h. die in (Geo-)Datenbanken abgespeicherten Daten können programmatisch als Objekte behandelt werden. Die Integration von Topologie-Operatoren gemäß des 9-IM-Modells (vgl. EGENHOFER & FRANZOSA 1991), sowie die Möglichkeit der Nutzung des Filter Encoding-Standards zur Abfrage räumlicher Daten erleichtern die weitergehende Verarbeitung der geographischen Objekte. Zur Integration von Messdaten steht eine Implementierung des Sensor Observation Services sowie die Kodierung von Sensordaten gemäß Observations and Measurements (COX 2007) und Sensor Model Language (BOTTS 2007) zur Verfügung. 2.2 Datenverarbeitungsschicht Für den Bereich Datenverarbeitung wird auf eine Implementierung der Web Processing Service Spezifikation (SCHUT 2007) zurück gegriffen. Diese ist die zentrale Instanz zur Bereitstellung Geodaten verarbeitender Funktionen. Sie wird beispielsweise zur Imple-

4 deegree 3 Architektur und Anwendungsfelder 751 mentierung der durch das INSPIRE Network Drafting Team definierten Draft Technical Guidance for INSPIRE Coordinate Transformation Services (NETWORK SERVICES DRAF- TING TEAM 2008) genutzt. Die in deegree 3 vorhandene WPS-Implementierung bietet das vollständige Protokoll des OGC Web Processing Service an, ohne den Ersteller von Prozessen mit den Protokolldetails zu konfrontieren. Vielmehr wird eine einfach strukturierte Programmierschnittstelle verwendet, welche drei Lebenszyklus-Methoden zur Verfügung stellt: 1. Prozessinitialisierung (init): Hier können für die Prozessausführung relevante Ressourcen initialisiert werden (z.b. das Laden von Koordinatentransformationssystemen). 2. Prozessausführung (process): Hier wird die Verarbeitungslogik implementiert (z.b. Transformation eines Koordinatenpaares von WGS84 nach Gauß-Krüger 2). 3. Postprozessierung (destroy): Hier können verwendete Ressourcen (z.b. Datenbankverbindungen) wieder frei gegeben werden. Neben den Lebenszyklus-Methoden bietet deegree 3 ein über Java-Schnittstellen definiertes Objektmodell, mit dessen Hilfe die Eingabe- (vgl. Abb. 2) und Ausgabedatentypen der WPS-Prozesse definiert werden können. Hier ist neben dem direkten Zugriff auf Daten von lokalen oder entfernten Datenquellen auch der Zugriff auf Datenströme realisiert, was die Verarbeitung von sehr großen Datenmengen erlaubt. Diese Architektur gestattet es dem Prozessentwickler die Implementierung weitestgehend ohne die Erstellung von prozessunspezifischen Programmcode durchzuführen, da deegree alle Details des Protokolls und der Bereitstellung von Metadaten (z.b. in Form von Capabilities- und DescribeProcess-Dokumenten) übernimmt. Zur Implementierung von Prozessen kann der Entwickler auf die im Rahmen des deegree-frameworks implementierten Funktionalitäten (GML-Verarbeitung, Koordinatentransformation, Erzeugung von WMS-Layern, etc.) zurückgreifen. Abb. 2: Prozess-Input-Datentypen

5 752 C. Kiehle, J. Fitzke und M. Schneider 2.3 Präsentationsschicht Neben den o.a. Weiterentwicklungen von Geodateninfrastruktur-Technologien haben sich in den letzten Jahren insbesondere interaktive Internetanwendungen weiterentwickelt. Durch sogenannte Web 2.0 Technologien (O'REILLY 2005) sind mittlerweile Internetanwendungen realisierbar, die von der Funktionalität her Desktop-Anwendungen sehr nahe kommen; hierfür ist insbesondere die Kombination aus asynchroner XML-Verarbeitung und JavaScript (AJAX) verantwortlich. Derzeit befindet sich eine AJAX-basierte Internetanwendung für deegree in der Planungsphase. Für den Desktopbereich ist bereits die Software igeodesktop (POTH 2008) verfügbar, welche als Client für deegree dient. igeodesktop ist ein vollständiges Desktop-GIS zur Erfassung, Verarbeitung, Analyse und Präsentation von Geodaten. Vornehmlich an Entwickler und Systemadministratoren sind diverse Kommandozeilenwerkzeuge gerichtet, welche die interaktive Kommunikation mit verschiedenen Diensten (z.b. WPS), die Integration von Geodaten, sowie die Nutzung anderer Funktionalitäten erlauben. 2.4 Diensteschicht Die Diensteschicht kapselt alle Funktionalitäten des deegree-frameworks über OGC-konforme Schnittstellen. Derzeit stehen hier folgende Dienste bereit: Catalogue Service Web (CSW) Sensor Observation Service (SOS) Web Coverage Service (WCS) Web Coordinate Transformation Service (WCTS) Web Map Service (WMS) Web Feature Service (WFS) Web Processing Service (WPS) Web Perspective View Service (WPVS) Um auch mittelfristig eine Konformität zu Spezifikationen von INSPIRE sowie Standards der Mainstream-Informationstechnologie zu bewahren, ist als zusätzliches Anwendungsprotokoll eine SOAP-Implementierung in deegree 3 verfügbar, welche transparent vor beliebige Dienste geschaltet werden kann. 3 Anwendungsfelder 3.1 Forschungs- und Entwicklungsprojekte Derzeit ist deegree 3 in drei Forschungs- und Entwicklungsprojekten mit jeweils unterschiedlichen Schwerpunkten im Einsatz. Im Projekt GDI-Grid ( wird die effiziente Nutzung von Grid-Computing-Technologien für die raumbezogene Datenverarbeitung untersucht. Im Rahmen dieses Forschungsprojektes werden vor allem die deegree 3- Dienste Web Processing Service, Web Feature Service sowie Web Coverage Service eingesetzt. Auf Basis dieser Dienste, welche dahingehend erweitert wurden, dass sie in einer Grid-Computing Infrastruktur lauffähig sind (KIEHLE et al. 2008), werden Hochwas-

6 deegree 3 Architektur und Anwendungsfelder 753 sersimulationen, Evakuierungsszenarien sowie Lärmausbreitung in bebauten Gebieten berechnet. Dabei kommt dem Web Processing Service eine besondere Bedeutung als geodatenverarbeitenden Dienst zu: Mithilfe verschiedener WPS-Instanzen werden Arbeitsabläufe (workflows) im Grid gekapselt und können so über eine einheitliche, OGC-konforme Schnittstelle angesprochen werden. Dadurch ist im Ansatz ein verteiltes GIS entstanden, welches die Prozessierung großer Datenmengen in einer dezentralen Rechnerinfrastruktur ermöglicht. Im Rahmen des Projektes EDIM (Earthquake Disaster Information System for the Marmara Region, Turkey, wird ein Frühwarnsystem für Erdbebenereignisse im Großraum Istanbul aufgebaut, wobei durch verschiedene Sensornetzwerke seismische Ereignisse aufgezeichnet werden. Diese Sensoren werden durch einen deegree 3 Sensor Observation Service (SOS) in eine Geodateninfrastruktur integriert. Die Integration von Echtzeitdaten ist hier vor allem für Experten aus dem Bereich Frühwarnung relevant. Um diese Daten besser interpretieren zu können, wurden weitere Komponenten zur Visualisierung dieser Daten in Form von Diagrammen, Kartodiagrammen und Web Map Services eingesetzt. Das Projekt Flex-I-Geo-Web fokussiert die Bereitstellung flexibler Komponenten für einen webbasierten Software-Baukasten. Mit diesem sollen Nutzer in die Lage versetzt werden, auf Basis verteilter Dienste und Daten Geodatenportale zu erstellen. Die Geodatenportale sollen neben den Funktionen eines klassischen Auskunftssystems auch Analysefunktionalitäten über Web Processing Services anbieten, z.b. um Baulückenkataster zu erstellen. deegree 3 dient dabei als Basistechnologie zum Aufbau der Projektgeodateninfrastruktur, in erster Linie wird hier jedoch die deegree 3-Geodatenportaltechnologie genutzt D-Visualisierung Die 3D-Geodatenvisualisierung ist in deegree bereits seit 2003 mit einer Implementierung des OGC-Dienstes Web Terrain Service enthalten (FITZKE et al. 2003). Dieser inzwischen als Web Perspective View Service bekannte Dienst liefert über eine standardisierte Schnittstelle Bilder mit 3D-Ansichten und ist in seiner Funktionsweise mit dem Web Map Service vergleichbar. Im Rahmen der Entwicklung von deegree 3 wurde diese Komponente vollständig neu erstellt. Wesentliche Anforderungen an die Implementierung, insbesondere aus dem Bereich der Visualisierung von 3D-Stadtmodellen, waren dabei: Unterstützung der OGC-Schnittstelle WPVS Hohe Performance auch bei großen Datenbeständen, einschließlich Gebäudemodellen Unterstützung von Prototypen und Billboards, beispielsweise für Stadtmobiliar CityGML- und VRML-Schnittstelle zum Datenimport Die in diesem Zusammenhang realisierte Multiresolution-Technologie zum Zugriff auf große Datenbestände, wie es beispielsweise bei hochaufgelösten digitalen Geländemodellen der Fall ist, basiert auf Forschungsergebnissen im Bereich der Computergraphik (CIGNONI et al. 2003/2005). Der in der Version 2 noch enthaltende Grundgedanke der Nutzung von OGC-Schnittstellen auch innerhalb der deegree-api wurde nun beim Zugriff auf Rasterdaten verworfen. Bei der 3D-Visualisierung werden Geländetexturen wie beispielsweise

7 754 C. Kiehle, J. Fitzke und M. Schneider hochaufgelöste Luftbilder nicht mehr vom internen WMS oder WCS geliefert, sondern direkt aus unkomprimiert abgelegten Grid-Strukturen gelesen. Ein weiteres wichtiges Element bei der Performance-Verbesserung im Vergleich zur alten Lösung in deegree 2 ist die Verwendung eines maßstabsabhängigen Qualitätsmodells für 3D-Geoobjekte (Abb. 3). Mit diesem Ansatz können 3D-Geodaten für verschiedene graphische Auflösungsstufen abgelegt werden. Die Erzeugung der 3D-Ansicht einer Stadtlandschaft von über 750 km², mit ca Gebäudeobjekten, einem Geländemodell mit einer horizontalen Basisauflösung von 1 Meter und einem mit 10 cm aufgelösten Luftbild als Geländetextur ist somit mit vertretbarer Anfragezeit (unter 5 Sekunden) in beliebige Web-Applikationen integrierbar (Abb. 4). Abb. 3: Maßstabsabhängiges Qualitätsmodell für 3D-Geoobjekte Abb. 4: 3D-Szene der Stadt Bonn mit Gelände- und Gebäudemodell

8 deegree 3 Architektur und Anwendungsfelder XPlanung In der E-Government-Initiative XPlanung wird seit 2004 ein geometrisch/semantisches Datenmodell und ein GML-basiertes Austauschformat (XPlanGML) für die Festsetzungen und Regelungen der Bauleitplanung und Regionalplanung entwickelt (u.a. GDI-DE ). Im deegree-projekt wurde bereits sehr früh eine Umsetzung dieses Standards realisiert (Müller 2006). In deegree 3 wurde die Unterstützung von XPlanGML erweitert und insbesondere die Darstellungsweise der Pläne im WMS nochmals verbessert. Unter Verwendung des transaktionalen Web Feature Service können nun Planinstanzen entsprechend XPlanGML 2.0 und 3.0 in eine Geodatenbank geladen werden, wobei Objekt-Verweise (XLinks) innerhalb des GML-Dokuments vollständig abbildbar sind. Das besondere an der Persistenzschicht, mit der die Objektstrukturen in relationale Datenbankstrukturen übertragen werden, ist die Strukturflexibilität: Das gesamte GML-Dokument kann, ergänzt um wenige Index- Informationen, als Ganzes in einem Binary Large Object (BLOB) gespeichert werden, oder aber es werden Teile der Dokumentstruktur oder auch der gesamte Objektbaum relational aufgelöst. Auf diesen Datenbankstrukturen setzt der WMS auf, um die XPlanGML-Daten entsprechend den einschlägigen Vorschriften zu visualisieren. Wesentliche Änderungen gegenüber der Implementation in deegree 2 sind hier hinsichtlich der Darstellung verbesserte (siehe Abb. 5) und performanceoptimierte Rendering-Prozesse sowie, ebenso wie beim 3D-Dienst WPVS, der Wegfall unnötiger interner Zugriffswege in der API. Abb. 5: Komplexe Zeichenvorschriften zur Visualisierung von XPlanGML 4 Organisatorische Aspekte Bereits seit der Gründung des deegree-projektes (früher: JaGo) im Jahr 2000 stehen Universität Bonn und lat/lon GmbH (früher GbR) für die Entwicklung und Verfügbarkeit als Freie Software. Mit zunehmender Wahrnehmung des Projektes und Nutzung seiner Software wurden vermehrt Maßnahmen zur Unterstützung der Community-Prozesse durchgeführt. Mit den Standard-Werkzeugen Mailing-Listen, Wiki und Bug-Tracker wurden bereits früh wichtige Elemente zur Zusammenarbeit im Projekt etabliert. Ein weiterer Schritt zu mehr Transparenz und Qualität wurde Mitte 2008 mit dem sog. Inkubationsprozess in der Open 1 Aktuelle Informationen zu XPlanung sind im Internet-Angebot von Deutschland Online unter verfügbar.

9 756 C. Kiehle, J. Fitzke und M. Schneider Source Geospatial Foundation (OSGeo) begonnen. Mit der Inkubation werden Open Source-Projekte in vollwertige OSGeo-Projekte überführt, wobei wichtige Qualitätssicherungsschritte ausgeführt werden müssen. In diesem Zusammenhang wurde eine transparente Organisationsstruktur, bestehend aus technischer Leitung und strategischem Management, etabiliert, Richtlinien zur Mitwirkung am Projekt definiert und der gesamte Code-Bestand einem Review hinsichtlich des Copyright unterzogen. Die Ergebnisse sind im OSGeo-Wiki 2 dokumentiert. 5 Bewertung und Ausblick Mit deegree 3 ist eine konsequente Weiterentwicklung des GDI-Frameworks vollzogen worden. Neben der Anpassung auf neue Basistechnologien (insbesondere Java 1.6) sowie dem Umstieg von einer baumbasierten XML-Verarbeitung hin zu einer Streaming-basierten XML-Verarbeitung, konnten deutliche Performancegewinne erzielt werden. Dies ermöglicht die effiziente Verarbeitung von sehr großen Geodatensätzen. Die Unterstützung aktueller OGC-Protokolle, insbesondere Web Processing Service sowie Spezifikationen des Sensor Web Enablements weist den Weg in die Zukunft von Geodateninfrastrukturen: die Integration von Echtzeitdaten sowie die Verfügbarkeit von Analysefunktionalitäten für verteilte Geodaten. deegree 3 wird bereits in einigen Projekten produktiv eingesetzt. Die ständige, aktive Teilnahme am Standardisierungsprozess des Open Geospatial Consortiums garantiert dabei weiterhin eine hohe Standardkonformität sowie eine zukunftsweisende Integration von Technologien. Danksagung Teile der hier vorgestellten Ergebnisse sind mit Mitteln des BMBF im Rahmen des Geotechnolgien-Förderprogrammes sowie mit Mitteln des BMBF im Rahmen der D-Grid-Initiative gefördert worden. Eine weitere Förderung erfolgt im Rahmen des Europäischen Fond für Regionale Entwicklung (EFRE) durch das Land Nordrhein-Westfalen. Die Autoren danken diesen Förderinstitutionen für ihre Unterstützung. Darüber hinaus danken die Autoren Frau Anne Loos für die Redigierung des vorliegenden Textes. Literatur ANDRAE. C. (2008): OpenGIS essentials: Spatial Schema ISO und ISO vorgestellt und erklärt. Wichmann. BOTTS, M. (2007): OpenGIS Sensor Model Language (SensorML). ( ). CIGNONI, P., GANOVELLI, F., GOBBETTI, E., MARTON, F., PONCHIO, F., SCOPIGNO, R. (2003): BDAM Batched Dynamic Adaptive Meshes for High Performance Terrain Visualization. In: BRUNET, P. & FELLNER, D. (Eds.): Proceedings of Eurographics 2003, 22 (3), S

10 deegree 3 Architektur und Anwendungsfelder 757 CIGNONI, P., GANOVELLI, F., GOBBETTI, E., MARTON, F., PONCHIO, F., SCOPIGNO, R. (2005): Batched Multi Triangulation. In: IEEE Visualization, S. 27. COX, S. (Hrsg.) (2007): Observations and Measurements Part 1 Observation schema. ( ). O. A. (2009): deegree Wiki. ( ). EGENHOFER, M. J. & FRANZOSA, R. D Point-set topological spatial relations. In: International Journal of Geographic Information Systems, 5/2, S FITZKE, J., GREVE, K., MÜLLER, M., POTH, A. (2003): Deegree ein Open-Source-Projekt zum Aufbau von Geodateninfrastrukturen auf der Basis aktueller OGC- und ISO- Standards. In: GIS 9/2003, S GDI-DE GESCHÄFTS- UND KOORDINIERUNGSSTELLE GDI-DE (2007): Modellprojekt XPlanung Abschlussbericht Ein Beitrag zum Aufbau der Geodateninfrastruktur in Deutschland. Version GDI_DE_XPlanung.pdf ( ). GORTON, I. (2006): Essential Softrware Architecture. Springer. GREVE, K., POTH, A., MÜLLER, M. & FITZKE, J. (2007): Degree-Projekt. In: GIS-Business, 6/2007, S KIEHLE, C., KEUCK, C. J. & GREVE, K. (2008): Integration von Geodateninfrastrukturkomponenten in Grid-Computing-Umgebungen. In: STROBL, J. et al. (Hrsg.): Angewandte Geoinformatik Wichmann, S MÜLLER, M. U. (2006): Visuelle Umsetzung der Planzeichenverordnung mit SLD im Rahmen des Xplanung-Projektes. In: STROBL, J. et al. (Hrsg.): Angewandte Geoinformatik Wichmann, S NETWORK SERVICES DRAFTING TEAM (2008): Draft Technical Guidance for INSPIRE. Technical_Guidance_Coordinate_Transformation_Services_v1.0.pdf ( ). SOMMERVILLE, I. (2009): Software Engineering 8. Addison-Wesley. TAYLOR, R. N., MEDVIDOVIC, N. & DASHOFY, E. (2009): Software Architecture: Foundations, Theory, and Practice. John Wiley & Sons.