terraseek OpenGIS basierter Katalogdienst für Geodaten und Geoservices

Transkript

1 EnviroInfo 2001: Sustainability in the Information Society terraseek OpenGIS basierter Katalogdienst für Geodaten und Geoservices Uwe Voges 1 Abstract The German state Northrhine Westfalia is building a geospatial infrastructure (GDI) based on the OGC Web services. One result is terraseek, a search engine for georesources, built by con terra GmbH and the Institute for Geoinformatics (University of Münster). terraseek is the first conformant implementation of the OGC catalog services. 1. Einführung Zur Belebung des Geodatenmarktes (besser: Geoservicemarktes, s.u.) ist es erforderlich, durch die Schaffung einer auf modernen Informationstechnologien basierenden Geodateninfrastruktur, eine bessere Vernetzung von Anbietern, Dienstleistern und Nutzern zu erreichen. Der Stand der Softwaretechnologie sowie der internationaler Standards (ISO, OGC, W3C) bietet mittlerweile eine nutzbare Basis für den Aufbau solcher vernetzter, komponentenbasierter Infrastrukturen. Vor allem die serviceorientierten Spezifikationen des OpenGIS Consortiums (OGC) können für den Aufbau von Geodateninfrarstrukturen einen wichtigen Beitrag leisten. Das Land Nordrhein-Westfalen fördert die Entwicklung einer landesweiten Geodateninfrastruktur (GDI). Eines der ersten Ergebnisse ist terraseek, eine von der con terra GmbH zusammen mit dem Institut für Geoinformatik der Universität Münster (IfGI) realisierte Suchmaschine für Geodaten und Geoservices, die auf den OGC Catalog Services basiert und als erste hierfür die Zertifizierung von der OGC erhielt. 2. GDI Nordrhein-Westfalen Im Rahmen der Softwareinitiative des Landes NRW, einem Teil von media NRW, befaßt sich die Arbeitsgruppe Geodateninformationssysteme mit den für den Aufbau eines offenen Geodatennetzes NRW notwendigen technischen Voraussetzungen (GDI-NRW, vgl. Gleichzeitig hat das Land NRW das 1 Dr. Uwe Voges, con terra GmbH, Mendelstr. 11, D Münster, voges@conterra.de, Internet:

2 485 Fördervorhaben GEOBASIS.NRW gestartet. Hier sollen innerhalb von 5 Projektteams, die sich aus Vertretern von Städten, Industrie und Regionalbehörden zusammensetzen, netzintegrierte kommunale Geoinformationssysteme auf der Grundlage von ATKIS sowie des neuen AdV-Standards ALKIS konzipiert und praktisch erprobt werden. 2.1 Referenzmodell Zielsetzung, Inhalt und Architektur von GDI werden in einer Rahmenspezifikation, dem sog. Referenzmodell GDI NRW, beschrieben (Kuhn et al. 2000). Das Ziel des Referenzmodells ist es, die wichtigsten Komponenten von GDI sowie die Anforderungen und Schritte für das Design ihrer Details zu definieren. Entwickelt wird das Referenzmodell von sog. Special Interest Groups (SIG s). Con terra und IfGI arbeiten im Rahmen der Architecture SIG zusammen mit anderen Firmen und Institutionen am Architekturmodell, einem Teil des Referenzmodells. Grundlage des Abbildung 1: Geodatennetz NRW Architekturmodells sind neben innovativen IT-Konzepten vor allem internationale Standards. Von zentraler Bedeutung sind hier die Spezifikationen der OGC. Derzeit richten die SIGs eine Testumgebung ein, die zur Prüfung der Konzepte und zur Gewinnung weiterer Spezifikationen für das Referenzmodell genutzt werden soll.

3 Grundlage: OGC Web-Services Ziel der OGC ist die Schaffung der Möglichkeit digitaler Systeme Geoinformationen aller Art auszutauschen und sie kooperativ über ein Netzwerk miteinander kommunizierender Software-Komponenten zu verarbeiten ( interoperable geoprocessing ). Sie definiert und standardisiert primär nicht bestimmte Austausch-/Dateiformate, sondern Dienste (Services), die die Komponenten zur Verfügung stellen und die von anderen Komponenten aufgerufen werden können (Buehler/McKee 1998). Ein Beispiel sind die Simple Feature Services (OGC 1999b), die Methoden für den Zugriff auf die Basiseinheiten geographischer Information, die Simple Features, spezifizieren. Damit verteilte Komponenten auf einer oder mehreren, auch heterogenen Plattformen miteinander kommunizieren können, bedarf es einer homogenen Umgebung, der sog. Distributed Computing Plattform (DCP). Hierzu gehören etwa CORBA, Web/HTTP, COM oder SQL/ODBC. Ein Service kann somit definiert werden als selbständige, ausführbare Softwarekomponente, die prinzipiell weder an ein bestimmtes Betriebssystem oder Netzwerk noch an eine bestimmte Programmiersprache oder Implementierung gebunden ist und über ein definiertes Protokoll, d.h. einer für eine bestimmte Distributed Computing Platform definierte Schnittstellenbeschreibung, aufgerufen werden kann. Solche Schnittstellenbeschreibungen liefern die OGC Spezifikationen. Die für die DCP Web/HTTP spezifizierten Services werden als Web-Services bezeichnet. 2.3 Architekturmodell GDI realisiert eine Service Architektur, die auf den OGC Web Services basiert. Mittels GDI soll dann das Geodatennetz NRW entstehen, bestehend aus interoperablen Services-basierten Knoten (Abb. 1). Das GDI Architekturmodell definiert diese Service Architektur und beschreibt detailliert die für GDI relevanten Services. Eine Bewertung der auf dem OGC Basic Service Model (de la Beaujardiere 2001) basierenden OGC Web Services im Verhältnis zu den im Rahmen von GDI geplanten einzusetzenden Web-Services ergibt folgendes Bild: 1. Bereits jetzt in GDI einsetzbare OGC Web Services: Web Map Service (verteiltes Web Mapping): derzeit Version 1.08 Web Feature Service (online- Zugriff auf Features): derzeit Version Für GDI anzupassende bzw. erst in einer neuen Version verwendbare Services: Catalog-/Registry Services (Suche nach Georesourcen): IP Draft Version Web Coverage Service (Zugriff auf Coveragedaten): derzeit Version Fehlende OGC Services, die im Rahmen von GDI spezifiziert werden: Web Ordering und Pricing Service (online-bestellung, Preisbildung etc.)

4 OGC Catalog Services Jemand der im Internet nach bestimmten Informationen recherchiert, hat keine Alternative als in bekannten Locations zu suchen und über Links zu anderen Locations zu navigieren. Eine solche Suche ist sehr ineffektiv. Ein Weg zur Verbesserung dieser Situation besteht darin, die Resourcen zu katalogisieren (OGC 1999a). OGC Kataloge enthalten Informationen, die Katalogeinträge, welche Geodaten (vor allem Datensätze) und Geoservices beschreiben und referenzieren (Abb. 2). Abbildung 2: Datenmodell eines OGC Catalogs Diese Informationen (z.b. Thematik, Raumbezug) werden als Metadaten bezeichnet (Abb. 2). Sie können eingesehen und es kann eine Suche darauf angewendet werden. Die gefundenen Daten und Services lassen sich dann über Verknüpfungen zugreifen (OGC 1999a). Während die OGC Spezifikation unabhängig von einem speziellen Metadatenmodell ist, wird die Verwendung von ISO TC211 Metadatenmodellen nahegelegt. Für GDI wurden bisher ISO TC/ (Geodaten) und ISO TC/ (Geoservices) als Standards in Betracht gezogen. Die OGC Catalog Services decken im Rahmen der OGC Service Architecture die Katalogdienste für Georesourcen ab. Sie umfassen Dienste und Funktionen zur Verwaltung von Katalogen und zum Zugriff auf Katalogeinträge.

5 Funktionen eines Katalogs Die wichtigste Funktion eines Katalogs besteht darin, die in ihm enthaltenen Einträge auf verschiedene Weise (z.b. nach Raum- oder Zeitbezug) zu durchsuchen. Diese Query-Funktion findet alle Einträge, die den Bedingungen (= query-definition) entsprechen. Die Ergebnismenge wird als Collection z.b. in XML-Format zurückgeliefert. Die Formulierung einer Anfrage (i.d.r. durch Anwendungsprogramme) erfolgt in der sog. OGC_Common Catalog Query Language (CQL). Beispiel: title like '%Kaufkraft%' and timestamp>= DATE" " and intersects( GeographicBoundingBox, ENVELOPE(-30.88, 30, 70.1, 40.7 )) Die zuletzt erläuterte Funktionalität zum Auffinden von Katalogeinträgen wird den sog. Discovery Services zugeordnet. Neben dem Discovery-Service umfaßt ein OGC Catalog Service Dienste zum Management von Katalogen und Katalogeinträgen sowie zum Zugriff (Access) auf die im Katalog beschriebenen Georesourcen. 3.2 Referenzarchitektur Die Referenzarchitektur eines OGC Catalogs zeigt eine multi-tier Anordnung von Clients und Servern (Abb. 3). Da auch Katalog-Einträge der fundamentalen Defini tion von Simple Features entsprechen, sollte die Klasse der Katalogeinträge das Feature-Interface implementieren. Katalogeinträge werden somit zu Subtypen von Features und Kataloge damit zu Subtypen von Feature-Collections (OGC 2000). Es ist dann auch möglich, den Datenspeicher des Katalogs direkt durch ein OGC konformes feature data access interface zuzugreifen und somit von den speziellen Zugriffen auf eine physische Datenquelle zu abstrahieren. Die Abb. 3 zeigt, daß an fast allen Stellen OGC Catalog- bzw. Feature-Interfaces eingesetzt werden. Die Referenzarchitektur der OGC Catalog Services sieht auch vor, daß ein Katalog eine Anfrage akzeptiert und diese Anfrage an andere Kataloge weiterleiten kann. Abbildung 3: Architekturmodell eines OGC Catalogs

6 489 Das OGC Catalog General Model definiert Verhalten und Schnittstellen die für alle Kataloge gültig sind. Spezielle Implementierungsprofile liegen für die DCP s CORBA, COM und WWW vor. Jedes muß Konsistenz mit dem General Model zeigen. Diese Konsistenz erlaubt die Konstruktion von Brücken zwischen den Profilen. Da GDI auf Web-Services basieren wird, ist das Web-Profile besonders interessant. Bisher (6/2001) existiert ein sog. Stateful Catalog Services Web-Profile, basierend auf Z Dieses vor allem im Hinblick auf die Interoperabilität mit anderen Z39.50 Communities. Ein stateless Web-Profile, das besser zu den anderen Web- Services der OGC Services Architektur paßt, ist bei der OGC in der Entwicklung. Es existiert derzeit eine Draft-Spezifikation, an der auch die con terra mitwirkt. 4. terraseek OGC/GDI-konformer Catalog Server 4.1 Überblick terraseek ist ein GDI- und seit Mai 2001 der erste OGC zertifizierte Catalog Server. Entwickelt wird er von der con terra GmbH in Kooperation mit dem IfGI im Rahmen von GDI. Er besteht aus dem terraseek.applicationserver, der terra- Seek.Middleware, dem terraseek.explorer sowie dem sich in der Entwicklung befindlichen terraseek.administrator, der XML-basierte Metadatensätze entgegennimmt oder von einem Service erfragt und in die Metadatenbank einpflegt (Abb. 4). 4.2 terraseek.applicationserver Im folgenden werden (unter Bezugnahme auf das Referenzmodell der OGC Catalog Services) die zur Implementierung des Applicationservers von terraseek eingesetzten Technologien dargestellt. Im Zentrum des Applicationsservers steht eine OGC zertifizierte Java- Implementierung (CSServer ) der OGC Catalog Services Specification for CORBA (OGC 2000) (Abb. 4). Dieses vor allem vor dem Hintergrund, daß die CORBA-Spezifikation am weitesten ausgereift und eine einfachere Integration mit bestehenden Komponenten möglich ist. Als Abfragesprache dient CQL. XML wird in verschiedenen Bereichen der Umsetzung eingesetzt. Der CSServer erlaubt es, entsprechend den zwingend erforderlichen Vorgaben durch das General Catalog Interface-Model, Katalog-Anfragen auf verschiedene Kataloge zu verteilen. Die Implementierung enthält zudem Eigenschaften wie sie bei einem Applicationserver typisch sind,

7 490 terraseek.administrator terraseek.explorer HTTP OGC WRS OGC WMS terraseek.middleware OGC CS 1.0 CORBA TCP/IP AXL terraseek.applicationserver Custom Interface terraseek.csserver OGC SF 1.1 CORBA ArcIMS terraseek.sfserver JSDE JDBC/SQL3 ArcSDE 8.x Files Files Files Metadaten (ISO...) beschreibt Geodaten Abbildung 4: Architekturmodell von terraseek wie z.b. Thread- und Session-Management. Entsprechend den Ausführungen zum Referenzmodell implementiert der terraseek.applicationserver auch die Schnittstelle der OGC Simple Feature Services für CORBA (OGC 1999b) (SFServer). Hierüber greift der CSServer auf die Metadaten zu. Der Zugriff des SFServers auf die in einer objekt-relationalen-datenbank (Informix IDS.2000 oder Oracle 8i) vorliegenden Metadaten erfolgt alternativ mittels der Java API von Esri s Spatial Database Engine (JSDE) oder via JDBC und SQL3. Um eine möglichst hohe Flexibilität bzgl. der Implementierung des verwendeten Metadatenmodells (z.b. ISO) zu bekommen, wird diese vom sog. Metadata Abstraction Layer (MAL) gekapselt. Generatoren zur Erzeugung der Datenbankaufrufe arbeiten mit dem MAL eng zusammen. Durch den MAL ist es möglich, die Imple-

8 491 mentierung des Metadatenmodells zu ändern, ohne die Logik des CSServers anpassen zu müssen. Die Analyse der Anfragen übernimmt ein CQL-Parser. 4.3 terraseek.middleware Der CSServer ist von Clientanwendungen auf zwei verschiedene Arten zugreifbar: direkt über CORBA oder via HTTP. Für den Zugriff via Internet/Intranet (HTTP) Abbildung 5: terraseek.explorer orientiert sich die Implementierung an der Draft Version 0.02 des Stateless Web- Profile (Web Registry Service) der OGC Catalog Services Spezifikation. Die HTTP-Schnittstelle kann von einer Vielzahl zugreifender Clients mit minimalen Systemvoraussetzungen verwendet werden. Sie ist somit optimal für die In-

9 492 tegration ins Internet geeignet. Implementiert ist diese Bridge in Form eines Java- Servlets, das die Aufrufe zwischen dem Web- und dem CORBA-Profil konvertiert. 4.5 terraseek.explorer Der Internet/Intranet-Client von terraseek (terraseek.explorer) unterstützt die Recherche nach Geodaten und Geoserivces. Mit ihm können sowohl Attribute als auch räumliche Abfragekriterien definiert werden (Bild 5). Die Definition des räumlichen Filters geschieht durch Selektion eines rechteckigen Ausschnittes innerhalb einer interaktiven Übersichtskarte, die auf dem Arc Internet Map Server (ArcIMS) von Esri basiert. Eine Erweiterung um komplexere räumliche Abfragen (z.b. Polygone) ist möglich. Aus den Abfragekriterien wird ein CQL-Statement erzeugt, das via HTTP zur Ausführung an die terraseek.middleware gesendet wird. Die Metadaten der Treffermenge können clientseitig in unterschiedlicher Detaillierung betrachtet werden. Zusätzlich werden die Bounding-Boxen der Treffer in der via ArcIMS erzeugten Übersichtskarte dargestellt. Der terraseek.explorer basiert auf (D)HTML und JavaScript 1.2. Art und Umfang der Suchattribute sind konfigurierbar. Sofern Geoservices im Katalog beschrieben werden, besteht die Möglichkeit, einen gefundenen Service direkt aufzurufen ( Service im Fenster öffnen in Abb. 5). Ein Beispiel ist der direkte Zugriff auf einen Web Mapping Service, der es erlaubt, gefundene Daten zu visualieren oder ein spezieller Data-Access-Service (RTRAF- Service in Abb. 5), der Geodaten nach einer Transformation zum Download oder zur Weiterverarbeitung anbietet. Es sind natürlich weitere Dienste vorstellbar, die in terraseek integriert werden können. Auch der bereits unter verfügbare GeodatenKIOSK der con terra wird zukünftig auf terraseek aufbauen. Literaturverzeichnis Buehler, K. & McKee, L. (1998): The OpenGIS Guide Introduction to Interoperable Geoprocessing and the OpenGIS Specification. 3. Edition, OpenGIS Consortium, Wayland, Massachusetts. de La Beaujardiere, J (2001): Basic Services Model Draft Candidate Implementation Specification. Version 0.0.8, OpenGIS Consortium Discussion Paper #01-022r1. Kuhn et al. (2000): Reference model 1.0. Geospatial Data Infrastructure (GDI) Northrhine- Westfalia. OGC (1999a): The OpenGIS Abstract Specification. Topic 13: Catalog Services. Version 4. OpenGIS Project Document Number doc. OGC (1999b): OpenGIS Simple Features Specification For CORBA. Revision 1.1. OGC (2000): OpenGIS - Catalog Interface Implementation Specification Version 1.0.