Wege jenseits von Google Maps mit GeoTools und uDig

Modell vs. Modell

Das in Abbildung 1 gezeigte Objektmodell von GeoTools ist natürlich nur die Spitze des Eisbergs. Mittels FeatureSource- und FeatureStore-Klassen werden Datenquellen wie Shapefiles gekapselt und Features verwaltet.

Sofern die eigenen Geschäftsobjekte nicht bereits als externe Datenquellen in uDig importiert werden können (wenn z.B. ein WMS-Server die notwenige Repräsentation herstellt), gibt es grundsätzlich zwei Möglichkeiten, diese mit uDig zu koppeln. Erstere wäre die Implementierung eines eigenen FeatureStore, der die Geschäftsobjekte kapselt und sie dabei GeoTools-tauglich macht. Hierbei übernimmt der FeatureStore die Verantwortung für Persistenz und Konsistenz der Daten. Schlichtweg aus Komplexitätsgründen sei dem Neuling hiervon jedoch abgeraten. Mit hoher Wahrscheinlichkeit werden die betroffenen Geschäftsobjekte bereits in einem Modell in der Anwendung vorliegen, weshalb die zweite Möglichkeit empfohlen wird: Ein analog zu Listing 2 angelegter temporärer Featuertyp zusammen mit einem temporären uDig-Layer dient als Container für eine zweite Repräsentanz der Geschäftsobjekte. Eine Bridge (z.B. ein Wrapper, der den uDig-Layer gegenüber der eigenen Geschäftslogik kapselt und Methoden für Manipulation bereitstellt) sorgt dafür, dass Änderungen im eigenen Modell (z.B. Löschen eines Datensatzes) in der Feature-Collection nachgezogen werden (d.h. im Beispiel in der Karte gelöscht werden). Umgekehrt – wenn auch eine Veränderung der Geschäftsobjekte über uDig-Mechanismen möglich sein soll (z.B. Löschen eines Features aus dem Layer-Inhalt-Viewpart) – muss das eigene Modell konsistent gehalten werden. Hier wiederum können Listener in uDig verwendet werden.

Anbindung Oracle Spatial/PostGIS

Ganz neue Anwendungsmöglichkeiten ergeben sich bei der Integration von Datenbanken mit raumbezogenen Funktionen wie Oracle Spatial. Mithilfe von relativ leicht zu entwickelnden Tools können dem Anwender Werkzeuge an die Hand gegeben werden, mit denen er räumliche Abfragen innerhalb der Karte durchführen kann. Ein Beispiel wäre ein Werkzeug, um ein Polygon in der Karte zu zeichnen, das entsprechend konvertiert in einem SQL-Statement mündet und schließlich alle georeferenzierten Objekte im gezeichneten Polygon zurückliefert. Je nach Mächtigkeit der Datenbank sind hier viele interessante Szenarien denkbar. Doch der Fall, dass ein unvorsichtiger Benutzer Flächen markiert, deren räumliche Abfrage in der Datenbank Ergebnismengen mit Millionen Treffern generiert, sollte ebenfalls Beachtung finden und gegebenenfalls abgefangen werden.

Spätestens an dieser Stelle wird deutlich, dass mit GeoTools und uDig keine Alternativen zu Google Maps & Co realisiert werden sollten, sondern dass der Fokus auf klar strukturierten und mit GIS-Funktionalität angereicherten Unternehmensanwendungen liegt, bei denen raumbezogene Geschäftsobjekte visualisiert und die dadurch angepasste Funktionalität angereichert werden .

Fazit

Die Fülle der angeschnittenen Themen und Aspekte zeigt, dass ein Ausflug in die Geoinformatik länger dauern kann als man eventuell erwartet, wenn der Kunde in seiner Anwendung „eine Kartendarstellung, so wie bei Google“ haben möchte. Die meisten Entwickler betreten Neuland, wenn sie sich erstmalig mit Projektionen, Erdmodellen und Ähnlichem auseinandersetzen müssen. Hinzu kommt, dass die Vielzahl der Standards und Spezifikationen abschreckend wirken kann.

Insgesamt lässt sich feststellen, dass aufgrund der Mächtigkeit der vorliegenden Produkte mit einem höheren Einarbeitungsaufwand als beispielsweise für GoogleMaps oder OpenLayers gerechnet werden muss. Es stehen jedoch auch ganz klar andere Anwendungen im Vordergrund, die über die reine Visualisierung hinausgehen. Möchte man eine RCP-Anwendung erweitern oder schaffen, so sei auf uDig verwiesen. Auf der einen Seite ermöglicht die Fülle der mitgebrachten Funktionalität und die hohe Modularität eine sehr schnelle Integration in die eigene Anwendung. Auf der anderen Seite hat auch diese Anwendung einige Altlasten, und gegebenenfalls kommt man um einen Eingriff in den Quellcode nicht herum. Aufgrund der hohen Abstraktion, der Verwendung des Eclipse Modelling Frameworks (EMF) und den zahllosen Extension Points, läuft man hier Gefahr, am Anfang leicht den Überblick zu verlieren.

Bei Swing-Anwendungen bleibt uDig außen vor und man wird die GeoTools-Bibliothek verwenden. Mittels der vorhandenen Quellcodebeispiele gelingt der Einstieg sehr schnell.

Sowohl für uDig als auch GeoTools gilt, dass auf der jeweiligen Website viel Material, Erklärungen und Beispiele zu finden sind. Allumfassende Kompendien existieren jedoch nicht, was aufgrund der Größe der Projekte und der Entwicklungsgeschwindigkeit auch nicht erwartet werden kann. Für beide Projekte gibt es allerdings Mailinglisten, in denen seitens der Entwickler zügig und äußerst hilfsbereit geantwortet wird.

Frei nutzbare Geodaten

Häufig bestehen die eigenen vorliegenden Geodaten aus Vektorinformationen zu Infrastrukturobjekten, Arealen und Ähnlichem, nicht jedoch aus generellen Kartengrundlagen bzw. „Hintergründen“. Möchte man hierfür auf frei verfügbare Daten zugreifen, gilt es, sich über lizenzrechtliche Belange zu informieren, besonders wenn die eigene Software kommerziell vertrieben werden soll. Um Google Maps einzubinden, ist eine Registrierung und gegebenenfalls die Zahlung von Lizenzgebühren erforderlich. Eine Alternative bietet die Liste öffentlich zugänglicher WMS-Server. Es sind jedoch bei jedem der dort aufgeführten Server die Benutzungsrichtlinien zu beachten. Freie Vektordaten sind hier zu erhalten. Darunter befinden sich administrative Daten, Höhendaten und Klimadaten. Da präzise, aktuelle und hochaufgelöste Geodaten immer mit hohem Erstellungsaufwand verbunden sind, sind sie fast nur kommerziell erhältlich.

Matthias Lendholt, zertifizierter SCJP, ist am GeoForschungsZentrum (GFZ) Potsdam als Softwarearchitekt und -entwickler bei der Realisierung von (Tsunami-)Frühwarnsystemen tätig.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.