The inspire specifications to implement a spatial data structure in Europe, combined with the official regulations, led to a significant increase of GIS development projects in the German administration. Therefore, the nature protection administration in the German federal state of Rhineland-Palatinate relaunched a project to completely rebuild their landscape information system. The modelling is based on feature catalogues formally modelled as UML diagrams (Enterprise Architect Models). Web apps, build automatically from the application scheme (using the ISO 19xxx standards), contribute to a platform for the management of the geodata in a distributed and heterogeneous environment. The presentation highlights a practical overview of the components, how administrative geodata will be managed with the help of “open source” software in the near future. Moreover, some software tools are presented, building readable and publishable feature type catalogues and XML schemes to define normalized interfaces for third parties.
Wenn man für eine überschaubare Fachverwaltung eines Bundeslandes über einen
langen Zeitraum die Verantwortung für die Datentechnik trägt, gewinnt man einen
besonderen Blick auf die Entwicklungsgeschichte der GIS-basierten
Datenverarbeitung [
In Phase I (etwa bis 1995) wurden Daten noch ohne Geometrien in dateibasierten Datenbanken (mit Bezug zu Kartenblättern über Kennungen) gesammelt. In Rheinland-Pfalz (RP) wurde z. B. die Biotopkartierung als Eigenentwicklung (eine in C programmierte Datenbankanwendung, genannt Geobase) vorgehalten. Dies erlaubte, die Datenbank auszuwerten und diese Auswertungen in der Karte manuell nachzuvollziehen.
In Phase II (ca. 1995 – 2000) wurde GIS eingeführt - zu den Fachdaten wurden die Geometrien erfasst. Mit dem GIS Programm Arc/Info auf einer unix workstation konnten umfangreiche Planungsaufgaben am Computer durchgeführt werden. Diese Phase war geprägt durch die ausschließliche Übernahme der Aufgabe durch Experten. Die Algorithmen wurden individuell erstellt, die Daten wurden extra dafür aufbereitet. Die Hardware war extrem teuer und der Austausch von Daten war auf wenige Spezialisten beschränkt, die im „handshake“-Verfahren miteinander kommunizierten. Das Datenmodell war die „Geheimwissenschaft“ der IT-Experten.
Phase III (2000-2010) bezeichnen wir hier als die Phase der aufkommenden DesktopGIS Systeme. Die Fa. ESRI lieferte mit Arc/View und dem Datenformat shape das Treibmittel für eine rasante Entwicklung. Plötzlich waren überall Daten gefragt. Das Datenmodell war nicht mehr nur Privatsache der IT-Experten. Gleichzeitig war es nun möglich, auch die Datenerfassung zu automatisieren. Nun konnten Fachleute, z. B. Biotopkartierer, selber Daten mit Anwendungen erfassen. Der Bedarf nach einem verständlichen Datenmodell zusammen mit Werkzeugen zur einfachen Erfassung entstand. Die Fa. Conterra entwickelte daher für die Natur-schutzverwaltung NRW das System OSIRIS als kompletten Baukasten: • Objektarten, Attribute und Schlüssellisten definieren das Datenmodell • die Metadaten über das Datenmodell (Kartierverfahren genannt) konnten weiter verwendet werden • aus dem Kartierverfahren können frei definierbare Erfassungsmasken erstellt werden • professionelle GIS-Standard-Werkzeuge unterstützen die Erfassung neuer
Objekte bzw. die kontinuierliche Pflege existierender Daten.
Für eine Fachverwaltung ergab sich eine sehr produktive Ausstattung. Schon früh wurde xml als eines der möglichen Austauschformate in RP genutzt. Die Umweltverwaltungen der Bundesländer genießen über eine Vereinbarung einen gegenseitigen Austausch von Technologie (Vkoop UIS). So gelangte das OSIRIS System zur Naturschutzverwaltung von Rheinland-Pfalz.
Ergänzt wird das Kartierverfahren durch eine Datenverwaltung auf einem Informix Datenbank-Server. Auf diesem ist das Datenmodell implementiert. Die Pflege des Datenmodells ist eine Dienstleistung der Fa. Conterra. Eine in ArcGis integrierte Oberfläche erlaubt die Datenverwaltung auf dem zentralen Datenbank-Server und steuert das geregelte IN/OUT der Daten. Für die Bedienung ist IT Fachpersonal nicht mehr zwingend notwendig. In Rheinland-Pflalz wird hierfür Naturschutzfachpersonal eingesetzt, damit eine Beurteilung der Datenqualität so mit einfließen kann. Wie ausgeführt, ist eine Fachverwaltung ein kleines Universum für sich. Daten werden von Fachleuten (aus Büros) gesammelt, die Teil des Gesamtsystems sind. Sie verwenden die Software-Komponenten und kennen sich aus. Auch die Datennutzer gehören zum selben Anwenderkreis.
Geo-Daten wurden in RP zunehmend auch im Internet dokumentiert und dort verfügbar gemacht. Dafür wurde das Datenmodell stark vereinfacht, d. h. wesentliche Attribute wurden in nur einer Tabelle zusammengefasst. Inzwischen ist die Produktionsdatenbank in RP eine PostgreSQL Datenbank geworden und darauf arbeitet ein Kartenclient (mapserver) die ständig wachsende Abfrageflut ab. Nach zehnjähriger Nutzung des Systems sollen zukünftig durch den Einsatz des neuen Systems folgende Nachteile vermieden werden: zum einen das streng hierarchisch ausgelegtes relationales System, was zu stark verschachtelten Datenstrukturen führt, und zum anderen die fehlenden Möglichkeiten einer verständlichen 140 Modelldokumentation. Ein Beispiel für die nötige Verschachtelungstiefe des Attributs „Tierart“ zeigt der folgende Auszug aus dem Datenmodell: <attribut name="FLAECHE" value="25,5358" /> <attribut name="FLANZ" value="9" /> <attribut name="KENNUNG" value="KOM-1493204890966" /> <attribut name="OBJBEZ" value="ICE NBS PFA 41 VG Asbach Nord Kom E 2.1.2" /> <attribut name="PROJEKT_URSPRUNG" value="OSIRIS Rheinland-Pfalz" /> </row> <table name="BtypHtyp"> <row> <attribut name="Biotoptyp" value="AA0" /> </row> <table name="Vegetationstyp"> <row> <attribut name="Vegetationstyp" value="Galio odorati-Fagetum typicum" /> </row> <table name="Schichtung"> <row> <attribut name="Schicht" value="Ohne Zuordnung" /> </row> <table name="Tierliste"> <row> <attribut name="Tierart" value="Milvus milvus" /> …. 1.4 Web-GIS Phase IV (ab 2010) bezeichnen wir als die Phase der aufkommenden Web-GIS Systeme. Die in Abschnitt 1.3 benannten Nachteile des OSIRIS-Baukastens wurden erst deutlich mit der Erweiterung der Anwender auf Nutzer außerhalb des Fachstrangs. Wesentlich für Phase IV ist jedoch, dass sich in der Geowelt weltweit einheitliche Standards herausbilden mussten, um im Web Anwendungen effizient betreiben zu können. Anders als bei der Kataster- und Vermessungsverwaltung, die als Lieferant von Geobasisdaten auf den Datenaustausch mit der Geowelt angewiesen ist, war für die kleine Naturschutzwelt ein Übergang auf Standards zur Zeit der Einführung von inspire noch nicht essentiell notwendig. Dies hat sich geändert. Ausschlaggebend dafür sind folgende Gründe: • bei der Einbeziehung anderer Verwaltungen, wie z. B. in Zusammenarbeit mit verschiedenen Eingriffsverwaltungen bei Kompensationsmaßnahmen, zeigten 141 sich in Phase III deutlich Nachteile bei der Dokumentation, der Beschreibung des Fachmodells und der Darstellung von Schnittstellen. • die ersten großen Datenkonsumenten, die durch inspire entstanden sind, bedürfen umfangreicher Fachdokumentation.
Die Art und Weise, das Datenmodell zu erstellen und zu beschreiben, entwickelte durch die EU- Vorschriften entsprechende Vorbildfunktion. Anders als beim AAAModell der Vermessungsverwaltungen, ebenfalls als Anwendungsschema modelliert, hat inspire im Naturschutz einen entscheidenden Vorteil: Es ist wirklich einfach geworden! Das ist überraschend und gut.
I: Nur Datenbank Interne Datenrecherche möglich II: Workstation Arc/Info Spezialisten-GIS: Interne Planungsunterstützung III: Desktop-GIS + Erleichtertes Datenhandling: Daten werden von Externen web-mapping erhoben und genutzt (shape) IV: Inspire – standardisiertes Einstieg in echtes e-government: Umfassender Datenmodell und Datenaustauch Webservices
Tabelle 1: Übersicht zu GIS-Phasen der Rheinland-Pfälzischen Naturschutzverwaltung
Ein letzter Grund für die Umstellung auf mehr Standards sei abschließend noch angeführt: die zunehmende Personalknappheit in der Verwaltung bei wachsenden Aufgaben. Deshalb prognostizieren wir für die nächste Phase eine zunehmende Automatisierung von Verwaltungsprozessen, bis hin zur vollständigen Übernahme von Aufgaben durch den Computer. Wenn hierbei mehrere Verwaltungsstellen betroffen sind, geht das nicht ohne klare Vereinbarungen – also Standards. Dabei ist die Vereinheitlichung und Dokumentation des Datenmodells noch der einfachste Aspekt. Viel schwieriger ist die Harmonisierung der unterschiedlichen Vokabularien – Techniken des semantischen web könnten hier helfen.
Natürlich sollte die Möglichkeit, schnell und effektiv eine Datenbankmodellierung und Erfassungsmöglichkeit zu generieren, weiter die Produktivität in der Naturschutzverwaltung vorantreiben.
Im nächsten Abschnitt wird der Übergang von Phase III zu Phase IV in Rheinland-Pfalz ausführlich dargestellt. Die Vorteile der Standardisierung, der Automatisierung von Dokumentation, der Wiederverwendbarkeit von Teilmodellen und der Möglichkeit, Web-Erfassungsmodule automatisch zu generieren, werden so im Zusammenhang deutlich gemacht.
In Abschnitt 3 werden die einzelnen verwendeten Komponenten zusammenhängend vorgestellt und einzelne davon am Beispiel einer konkreten Objektart (Artdaten) näher beleuchtet. Ein Ausblick beschließt den Beitrag in Abschnitt 4.
Rheinland-Pfalz stellt seit 2016 die Modellierung von Geo-Fachdaten um: statt einem
GISPAD-Kartierverfahren (s. Phase III) wird als neuer Objektartenkatalog ein ISO
konformes GML-Anwendungsschema [
Wir stellen nun nacheinander kurz den Ausgangspunkt (Phase III) und das neue Konzept für Phase IV vor und gegenüber.
Grundlage der bisherigen Anwendungsstrategie war das monolithische Datenbanksystem OSIRIS auf der Grundlage eines maschinenlesbaren sog. Gispad-Kartierverfahrens. Mit dem Werkzeug GISPAD - Objekteditor der Fa. Conterra konnte das Kartierverfahren definiert, sukzessive erweitert und fortgeschrieben werden. Das Kartierverfahren beinhaltet nicht nur das Datenbankmodell, sondern auch alle Schlüssellisten. Außerdem sind im Kartierverfahren frei definierbare Erfassungsmasken mit abgelegt. Das Kartierverfahren besteht aus einer Access Datenbank mit den das Modell beschreibenden Metadaten. Es kann selber in Desktop-GISPAD geladen werden und stellt so ein Werkzeug zur Datenerfassung für OSIRIS bereit. Abbildung 1 veranschaulicht das Zusammenspiel der Komponenten. Erweitert wurde OSIRIS um ergänzende Fachinformationssysteme (eFIs), die eine verteilte Erfassung und Pflege von Naturschutzobjekten im Verwaltungsvollzug unterstützen. Die fortlaufende Kontrolle von Naturschutzmaßnahmen oder die kaufmännische Abwicklung von dazu benötigten Ausschreibungs- oder Beschaffungsprozessen sind Beispiele für unterstützten Verwaltungsvollzug. Im Zuge dieser eFI-Entwicklungen sind dann auch web-basierte Erfassungswerkzeuge entstanden, zunächst noch als Individualanwendungen.
Abbildung 1: Komponenten des aktuellen LANIS
Weitere Fachanwendungen, wie z. B. das Artenfinder-Serviceportal (AFSP) als eine
citizen-science-Anwendung, das für den Naturschutz in Rheinland-Pfalz wichtige
Daten liefert
Die neue Konzeption setzt der bestehenden Denkweise keine grundlegend andere Architektur entgegen, legt aber einen weitaus höheren Wert auf die Verwendung von Standards in der Modellierung. Datenzugriff und –nutzung werden konzeptionell nicht verändert. Alle anderen Aspekte führten zu einer Neudefinition des LANIS in den folgenden sieben Themenfeldern:
Die für den amtlichen Naturschutz relevanten 28 Objektarten werden vollständig in einem ISO konformen GML-Anwendungsschema repräsentiert. Als Vorlage für die Modellierung dienen Inspire-Konventionen und -packages. Schlüssellisten werden nicht im Modell verwaltet, sondern nur referenziert.
Grundlage für alle IT-Komponenten bildet die aus dem UML-Modell ableitbare XML Schemadatei. Diese maschinenlesbare Dokumentation des Objektartenkatalogs liefert zudem die Schnittstellenbeschreibung für die Anbindung von externen Komponenten außerhalb der eigenen Verwaltung.
Der Objektartenkatalog als Fachmodell für einen breiteren Anwenderkreis wird „menschenlesbar“ dokumentiert.
Diese ersten drei Themenfelder sind bereits abgearbeitet und im Einsatz. Um die Vorgabe so weit wie möglich umzusetzen, alle für die Praxis und den Betrieb nötigen IT-Komponenten mit einer Modellfortschreibung automatisiert anpassen zu können, werden derzeit die folgenden Themenfelder weiter bearbeitet:
Ziel ist es, einzelne Objektarten und -gruppen auf einer zentralen PostGresSQL-Datenbank effektiv zu verwalten.
Die verteilte Pflege, Fortschreibung und Kontrolle von amtlichen Fachdaten durch autorisierte Fachnutzer wird durch Erfassungs- und Pflegeanwen-dungen unterstützt.
Die Erhebung und Fortschreibung von Fachdaten (insbesondere durch Externe/Dritte, ggf. auch offline) wird so unterstützt.
Die automatische Generierung eines Datenbankschemas aus dem Anwendungsschema stellt heutzutage keine große Herausforderung mehr dar (Themenfeld 4). „Enterprise Architect“ (EA) als Standard-Modellierungswerkzeug liefert eine nutzbare ddl bereits „frei Haus“. Für die Themenfelder 5 und 6 wurden im Baukasten oNEO Werkzeuge definiert und umgesetzt, deren Einsatz zur Zeit evaluiert wird. Das letzte Themenfeld ist in Vorbereitung:
die die administrative Datenpflege, -aufbereitung, –repräsentation und – synchronisation unterstützen.
Diese Werkzeuge sollen ebenfalls Aktualisierungen des Fachmodells aufgreifen und für die Datenhaltung geeignet nachführen können. Dazu gehört auch die automatische Re-Konfigurierbarkeit des Kartenclient und der OGC-Dienste, wenn sich das Fachmodell weiterentwickelt.
Abbildung 2 zeigt in einer Übersicht die Komponenten des neuen Baukastens, um Komponenten eines Informationssystems automatisiert aus Modell-Definitionen zu generieren und fortzuschreiben.
Abbildung 2: Konzepte und Werkzeuge von ONeo
Ausgangspunkt ist die Datenmodellierung, modelliert mit dem Werkzeug Enterprise
Architect (EA) [
Mit Unterstützung des frei verfügbaren Werkzeugs shapechange wurde mit oDOK eine individuelle Lösung geschaffen, die das Fachmodell für einen größeren Anwenderkreis nachvollziehbar und lesbar dokumentiert. Die technischen SchnittstellenSchemata werden ebenfalls von oDOK zur Verfügung stellt (s. auch Abschnitt 3.1). Schlüssellisten werden in oNEO außerhalb des EA-Modells definiert und gepflegt. Um Schlüssellisten verteilt anzulegen, zu pflegen und zu verwalten wird die Anwendung oKey genutzt. Zur Veröffentlichung werden die Schlüssellisten aus oKey beim Geoportal Rheinland-Pfalz mit Methoden des semantischen web (skos) hinterlegt (Bsp.: http://www.geoportal.rlp.de/skosmos/de/).
In das formale Datenmodell werden alle Schlüssellisten über Referenzen eingebunden (s. auch Abschnitt 3.2).
Die Generierung eines Datenbankschemas über den dll-Generator von EA unter Berücksichtigung der Referenzlisteneinbindung führt zur Grundlage der zentralen Datenbankanwendung.
Eine letztes wichtiges Werkzeug im Baukasten oNEO ist eine Konfigurationsoberfläche (App-O-Mat), die aus EA-Modellen (mit spezifischen Eigenschaften) und Schlüssellisten automatisch Web-Anwendungen generiert. Dieser Ansatz wird in Abschnitt 0 ausführlicher vorgestellt.
In Rheinland-Pfalz werden Informationen über das Vorkommen von Arten als Artbeobachtungen von Tieren und Pflanzen unterschieden. Das UML-Modell für Artendaten zeigt Abbildung 3.
Die Objektarten FundorteTiere und Fundorte Pflanzen verwenden einen gemeinsam nutzbaren feature Type Artbeobachtung. Spezielle, nur für Pflanzen sinnvolle Attribute 147 (z. B. Deckungsgrad) und andere, die nur für Tiere (z. B. Erfassungs-methode) zweckmäßig sind, ergänzen die Attribute aus Artbeobachtung in der eigentlichen Objektartendefinition für Tiere und Pflanzen.
Abbildung 3: UML-Diagramm für Objektarten Tiere und Pflanzen Artbeobachtungen von Tieren und Pflanzen ist gemein, dass vereinfachend der Beobachtungsort als Punkt angegeben (Datentyp GM_Point) wird (Flächen für Pflanzenvorkommen werden im Rahmen der Aktivitäten der Biotopkartierung in einer anderen Objektart erfasst). Die vorgefundene Art wird aus einer Schlüsselliste ausgewählt (die Datentypbezeichnung CL<name> bezeichnet stets Schlüssellisten), ebenso wie Angaben zur Begehungsmethode, zur Informationsquelle und zur Häufigkeit. Genauere und umfassendere Angaben zur Objektmodellierung stehen öffentlich unter http://www.osiris-projekt.rlp.de/ok_osiris zur Verfügung.
Abbildung 4 zeigt beispielhaft eine Seitenansicht für das sog. OsirisObjekt, um hier einen ersten Eindruck zum Stil und zur Lesbarkeit der Dokumentation zu vermitteln. Alle Objektarten in OSIRIS verwenden das sog. OsirisObjekt als Datentyp. Es enthält u. A. als Attribute eine Kennung, eine sprachliche Benennung und das Datum der Veröffentlichung.
Abbildung 4: Dokumentation (als Web-Portal) generiert aus xsd-Modell
Schlüssellisten sind weniger stabil als Objektartenmodelle. Dies war ein Grund, die Schlüssellistenverwaltung als eine eigenständige Komponente einzubinden und unabhängig von der Pflege und der Fortschreibung des Objektartenmodells zu betrachten. Das Anwendungsschema zusammen mit den Schlüssellisten definiert das Kartierverfahren.
Ursprünglich sollte die Schlüssellistenpflege und Dokumentation im Rahmen der GDIDE-Registry genutzt werden. In Ermangelung eines verfügbaren Angebotes wurde ein Ersatz geschaffen, mit dem auch die Fachseite an der verteilten Erstellung und Pflege von Schlüssellisten breit beteiligt werden kann. Abbildung 5 zeigt den Aufruf einer Schlüsselliste in oKey.
Abbildung 5: Repräsentation der Schlüsselliste für Tiere Im linken Teil der Maske ist die Schlüsselliste hierarchisch dargestellt und lässt sich beliebig verschachteln. Im rechten Teil der Anwendung (hier nur verkürzt dargestellt) werden konkrete Informationen zu einem ausgewählten Schlüsseleintrag dargestellt. Besonderer Wert wurde auf die Einbindung externer amtlicher Liste und Thesauri gelegt. Einträge zu Arten werden z. B. auf die amtliche Listen von EU-Nomen referenziert (http://www.eu-nomen.eu), entsprechend Inspire. Der Biotopschlüssel bildet den Inspire relevanten Habitatschlüssel von EUNIS ab. Abbildung 6 zeigt einen Ausschnitt für einen Eintrag aus der Schlüsselliste beim Geoportal Rheinland-Pfalz.
Abbildung 6: Schlüsselliste der Biotope http://www.geoportal.rlp.de/skosmos/de/
App-O-Mat heißt das Werkzeug, um ausgehend von einem EA-Modell ohne Programmierkenntnisse für einzelne Objektarten(gruppen) schnell und kostengünstig eine passende Web-Anwendung automatisch zu erzeugen.
Abbildung 7: Generierte Web-Anwendung zum EA-Modell Tier- und Pflanzenarten Abbildung 7 zeigt beispielhaft eine Erfassungsmaske, generiert aus dem Arten-Modell. Die Anwendung http://serviceportal.naturschutz.rlp.de/artendaten/ ist für externe Nutzer als Serviceportal bereits im Einsatz. Auf dem Reiter Tierart finden Sie die Attribute des Datenmodells wieder, die das Vorkommen einer Tierart ergänzen. Standardmäßig unterstützt der App-O-Mat sog. CRUD-Operationen (create, read, update und delete), die das Anlegen und Bearbeiten von Objekten ermöglichen. Für die Identifikation von Objekten können in der Anwendung „Suchfilter“ konfiguriert werden, um die Ergebnismengen geeignet zu filtern.
Die Zusammenstellung von Erfassungsmasken und Suchfiltern zu einer Objektart ist das Einzige, was Fachpersonal tun muss. Eine Erfassungsmaske wird im App-O-Mat entworfen, in dem alle im Modell verfügbaren Attribute als Felder auf unterschiedliche Reiter (als sinngebende Einheiten) verteilt werden können. Für jeden Reiter können die Felder in einer gewünschten Reihenfolge angeordnet werden.
Zusätzlich sind in Rheinland-Pfalz weitere Module aktivierbar: • eine Nutzerverwaltung (u. A. mit verschiedenen Rollen und Mandanten, z. B. den
Kreisverwaltungen in RP) • eine Upload-Verwaltung für Dokumente und Bilder • eine Zeitstrahl-Visualisierung (time-line)
Abbildung 8: Modul Kartenanwendung zur Erfassung von Geometrie-Daten In Rheinland-Pfalz werden die so generierten Web-Anwendungen in Java erzeugt. Die erzeugten Anwendungen können automatisch auf einem Server eingesetzt und veröffentlicht werden. Ein Bereich für individuelle „code-ergänzungen“ ermöglicht zudem, dass über diese Standardfunktionen hinaus gehende Funktionserweiterungen bestehen bleiben, wenn das Modell fortgeschrieben wird. Dies ist zur Zeit z. B. ein Input-/Output (geo-packages für Artdaten). Geplant ist, sukzessive weitere Module in den App-O-Mat einzubinden, wie z. B. ein kanonischer xsd-Import/Export, ein Berichtsgenerator oder Freigabemechanismen. Der App-O-Mat kann prinzipiell Anwendungen in beliebigen Programmiersprachen erzeugen, da für die einzelnen Bausteine programmiersprachenbezogene Vorlagen zur Anwendungserzeugung verwendet werden.
Inspiriert durch die Arbeiten in INSPIRE hat Rheinland-Pfalz den nächsten Schritt gewagt: Ausgehend von einer an Standards orientierten Modellierung werden nicht nur Schnittstellen definiert und beschrieben, sondern das gesamte LANIS soll sich weitestgehend aus dem Anwendungsschema ableiten und fortschreiben lassen. Sicherlich ist eine Fortschreibung nicht beliebig automatisierbar. Aber die gängigen Fortschreibungsaspekte (Ergänzungen, Umbenennungen, Konsolidierung, Vereinheitlichung) werden unterstützt und vereinfacht, da insbesondere auch die 152 Wiederverwendbarkeit von Datentypen und Standards sowie die Trennung von Modell und Referenzlisten dazu beitragen.
Modellgetriebene Softwareentwicklung ist die methodische Grundlage für das Vorgehen in Rheinland-Pfalz: Softwaresysteme werden ganz oder teilweise aus einem Modell generiert. Auch dem Ziel, die Fachseite frühzeitig und transparent in den Entwicklungsprozess mit einzubinden, wurde in ONeo Rechnung getragen. Die Nutzung frei verfügbarer Werkzeuge und Datenbankmanagementsysteme ermöglichte ein Vorgehen in kleinen Schritten, ohne hohe Kosten zu verursachen.