LeipzigKonzept für GDI

Die Stadtverwaltung Leipzig hat sich unter Leitung des Amtes für Geoinformation und Bodenordnung (Amt 62) zusammen mit IT-Dienstleister Lecos die Frage gestellt, wie das bestehende Rauminformationssystem in eine zukunftssichere Infrastruktur überführt werden kann und hierzu gemeinsam mit dem Beratungshaus CFGI zunächst ein Grob- und anschließend ein Feinkonzept erarbeitet. Dabei waren zum einen Standardisierungsaspekte zu berücksichtigen, die sich aus dem INSPIRE-Prozess und den daraus abgeleiteten Zugangsgesetzen des Bundes (GeoZG) und des Freistaates Sachsen (SächsGDIG) ergeben, zum anderen fachliche Überlegungen, wie die Einrichtung von E-Government-Komponenten. Der Fokus der zu erarbeitenden Handlungsempfehlungen lag somit zunächst auf der Optimierung der internen Prozesse, aus der quasi als Nebenprodukt die Bedienung der rechtlichen Situation resultierte. Dieses Verhältnis ist bereits in der Projektausschreibung zu erkennen, die eine Steigerung der Effizienz und Wertschöpfung vorhandener Datenbestände durch Harmonisierung und Integration sowie eine Erleichterung des Zugriffs auf aktuelle Geo-Informationen – insbesondere für Nicht-Experten innerhalb und außerhalb der Verwaltung – ebenso fordert wie die Festlegung von Standards für vorhandene und künftig zu erzeugende Geodaten, die Beschleunigung der Geschäftsprozesse durch die Integration von Geo-Informationen und GIS-Funktionalitäten, die Verbesserung der Dienstleistungen gegenüber Bürgern und Wirtschaft sowie eine mittel- und langfristige Kosteneinsparung.

Zwei Schwerpunkte gesetzt

Die Konzeptphase hatte also zwei Schwerpunkte: Einerseits sollte eine neue Basis für die Verarbeitung der Geodaten in der Stadt Leipzig konzipiert und Alternativen zur bisherigen Software eruiert werden. Andererseits war ein GDI-Konzept für Distribution und Zugriff auf raumbezogene Daten aus den beteiligten Ämtern zu erstellen. Die Vorgehensweise war mehrstufig angelegt. Im Rahmen einer Bestandsermittlung wurde über Fragebögen und Interviews zunächst die Ist-Situation in den 14 Ämtern (21 Abteilungen) erfasst. Dabei wurden sowohl die Leipziger Geodatenbasis (LGDB) als auch die Software-Infrastruktur beleuchtet. Das Ergebnis wurde in einer Stärken-Schwächen-Analyse bewertet und mit einem zuvor definierten GDI-Referenzmodell abgeglichen. Dadurch konnten konkrete Handlungsempfehlungen formuliert werden, die eine GDI auf technischer und organisatorischer Ebene beschreiben. Auf Basis des Grobkonzeptes wurden strategische Entscheidungen getroffen, die dann im Feinkonzept konkretisiert wurden. Das Feinkonzept konzentrierte sich auf die Unterstützung der Verwaltungsprozesse und die Integration der LGDB in ein Geodata-Warehouse (GDW) mit zugehöriger Software- und Server-Architektur. Zudem wurden eine Kosten-Nutzen-Betrachtung und ein Konzept für den technischen GDI-Betreiber erstellt sowie das Thema Datenschutz behandelt. Ein Stufenplan beschreibt die konkrete Umsetzung.

Ist-Situation problematisch

Die Ist-Situation stellt sich folgendermaßen dar: Für die Aktivitäten im Zusammenhang mit Geodaten sind für die beteiligten Ämter 64 Gesetze und Verordnungen relevant. 90 Prozent der Aufgabenstellungen in den Abteilungen haben einen direkten Raumbezug. Mehr als die Hälfte der befragten Organisationseinheiten befasst sich zudem mit der Erfassung, Fortführung, Zusammenführung und Analyse von Geodaten. Dabei fiel positiv auf, dass nur drei Prozent der Geodaten nicht in digitaler Form vorliegen. Trotzdem lassen sich 44 Prozent der 148 ermittelten Primärdatenbestände nicht elektronisch austauschen. Grund sind die Insellösungen, die in vielen Fällen nicht standardkonform arbeiten und somit zu hohen Aufwänden in der Datenbereitstellung führen: Die Informationen zur LGDB werden aus 284 Quellen bezogen und in 462 Varianten wieder abgegeben. Diese Vielfalt ist aktuell notwendig, damit alle Nutzer die Daten für ihre Zwecke verwenden können. Abgesehen von der Redundanz mit entsprechenden Nachteilen für die IT-Ausstattung ist die Situation aber auch deshalb problematisch, weil die Datensätze nicht alle gleichzeitig produziert werden. Aus der Abkopplung vom Primärbestand ergeben sich erhebliche Inkonsistenzen in der Aussage eines Datensatzes. Der Grund dafür liegt letztlich in der fehlenden verbindlichen GIS- und GDI-Strategie und der daraus resultierenden Vielfalt der eingesetzten Produkte zur Geodatenverarbeitung.

Klassisches GDI-Modell als Referenz

Als Referenz wurde ein klassisches GDI-Modell gewählt, weil es verständlich und einfach anzuwenden ist. So konnten den Prozessen in der Stadtverwaltung Rollen wie Geo­datenproduzent, Geodatennutzer und GDI-Betreiber zugewiesen und daraus eine Architektur abgeleitet werden. Ein wesentlicher Aspekt war die Empfehlung zur Einrichtung einer koordinierenden Einheit, die ein gewichtiges Mitspracherecht bei der Entscheidung über Software-Beschaffungen und die Einbindung von Geodaten in die GDI hat. Beim fachlichen GDI-Betreiber Amt 62 soll ein GDI-Koordinator eingerichtet werden, den eine Arbeitsgruppe unterstützt, an der unter anderem GDI-Verantwortliche der Ämter mitwirken.

Technische Zentralisierung für alle Geodaten

Um auch in Zukunft eine aus fachlicher Sicht notwendige Offenheit bezüglich der GIS-Produkte zuzulassen und dennoch den Anforderungen gerecht zu werden, basiert das Konzept auf einer technischen Zentralisierung für alle Geodaten, die künftig über Services oder direkt von internen und externen Nutzern benötigt werden. Aufgrund einer Marktrecherche und einer anschließenden Bewertung der Ergebnisse wurde beschlossen, eine auf ESRI-Produkten basierende Infrastruktur aufzubauen. Ein weiterer wesentlicher Gesichtspunkt dabei war, dass in der Stadtverwaltung Leipzig bereits zahlreiche ESRI-Lizenzen genutzt werden. Aber auch Produkte wie FAMOS LE werden künftig eine Rolle spielen, sodass ein standardkonformer Übergang geschaffen werden muss. Dieser besteht aus einer zentralen Oracle-Datenbank und dem Geodata-Warehouse, mit dem alle GIS-Produkte kommunizieren – sei es direkt oder über Schnittstellen. Diese Forderung wird bei künftigen Beschaffungen durch die GDI-Koordination sichergestellt. Organisatorisch verbleibt die Verantwortung für die Geodaten beim jeweiligen Amt. Das GDW wird die benötigten Daten standardkonform zur Verfügung stellen, zum Beispiel über WMS, WFS oder CityGML.
Im Rahmen eines umfangreichen Diskussionsprozesses, der erheblich lizenzrechtlich geprägt war, wurde eine geeignete Architektur für das Gesamtsystem entwickelt. Eine Herausforderung bestand darin, zu klären, wie viele ArcGIS-Server-Lizenzen benötigt werden, um eine performante GDI mit einer Internet-Auskunftskomponente zu etablieren. Auch Cloud-Modelle wurden in Betracht gezogen. Da das ESRI-Lizenzrecht diese Variante aber noch nicht rechtssicher unterstützen kann, wurde eine eher klassische Architektur entwickelt, bei der dank einer Application Firewall auf eine Zweitinstallation in der DMZ verzichtet werden kann.
Nach Fertigstellung des Feinkonzeptes und entsprechender Beschlusslage in der Stadt stehen zunächst Entscheidungen über dessen Realisierung an. Das Umsetzungsprojekt wird voraussichtlich zwei Jahre in Anspruch nehmen, in denen Teile der Infrastruktur doppelt betrieben werden müssen. Weitere Aspekte, die sich vermutlich in dieser Zeit entwickeln werden, betreffen etwa 3D-Stadtmodelle oder den Einsatz mobiler GIS-Komponenten. Außerdem ist noch in diesem Jahr der Relaunch der städtischen Website geplant, für die ebenfalls Geodaten bereitgestellt werden müssen.