Konferenz 2009/Erfahrungen WebGIS

Der große Äpfel/Birnen Vergleich - Erfahrungen mit verschiedenen WebGIS Software Tools Till Adams Marc Jansen

Einleitung

„Wer nur einen Hammer hat, für den ist alles ein Nagel“. Wer daneben aber auch noch einen Schraubenzieher, eine Zange und anderes Werkzeug besitzt, wird als Heimwerker bessere Resultate erzielen. Auch die OpenSource GIS Welt diversifiziert sich zunehmend. Dies ist unserer Meinung nach ein Ausdruck dafür, daß für verschiedene Anforderungen auch unterschiedliche Werkzeuge benötigt werden - oder mit anderen Worten ausgedrückt, in der IT- Branche allgemein, wie auch beim Aufbau einer WebGIS Architektur im speziellen, ist es notwendig, seinen Blick offen zu halten und für unterschiedliche Fragestellungen auch die Werkzeuge zu benutzen, die dafür am Besten geeignet sind und nicht zwingend die Werkzeuge, die man am besten beherrscht, so umprogrammieren, daß Sie das tun, was man möchte.

Die Autoren entwickeln gemeinsam seit mehreren Jahren maßgeschneiderte WebGIS Lösungen für verschiedenste Fragestellungen von kommunal bis universitär, in unterschiedlichen Umgebungen und Orten dieser Welt von Qatar bis Kopenhagen. Wir wollen in diesem Vortrag zunächst einen Überblick über die unterschiedlichen Anforderungen an ein WebGIS Projekt sowie über die unterschiedlichen Software-Tools geben. Grundsätzlich vergleichen wir hier, wie aus dem Titel bereits ersichtlich, Äpfel mit Birnen. Also Objekte, die sich vielleicht nur teilweise vergleichen lassen. Zudem wollen wir auch nicht verschweigen, daß es auch noch Quitten, Pfirsiche und Kirschen gibt, die wir hier jedoch nicht betrachten wollen – dafür wäre sicher eine ganze Biologie-Vorlesung vonnöten. Grundsätzlich erhebt dieser Aufsatz nicht den Anspruch wissenschaftlich zu sein, sondern soll Denkanstösse aus der Praxis liefern. Als ein Beispiel einer mehr wissenschaftlicheren Untersuchungsansatzes sei hier auf die Diplomarbeit von E. Schütze [1] verwiesen.

Dennoch soll nach einem Überblick versucht werden, anhand von Projektbeispielen der letzten Jahre, die Entscheidung für die ein- oder andere Software zu beleuchten. Dazu bemühen auch wir das Prinzip der Reduktion von Komplexität, weshalb wir natürlich hier unseren eigenen Werkzeugkasten öffnen, der sicherlich nicht allumfassend ist, aber doch auf einen reichen Erfahrungsschatz zurückblickt. Selbst schon über die Auswahl des Betriebssystems liesse sich an dieser Stelle episch diskutieren. Das Ziel des Vortrages ist es nicht, daraus Handlungsanweisungen im Sinne eines Entscheidungsdiagrammes abzuleiten, sondern vielmehr Ideen zu entwickeln, die dem Leser aufgrund seiner eigenen Erfahrung in Verbindung mit den hier vorgestellten Gedanken helfen sollen, seine eigenen Entscheidungen zu fällen bzw. bereits gefällte Entscheidungen zu hinterfragen.

Überblick

Als erstes wollen wir eine kurze Definition unserer Sichtweise eines WebGIS geben: „Ein WebGIS stellt GIS-Funktionalität und raumbezogene Daten aus unterschiedlichen Quellen im Internet bereit und bietet dem Benutzer die Möglichkeit, intuitiv Antworten auf räumliche Fragestellungen zu finden. Das System besteht dabei aus unterscheidlichen Komponenten; vom Server über Datenhaltung, Kartenserver bis hin zu dem Clienten mit seinen Funktionen.“ [eigene Definition] Daraus wird deutlich, daß ein webbasiertes GI-System aus verschiedenen Komponenten besteht. Eine Hauptanforderung an ein solches System ist daher der modulare Aufbau aus Einzelkomponenten, die idealerweise über definierte Schnittstellen kommunizieren sollten um so den späteren Austausch einzelner Komponenten problemlos, oder zumindest so zu ermöglichen, daß nicht das komplette System umgebaut werden muß. Tabelle 1. gibt einen Überblick über die wichtigsten Anforderungen an ein WebGIS-Projekt. Jedes WebGIS Projekt hat seinen eigenen Charakter, der sich aus der Fragestellung, den beteiligten Organisationen und Personen als auch aus dem Fokus, Benutzern, Daten u.v.m. ergibt. Dazu kommt natürlich die zentrale Fragestellung, sowie die Frage nach den benötigten Werkzeugen. Daraus ergeben sich eine Fülle von Fragen, die vor dem eigentlichen Projektbeginn geklärt werden sollten: Sind die künftigen Benutzer Fachleute oder soll das Entwickelte jeden ansprechen? Wird das Projekt in eine bestehende Architektur integriert ? Welche Datenquellen habe ich bzw. welche möchte ich einbinden? Welches Budget steht mir zur Verfügung? Soll die Anwendung im Intra- oder Internet laufen? uvm.

Tabelle 1: Übersicht Anforderungen an ein WebGIS (IT) Projekt Anforderung Kurzerläuterung Fragestellung Was ist der Fokus des Projektes, Alleinstellungsmerkmal Benutzer Welche Benutzer wird das System haben (techn. Hintergrund) Entwicklung Aufwand, Budget, Eigenleistung, Vergabe Umgebung/Architektur Integration in bestehende Architekturen, Stand-Alone Server Anforderungen/Features Benutzerführung, Werkzeuge, Spezialfunktionen Daten Eigene Daten, Datenimport, externe Dienste usw. Pflege und Updates Laufzeit, Wer pflegt welche Komponenten Schnittstellen API, OWS, etc. Die obige Liste erhebt nicht den Anspruch der Vollständigkeit. Ebenso könnten weitere Anforderungen wie Sicherheit der Anwendung, Flexibilität, rechtliche Aspekte odereinfach Kundenvorgaben aufgeführt werden. Welche der Punkte nun als wichtig oder weniger wichtig eingestuft werden, wäre wiederum eine Wissenschaft für sich, da sich zunächst die Frage der Sichtweise stellen würde: Bin ich Projektleiter, Kunde oder Entwickler? Grundsätzlich sollte aber unbestritten sein, daß der Fokus auf der möglichst einfachen Entwicklung mit möglichst einfacher Bedienung und möglichst einfacher Pflege im Vordergrund stehen sollte. Eine Matrix oder ein Entscheidungsdiagramm, welche das Gewicht der unterschiedlichen Komponenten aufgrund der eigenen Anforderungsliste aufzeigt, kann als wertvoller Leitfaden und als Grundlage für die Software-Entscheidung verwendet werden. Grundsätzlich sind aber alle Entscheidungen für oder gegen eine Software auch von persönlichen Präferenzen, also nicht metrischen Kriterien, geleitet. Vor dem Hintergrund der aufgelisteten Anforderungen wollen wir nun einen Überblick über diverse Softwarekomponenten aus dem OpenSource Bereich geben, die in WebGIs Projekten zum Einsatz kommen. Der Fokus liegt dabei im Bereich der GIS-Server, sowie Clientkomponenten, aber auch bei dieser Auflistung gilt unser Prinzip der Reduktion von Komplexität.

Tabelle 2: Überblick über Client und Mapserver Komponenten aus dem OS Bereich Software Kurzbeschreibung Link OpenLayers „Free Maps for the Web“ [2] Mapbender „Software und Portal für Geodaten Management“ [3] P-Mapper Mapserver PHP/Mapscript Framework [4] Mapfish Web 2.0 Mapping application framework [5] Mapbuilder Mapping made easy!“ [6] iGeoPortal „Basis für Web-gestützte GDI-Clients“ [7] GeoExt „Groundwork for creating web-mapping applications“ [8] Deegree „Free Software for Spatial Data Infrastructures“ [9] UMN Mapserver „Open Source platform for publishing spatial data in the web“ [10] GeoServer „Share and edit geospatial data in the internet“ [11] Grau hinterlegte Komponenten gehören dabei der Gruppe der Kartenserver an, alle anderen sind Clienten, aber auch teilweise auf andere Komponenten aufsetzende Frameworks Als Beispiel sollen hier MapFish, was als Backend für OpenLayers fungiert oder P-Mapper, der auf UMN Mapserver aufsetzt genannt werden. Wir wollen an dieser Stelle nicht verschweigen, daß zu einer WebGIS Architektur noch weitere Komponenten gehören, angefangen von der Hardware, dem Betriebssystem, dem Webserver, der Datenhaltung usw., möchten uns aber hier auf die im Titel genannten eigentlichen WebGIS-Werkzeuge konzentrieren.

Ausgewählte Komponenten

Etwas genauer werden wir uns nun jeweils zwei der oben aufgelisteten Komponenten anschauen. Exemplarisch haben wir dazu die Komponenten ausgewählt, bei denen unser Erfahrungsschatz am umfassendsten ist. Dies sind GeoServer und UMN Mapserver für die Kartenserver sowie Mapbender und OpenLayers für die Webmapping Clients. Grundsätzlich sollte aber auch das Projekt oder die Software, die man verwenden möchte selber betrachtet werden. So wäre es jetzt beispielsweise fatal als zentrale Komponente ein OpenSource Projekt wie z.B. MapBuilder einzusetzen, denn MapBuilder wurde von Steve ottens aus dem Project Steering Committee auf der FOSS4G 2008 als „tot“ erklärt [12]. Die Energie der Entwickler wird fortan in die Weiterentwicklung von OpenLayers fliessen. Daneben sind für Wahl der geeigneten Komponenten auch weiche Faktoren wie eine Art von Feeling notwendig. Dieses Feeling gibt gefühlte Sicherheit für das Fortbestehen der verwendeten Komponente und kann sich aus dem Alter des Projektes, Releasetaktung, Grösse der Community, potentiell vorhandenen Dienstleistern, Architektur des Projektes usw. ableiten. Auch für OS-Projekte gibt es einen Wettbewerb, der Projekte hochkommen und vergehen lässt, andere jedoch eine breite Basis an Anwendern und Entwicklern finden.

Kartenserver

Die Kartenserver bilden die Brücke zwischen Daten und Datendiensten auf der einen, als auch der Benutzeroberfläche auf der anderen Seite. Vom Benutzer angeforderte Karten werden als Kartenbild erzeugt und an den Clienten ausgeliefert bzw. über de nWFs angeforderte Features als XML ausgeliefert und vom Clienten interpretiert.. Das Resultat beider Softwarekomponenten wird mitunter dasselbe sein, denn der Benutzer vermag unter Umständen eine Karte nicht dahingehend unterscheiden, ob diese nun von einem GeoServer oder UMN Mapserver oder anderem Kartenserver geliefert wurde. Dennoch gibt es zwischen beiden Komponenten erhebliche Unterschiede, insbesondere in der Technologie, der Funktionalität aber auch in der Konfiguratuon. So benötigt GeoServer eine Umgebung zur Ausführung von Java-Code auf Webservern, z.B. den Apache Tomcat (Application Server), während der UMN Mapserver als CGI-Skript dies nicht benötigt. Daher kann letztgenannter keine Session zwischen Client und Server persistent nutzen. Insofern ist rein funktionell beim UMN Mapserver nicht mit einer Erweiterung der WFS Funktionalität hin zum transaktionalen WFS zu rechnen [13]. Dies wiederum ist aber eine Funktion, die der GeoServer hingegen bietet. Bei der Konfiguration kann beim GeoServer vieles über die mitgelieferte Konfigurationsoberfläche bewerkstelligt werden. Der UMN Mapserver benötigt seine Konfigurationsdatei, das sogenannte Mapfile. Dafür können viele Funktionen und insbesondere auch eine sicherlich deutlich ausgereiftere Symbolisierung über das Mapfile angesprochen und definiert werden. In der folgenden Auflistung verweisen wir auf die speziellen Stärken der jeweiligen Software, die für uns als Entscheidungskriterium dient.

UMN Mapserver Symbolisierung Flexibilität Geschwindigkeit [13] verschiedene Datenquellen

GeoServer WFS-T Konfiguration über Oberfläche konsequente Trennung von Datenquelle und Repräsentation Geschwindigkeit [13]

Webmapping-Clienten Die (Webmapping) Clienten ermöglichen die Interaktion des Benutzers mit den angebotenen Kartendaten bzw. den Kartenservern. Der Client muß in der Lage sein, die unterschiedlichen Dienste anzusprechen und Karten (meist als Bilddateien) entsprechend anzuzeigen. Idealerweise bringt der verwendete Client schon möglichst viel der Funktionalität mit, die später benötigt wird. Im Grunde kann man die hier vorgestellten Clienten nur in Teilen vergleichen, da der Fokus dieser beiden Clienten ein ganz unterschiedlicher ist. Während der Fokus von OpenLayers eher auf „WebMapping und Web 2.0“ und damit verbunden auf der Integration von möglichst vielen verschiedenen Datenquellen – OWS konformen wie auch proprietären wie Google, Yahoo etc. - liegt, konzentriert sich Mapbender eher auf die Verwaltung von OWS Diensten und bietet ein ausgereiftes Backend.

OpenLayers viele Datenquellen (OWS, Google+Yahoo+MSVE API, ArcIMS etc.) reines JavaScript ohne serverseitige Dependenzen hohe Flexibilität besonders im Zugriff auf OpenLayers Objekte leichte Integration und Erweiterung (andere externe Bibliotheken)

Mapbender Benutzeradministration und Nutzerverwaltung, OWS Portal schnelles Erstellen einer Kartenoberfläche durch Administrationsoberfläche Einstieg ohne Programmierkenntnisse

Projektbeispiele und Diskussion

Als Entscheidungshilfe in unseren Projekten welcher Client nun der richtige ist, reicht oft der Blick auf die gewünschten Datenquellen aus. Viele offene Anwendungen wollen Karten der bekannten OSM, Google, Yahoo oder MS Virtual Earth Dienste einbinden. Ein weiterer Punkt ist oft die leichte Integration in bestehende Frameworks (Ruby onRails, Symfony, CMS) und die Interaktion mit bestehenden Funktionen derselben. Konzentriert man sich jedoch auf die Orchestrierung von OWS Diensten bietet Mapbender dazu spezifische Funktionalität. Wichtig ist zudem oft die Frage, ist die Karte überhaupt der Schwerpunkt oder ist diese lediglich ein Element der gesamten Anwendung? Unserer Erfahrung nach ist es deutlich einfacher dynamische Komponenten, wie z.B. aus Datenbankabfragen Themenlayer zur Laufzeit hinzufügen oder das Highlighten von Objekten zu bewerkstelligen, wenn man über JavaScript direkten Zugriff auf alle Objekte des Kartenclienten hat. Dies wiederum spricht deutlich für die Verwendung von OpenLayers. Einen Eindruck davon vermittelt Abbildung 1 als Screenshot aus einem unserer Projekte mit der Thematik dynamisch Strecken von Entsorgungsfahrzeugen anzuzeigen. Nutzer können dynamisch eine Datenbank mit einem QueryBuilder abfragen und sich alle Treffer als Tabellen-Grid und auf der Karte anzeigen lassen. Aufgrund der anforderung Online Daten digitalisieren zu können, wurde hier als Kartenserver GeoServer eingesetzt. Abb. 1 Interaktion OpenLayers mit komplexer Benutzeroberfläche

Steht der Portalcharakter und auch viele GIS-spezifische Funktionen im Vordergrund, wie dies z.B. bei unserem Projekt „Chemieatlas Ruhrgebiet“ [15] der Fall war, so lassen sich bestehende Funktionen des Mapbender nutzen und minimieren so den Entwicklungsaufwand. Abgesehen davon stehen meistens die Fragestellung und die anvisierten Benutzer im Vordergrund – so bietet die OpenLayers Oberfläche aufgrund der an das weit verbreitete GoogleMaps Interface angelehnte LookFeel bereits ein Aussehen, welches vielen Benutzern vertraut ist. Die Kartenoberfläche des Mapbenders ist zwar prinzipiell frei konfigurierbar, insbesondere wenn mit eigener Programmierung etwas nachgeholfen wird, dennoch erinnern die meisten Mapbender Oberflächen oft an die Portierung eines Desktop GIS in das Internet und bieten für viele WebMapping- Anwendungen meist auch zu viele Funktionen (was natürlich kein Verschulden der Software, an sich sondern das des Administrators ist). Dennoch kann gesagt werden, das in Projekten, in welchem bei uns Mapbender verwendet wurde, entweder die Lösung schnell aufgebaut werden musste – die Konfiguration der Oberfläche über das Backend kam uns hier zugute – oder der gewünschte Portalcharakter wie in Chemieatals oder auch dem Kartenserver der Stadt Soest [16] eine gewichtige Rolle bei der Entscheidung gespielt hat.

Bei der Entscheidung welcher Kartenserver verwendet wird, sieht die Welt schon wieder etwas anders aus. Aufgrund der Tatsache, daß beide betrachteten Kartenserver lizenzkostenfrei einsetzbar sind und sich gegenseitig auch nicht stören, ist hier eine Anwendung beider möglich. Bildlich gesprochen - die Grösse des Schraubenschlüssels ist frei wählbar. So kann beispielsweise in derselben Anwendung des NABU [17] alle WMS von einem UMN Mapserver kommen, während alle WFS vom GeoServer geliefert werden – und dies aus denselben Datentabellen in PostGIS. Abb. 2 Welthungerindex 2007 mit Mapbender

Als einziges komplettes Ausscheidungskriterium für den UMN Mapserver ist die Notwendigkeit einen WFS-T einzusetzen. Aufgrund der deutlich grösseren Möglichkeiten bei der Symbolisierung im Vergleich zur aus SLD basierenden Symbolisierung im GeoServer wurde für die Darstellung der Karten (WMS) bei uns jedoch meist der UMN Mapserver gewählt. Der Vortrag wird das oben dargestellte konkret am Beispiel des Projektes „Informationssystem Wahner Heide“, ein Projekt, welches für die NABU Kreisverbände Köln und Rhein-Sieg [17] umgesetzt wurde, diskutieren.

Kontakt zu den Autoren: Till Adams Marc Jansen terrestris GmbH Co. KG Irmintrudisstr. 17, 53111 Bonn ++49/(0)228 962 899 52 adams@terrestris.de, jansen@terrestris.de

Literatur Links [1] Stand der Technik und Potenziale von Smart Map Browsing im Webbrowser, E. Schütze, www.smartmapbrowsing.org [2] OpenLayers: http://www.openlayers.org [3] Mapbender: http://www.mapbender.org [4] P-Mapper: http://www.pmapper.net/ [5] Mapfish: http://www.mapfish.org [6] MapBuilder: http://www.mapbuilder.net/ [7] IGeoPortal: http://demo.deegree.org/igeoportal-std [8] GeoExt: http://www.geoext.org [9] Deegree: http://www.deegree.org [10] UMN Mapserver: www.mapserver.org [11] GeoServer: www.geoserver.org [12] http://wiki.osgeo.org/wiki/FOSS4G2008_LightningTalks [13] http://www.mapserver.org/ogc/wfs_server.html#to-do-items-and-known-limitations [14] Comparing the Performance of Open Source Web Map Servers, J. Deoliveira, A. Aime: http://conference.osgeo.org/index.php/foss4g/2008/paper/view/256/191 [15] http://www.chemieatlas.de [16] http://gis.soest.de [17] http://www.nabu-wahnerheide-koenigsforst.de