Vorgangsbearbeitung und Geodaten in einer Anwendung mit Embedded GIS

Die Kombination von Sach- und Geodatenverarbeitung in einer Anwendung ist ein Schlüsselfeature für künftige Entwicklungsumgebungen
Frau hält in einer Hand ein Tablet und fasst mit der anderen Hand eine Glasscheibe an.
Wer mit Sachdaten und Geodaten zu tun hat, hat sich wohl schon häufiger diese Fragen gestellt: Warum sind Geoinformationssysteme (GIS) so völlig anders aufgebaut als andere 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 es naheliegend ist, gibt es kaum Entwicklungsumgebungen, Frameworks und sonstige Tools, um kombinierte Sach- und Geodatenanwendungen effizient zu entwickeln. Dies hat vermutlich historische Gründe: GIS-Systeme waren anfangs vor allem für Kartographen und andere Geodatenspezialisten da, und sie dienten im Wesentlichen 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-Abteilungen‘ in den meisten Unternehmen und Behörden relativ unabhängig von der sonstigen Unternehmens-IT etabliert haben – 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

Geänderte Erwartungshaltung seit Google Maps

Mit dem Aufkommen von des -Kartendienstes Google Maps und zahlreichen geodatenverarbeitenden 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, warum die High-End-Computerausstattung im Büro oftmals nicht dazu in der Lage ist, die gerade bearbeiteten Sachverhalte auf einer normalen Straßenkarte darzustellen, geschweige denn mit der Maus auf der Karte die Objekte zu selektieren, mit denen man sich weiter beschäftigen möchte?

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 – möglicherweise, weil man das so noch nie gesehen hat und sich darum gar nicht vorstellen kann. Scopeland Technology war in unzählige Projekte involviert, bei denen Kunden und zwar nicht nur die Endanwender, sondern sogar die IT-Verantwortlichen, davon überzeugt werden wollten, dass dies möglich ist. Erst wenn es einen lauffähigen Prototypen einer solchen kombinierten Anwendung auf dem Bildschirm zu sehen gab, kam der erstaunte Ausruf: „Ach so! Jetzt verstehe ich. Ja, das wollen wir haben!“

Embedded GIS als gemeinsam entwickelter Plug-In-Standard

Warum so viele Lösungsanbieter etwas so Naheliegendes nicht auf dem Schirm haben, bleibt ein Rätsel. Das wird sich jedoch schon bald ändern, obwohl es dafür keine einfache Lösung gibt. Denn 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 vielfältige Herausforderungen, zum Beispiel die Notwendigkeit, dass die Anzeige der 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 Scopeland Technology, 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 selbst zum GIS-Hersteller

Damit gelang es in den vergangenen Jahren, zahlreiche Pilotprojekte erfolgreich umzusetzen. 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, oftmals sogar mehrere, nicht unterstützt wurden. Denn die Integration von normalen GIS-Produkten in individuell programmierte Fachanwendungen war zwar prinzipiell möglich, aber selten gut genug für wirklich anspruchsvolle Kunden.

Letztlich bleibt einem Lösungsanbieter nichts anderes übrig, als sich sein eigenes Framework zu entwickeln, und so selbst zum GIS-Hersteller zu werden. Diesen Weg sind einige Softwarehäuser gegangen, mit unterschiedlich überzeugenden Ergebnissen. Zumindest ist das ein Weg, der funktioniert, und der in einigen Branchen, z.B. bei Energieversorgern und in kommunalen Betrieben, recht verbreitet ist. Einige Hersteller, die solche Lösungen anbieten können, haben sich damit eine gute Marktnische erarbeitet.

Funktioniert Embedded GIS auch mit Low-Code?

Während der Embedded-GIS-Ansatz bei 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 fast alle 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 brachiale 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 zunehmen wird, werden die Anwender von Low-Code-Produkten erwarten, dass man die gerade aktiven Datenobjekte mit einem Klick 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 noch schwer. Der Embedded-GIS-Ansatz macht eigentlich nichts anderes, als ein eigenes GIS-Control vorzuhalten und eigene Geodatenfunktionen zu verwenden. Da aber alles per Mausklick auf Anhieb funktionieren muss und man 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. Ein voll entwickeltes Embedded-GIS-Konzept bettet also nicht einfach nur eine vorhandene GIS-Komponente ein, sondern es setzt voraus, dass alles sowohl für die klassische Vorgangsbearbeitung und für die relationale Datenbankarbeit ausgelegt ist, als auch als Geodatensystem.

Erste Pilotprojekte bei großen Bundesbehörden zeigen, dass der Ansatz funktioniert, und zwar nicht nur technisch, sondern insbesondere hinsichtlich der Akzeptanz der Benutzer. Die Kombination von Sach- und Geodatenverarbeitung in einer Anwendung könnte sich also als ein Schlüsselfeature für künftige Entwicklungsumgebungen, insbesondere für Low-Code-Entwicklungsplattformen, erweisen.


Autor: Karsten Noack, Geschäftsführer Scopeland Technologies GmbH
Bildrechte: shutterstock



Ähnliche Beiträge