Funktionen rein oder raus?

Letzte Woche war Upgrade-Tag (12.12.2008)! Das Unternehmen, für das ich arbeite, hat nach reiflicher Planung das Upgrade auf Version 4.1 des Smallworld GIS ins Auge genommen und eine Teststellung zum Jahresende (2008) installiert bekommen. Als GIS Sytstemadministrator bedeutet das auch, neben den notwendigen Vorbereitungen, dass für den Installationstermin und eine anschließende Testphase genug Zeit eingeplant wird. Diesmal war alles ein wenig anders. Die Teststellung wurde an meinem letzten Arbeitstag für dieses Jahr durchgeführt und meine GIS Kollegen haben in meiner Abwesenheit noch ein paar Tage Zeit, das System ein wenig kennenzulernen und auszuprobieren. Auf die Unterschiede der beiden Versionen möchte ich hier noch garnicht eingehen. Das spare ich mir für den Zeitpunkt auf, wenn ich mit dem System ein wenig mehr gearbeitet habe. Um das neue GIS gut unter Kontrolle zu halten, werde ich im Januar eine Konfigurationsschulung besuchen. Danach werde ich zu diesem Thema sicher eine Menge mehr sagen können.

Bei einem solchen Installationstermin — der mittlerweile nicht mehr im Serverraum, bei unsäglicher Lautstärke stattfinden muss, so wie noch zu Zeiten von SW GIS 2 — gibt es immer ein wenig Leerlauf, wenn Datenbanken kopiert werden oder die notwendigen Installationen von Webservern und sonstigen Diensten durchgeführt werden müssen. Um jetzt aber wirklich auf den Punkt dieses Beitrags zu kommen: während dieser Leerlaufzeiten habe ich die von mir gerne genutzten Gelegenheiten, mich mit Anderen auszutauschen, die Geoinformation beruflich betreiben und auch mal über den Tellerrand hinausschauen. In diesem Fall war der „Leidensgenosse“ Herr Christian Vogt. Er ist einer der Gesellschafter unseres Dienstleisters GIS Consult GmbH. GIS Consult (im weiteren als GC bezeichnet) betreut Unternehmen und Kommunen rund um das Thema GIS. Ich kenne das Unternehmen jetzt schon seit meinen Anfängen im GIS und habe ein durchweg positives Bild von den Kollegen dort in menschlicher und fachlicher Hinsicht. Genug Schleichwerbung! :-)

Also, eines von verschiedenen Themen, auf das wir im Laufe des Tages gekommen sind, war die Frage danach, wie und wo ich meine Geodaten ablegen kann. Aus dem Blog hier ist sicher bekannt, dass ich bei der Beantwortung dieser Frage zu Postgres/PostGIS neige. Das liegt zum Teil daran, dass PostGIS, als Geospatial-Erweiterung zu Postgres, einen großen Vorrat an OGC-konformen Funktionen mitbringt, auf die man in der Applikationsentwicklung mit z. B. PHP zurückgreifen kann. Postgres benutze ich also nicht nur als zentralen Datenspeicher für meine Geodaten, sondern nutze auch die Funktionen, die PostGIS mitbringt, um damit meine Aufgaben zu erledigen. Dies ist für mich eine sehr angenehme Variante, da ich mich sehr intensiv mit den Daten auseinander setzen kann, ohne mich um die Bereitstellung von Funktionen zu kümmern. In meinem beruflichen Umfeld verhält sich das Ganze aber z. B. genau anders herum. Wie mir Herr Vogt eindrucksvoll zeigte, lässt sich an das SW GIS 4.1 mit einem neuen kleinen Tool nahezu jede beliebige Datenquelle anhängen, die gewissen Standards genügt. Dies könnte ich bei Quantum GIS auch noch bei einem gewissen Umfang an Datenquellen erreichen. Hier habe ich allerdings das Problem der Funktionalität. Gehen wir von der Basisinstallation von Quantum GIS aus, so bringt es alles mit, um Datenquellen mit Geodaten anzuzeigen. Die Funktion ‚Pufferung‘ bringt QGIS auch noch mit. Aber dann? Wonach ich hier suche, ist ein anwenderfreundliches Abfragetool, mit dem ich die Tabellen meiner Datenquellen ansprechen kann, um alphanumerische oder sogar grafische Auswertungen auszuführen. Soweit ich weiß, geht dies über eine Konsole, die ich öffnen kann, um Abfragen einzugeben. Dies erschien mir aber nicht sehr benutzerfreundlich. Das SW GIS hat hier ein anderes Konzept. Hier sind nur die Daten in der Datenbank abgelegt, welche die Aufgabe übernimmt, diese performant und komfortabel zu verwalten. In der grafischen Oberfläche des System (SW GIS Version 3.1!!) ist eine Abfrageumgebung vorhanden, welche den Anwender dabei unterstützt, Abfragen in Form von Texten (ähnlich SQL) oder grafisch orientiert, syntaktisch richtig zu erstellen. Die Abfragen in Form von Texten als auch die grafisch orientierten Abfragen führen, allgemeine Kenntnis von Abfragelogiken vorausgesetzt, sehr schnell zum gewünschten Ergebnis. Näher darauf einzugehen, würde den Rahmen dieses Beitrags sprengen. Vielleicht komme ich darauf in einem späteren Beitrag zurück. Die kompletten Funktionen sind in der Anwendung, im so genannten Image, abgelegt. Dieses wird in eine Art virtuelle Maschine geladen und stellt die generellen und die kundenspezifischen Funktionen zur Verfügung. Hier kommt dann wieder die GC ins Spiel, die als Entwicklungspartner von Smallworld Deutschland, diese Funktionen programmiert.

Der Leser mit etwas Erfahrung wird mir jetzt zurecht vorwerfen, dass diese Ausführungen nicht ganz fair sind. Wenn ich mich selber und die Community von QGIS bemühe, werde ich sicher mit einem gewissen Aufwand identische Funktionen für QGIS hinbekommen. Den Punkt, den ich hier herausarbeiten möchte, ist aber der Funktionsumfang der Datenbanken. Mit mehr oder weniger Aufwand kann ich jeder Applikationen mit einem entsprechenden Unterbau (Programmiersprache) die Funktionen beibringen, die ich benötige. Smallworld GIS trennt allerdings die Aufgaben der Datenhaltung und der Abfragefunktionen schärfer, als dies PostGIS tut. Auf der einen Seite haben wir eine reine Datenhaltung (jemand aus dem Smallworld Umfeld möge mir hier widersprechen, wenn das nicht so ist!!), während auf der anderen Seite OGC-konforme Funktionen bereitstehen, die ich in eine SQL-Abfrage einbauen kann.

Ich muss allerdings dazusagen, dass die Diskussion in meinen Augen weniger die Frage nach dem Besser oder Schlechter stelllt. Vielmehr geht es mir darum, unterschiedliche Philosophien aufzuzeigen. Wenn ich in meiner Datenbank keine oder nur sehr wenige Funktionen habe, die mir erlauben, Geodaten grafisch auszuwerten (z. B. MySQL), bleibt mir garnichts anderes übrig, als die Funktionen ausserhalb der Datenbank bereitzustellen. Habe ich eine Applikation, welche nahezu beliebige Datenquellen mit Geodaten öffnen kann, sollte ich mich auf darauf konzentrieren, die Basisfunktionen so zu entwerfen, dass ich diese auf alle diese Datenquellen anwenden kann. Hierzu zählen für mich Lese- und Schreibfunktionen von Sachinformationen und Geometrien. Sind in einer Datenquelle Geometrien vorhanden, möchte ich diese ggfs. auch verändern und wieder abspeichern. Solche Funktionen sollten dann immer bereitstehen.Sind in der Datenbank soviele Funktionen vorhanden, dass ich mehr Zeit darauf verwenden kann, die Sachinformationen für den Anwender in ansprechender und sinnvoller Weise darzustellen, sollte ich dies auch tun. Warum das Rad neu erfinden?

Hat man ein bestehendes GIS, stellt sich die Frage danach, wo die Funktionen zu finden sind, meist garnicht. Man kann bei der Auswahl nach einem neuen GIS aber auf diesen Punkt sein besonderes Augenmerk legen. Man sollte sich hier also die Fragen stellen:

• Muss ich regelmäßig externe Datenbestände mit meinen eigenen Datenbeständen in Verbindung bringen?
• Enthalten die externen Datenbestände Geodaten und stehen diese in einem Standarddateiformat zur Verfügung?
• Kann ich über geeignete Software (ODBC-, JDBC- oder sonstige Treiber) externe Datenquellen bequem anbinden?

Sind das Punkte, die überwiegend zutreffen, könnte man die Funktionen auf Seiten der Applikation suchen und ausbauen. In dieser Kategorie sind IMHO spezielle GIS zu finden, die externe Daten benötigen, die weniger aus dem GIS-Umfeld stammen und sich häufig ändern.

• Werden die externen Daten nur in größeren Zeitabständen aktualisiert?
• Sind die Geodaten in sehr einfachen Dateiformaten verfügbar (z. B. Textformat)?
• Lassen sich die externen Geodaten bequem in meine zentrale Datenbank importieren?

Sind das Punkte, die überwiegend zutreffen, könnte man nach einer performanten Datenbank suchen, die neben den Geometriedatentypen auch den größten Teil der Funktionen zur Verfügung stellt, die ich benötige.

Leider werden die Grenzen zwischen den Kategorien stark verwischt, wenn man in den Bereich der Webanwendungen kommt. Man kann seine Daten in geeigneter Weise auf einen vorhandenen Webkartendienst aufsetzen, und auch ohne viel Mühe einen eigenen Mapserver aufsetzen, der die speziellen Karten bereitstellt. Hier kann man auf beide Varianten zurückgreifen. Ich werde mich in einem späteren Beitrag speziell mit der Thematik der WEB-GIS-Anwendungen auseinanderstzen, weshalb ich hier die Ausführungen einfach bis dahin unterbreche.

Ein Fazit kann ich zu diesem Thema, wie schon erwähnt, also nicht wirklich geben. Ich kann dem interessierten Leser lediglich ein paar Punkte an die Hand geben, mit denen er in die Diskussion einsteigen kann, wo die Geodaten in dem speziellen Fall möglicherweise bessser aufgehoben sind. In konkreten Fällen versuche ich gerne, etwas Licht in die Situation zu bringen. Man kann aber genauso gut ein entsprechendes Forum besuchen oder ein beratendes Unternehmen wie die GC konsultieren.

Werbung