Eine Typisierung: OpenLayers, Mapbender und MapFish

From MapbenderWiki

Jump to: navigation, search

Read the English language version of a Typification of OpenLayers, Mapbender and MapFish.

Autoren
Foliensatz

Contents

Eine Typisierung: OpenLayers, Mapbender und MapFish

Zusammenfassung

Dieser Vortrag entstand aus dem Wunsch heraus, ein klareres Verständnis für die Aufgaben und Ziele der drei Web Mapping-Komponenten der OSGeo, OpenLayers, Mapbender und MapFish, zu entwickeln. Es gibt eine Vielzahl weiterer Web Mapping-Komponenten, die meist Bestandteil eines Serverframeworks wie deegree oder MapGuide Open Source sind, auf die hier aber nicht näher eingegangen wird. Hier geht es um drei Typen von Software, die für unterschiedliche Herangehensweisen entwickelt wurden, aber auch ausgezeichnet miteinander kombinierbar sind.

Zunächst scheinen die drei Software-Projekte direkt miteinander zu konkurrieren, da sie jeweils Karten anzeigen und grundlegende Navigationsmöglichkeiten bieten. Aus dieser Perspektive ist das richtig:

Funny screen shot to show how OpenLayers works as standalone, in MF and MB.

Dass die Abbildungen identisch sind ist kein technischer Fehler, sondern soll zeigen, dass die Unterschiede der Software vor allem "unter der Haube" zu finden sind. Dort bilden sie so unterschiedliche Spektren ab, dass die Entscheidung für eine der drei Software-Projekte oder auch einer Kombination daraus nicht schwer fallen sollte und entsprechend der Fragestellung, die es zu lösen gilt, ausgewählt werden.

Haftungsausschluss

Vorab sei noch darauf hingewiesen, dass sowohl Christoph Baudson, als auch Arnulf Christl befangen sind, da sie beide seit vielen Jahren und mit viel Spaß im Projekt Mapbender arbeiten und sich deshalb in diesem Projekt besonders gut auskennen. In der Open Source Community gibt es den Kunstbegriff der "Coopetition" der sich aus "Competition" und "Cooperation" zusammensetzt, also der Kombination von Wettbewerb und Kooperation. Genau das ist es, was uns alle (im Idealfall) beflügelt und Raum lässt für Neues und Diversität. Wir hoffen, dass wir ein möglichst neutrales Bild schaffen konnten.

Zusammenfassung

Kurz zusammengefasst kann man OpenLayers als JavaScript-Bibliothek für Web-Entwickler beschreiben, Mapbender als Softwarepaket zum Management von GDI in Geoportalen und MapFish als Entwickler-Framework für komplexe WebGIS Anwendungen. Natürlich kann man alle drei auch in den jeweils anderen Kontexten einsetzen, bezahlt das aber mit deutlichen Mehraufwänden. Nachfolgend werden die Gemeinsamkeiten und Unterschiede der drei OSGeo-Projekte detailliert vorgestellt.

Zur Geschichte der Projekte

Jedes Open Source Projekt hat einen Ursprung und eine Geschichte, die hier kurz vorgestellt werden soll. Wir fangen in der zeitlichen Entwicklung mit dem ältesten Projekt Mapbender an und hören mit MapFish, dem jüngsten Spross, auf. Zwischendurch genehmigen wir uns einen Seitenblick in die (angebliche) Revolution, die GoogleMaps ausgelöst hat.

Mapbender

Die Ursprünge von Mapbender gehen auf ein Projekt der Uni Bonn im Jahr 1997 zurück, bei dem untern anderem Arnulf Christl mitarbeitete. Im Projekt "GIS Experimental Server" wurde auf Basis der später in 2003 "verstorbenen" proprietären Software SICAD Spatial Desktop ein vollständig über Oberflächen konfigurierbarer OGC WMS Dienst implementiert.

Für diesen OGC-standardisierten Server wurde ein Client benötigt, der zunächst als einfache Perl-Anwendung implementiert wurde. In den folgenden Jahren wurde aus den Erfahrungen, die in dem Pionierprojekt erworben wurden, durch die Firma CCGIS eine eigene WebGIS Anwendung entwickelt, die CCGIS Client Suite. Mit der Übernahme der Firma SICAD Geomatics durch die AED Graphics in 2002 wurde die Entwicklung der Serverkomponente SICAD Spatial Desktop in 2003 eingestellt. Statt auf die proprietäre Lösung ArcIMS umzusatteln, wie den ehemaligen Partner SICAD Geomatics empfohlen wurde, setzte das Entwicklerteam rund um Mapbender auf Nachhaltigkeit und unterstütze die inzwischen weit verbreitete Software UMN MapServer eingesetzt. Wiederum aus Gründen der Nachhaltigkeit wurde aber nicht das praktische, skriptfähige aber nicht standardisierte Template-System von MapServer genutzt, sondern vollständig auf die offenen Standards des OGC. Im Rahmen dessen wurde die bis dato proprietäre Client-Software CCGIS Client Suite komplett überarbeitet, unter die GNU GPL Open Source Lizenz gestellt, in Mapbender umgetauft und die Kernentwicklung durch Uli Rothstein weitergeführt. Wie sich zeigt, waren diese Entscheidungen richtig, denn neben den vielen Client-Softwarepaketen der Stumr-und-Drang Zeit wie Chameleon, kaMap, CartoWeb, MapBuilder und praktisch allen proprietären Lösungen überlebte einzig Mapbender die Evolution der ersten Jahre als konstante Größe.

Eine weitere Evolutionsstufe erreichte das Projekt mit dem Rückzug des nicht-Informatikers Arnulf Christl aus der Kernentwicklung und der zunehmenden Professionalisierung der Software durch den Informatiker Christoph Baudson. Nach und nach wurde die Grundlage von Mapbender entrümpelt und zu wirklich guter Software umgebaut, was allerdings auch außerordentliche Anstrengungen erforderte und Jahre brauchte. Der Prozess ist noch lange nicht abgeschlossen. Wichtig ist aber, dass alle Anwender während der gesamten Laufzeit immer auf neue Versionen gebracht werden konnten und es zu keinem großen Systembruch kam, wie ihn viele Softwarehersteller irgendwann gehen müssen, und der bei Anwendern zu außerordentlich großen Umstellungs-Aufwänden führen kann.

Als sich Ajax als asynchrone Technologie durchsetzte wurde sie auch in Mapbender eingeführt und mit der Einführung von jQuery hat sich die Mapbender-Entwicklergruppe eine ausserordentlich leistungsfähige Bibliothek ins Projekt geholt, die wesentlich ansprechender Oberflächen ermöglicht und bewährte Funktionalität im neuen Gewand bietet. Alles auf dem aktuellen Stand und fast ohne Schmerzen, das kann nicht jede Software von sich behaupten.

OpenLayers

Die ersten Ideen für OpenLayers entstanden auf der O'Reilly Where 2.0 Konferenz in 2005. Kurz vor der nächsten Where 2.0 Konferenz wurde am 27. Juni 2006 das Release 1.0 veröffentlicht. Das zeigt schon sehr deutlich den ganz anderen Ursprung und Ziel dieser Software. Hier geht es um Web 2.0 und wir befinden uns bereits in der "Nach-Google-Maps" Ära. OpenLayers wurde ganz klar als Alternative zu proprietären Google Maps Lösungen entwickelt, was auch gelungen ist. Sogar das [ http://industry.slashgeo.org/article.pl?sid=09/05/03/011210 Weiße Haus in den USA nutzt OpenLayers als Kartenanwendung] – obendrein auf der Grundlage von OpenStreetMap-Daten.

In 2007 wurde das erste Mal die viel zitierte "Slippy-Map" eingeführt und geradezu als Revolution in der Web Mapping Technologie ge-hyped (diesen Neo-Anglizismus konnte ich mir nicht verkneifen, der eine Autor). In der gleichen Zeit wurde auch die Rasterkachel "wiederentdeckt", eine altbackene Technologie, die wir eigentlich bereits 1998 überwunden glaubten.

Exkurs I: Gekachelte oder ungekachelte Dienste?

Google Maps hat die Kachel wieder hoffähig gemacht. Seitdem sind eine Vielzahl von Kachelungssystemen entwickelt worden, die leider alle untereinander nicht kompatibel sind. Technologisch betrachtet ist die Kachelung von Karten eigentlich ein Rückschritt. Allerdings vertragen sich Kacheln besser mit herkömmlicher Internet-Technik, vor allem bei vielen parallelen Zugriffen auf statische Karten. OpenLayers unterstützt eine wachsende Anzahl von Servern, die Kachelung unterstützen (z.B. OpenStreetMap, Bing, Google Maps, Yahoo, etc.), ein Vorteil für MapFish, der OpenLayers voreingestellt als Frontend unterstützt. Einer der Hauptvorteile von Kachelungsdiensten ist die Bereitstellung der Karten über einfache und bewährte Verzeichnisdienste eines Webservers, und eine dadurch bedingte hohe Skalierbarkeit. Um die Server gleichmäßig zu belasten setzen Browser aus Prinzip immer nur vier parallele HTTP-Anfragen ab. Um diese Limitierung zu umgehen, können die Kacheln von verschiedenen Basis-URLs angefordert werden, was zu mehr Parallelität im Zugriff führt, aber auch mehr Komplexität beim Aufbau der Serverlandschaft erfordert. Bei Google Maps kann man dies daran erkennen, dass die Kacheln mit unterschiedlichen Servernamen angefordert werden.

Parallele Server können auch auf einer physikalischen Maschine laufen und über Alias-Einträge im Webserver quasi-virtualisiert werden. Dabei wird allerdings in Kauf genommen, dass mehr Netzlast verursacht wird. Bei stetig steigender Leistungsfähigkeit der Leitungskapazität auf Seite der Endverbraucher ist das weniger ein Problem, viele Browser werden unter dem massiven Einsatz komplexer JavaScript Bibliotheken und massiv-paralleler HTTP Zugriff jedoch fast lahmgelegt. Auf Seite des Kartenanbieters werden auf jeden Fall größere Kapazitäten benötigt.

Exkurs II: Warum brauchen wir überhaupt noch OGC WMS-Dienste?

Die einfachste Grund ist, dass Kacheln keine dynamischen Daten enthalten können. Wenn also sich schnell ändernde Inhalte visualisiert werden sollen, ist die Kachelung im Nachteil. GeoWebCache ist eine von mehreren Lösungen, die bei Änderungen in den Daten bis auf den Server durchgreifen.

Diagram source: GeoWebCache, Arne Kepp

Dabei werden aber die Vorteile schneller Antwortzeiten und vorkonfigurierter Netzlasten zumindest teilweise wieder ausgehebelt. Außerdem führt die Nutzung einer weiteren Komponente, die installiert, gewartet und betrieben werden muss, zu größerer Komplexität in der Netzwerk-Architektur. Gekachelte Kartendienste unterschiedlicher Anbieter passen geometrisch nicht exakt übereinander, was eine der essentiellen Grundfähigkeiten von Geoinformationssystemen, die dynamische Kombination und Überlagerung, unmöglich macht.

Der OGC WMS Standard spezifiziert detailliert wie Kartenbilder dynamisch und geometrisch korrekt erzeugt werden. OGC WMS Dienste können auch Kacheln ausliefern, die proprietären Kacheldiensten überlagert werden. Die Generierung der Anfrage übernimmt dabei der Client, der Server muss lediglich die Projektion unterstützen. Google stellt für OGC-Dienste den SRS-Code 900973 bereit (das ist ein Wort und Zahlenspiel und heißt übersetzt G=9 O=0 O=0 G=9 L=7 E=3). In OpenLayers kann durch einen einfachen Schalter eingestellt werden, ob ein OGC WMS Dienst gekachelt oder als Vollbild angefordert werden soll, die Kachelung schließt den OGC Standard also nicht aus. Allerdings müssen WMS mit Kachelungs-Anspruch speziell dafür konfiguriert werden, ein Whitepaper das die Zerlegung von Texten und Symbolen an Kachelgrenzen spezifiziert steht hierfür noch aus.

Ein weiterer Vorteil des OGC WMS Standards ist die Unterstützung unterschiedlicher Koordinatensysteme und Projektionen aus einer Datenquelle. Bei gekachelten Systemen muss dagegen für jedes Koordinatensystem und jede Projektion ein eigener Kachelstapel erstellt werden, was schnell zu sehr großen Datenmengen auf dem Webserver führt. Die Dauer der Generierung aller Kacheln in allen Zoomstufen wird ebenfalls in die Höhe getrieben, dabei kann es sich schnell um Stunden oder sogar Tage handeln. Auch hier kann GeoWebCache helfen, allerdings wieder mit den oben genannten Einschränkungen.

Die Mitglieder des OGC haben in 2007 angefangen, einen Kachelungsstandard für Kartendienste zu entwerfen, der inzwischen bis zur Kommentierungsphase entwickelt wurde. Ob sich dieser Standard auch durchsetzen wird, kann nur die Zeit zeigen, denn die betroffenen Anbieter werden wenig Interesse daran haben, eine andere Kachelung zu unterstützen als die eigene. Das Grundprinzip der großen drei (Google, Yahoo und Microsoft) ist weiterhin, Kunden in der eigenen Lösung festzusetzen, ein Grundsatz, den wir Dank OGC mit viel Aufwand und Zeit zumindest bei den GIS Herstellern nach und nach aufbrechen konnten. Das Interesse bei den großen Suchmaschinen und Content-Kraken ist hier leider vergleichsweise gering.

MapFish

Das Projekt MapFish ist noch recht jung. Es wurde federführend von der Firma Camptocamp1 entworfen und entwickelt, die ein weiteres, eigenes Projekt, CartoWeb2, nach und nach durch MapFish ersetzen werden. CartoWeb war zu unflexibel in der Nutzung unterschiedlicher Dienste und hat zu stark auf proprietäre Schnittstellen gesetzt, was bei Änderungen ständige Nacharbeit erforderte. Des weiteren war die Codebasis nicht sauber und reif genug, um als normales Open Source Projekt eine Community zu finden, ein ähnliches Problem mit dem übrigens auch Mapbender über Jahre gerungen hat.

Des weiteren wollten die Entwickler von MapFish von vornherein alle neuen Architekturparadigmen (vor allem REST, aber auch SOAP) und -Sprachen (vor allem REST-freundliche wie Python) bedienen, was mit einer Neuentwicklung viel einfacher ist, als dies in einem altes Projekt umzusetzen. Ob die Rechnung in dieser Breite aufgeht, oder einzelne Bestandteile zum Nachteil anderer bevorzugt entwickelt werden wird nur die Zeit zeigen können.

MapFish hat sich in den Projektstrukturen frühzeitig an den Anforderungen der OSGeo orientiert, was einen großen Vorteil für die Organisation und Steuerung des Projektes bringt. Auch hier der Vorteil des Spät-geborenen. Des weiteren hat Camptocamp eine ausgezeichnete Marketing-Maschinerie aufgebaut und kümmert sich um internationale Anerkennung, was für die Unterstützung und Bekanntmachung eines neuen Projektes im bereits recht gut bedienten Web Mapping Markt außerordentlich wichtig ist. Im Rahmen der Open Source Steuerung wurde ein breit aufgestelltes Project Steering Committe gebildet, in dem untern anderem Till Adams von terrestris3 vertreten ist.

Die Planung in der MapFish Entwickler Community geht derzeit davon aus, OpenLayers als einziges Frontend anzubieten. Anders die Mapbender Entwickler, die OpenLayers zwar ebenfalls unterstützen, aber zusätzlich noch eigene Viewer pflegen, weil dadurch den Administrator-Benutzern mehr Flexibilität geboten wird, als nur durch eine einzige Plattform.

Komponentenanalyse Client

OpenLayers: OpenLayers bietet als JavaScript-Bibliothek eine einfache Möglichkeit, Karten in anderen Web-Anwendungen zu integrieren. Die Grundfunktionen orientieren sich an den Funktionen der bekannten Google Maps Anwendungen und übertrifft diese in manchen Bereichen. Zoom-Funktion mit Mausrad, Slippy-Map, Kachelung, WMS-Unterstützung, aber auch temoräre Objekte und eine umfangreiche Web-basierte Rendering-Engine. Die Konfiguration erfolgt über eine einfache Syntax, die in einer HTML-Seite hinterlegt werden kann. Für die Nutzung sind allerdings grundlegende JavaScript-Kenntnisse erforderlich, die mit steigender Funktionalität schnell recht anspruchsvoll werden.

Als reiner JavaScript Kartenviewer ist OpenLayers nicht mit Mapbender oder MapFish zu vergleichen. Die beiden letztgenannten Projekte decken ein viel breiteres Spektrum ab, und sind sich konzeptionell nicht ganz unähnlich: Sowohl MapFish als auch Mapbender bestehen aus einer Client- und Serverkomponente, die wie folgt aussehen:

MapFish: Der MapFish Client besteht neben MapFish-eigenen JavaScript-Dateien aus OpenLayers und GeoExt-Komponenten. OpenLayers ist also ein integraler Bestandteil von MapFish. GeoExt-Komponenten sind mit der mächtigen ExtJS-JavaScript-Bibliothek entwickelte Widgets für OpenLayers. Man kann GeoExt durch User Extensions um eigene Widgets erweitern. MapFish wird in HTML, JavaScript und einer der unterstützten Skriptsprachen programmiert, Kentnisse der MapFish-eigenen API sind ebenfalls erforderlich.

Mapbender: Der Mapbender Client bringt ebenfalls eigenes JavaScript mit, was auf der schlanken Bibliothek jQuery basiert. Er verwendet in der ausgelieferten Fassung einen eigenen Mapbender-Kartenviewer. Die Widgets (wie Suchmodule oder Digitalisierung) basieren auf jQuery-UI-Komponenten, einer Bibliothek aus populären jQuery-Plugins, die mit dem jQuery UI Themeroller gestaltet werden können. Es gibt zudem die Möglichkeit, OpenLayers als Kartenviewer einzusetzen, was allerdings noch nicht viele Mapbender Widgets unterstützen. Die Erstellung einer Anwendung erfolgt zwar ohne Programmierkenntnisse über eine Web-basierte Oberfläche, erfordert aber Kenntnisse in der Mapbender-eigenen Anwendungslogik.

Die Graphik zeig die unterschiedliche Tiefe der Einbindung. File:Javascript web mapping clients.png

Komponentenanalyse Server

Über den MapFish Server können räumliche Daten über eine REST-Schnittstelle eingefügt, aktualisiert, abgefragt und gelöscht werden. Damit geht MapFish wie seine Vorgänger wieder einen eigenen, monolithischen Weg, anders als Mapbender der keine eigene Datenhaltung hat und verteilte Architekturen bedient. Das MapFish REST Protokoll ist sowohl in PHP, Java als auch in Ruby implementiert. Der MapFish Server erweitert das Python-Framework Pylons und benutzt Bibliotheken wie Shapely oder SqlAlchemy.

Der Mapbender Server ist in PHP implementiert, und orchestriert oder administriert außer OGC-konformen Diensten auch Benutzer und Applikationen. Dadurch kann jeder berechtigte Benutzer Anwendungen erstellen oder bearbeiten, und anderen Benutzern Zugriff darauf gewähren. Applikationen bestehen neben einem Kartenviewer und Widgets aus Diensten wie OGC WMS und WFS. Anders als MapFish hat Mapbender keine eigene Datenhaltungskomponente, sonder nutzt OGC WFS-Dienste für suchen, anlegen und ändern von Geometrien, sowie OGC WMS zur Anzeige. Man kann alle Dienste über Oberflächen per Mausklicks vorkonfigurieren und mit diesen Einstellungen in Applikationen verwenden. Die Konfigurationen werden in einer PostgreSQL-Datenbank vorgehalten, zusätzlich kann PostGIS als Werkzeugkasten für spezielle GIS-Methoden genutzt werden. Die Administrationstätigkeiten erfolgen über ein Webinterface, man muss keine einzige Zeile Code selbst produzieren.

MapFish Mapbender
JavaScript-Bibliothek ExtJS jQuery
Widgets MapFish Client + GeoExt Mapbender jQuery (UI) Plugins
Kartenviewer OpenLayers Mapbender-Kartenviewer, optional OpenLayers
Administration Quellcode Administrationsoberflächen
Managed Nein Ja
Datenbankkomponente SqlAlchemy PostgreSQL, PostGIS

Lizenz und Copyright

MapFish wird unter der GPLv31 veröffentlicht, einige Komponenten unterliegen auch anderen Lizenzen. Vor allem die Nutzung der Ext-Bibliothek, die in neueren Versionen teilweise nur unter einer propritären Lizenz genutzt werden kann, ist etwas unklar. Das Copyright der MapFish Software ist so verschieden und verteilt wie der Code und liegt teilweise bei Camptocamp, SourcePole (Pirmin Kalberer) oder ist nicht klar definiert (GeoExt). Der Inkubationsprozess der OSGeo2 wird diese Unklarheiten beseitigen.

Mapbender wird unter einer Doppellizenz veröffentlicht, je nach Präferenz des Anwenders oder Entwicklers unter BSD oder GPLv23. Damit können Mapbender-Komponenten seit Mitte 2009 auch durch proprietäre Hersteller genutzt werden. Das Copyright der Software Mapbender liegt bei der OSGeo, die sehr klare Bedingungen zu Änderungen der Lizenz vorschreibt. Das Projekt gehört damit der OSGeo-Community.

OpenLayers wird unter einer eigenen BSD-Style Lizenz veröffentlicht. Das Copyright liegt bei der Firma MetaCarta, es ist aber bereits eine Diskussion im Gange, in der beraten wird, ob das Copyright an die OSGeo abgetreten werden soll.

Welches Framework für welche Aufgabe?

Diese Frage soll, wie eingangs erläutert, nicht mit einer klaren Martix beantwortet werden, da sie zu einem Teil immer auch subjektiv ist. Im Vortrag werden wir näher darauf eingehen wie eine Entscheidung getroffen werden kann. Die OSGeo Wiki-Seite Choosing a Web Mapping Platform sollte regelmäßig aktualisiert werden, um den aktuellen Stand der Entwicklung zu dokumentieren.

Die Vorteile von MapFish sind derzeit vor allem unter der Haube zu finden, der Code ist klarer strukturiert, die Komponenten besser isoliert und es gibt eine umfangreiche API. Des weiteren wird serverseitig eine REST-API für unterschiedliche Sprachen angeboten. Der Entwickler fühlt sich hier schnell wohl.

Die Mapbender Codebasis ist ungleich komplexer und weist aufgrund ihres Alters einige gewachsene Strukturen auf, die für den neuen oder unbedarften Entwickler schwerer nachzuvollziehen sind.

Bei der Erstellung von leistungsfähigen User Interfaces mit allen schicken, neuen Effekten unterscheidet sich die Leitungsfähigkeit der zwei Produkte nicht grundlegend. Die Ext- bzw. GeoExt-Bibliotheken bieten die gleichen Aufklapp-Fenster, Zoom-Effekte etc. die aus dem Web 2.0 bekannt sind, wie die jQuery-Bibliothek. Ext-Komponenten sind im Erscheinungsbild immer sehr ähnlich, der Aufwand diese anzupassen ist vergleichbar mit der herkömmlicher Mapbender Karten-Viewer. Der jQuery Themeroller bietet hier in Mapbender eine sehr komfortable Möglichkeit Layouts anzupassen, allerdings werden sich erfahrungsgemäß die wenigsten Anwender einen eigenen "Theme rollen", sondern eher einen fertigen Stil auswählen. Das ist ein Grund warum Kartenanwendungen aus beiden Frameworks einen hohen Wiedererkennungswert haben. Will man etwas speziellere Layouts erzeugen, muss man Hand anlegen, Beispiele dafür gibt es in beiden Softwareprojekten.

Mapbender hat eher den Charakter einer Software, während MapFish als Entwicklerwerkzeug betrachtet werden sollte. OpenLayers kann als Bibliothek durch beide Frameworks genutzt werden, oder als eigenständige Anwendung ohne integrierte Serverkomponente.

Wenn viele Dienste durch unterschiedliche berechtigte Benutzer in verteilten Architekturen mit einer Vielzahl von Diensten verwaltet, geschützt und überwacht werden sollen, ist Mapbender die erste Wahl. Es gibt auch in MapFish bereits einige Entwicklungen in dieser Richtung, aber noch in einem eher prototypischen Zustand, vergleichbar mit der Integration von OpenLayers in Mapbender.

MapFish ist dagegen die Plattform der Wahl, wenn OpenLayers mit allen Facetten genutzt werden soll, einschließlich temporär gerenderter Objekte im Druck. Hier greift die Erweiterung GeoExt, die als Widget alle OpenLayers Objekte und Methoden kapselt und bereitstellt - aber eher für Webentwickler und nicht Endbenutzer. Als umfangreiche Entwickler-Suite ist MapFish derzeit die komfortabelste Lösung.

OprenLayers ist derzeit die De-Facto Standard-Lösung für Web-Entwickler, die "eben mal" mit wenig Aufwand eine Karte in ihre Anwendung einbinden möchten. Hier lohnt es sich nicht Mapbender oder MapFish in Betrieb zu nehmen. Als Karten-Viewer wird OpenLayers in vielen Projekten bereits exklusiv genutzt.

Zusammenfassend kann man feststellen, dass die Open Source Geo-Community mit diesen drei Softwareprojekten eine ausgezeichnete Basis hat, um alle Anforderungen zu bedienen. Nicht zuletzt sollte die Wahl aber auch danach entschieden werden, welche Kenntnisse der Dienstleister des Vertrauens mitbringt.

Verweise und Referenzen

Retrieved from "http://www.mapbender.org/Eine_Typisierung:_OpenLayers,_Mapbender_und_MapFish"
Views
Personal tools