Warum eigentlich sind Geographische Informationssysteme (GIS) so völlig anders aufgebaut als die anderen Programme, mit denen Fachanwender in großen Unternehmen und Behörden arbeiten? Und warum braucht man überhaupt zwei verschiedene Programme, wenn man im Zuge der Bearbeitung eines fachlichen Vorgangs mal schnell den Geokontext dazu sehen will? Obwohl dies absolut naheliegend ist, gibt es jedoch kaum Entwicklungsumgebungen, Frameworks und sonstige Tools, um kombinierte Sach- und Geodatenanwendungen effizient zu entwickeln.
Foto: Scott Prokop - shutterstock.com
Vermutlich hat das historische Gründe: GIS-Systeme waren anfangs vor allem für Kartographen und andere Geodatenspezialisten da, und sie dienten im Wesentlichen nur dazu, thematische Karten für unterschiedliche Zwecke zu entwickeln. Da sie sich völlig getrennt von der sonstigen PC- und Browser-Welt entwickelt haben, funktionieren sie auch anders, und sind für gelegentliche, ungeübte Nutzer oftmals nur schwer zu beherrschen.
So kam es dazu, dass sich die "GIS-Abteilung" in den meisten Unternehmen und Behörden relativ unabhängig von der sonstigen Unternehmens-IT etabliert hat - mit vollständig getrennten Aufgabenbereichen: Die einen entwickeln die Software, mit der die Fachanwender ihre Vorgänge bearbeiten, und die anderen die dazu zugehörigen Karten. Bis vor einiger Zeit war das normal, und niemand störte sich daran.
Bei Google Maps und Apps mit Geodaten geht das doch auch
Seit dem Aufkommen von Google Maps und unzähliger geodatenverarbeitender Smartphone-Apps änderte sich aber die Erwartungshaltung der Fachanwender grundlegend.
Wenn man heute mit einem Klick auf dem Handy sehen kann, wo sich der Bus oder die nächsten Taxis befinden, wie man am schnellsten irgendwohin kommt, und was für Hotels oder Gaststätten sich in der Nähe befinden, dann fragt man sich doch:
Warum ist die High-End-Computerausstattung im Büro oftmals nicht mal dazu in der Lage, die gerade bearbeiteten Sachverhalte auf einer ganz normalen Straßenkarte darzustellen, geschweige denn mit der Maus auf der Karte die Objekte zu selektieren, mit denen man sich weiter beschäftigen sollte?
Auf die simple Idee, anspruchsvolle Geodatendarstellungen (Flächen, Linien, Punkte) mit all ihren Feinheiten, wie beispielsweise einer Legende und zu- und abschaltbaren Layern direkt in die sachdatenorientierten Anwendungen einzubauen, sind offenbar bislang nur wenige Softwarehersteller gekommen. Auch auf Kundenseite wird dieses Feature bislang nur selten verlangt - schlichtweg, weil man das so noch nie gesehen hat und sich vielleicht gar nicht vorstellen kann.
Der Autor dieses Artikels war in unzählige Projekte involviert, bei denen der Lösungsanbieter die Kunden, und zwar nicht nur die Endanwender, sondern sogar die IT-Verantwortlichen, mühevoll davon überzeugen musste, dass sowas überhaupt möglich ist. Erst wenn man einen lauffähigen Prototypen einer solchen kombinierten Anwendung auf dem Bildschirm hatte, kam der erstaunte Ausruf: "Ach so….! Jetzt verstehe ich. Ja… das will ich haben!" Warum so viele etwas so Naheliegendes nicht auf dem Schirm haben, bleibt ein Rätsel, aber dies wird sich mit Sicherheit grundlegend ändern, und zwar sehr bald.
Ein gemeinsam entwickelter Plug-In-Standard: Embedded GIS
Doch leider ist das gar nicht so einfach umzusetzen. Mangels geeigneter Frameworks bleibt den Entwicklern nichts anderes übrig, als die vorgefertigten Map-Controls vorhandener GIS-Systeme in ihren Java Script- bzw. Java- oder .net-Code zu integrieren, und dann die Funktionalität beider Welten so gut es geht miteinander zu verbinden.
Dabei stellen sich etliche Herausforderungen, wie z.B. die Notwendigkeit, dass die Anzeige der gerade angeklickten Objekte in beiden Systemen (dem Sachdatenprogramm und dem GIS-Control) stets zueinander synchronisiert werden muss, um nicht versehentlich inkonsistente Daten anzuzeigen. Noch schwieriger wird es, wenn es darum geht, Objekte dynamisch einzufügen oder zu löschen, weil man dann eine Transaktion über zwei getrennte Welten aufbauen muss.
Insgesamt wurden seinerzeit 20 Andockpunkte identifiziert, die beim Einbetten fremder Map-Controls bidirektional zu bedienen sind. Da der Entwicklungsaufwand dafür sehr schnell in eine Größenordnung kam, die kein einzelner Kunde bezahlen wollte, beschloss der Dienstleister, gemeinsam mit insgesamt sechs GIS-Anbietern und -Herstellern einen gemeinsamen 'Embedded GIS'-Plug-In-Standard zu entwickeln, der von den beteiligten Firmen in ihre jeweiligen Punkte integriert wurde bzw. dort angeflanscht werden konnte.
Lösungsanbieter werden quasi selbst zum GIS-Hersteller
Damit gelang es in den vergangenen Jahren, zahlreiche Pilotprojekte erfolgreich umzusetzen - jedenfalls so erfolgreich, dass die Kunden überglücklich waren, überhaupt eine funktionierende kombinierte Sach- und Geodatenanwendung zu bekommen. In jeder Hinsicht zufriedenstellend aber war das nicht, weil praktisch alle so eingebundenen GIS-Produkte jeweils ihre besonderen Eigenheiten hatten, die dazu führten, dass von den 20 Andockpunkten immer mindestens einer oder oftmals mehrere nicht unterstützt wurden.
Beispielweise war es bei einem marktbedeutenden GIS-Produkt nicht möglich, aus der Sachdatenanwendung heraus die bedingte Darstellung der Objekte (z.B. rote, grüne und gelbe Häuschen) zu steuern. Bei einem anderen System war es nicht möglich, Abstände zu berechnen, und es wies zudem eine schlechte Performance auf, wenn man eine größere Datenmenge aus der Sachdatenanwendung an das GIS-Control zur Anzeige übergeben wollte, und ein drittes schließlich hatte sich durch völlig unverständliche Fehlermeldungen ausgezeichnet, wenn die Internetverbindung mal kurz unterbrochen wurde.
Fazit: Die Integration von normalen GIS-Produkten in individuell programmierte Fachanwendungen ist zwar möglich, aber niemals gut genug für wirklich anspruchsvolle Kunden.
Letztlich bleibt einem als Lösungsanbieter nichts anderes übrig, als sich sein eigenes Framework zu entwickeln, und so quasi selbst zum GIS-Hersteller zu werden. Diesen Weg sind einige Softwarehäuser gegangen, mit unterschiedlich überzeugendem Ergebnis. Zumindest ist das ein Weg, der funktioniert, und der in einigen Branchen, z.B. bei Energieversorgern und in kommunalen Betrieben, recht verbreitet ist. Die wenigen Hersteller, die fit darin sind, solche Lösungen anbieten zu können, haben sich damit eine recht gute Marktnische erarbeitet.
Embedded GIS mit Low-Code: Wie geht das?
Während dieser Ansatz bei "normaler", handgeschriebener Anwendungssoftware noch mit vertretbarem Aufwand umsetzbar ist, vor allem, wenn man sich damit auf eine bestimmte Branche und die dort geforderten Features spezialisieren kann, stehen sämtliche Hersteller von Low-Code-Development-Plattformen vor einer Herausforderung.
Die Low-Code-Technologie basiert auf dem Prinzip, Anwendungslösungen interaktiv und ohne Programmierung aus vorgefertigter Funktionalität "zusammenzuklicken", um so positive Effekte hinsichtlich der Entwicklungskosten und Projektlaufzeiten, sowie der Pflegbarkeit der Software zu erreichen.
Wenn man davon ausgeht, dass die Nachfrage nach solchen kombinierten Anwendungen kontinuierlich weiter zunehmen wird, dann werden die Anwender von Low-Code-Produkten erwarten, dass man die gerade aktiven Datenobjekte mit einem Klick ebenso auch auf eine Landkarte zaubern kann, und natürlich mit ebenso hohen Ansprüchen bezüglich der weiteren Aspekten und Features von Geoinformationssystemen.
Bislang tun sich die bekannten Hersteller mit dieser Anforderung allesamt noch schwer. Der Embedded-GIS-Ansatz macht eigentlich auch nichts anderes, als ein eigenes GIS-Control vorzuhalten und eigene Geodatenfunktionen zu verwenden. Da aber alles per Mausklick auf Anhieb funktionieren muss, und man überhaupt nicht wissen kann, wozu das Ganze mal benutzt werden wird, war es erforderlich, dafür ein wirklich komplettes, vollumfängliches eigenes GIS-System zu entwickeln.
Oder besser gesagt: Alle Tools der Plattform waren so auszuprägen, dass sie beliebige Informationen auf identische Art und Weise bearbeiten und visualisieren können, nur halt nach Belieben mal tabellarisch, mal als Chart- oder als Map-Control, oder auch alles gleichzeitig. Ein voll entwickeltes Embedded-GIS-Konzept bettet also nicht einfach nur eine vorhandene GIS-Komponente ein, sondern setzt voraus, dass absolut alles sowohl für die klassische Vorgangsbearbeitung und für die relationale Datenbankarbeit ausgelegt ist, und zugleich auch als Geodatensystem.
Der Aufwand dieser Verschmelzung war laut Angaben des Herstellers erheblich, und es bleibt abzuwarten, ob die Nachfrage dem tatsächlich gerecht werden wird. Erste Pilotprojekte bei großen Bundesbehörden beweisen aber, dass es funktioniert, und zwar nicht nur technisch, sondern vor allem hinsichtlich der Akzeptanz der Benutzer. Die Kombination von Sach- und Geodatenverarbeitung in einer Anwendung könnte sich als ein Schlüsselfeature für künftige Entwicklungsumgebungen, insbesondere für Low-Code-Entwicklungsplattformen, erweisen. (hal)