Geoland.harvest - das Metadateninformationsnetzwerk der österreichischen Bundesländer
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Geoland.harvest – das Metadateninformationsnetzwerk
der österreichischen Bundesländer
Rainer PRAGER1
Zusammenfassung
Geoland.at ist das Geoportal der österreichischen Länder mit dem Ziel einen zentralen und
kostenfreien Zugang auf Geodaten und Geoservices der österreichischen Bundesländer zu
ermöglichen. Geoland.at ist damit Teil von derzeit im Aufbau befindlichen nationalen bzw.
internationalen Geodateninfrastrukturen (GDI), die die Nutzung von öffentlichen Geodaten
für Verwaltung, Wirtschaft, Forschung, Bildung und Bürger wesentlich verbessern.
Im Projekt „geoland.at Metadateninformationsnetzwerk“ wurde die Integration einer län-
derübergreifenden Metadatensuche konzipiert und umgesetzt. Die Grundlage dieses inter-
operablen Katalognetzwerks bilden die internationalen Standards CS-W 2.0 (mit ISO AP
1.0) des Open Geospatial Consortium (OGC) sowie die ISO-Normen 10115/19119/19139.
Durch die Integration in das Länderportal wird eine länderübergreifende Metadatensuche
nach Geodaten und Geodiensten ermöglicht. Als Basis der Implementierung wurde die
Software terraCatalog ausgewählt und an die Anforderungen der Länder angepasst.
1 Einleitung
Als wesentliche funktionale Erweiterung des Geoportals www.geoland.at der österreichi-
schen Bundesländer wurde ein Katalognetzwerk auf Basis der Software terraCatalog auf-
gebaut. Die Erfassung und Verwaltung der Metadaten erfolgt bei den einzelnen Landesre-
gierungen und werden über einen Metadaten-Broker zentral recherchierbar gemacht.
Die Kommunikation zwischen dem Broker und den Katalogservices der Länder erfolgt
über das so genannte Portalverbundprotokoll und damit auf gesicherte Leitungen über das
Internet. Außerdem ist die Authentifizierung und Autorisierung für die Verwendung der
Software in den Landesregierungen über das Portalverbundprotokoll geregelt. Damit entfal-
len redundante Rechteverwaltungen.
Um die effiziente Erstellung und Verwaltung von Metadaten in dem auf ESRI Technologie
basierenden Geodatenmanagement der österreichischen Bundesländer zu gewährleisten,
wurde erstmalig eine bidirektionale Synchronisation von Metadaten zwischen ArcGIS und
dem zugrunde liegenden terraCatalog realisiert.
1
Projektteam der Bundesländer: Thomas EBERT (Oberösterreich), Michael HAUPOLTER (Tirol),
Wolfgang JÖRG (Wien), Oswald MÖRTH (Steiermark), Jürgen OBERRESSL (Vorarlberg),
Anton EITZINGER (Salzburg), Thomas PIECHL (Kärnten), Rainer PRAGER (Niederösterreich),
Thomas ZALKA (Burgenland), Gerhard TOZZI (Projektbegleitung).Geoland.harvest 231 2 Anforderungen der Länder 2.1 Hierarchische Broker-Architektur Die Länder führen ihre Kataloge im eigenen Wirkungsbereich und stellen Katalogservices zur Verfügung, die zentral in Kärnten, wo der Broker-Service installiert ist, zusammenge- fasst werden. Der Geolandbroker kann über das Länderportal www.geoland.at zentral abge- fragt werden. 2.2 Unterstützung des Österreichprofils „profil.AT“ für Metadaten Damit Kataloge durchsucht und die Informationen überhaupt gefunden werden können, ist es notwendig, dass Standards für die Implementierung verwendet werden. Für Metadaten gibt es eine sehr umfangreiche Norm, die nach bestimmten Regeln eingeschränkt werden kann. So eine Teilmenge der Norm, die auf alle Fälle die Core-Metadaten enthalten muss, nennt man Anwenderprofil. Ein solches Anwenderprofil wurde für Österreich von der AGEO, dem Dachverband für Groinformation in Österreich, in Auftrag gegeben und im Januar 2008 fertig gestellt. Dieses Profil soll im Metadateninformationsnetzwerk zur An- wenddung kommen. 2.3 Bidirektionale Synchronisation der Metadaten mit ArcCatalog Bei den österreichischen Landesverwaltungen wird für Bearbeitungen im Desktopbereich hauptsächlich ArcGIS 9.x verwendet. Die Metadatenverwaltung, die bereits standardmäßig im ArcGIS vorhanden ist, sollte weiter genutzt werden können. Die Bearbeitungen von Daten wirken sich oft unmittelbar auf die Metadaten aus (z.B. bei der Änderung eines Da- tensatzes kann sich die Ausdehnung des Datensatzes wesentlich ändern) Damit die geän- derten Werte des umschreibenden Rechtecks nicht händisch in den terraCatalog eingefügt werden müssen, sollen die Metadaten von ArcGIS in einfacher Art und Weise mit den Katalogmetadaten synchronisiert werden können. Umgekehrt sollten auch Einträge, die über den Webclient des terraCatalogs erfolgen, mit den Metadatendateien von ArcGIS synchronisiert werden können. 2.4 Verwendung des Portalverbundprotokolls Zwischen dem Broker und den Metadatenkatalogen der Länder soll die Kommunikation auf sicheren Leitungen erfolgen. Dazu soll das in Österreich zwischen den Behörden ver- einbarte Portalverbundprotokoll zum Einsatz kommen. Das Portalverbundprotokoll regelt die Kommunikation zwischen dem Stammportal, an welchem die Benutzer und deren Rechte verwaltet werden, sowie dem Anwendungsportal, das der konkreten Anwendung vorgeschaltet ist und den Benutzern nach Überprüfung der Berechtigung den Zugriff auf die Anwendung erlaubt. 2.5 Unterstützung von unterschiedlichen räumlichen Datenbanken Standardmäßig verwendet der terraCatalog Oracle für die Speicherung der Daten. Wegen der unterschiedlichen Systemumgebungen der einzelnen Bundesländer war hier die Unter-
232 R. Prager stützung folgender zusätzlicher Datenbankmanagementsysteme gefordert: ArcSDE 9.2 in Kombination mit MS SQL Server 2000 oder MS SQL Server 2005. 3 Systemarchitektur des terraCatalogs Das System besteht aus einer 3-Schicht-Architektur. 3.1 Datenschicht Die Metadaten, die OGC CSW 2.0 Harvesting-Aufträge, die Beschreibungen zu den ver- teilten Katalogen und die Informationen, die im Zusammenhang mit dem Berechtigungs- system stehen, werden in einer relationalen Datenbank (Oracle/Locator) oder auch mit Hilfe von ArcSDE 9.2 im MS SOL Server 2000/2005 verwaltet. 3.2 Serviceschicht Hier sind die für einen Applikationsserver typischen Eigenschaften wie Thread- und Sessi- on-Handling, Database-Connection-Pooling, und das Transaktionsmanagement enthalten. In der Serviceschicht sind einige HTTP-basierte Web-Schnittstellen implementiert. Diese Schnittstellen-Implementierungen decken alle verpflichtenden und viele optionale Proto- koll Bindungen (z.B. http/SOAP/XML) ab. Weiters verfügt die Serviceschicht über speziel- le Funktionen, die weit über die eines Katalog- oder Simple-Feature-Servers hinausgehen. 3.2.1 Broker-Service Das Broker-Service stellt die Funktionalität der verteilten Suche zur Verfügung. 3.2.2 Caching-Service Das Caching-Service ist ein Service, das den Inhalt von entfernten Katalogen abholen und im lokalen Datenspeicher des Brokers ablegen kann. Die Inhalte der Kataloge werden aus Performancegründen in der Datenbank des Brokers abgelegt. Dieser Caching-Mechanismus garantiert rasche Abfrageergebnisse auf den gesamten Bestand der Kataloge. Dieses Ca- ching-Service kann auch abgeschaltet werden und dann führt der Broker eine echte verteilte Suche in den am Broker registrierten Katalogen durch. Auf ein Abfrageergebnis über meh- rere verteilte Kataloge muss dann entsprechend lang gewartet werden bis die letzten Kata- loge durchsucht und alle Ergebnisse angezeigt werden. 3.2.3 Harvesting-Service Mit Hilfe dieses Services lassen sich XML-Ressourcen automatisch in den Katalog einbin- den. Die XML-Dateien werden an einer dem Katalog bekannten Stelle zu definierten Zeit- punkten abgeholt und in den Katalog eingelesen. Damit erspart sich eine Organisation den Aufbau und Betrieb eines Metadatenkatalogs und eines damit verbundenen Katalogservi- ces. Die Metadaten können in einer Applikation standardkonform erzeugt und in XML- Files gespeichert werden und über einen File-Server dem abholenden Katalog übergegeben werden. Diese XML-Files werden automatisch in den Katalog importiert. In gewissen Zeitabständen wird überprüft, ob die XML-Datei Änderungen aufweist oder vielleicht gar nicht mehr zur Verfügung gestellt wird. In diesem Fall überprüft das Har-
Geoland.harvest 233
vesting-Service in gewissen frei definierbaren Zeitabständen, ob die Datei noch vorhanden
ist. Sind nach einer gewissen Zeitspanne die Metadaten, die auf diese Art von dieser Quelle
bezogen wurden, nicht mehr vorhanden, dann werden sie aus dem Katalog gelöscht. Damit
ist gewährleistet, dass der Metadatenkatalog keine Metadaten von Daten enthält, die nicht
mehr angeboten werden.
3.3 Anwendungsschicht
In der Anwenderschicht erfolgen die Suche und die Auswahl der zu durchsuchenden ver-
teilten Kataloge.
Nach erfolgter Suche werden die Ergebnisse dargestellt und es werden Funktionen angebo-
ten, die sich auf den Ergebnissen ausführen lassen, wie etwa die Detailansicht der Metada-
ten eines Treffers, die Darstellung der räumlichen Ausdehnung des Treffers, der Export der
Metadaten, der Download der Daten oder die Darstellung der Daten in einem eigenen Kar-
tenfenster.
Je nach Rolle und Berechtigung des Anwenders kann in der Anwendungsschicht das Erfas-
sen und Editieren der Metadaten erfolgen und Metadatendokumente validiert werden.
4 Anpassungen an die Anforderungen der Länder
4.1 Verwendung des Österreichprofils „profil.AT“
Für die einheitliche Dokumentation der Geodatenbestände der Länder wird das profil.AT,
das im Januar 2008 fertiggestellt wurde, verwendet. Auf Grund der einheitlichen Beschrei-
bung der Geodaten können diese über Katalogservices zentral recherchiert, gefunden und
angezeigt werden. Das Metadatenmodell des profil.ATs enthält einige Änderungen gegen-
über dem ISO 19115/19119 Metadatenmodell. Die Änderungen berücksichtigen vor allem
jene Elemente, die in den Durchführungsbestimmungen für Metadaten der INSPIRE-
Richtlinie angegeben werden.
Weiters werden auch Metadateninformationen zu den Attributen eines Datensatzes gespei-
chert. Diese Informationen sind: Attributname, Datentyp, Genauigkeit und der Wertebe-
reich. Dazu wurde das Metadatenschema entsprechend ergänzt.
Es handelt sich hierbei um eine Erweiterung, die eine einfache und kompakte Beschreibung
der Attribute eines Datensatzes ermöglicht. Das Metadatenmodell des Standards ISO 19115
sieht bei der Attributbeschreibung die vom Datensatz unabhängige Beschreibung vor, was
einen hohen Aufwand für die solcherart verwalteten Attributmetadaten bedeuten würde.
4.2 Bidirektionale Synchronisation von ESRI XML-
Metadatenbeständen
Bestehende Metadaten im ESRI XML Format können weiterhin mit externen Werkzeugen
gepflegt werden (z. B. : im ArcCatalog). Im ArcCatalog werden die Metadaten von geän-
derten Datensätzen automatisch synchronisiert, wenn der Reiter für die Anzeige der Meta-
daten ausgewählt wird.234 R. Prager Dabei werden von ArcGIS drei Synchronisatoren verwendet, die die Daten in dem gewähl- ten Darstellungsstil der Synchronisatoren automatisch aktualisieren. Diese Synchronisato- ren liegen in ArcGIS in Form von „DataTypeDefinitions“ vor und berücksichtigen die Beschreibungen der Daten nach den Vorgaben von FGDC (Federal Geographic Data Committee, ISO 19115 (Draft!) und Geographic Network. Sie können wahlweise aus- und eingeschaltet werden. Die so erstellten und aktualisierten Metadaten werden bei filebasier- ter Datenhaltung in XML-Dateien gespeichert und bei der Dateiverwaltung mit Hilfe des ArcCatalogs automatisch aktualisiert. Wenn die Daten in einer Geodatabase gespeichert sind, dann wird das XML-File in einem Eigenschaftsfeld vom Typ Binaray Large Object (BLOB) verspeichert. Jede Bearbeitung eines Datensatzes kann sich unmittelbar auf die automatisch von ESRI geführten Metadaten auswirken. Wenn der Datensatz ergänzt wird, dann ändert sich das umschreibende Rechteck und es wäre unsinnig, wenn diese automatisch vorhandenen In- formationen im ArcCatalog dann händisch in ein Metadatenwerkzeug übertragen werden müssten. Es ist daher vorgesehen, dass nach der Bearbeitung von Daten die dazugehörigen Metada- ten über einen Synchronisationsmechanismus zwischen den Metadaten im ArcGIS und dem terraCatalog aktualisiert werden. Dazu wird der terraCatalog aufgerufen und eine eindeutige Verbindung zwischen der Me- tadatenbank und dem Metadatensatz aufgebaut. Anschließend wird ArcCatalog gestartet und der zu bearbeitende Datensatz ausgewählt. Mit Hilfe des Synchronisationsknopfes werden die Metadaten aus dem ArcCatalog in den terraCatalog übertragen. Die Eindeutig- keit wird über die UUID (Universal Unique Identifier) des Metadatensatzes sichergestellt. 4.3 Anpassungen des Berechtigungskonzepts der Standardsoftware In Österreich wurde als Teil der e-Govermentstrategie von Bund, Ländern und Gemeinden ein gemeinsames Kommunikationsprotokoll zwischen den Gebietskörperschaften konzi- piert. Der so genannte Portalverbund basiert auf bilateral abgeschlossenen Vereinbarungen zur Sicherstellung einer einheitlichen Sicherheitsstrategie und der Festlegung der organisa- torischen Zuständigkeiten. Das Portalverbundprotokoll regelt die Kommunikation zwischen dem Stammportal einer Organisation und dem Anwendungsportal, das einer Applikation vorangestellt ist, und von einer Organisation den Teilnehmern am Portalverbund zur Ver- fügung gestellt werden kann. Im Falle des Metadateninformationsnetzwerkes sollen die verteilten Kataloge, die bei den Ländern geführt werden, über einen Broker verknüpft werden. Die dazu notwenige Kom- munikation zwischen den Katalogen bei einer verteilte Suche oder bei Verwendung des Caching-Services, das die regelmäßige Sammlung der Daten durch den Broker sicherstellt, machen eine über das Portalverbundprotokoll gesicherte Verbindung notwendig. Die Ver- bindung zwischen den Katalogen der Länder und dem Broker erfolgt über den Portalver- bund, wobei der Broker über sein Anwendungsportal mit den Stammportalen der Länder kommuniziert. Ebenso wurde das Rechtekonzept der Nutzern und Nutzergruppen für den terraCatalog nicht lokal in der Software abgebildet, sondern es wird dafür die zentrale Nutzerverwaltung eines Landesportals genutzt. Die Nutzerinformationen werden über das Portalverbundpro-
Geoland.harvest 235 tokoll beim Aufruf an den terraCatalog übergeben. Somit entfallen redundante Benutzer- verwaltungen, die in der Applikation terraCatalog geführt werden müssten. Mit der Implementierung des Metadateninformationsnetzwerkes bei den österreichischen Landesverwaltungen wurden die bereits bestehenden Geodateninfrastrukturen der Länder um einen sehr wesentlichen Bestandteil erweitert. Damit erfüllen die österreichischen Bun- desländer bereits jetzt Teile der INSPIRE-Richtlinie wie Führung von Metadaten und die Bereitstellung von Suchdiensten zum Auffinden von Geodaten und Diensten. Literatur AGEO (Hrsg): profil.AT – METADATENPROFIL für Österreich(2008), Version 1.0 (28.01.2008). GSDI (Hrsg.): The SDI Cookbook, Version 2.0, 25. Jänner 2004. ISO (Hrsg) (2007): Geographic information – Metadata – XML schema implementation. – [Reference Number ISO/TS 19139:2007(E)]. KOGIS (Hrsg.): GM03 – Metadatenmodell, Version 2.3. Wabern. OGC (Hrsg): OpenGIS Catalogue Services Specification, Version 2.0.2. – Corrigendum 2 Release, 2007-02-23. OGC (Hrsg): OpenGIS Catalogue Services Specification, 2.0.2. – ISO Metadata Applicati- on Profile, Version 1.0, 2007-07-19. ÖNORM EN ISO 19115, Ausgabe 2005-04-01, Geographic information – Metadaten. – [Reference Number ISO 19115:2003]. ÖNORM EN ISO 19119, Ausgabe 2006-09-01, Geographic information – Services. – [Reference Number ISO 19119:2005]. Portalverbund Whitepaper, Rainer Hörbe und Michael Werzowa, 2005-02-17.
Sie können auch lesen
