2.6.1 Anforderungen für die Kopplung mit Programmen im allgemeinen

Hierunter fallen jene Anforderungen an das GIS, die überhaupt für die Kopplung mit einem anderen Computerprogramm nötig sind.
Zunächst einmal muß das GIS in Bezug auf Datenfluß interoperabel sein. Dies darf als notwendige Anforderung angesehen werden: wenn keine Möglichkeit besteht, Daten mit einem anderen Programm auszutauschen, also jedes vom GIS verwendete Datenformat zum Speichern seiner Daten inkompatibel zu einem bestimmten anderen Programm ist, so kann nicht von Kopplung zwischen dem GIS und diesem Programm gesprochen werden. Es kann hierbei noch verfeinert zwischen Import und Export von Daten (hier aus Sicht des GIS gemeint) unterschieden werden. Es muß also je nach beabsichtigter Richtung der Kopplung mindestens diese eine Austauschrichtung möglich sein, wenngleich in der Regel beide Richtungen benötigt werden, da das GIS meist sowohl als Datenquelle als auch als Datensenke dient.
Selten dürfte ein GIS über gar keine Austauschformate verfügen, jedoch ist Datenkompatibilität auch relativ zum nötigen Aufwand ihrer Herstellung, d.h. zur Programmierung eines Konverters, zu sehen: gilt es, ein kryptisches, nicht zugänglich dokumentiertes Datenformat zu entschlüsseln, so darf vernünftigerweise von Inkompatibilität gesprochen werden, auch wenn es prinzipiell gelingen könnte, einen Datenaustausch herzustellen.
Im Bereich des Möglichen, dafür aber stets mit Programmieraufwand verbunden sind minimalkompatible Datenformate auf Zeichenfolgenebene wie das ASCII- und das EBCDIC-Format oder das neuere UNICODE-Format. Daß auch diese noch Kompatibilitätsprobleme bereiten können, liegt in der Historie der Standardisierung dieser Formate, die zu unterschiedlichen Standards auf dem Macintosh einerseits und UNIX oder DOS andererseits geführt hat.
Das Problem des Datenaustausches ist allerdings nicht losgelöst vom anderen Programm zu sehen: Auch dieses benötigt oder produziert Daten in einem bestimmten Format. Ist das andere Programm erst noch zu erstellen, so kann der Aufwand für die Programmierung des Konverters durch die Wahl eines gut geeigneten Datenaustauschformats erheblich reduziert werden.
Es kann günstiger sein, die Daten über zwei Konverter und ein Zwischenformat auszutauschen statt über nur einen monolitischen Konverter. Ob das Zwischenformat dabei etwa als Datei auftaucht oder nur zur konzeptionellen Gliederung des Konverters benutzt wird, ist eine Frage der Implementierung und kann verborgen werden.
Ist Datenkompatibilität vorhanden oder herstellbar, so muß überlegt werden, ob es sich bei der beabsichtigten Kopplung um eine enge oder lose Kopplung handeln soll. Dies hat Auswirkungen auf die Notwendigkeit eines automatisierten Kontrollflusses. Soll nur eine lose Kopplung hergestellt werden, so reicht es aus, den Datenaustausch jeweils nach Durchführung der Berechnungen im GIS bzw. im anderen Programm durch die BenutzerIn ausführen zu lassen. Die dafür nötigen Bedienschritte müssen jedoch dokumentiert und den BenutzerInnen vermittelt werden.
Für eine enge Kopplung ist mehr Entwicklungsaufwand vonnöten, da neben der Datenflußkompatibilität auch noch die Steuerflußkompatibilität hergestellt werden muß.
Diese ist von der Plattform abhängig, auf der GIS bzw. das andere Programm ausgeführt werden sollen. Unter Plattform soll hier das System aus Hardware, Betriebssystem und gegebenenfalls Middleware verstanden werden. Im Falle verteilter Systeme wird zur Middleware diejenige Software gerechnet, die es Programmen ermöglicht, über Rechner-, Betriebssystem- bzw. Hardwaregrenzen hinweg miteinander zu kommunizieren.
Laufen das GIS und das andere Programm auf derselben Plattform, so ist zumeist keine Middleware erforderlich.
Soll das GIS als Server fungieren, so muß es durch ein anderes Progamm in die Lage versetzt werden können, Aktionen auszuführen und deren Ergebnis zurückzumelden.
Ein GIS sollte, wenn es als Client arbeiten soll, auch noch konfigurierbar sein, etwa, um Bedienelemente, die nicht der Durchführung von Simulationsexperimenten dienen, während der Nutzung des GIS zu diesem Zweck auszublenden oder zu deaktivieren und so die Benutzung zu erleichtern. Wenn es als Server eingesetzt wird, so hängt die Notwendigkeit der Konfigurierbarkeit davon ab, ob es überhaupt sichtbar wird während eines Simulationsexperiments. Wenn ja, so wird sie dann benötigt, wenn es nicht möglich ist, es gleichzeitig während eines Simulationsexperiments zu verwenden, ohne das Simulationsexperiment zu stören.
Die Ausführung von Aktionen wird im GIS etwa als (Makro-)Programmiersprache realisiert sein. Insbesondere zur raschen Prototyperstellung und zum Erlernen der Programmiersprache ist es hilfreich, wenn diese Programmiersprache auch aufzeichenbar (engl.: recordable) ist, d.h. nach Start der Aufzeichnung bis zu dessen Stop die Benutzerinteraktionen verzeichnet und in Programmcode umgesetzt werden.
Unter den vom GIS auszuführenden Aktionen muß sich die Möglichkeit befinden, Daten auszutauschen. Hier ist zu überprüfen, ob die für den Datenaustausch benötigten Datenformate auch automatisiert verwendet werden können, also der Sprachumfang der GIS-Programmiersprache mindestens hierin nicht gegenüber der durch Benutzerinteraktion verfügbaren GIS-Funktionalität zurücksteht. Minimal notwendig sind Möglichkeiten zur Datenabfrage, wie es die relationale Anfragesprache SQL oder eines ihrer raumbezogenen (GeoSQL) oder objektorientierten (OOSQL) Derivate ermöglicht.
Darüberhinaus ist das Vorhandensein von Kontrollstrukturen wünschenswert. Dazu zählen IF-THEN-ELSE und WHILE oder Rekursion, Variablen, Typprüfung, Modularisierung, Kapselung und Objektorientierung.
Im speziellen Fall eines in ein GIS eingebetteten Programms entfällt ein Großteil der eben angestellten Überlegungen in Bezug auf enge Kopplung. Hier ist die Kompatibilität des Steuerflusses des GIS und dem anderen Programm dadurch gegeben, daß das Modell unmittelbar in der GIS-Programmiersprache geschrieben ist. Die Kompatibilität des Datenflusses kann ebenfalls als gegeben angenommen werden, in Bezug auf das Datenmodell gelten jedoch die gleichen Anforderungen an das GIS wie weiter unten genannt.
Höhere Anforderungen sind jedoch an die Unterstützung der Programmierung und an die Programmiersprache selbst zu stellen.
Als programmierunterstützend wären hier - abgestuft nach Anspruch auf Komfort sowie Komplexität des Programmiervorhabens - das Vorhandensein eines Editors bis hin zu einer integrierten Entwicklungsumgebung mit Versionsverwaltung zu nennen.
Die eben als über eine Abfragesprache hinausgehenden wünschenswert genannten Eigenschaften der GIS-Programmiersprache sind für die Einbettung von Programmen in ein GIS teilweise ein Muß. Dazu zählen die einfachen Kontrollstrukturen (IF THEN ELSE, WHILE oder Rekursion). Weiterhin lediglich wünschenswert sind je nach bevorzugtem Programmierparadigma Variablen, Typprüfung, Modularisierung, Kapselung oder Objektorientierung.