Konzept zum Aufbau eines Infrastrukturknotens bei der Kreisverwaltung Oberhavel

Transkript

1 i Konzept zum Aufbau eines Infrastrukturknotens bei der Kreisverwaltung Oberhavel Dokument-Status Freigegeben (Version 1.0) Datum 11. September 2009 Verfasser Herausgeber und Rechte (Copyright) ESRI Deutschland GmbH Landkreis Oberhavel

2 ii Inhalt INHALT... II ABBILDUNGSVERZEICHNIS...V TABELLENVERZEICHNIS...VI MANAGEMENT SUMMARY...8 TEIL 1 ZIELE UND NUTZENPOTENTIAL EINFÜHRUNG ZIELE UND NUTZENPOTENTIAL DES INFRASTRUKTURKNOTENS Realisierung der Infrastruktur Schlanke Verwaltung Metadatenerfassung Anbindung an globale Anwendungen...14 TEIL 2 ANFORDERUNGSANALYSE ANFORDERUNGEN AUS INSPIRE, GDI-DE UND GDI-BE/BB INSPIRE Metadaten Standards Metadatenelemente Zeitplan Geodaten-Spezifikationen Themen Zeitplan Netzdienste INSPIRE Discovery Services INSPIRE View Services INSPIRE Download Services INSPIRE Transformation Services INSPIRE Invoke Spatial Data Services Zeitplan...26

3 iii Gemeinsame Datennutzung GDI Deutschland GDI-DE obligatorisch GDI-DE optional GDI-DE zukünftig Abweichungen zu INSPIRE GDI Berlin/Brandenburg Metadaten Amtliches Bezugssystem SPEZIFISCHE ANFORDERUNGEN DES LANDKREIS OBERHAVEL Unterstützung kommunaler Partner Zugriff auf das Metadateninformationssystem Zugriff auf Fachportale Zugriff auf Dienste Map Client und Online-Editierung (optional) Integration der Fachportale des Landkreis Oberhavel Unterstützung externer globaler Geodienste/Geonetzwerke D-Visualisierung (optional) ETL- und Geoprocessing Funktionen (optional) Zugriffskontrolle...37 TEIL 3 AUFBAU UND BETRIEB DES INFRASTRUKTURKNOTENS FUNKTIONEN UND LOGISCHE KOMPONENTEN Komponentenübersicht Funktionen der Dienste INSPIRE Network Services Native Mapping Dienste OGC Geoservices D-, Geoprocessing- und ETL Services (optional) Security Services Funktionen der Anwendungen Online Editierung (optional) Metadatenverwaltung Zugriffskontrolle REALISIERUNG DES INFRASTRUKTURKNOTENS...44

4 iv 6.1 IT-Infrastruktur der Kreisverwaltung Oberhavel Systemarchitektur zur Integration des Infrastrukturknotens Harmonisierung der Daten Variante A (Einsatz in der DMZ) Datenhaltung (Vektordaten) Datenhaltung (Rasterdaten) Bereitstellung der Dienste Bereitstellung der Anwendungen Integration der Fachportale Absicherung und Zugriffsschutz für Dienste und Anwendungen Administration Ausfallsicherheit/Lastverteilung Serverkomponenten Internetanbindung und Netzwerksicherheit Variante B (Absicherung durch Reverse-Proxy) Datenhaltung (Vektordaten) Bereitstellung der Dienste Administration Serverkomponenten Internetanbindung und Netzwerksicherheit Einsatz von Open-Source Softwarekomponenten Open Source Software für Zugriffsschutz Open Source Software für INSPIRE Network Services Fazit Umsetzungsempfehlung...62 TEIL 4 PLANUNG...FEHLER! TEXTMARKE NICHT DEFINIERT. 7 ZEIT- UND KOSTENPLAN...FEHLER! TEXTMARKE NICHT DEFINIERT. 7.1 Kostenplan Nur zum internen Gebrauch...Fehler! Textmarke nicht definiert. 7.2 Zeitplan...Fehler! Textmarke nicht definiert. REFERENZEN...66 GLOSSAR...68

5 v ABBILDUNGSVERZEICHNIS Abbildung 1: Infrastrukturknoten LK Oberhavel in der Hierarchie deutscher und europäischer Geodateninfrastrukturen...9 Abbildung 2: Muster zur Bereitstellung und zum Bezug von Geodaten (Publish-Find- Bind, nach Quelle GDI-DE Architekturkonzept)...12 Abbildung 3: Übersicht der INSPIRE Network Services...21 Abbildung 4: Anwendungsfälle für den Zugriff auf das Metadateninformationssystem...32 Abbildung 5: Anwendungsfälle Zugriff auf Fachportale...33 Abbildung 6: Anwendungsfälle für Zugriff auf Dienste...34 Abbildung 7: Anwendungsfall Online Editierung...34 Abbildung 8: Anwendungsfälle Integration der Fachportale...35 Abbildung 9: Unterstützung externer globaler Geodienste/Geonetzwerke...36 Abbildung 10: Übersicht der logischen Komponenten des Infrastrukturknotens...39 Abbildung 11: IT-Infrastruktur Kreisverwaltung Oberhavel...45 Abbildung 12: Schema zur Bereitstellung eines INSPIRE-konformen Datenmodells 46 Abbildung 13: Systemarchitektur Infrastrukturknoten - Variante A (DMZ)...48 Abbildung 14: Absicherung und Zugriffssteuerung für Dienste und Anwendungen...51 Abbildung 15: 2-Tier-Hochverfügbarkeitslösung für Dienste des Infrastrukturknotens...53 Abbildung 16: Systemarchitektur Infrastrukturknoten - Variante B (Proxy)...58 Abbildung 17: Zeitplan...Fehler! Textmarke nicht definiert.

6 vi TABELLENVERZEICHNIS Tabelle 1: Relevante Standards für das INSPIRE Metadaten Profil...15 Tabelle 2: Gegenüberstellung der ISO Core Metadatenelemente und des INSPIRE Profils...16 Tabelle 3: ISO- und INSPIRE-Metadatenelemente für Dienste...17 Tabelle 4: Termine zur Umsetzung des Bereichs Metadaten...18 Tabelle 5: Themen der Geodaten-Spezifikationen...19 Tabelle 6: Termine zur Umsetzung des Bereichs Daten-Spezifikationen...20 Tabelle 7: Relevante Spezifikationen für INSPIRE Discovery Services...21 Tabelle 8: Discovery Service Operationen...22 Tabelle 9: Quality of Service (INSPIRE Discovery Services)...22 Tabelle 10: Relevante Spezifikationen für INSPIRE View Services...22 Tabelle 11: View Service Operationen...23 Tabelle 12: Quality of Service (INSPIRE View Services)...23 Tabelle 13: Relevante Spezifikationen für INSPIRE Download Services...24 Tabelle 14: Download Service Operationen...24 Tabelle 15: Quality of Service (INSPIRE Download Services)...24 Tabelle 16: Relevante Spezifikation für INSPIRE Transformation Services...25 Tabelle 17: Transformation Service Operationen...25 Tabelle 18: Quality of Service (INSPIRE Transformation Services)...25 Tabelle 19: Termine zur Umsetzung der Network Services...26 Tabelle 20: Obligatorische Spezifikationen der GDI-DE...27 Tabelle 21: Optionale Spezifikationen der GDI-DE...28 Tabelle 22: Termine zur Verfügbarmachung von Netzdiensten und Geodaten...30 Tabelle 23: Fachportale des Landkreis Oberhavel...35 Tabelle 24: Serverkomponente ArcGIS Server (extern)...53 Tabelle 25: Serverkomponente ArcGIS Server (intern)...54 Tabelle 26: Serverkomponente Dienste-Server...54 Tabelle 27: Serverkomponente Anwendungs-Server...54 Tabelle 28: Serverkomponente Datenbank-Server...55

7 vii Tabelle 29: Internetfreigabe der Komponenten des Infrastrukturknotens...55 Tabelle 30: Serverkomponente ArcGIS Server...59 Tabelle 31: Evaluierung der alternativen Strategien zur Umsetzung des Infrastrukturknotens...62 Tabelle 32: Kostenplan...Fehler! Textmarke nicht definiert. Tabelle 33: Zeitplan und Aktionen...Fehler! Textmarke nicht definiert.

8 8 MANAGEMENT SUMMARY Der Landkreis Oberhavel plant den Aufbau eines Infrastrukturknotens als Bestandteil der Geodateninfrastruktur Berlin/Brandenburg und übergeordneter Geodateninfrastrukturen. Das vorliegende Dokument stellt das von der Kreisverwaltung Oberhavel beauftragte Konzept zum Aufbau des Infrastrukturkotens dar. Der geplante Funktions- und Leistungsumfang des Infrastrukturknotens entspricht nicht nur den Anforderungen der lokalen, nationalen und internationalen Geodateninfrastrukturen, in welche der Infrastrukturknoten eingebunden werden soll; um das Nutzenpotential des Infrastrukturknotens für den Landkreis Oberhavel und die kommunalen Partner optimal auszuschöpfen, sollen eine Reihe spezifischer Anwendungsfälle unterstützt werden, die den Funktionsumfang hinsichtlich der bereitgestellten Dienste und Anwendungen beträchtlich erweitern. Durch die Verteilung der in diesem Konzept identifizierten funktionalen Anforderungen an den Infrastrukturknoten auf logische Funktionseinheiten ist ein weitgehend technologieneutraler Entwurf der Gesamtarchitektur möglich. Der Infrastrukturknoten soll in bestehende, auf ESRI-Basistechnologie basierende GIS-Infrastruktur der Kreisverwaltung Oberhavel integriert werden. Hierbei werden zwei gängige Ansätze im Detail verglichen und eine Umsetzungsempfehlung entwickelt. Basierend auf der Umsetzungsempfehlung wird ein Zeit- und Kostenplan für die Realisierung des Infrastrukturknotens dargelegt.

9 9 TEIL 1 ZIELE UND NUTZENPOTENTIAL 1 Einführung Im Rahmen der Integration in die Geodateninfrastruktur Berlin/Brandenburg sowie übergeordneter Geodateninfrastrukturen plant der Landkreis Oberhavel den Aufbau eines Infrastrukturknotens. Mit diesem Dokument wird die Konzeption des künftigen Infrastrukturknotens vorgelegt. Ziel dieses Dokumentes ist der Entwurf des Infrastrukturknotens, der als Grundlage für die Realisierung dienen soll. Das Konzept zum Aufbau eines Infrastrukturknotens bei der Kreisverwaltung Oberhavel wendet sich u.a. an die folgenden Zielgruppen: Akteure der Kreisverwaltung Oberhavel (Projektleiter, Koordinatoren, Spezialisten) Akteure bei Dienstleistern zur Umsetzung des künftigen Infrastrukturknotens (Projektleiter, Architekten) Der Infrastrukturknoten bei der Kreisverwaltung Oberhavel ist als künftiger Bestandteil der Geodateninfrastruktur Berlin/Brandenburg (GDI-BE/BB) geplant. Mit der Integration der GDI-BE/BB in die Geodateninfrastruktur Deutschland (GDI-DE) und die europäische Geodateninfrastruktur (INSPIRE) ist der künftige Infrastrukturknoten damit auch Bestandteil dieser übergeordneten Geodateninfrastrukturen (siehe Abbildung 1). Abbildung 1: Infrastrukturknoten LK Oberhavel in der Hierarchie deutscher und europäischer Geodateninfrastrukturen Ziele und Methodik des Konzepts Das übergeordnete Ziel des vorliegenden Konzepts ist der vollständige Entwurf des künftigen Infrastrukturknotens, der als Grundlage für die Umsetzung bei der Kreisverwaltung

10 10 Oberhavel herangezogen werden soll. Der Entwurf des Gesamtsystems erfolgt auf Basis fünf unterschiedlicher Sichtweisen 1 : Unternehmenssicht (Organisation und Prozesse) Sicht auf Dateninhalte und Datenmodellierung Sicht auf Funktionen (noch ohne Betrachtung der Verteilung) Sicht auf Verteilung der Komponenten Sicht auf die konkrete einzusetzende Technik (so weit wie möglich hersteller- und Produktneutral) Grundlage der Konzeption stellt die Analyse der Anforderungen dar, die sich aus der Integration des Infrastrukturknotens in die Geodateninfrastruktur Berlin/Brandenburg und der übergeordneten Geodateninfrastrukturen (GDI-DE und INSPIRE) ergeben. Weiterhin werden die spezifischen funktionalen Anforderungen, die sich aus bestehenden und geplanten Anwendungsfällen der Kreisverwaltung Oberhavel ergeben, berücksichtigt. Auf Basis der Anforderungsanalyse erfolgt die Ableitung einer Funktions- und Komponentenmatrix, mit der sämtliche benötigten Funktionen des Infrastrukturknotens beschrieben und auf logische Komponenten verteilt werden. Der Entwurf einer geeigneten Systemarchitektur zur Integration des geplanten Infrastrukturknotens in die IT-Landschaft der Kreisverwaltung Oberhavel erfolgt auf Grundlage der identifizierten logischen Komponenten unter Berücksichtigung der bestehenden IT-Infrastruktur. Dabei werden Empfehlungen zur konkreten technischen Umsetzung der Komponenten des geplanten Infrastrukturknotens gegeben, wobei nach Möglichkeit eine hersteller- und produktneutrale Beschreibung erfolgen soll. Die Aufstellung eines Zeit- und Kostenplans für die Beschaffung, Installation und den Betrieb des geplanten Infrastrukturknotens erfolgt auf Basis der Komponenten aus dem Entwurf der Systemarchitektur. 2 Ziele und Nutzenpotential des Infrastrukturknotens Der Aufbau eines Infrastrukturknotens hat folgende allgemeine Ziele und Grundsätze: Zugriff auf dezentral verteilte Geodaten und Geodienste ermöglichen, Interoperabilität der GDI Komponenten sicherstellen, Aufsetzen auf bereits vorhandenen Infrastrukturen (z.b. World Wide Web) und berücksichtigen internationaler und nationaler Normen und Spezifikationen (insbesondere von ISO und OGC). 1 Grundlage stellt das Referenzmodell für offene und verteilte Datenverarbeitung (Reference Model of Open Distributed Processing, RM-ODP) dar, das Gegenstand des Standards ISO ist.

11 11 Ein Ziel der öffentlichen Verwaltung laut GDI-DE ist einen einfachen Zugang zu den verschiedenen und verteilt vorliegenden Geodaten der öffentlichen Verwaltung zu schaffen und ihre Nutzung zu erleichtern. D.h. der Aufwand und die Kosten für die Beschaffung, Aufbereitung, Speicherung und Konvertierung von Daten sollen minimiert werden. Zugrundeliegende Maßnahmen sind: die Recherche in Metadaten und den Bezug von Geodaten ermöglichen, die internen Prozesse zur Datenaufbereitung, Speicherung und Verteilung von Geodaten optimieren, die gesetzlichen Informationspflichten des Staates, wie z.b. im Umweltinformationsgesetz (UIG) und Informationsfreiheitsgesetz (IFG) beschrieben, umsetzen, die Informationspflichten gegenüber der EU (Lärmschutzrichtlinie, INSPIRE- Richtlinie, etc.) befolgen. Diese Ziele werden im Masterplan der GDI-BE/BB weiter konkretisiert. Die Ziele einer Geodateninfrastruktur in der Hauptstadtregion Berlin/Brandenburg sind insbesondere: die breite Nutzung von Geodaten, die Steigerung der Effizienz bei Entscheidungen in der Verwaltung, Wirtschaft und Wissenschaft und beim Bürger, die Stärkung des Wirtschaftsstandortes Berlin-Brandenburg, die positive Entwicklung des Geoinformationsmarktes durch länderübergreifende Steuerung (Geodaten stellen einen zentralen Rohstoff für die Wertschöpfung in vielen Wirtschaftsbereichen dar), die Integration der Geodateninfrastruktur in übergeordnete Geodateninfrastrukturen, die Einbindung kommunaler Ansätze, die Beteiligung von Wirtschaft, Wissenschaft und Nutzern am Aufbau der GDI- BE/BB. Die Realisierung der GDI-BE/BB ist als integraler Bestandteil des E-Government in Berlin und Brandenburg zu sehen. Neben dem allgemeinen Nutzen soll der Infrastrukturknoten des Landkreises Oberhavel auch spezifisches Potenzial nutzen und Vorteile bringen. Einige Möglichkeiten werden im Folgenden beispielhaft erläutert. 2.1 Realisierung der Infrastruktur Beim Infrastrukturknoten Landkreis Oberhavel soll ein besonderes Augenmerk auf die Realisierung einer OGC- und INSPIRE-konformen sowie das Funktionieren der Geodateninfrastruktur gelegt werden. So werden Geodaten, Dienste sowie Anwendungen über Metadaten einheitlich beschrieben (Metadateneditor) und an zentraler Stelle verwaltet bzw. auffindbar gemacht (Suchoberfläche, GeoGoogle ). Neben der eigentlichen Suche stellt auch die direkte Nutzung der Geodaten und auch weiteren Ressourcen einen elementaren Anspruch dar. D.h. es wird auf Basis der Metadaten gesucht und die Ergebnisse der Suchanfrage können je nach Ressourcetyp Möglichkeiten zur Nutzung

12 12 bereitstellen. Es werden sog. Bindings umgesetzt, einige Beispiele sind im Folgenden aufgelistet: Link zu einem Map Client, der einen Kartendienst (Geodatendienst) dynamisch einbindet und anzeigt Link zu einem Desktop-GIS, welches z.b. einen Kartendienst und lokale oder zentral vorliegende Geodaten miteinander visualisiert Aufruf einer Fachanwendung, die eine Fragestellung beantwortet (z.b. Start eines Fachportals des LK Oberhavel) Möglichkeit eines direkten Daten-Downloads Erweiterung der Beschreibung der Ressource durch weitergehende Informationen z.b. durch PDF-Dokumente Angabe von Kontaktdaten für z.b. weitergehende telefonische Beratung Durch diese Verknüpfungen findet das Publish-Find-Bind -Muster einer GDI Anwendung und hilft auch unerfahrenen Nutzern (z.b. Bürgern) gewünschte Informationen zu erhalten und Fragen zu beantworten. Von besonderer Bedeutung ist die Beschreibung oder auch die Anbindung an Anwendungen wie Fachportale des Landkreises (z.b. das Fachportal mit aktuellen Verkehrsauskünften). Abbildung 2: Muster zur Bereitstellung und zum Bezug von Geodaten (Publish-Find-Bind, nach Quelle GDI-DE Architekturkonzept) Zu nennen ist auch, dass neben der Bereitstellung von öffentlichen Ressourcen auch interne Ressourcen erfasst und beschrieben werden können. D.h. Metadatenbeschreibungen für sensible oder fachspezifische Daten, Dienste oder Anwendung können erzeugt und nur autorisierten Nutzern zugänglich gemacht werden. So kann der gesamte Geoinformationsbestand erfasst und zur Verfügung gestellt werden. Bspw. Projektinformationen können für nur wenige berechtigte Nutzer an zentraler Stelle beschrieben und verwaltet werden. Aber dennoch ist für alle Recherchen nur eine Suchoberfläche notwendig.

13 Schlanke Verwaltung Unter diesem Schlagwort werden die folgenden Aspekte eines Infrastrukturknotens verstanden: Vermeidung von Mehrfachdatenerhebungen/-beständen durch Beschreibung bestehender Ressourcen an zentraler Stelle Optimierung der Datenhaltung durch Beschreibung existenter Datenbestände (Transparenz verfügbarer Geodaten) Ermöglichen einer schnellen und umfassenden Nutzung von Geodaten aus verschiedenen Quellen durch Beschreibung von Parametern wie Datenquelle, Dateneigentümer, Nutzungsbedingungen usw. All diese Punkte zeigen, wie wichtig die Beschreibung von Datenbeständen durch Metadaten in einem zentralen System ist und welches Potential daraus geschöpft werden kann. Redundanzen werden vermieden, Effizienz im Zugriff gesteigert und vor Mehrfachnutzungen durch interne Nutzer aber auch Externe ermöglicht. Doch nur wenn die Bestände beschrieben sind, existiert die Möglichkeit zwischen Ressourcen vergleichen zu können. Dies steigert die Effektivität und Effizienz, da für eine Fragestellung die bestmögliche Datengrundlage gefunden werden kann. Entscheidungshilfen bieten z.b. Angaben zur Datenqualität, -aktualität, Genauigkeit oder auch Nutzungsbeschränkungen und Kosten. Diese Option ist bei fehlender Metadatenerfassung so nicht gegeben. Hervorzuheben ist zudem, dass die Anbindung von anderen Geodateninfrastrukturen einen Mehrwert bringt, indem die Geodatenbasis nicht mehr allein auf die Kreisverwaltung Oberhavel oder den Landkreis beschränkt ist. Es werden Geodatenbestände des Landes Brandenburg sowie der Hauptstadtregion und auch weiterer übergeordneter Geodateninfrastrukturen recherchierbar. Auf Basis dieser Vernetzung wächst die Anzahl der Möglichkeiten und Alternativen. 2.3 Metadatenerfassung Für die Realisierung der zuvor genannten Aspekte ist die Ressourcenbeschreibung über Metadaten an zentraler Stelle unabdingbar. Die Metadatenerfassung ist als neuer Arbeitsschritt in die gängigen Prozesse der Kreisverwaltung einzubauen. Dies bedeutet vorerst einen Mehraufwand. Die Arbeit kann aber an die speziellen Belange des Landkreises angepasst und verringert werden. D.h. obwohl die Vorgaben zur standardisierten Metadatenerfassung berücksichtigt werden, können Vereinfachungen und Voreinstellungen speziell für die Belange des Landkreis Oberhavel vorgegeben werden (z.b. Definition von Schablonen von Metadatendokumenten für die Ersterfassung). Bei der erstmaligen Erzeugung von Metadaten ist somit über feste Abläufe (optimierte Prozessschritte) und vorbereitete Vorgaben im Metadateneditor realisierbar, dass letztlich nur wenige Einträge/Angaben zu tätigen sind und der Aufwand je Metadatendokument übersichtlich ist.

14 14 Die Prozesse sind für die Beschreibung von Fachportalen oder Datenbeschreibungen z.b. von Ämtern und Fachbereichen abzustimmen und bspw. Kontaktvorlagen (Adressdaten) werden zentral vorgehalten und sind wieder verwendbar. 2.4 Anbindung an globale Anwendungen Der geplante Infrastrukturknoten des Landkreis Oberhavel ermöglicht neben der Bereitstellung interoperabler Dienste mit OGC-konformen Schnittstellen auch die Möglichkeit der Unterstützung von Schnittstellen, basierend auf IT-Standards wie SOAP oder REST oder auch verbreiteter GIS-Formate wie KML. Somit werden noch mehr Anwendungen nutzbar und für z.b. externe Nutzer ergeben sich neue Möglichkeiten. Sie können beispielsweise lokale, regionale Dienste mit spezifischen Inhalten des Landkreis Oberhavel in globalen Anwendungen wie GoogleEarth oder GoogleMaps hinzugeladen und dargestellt werden.

15 15 TEIL 2 ANFORDERUNGSANALYSE 3 Anforderungen aus INSPIRE, GDI-DE und GDI- BE/BB Ziel und Gegenstand einer Geodateninfrastruktur ist es, die digitalen Geoinformationen, die in vielen Bereichen der öffentlichen Verwaltung vorliegen über Netzdienste bereitzustellen sowie eine Harmonisierung der Geodaten zu erreichen. Dies bezieht sich auch auf die Beschreibung und Recherche der Geoinformation über Metadaten und den anschließenden Bezug der Geodaten. Die folgenden Anforderungen sind grundlegend für die Kooperationen verschiedener Systeme (Interoperabilität) über technische Schnittstellen sowie inhaltliche und organisatorische Bedingungen. 3.1 INSPIRE Interoperable und - wo möglich - harmonisierte Geodaten stellen einen zentralen Bestandteil des Gesamtvorhabens INSPIRE dar, dessen übergeordnetes Ziel der effektivere Zugang zu Geoinformation ist Metadaten Um dieses Gesamtziel erreichen zu können, ist es erforderlich Metadaten, beschreibende Daten zur Recherche und Bewertung von Geoinformationen (Geodaten und Geodatendienste), zu erzeugen Standards Das INSPIRE Profil gibt aus diesem Grund vor, anhand welcher Standards die Metadaten zu erstellen bzw. welche Metadatenelemente zu erfassen sind. Folgende Standards werden verwendet: Tabelle 1: Relevante Standards für das INSPIRE Metadaten Profil ISO ISO ISO/TS EN ISO 19115:2005, Geographic information - Metadata ISO 19115/Cor.1:2006, Geographic information Metadata, Technical Corrigendum ISO 19119:2005, Geographic information - Services ISO 19119:2005/Amd 1:2008, Extensions of the service metadata model 2007, Geographic information - Metadata XML Schema Implementation

16 Metadatenelemente Die zu erfassenden INSPIRE Metadatenelemente sind an die sog. ISO Core Elemente angelehnt. Diese 22 Kernelemente werden jedoch teilweise neu bewertet bzw. weitere Elemente werden gefordert - einen Vergleich der Metadatenelemente umfasst die folgende Tabelle: Tabelle 2: Gegenüberstellung der ISO Core Metadatenelemente und des INSPIRE Profils ISO Core INSPIRE Kommentar Dataset title (M 2 ) Resource title (M) - Dataset reference date (M) Temporal reference (C 3 ) ISO fordert ein Datum vom Typ creation, publication oder revision, während INSPIRE auch das Element Temporal Extent wertet Dataset responsible party (O 4 ) Responsible organisation (M) INSPIRE fordert die Eingabe von Name der Organisation sowie -adresse und eine Rolle Geographic location of the dataset (C) Geographic Bounding Box (M/C) INSPIRE ist restriktiver, verpflichtend für Datensätze und Datensatzserien mit direktem räumlichen Bezug Dataset language (M) Resource language (C) ISO sieht die Sprache als verpflichtendes Element, INSPIRE nur bei Ressourcen mit Text-Informationen Dataset character set (C) - - Dataset topic category (M) Topic category (M) - Spatial resolution of the dataset (O) Abstract describing the dataset (M) Spatial resolution (C) Resource abstract (M) - Distribution format (O) - - Additional extent information for the dataset (vertical and temporal) (O) Temporal extent (C) Spatial representation type (O) - - Reference system (O) - - In INSPIRE verpflichtend, wenn Maßstabszahl oder Auflösung angegeben werden INSPIRE ist restriktiver, denn letztlich ist eine Zeitreferenz erforderlich Lineage (O) Lineage (M) In INSPIRE verpflichtend für Datensätze und Datensatzserien 2 M (Abk. für englisch mandatory): verpflichtend, obligatorisch, verbindlich, vorgeschrieben 3 C (Abk. für englisch conditional): bedingt, abhängig, konditional 4 O (Abk. für englisch optional): optional, freiwillig, beliebig

17 17 Online resource (O) Resource locator (C) In INSPIRE verpflichtend, wenn Information hinterlegt werden kann Metadata file identifier (O) - - Metadata standard name (O) Metadata standard version (O) Metadata language (C) Metadata language (M) - Metadata character set (C) Metadata point of contact (M) - ISO ist hier restriktiver Metadata point of contact (M) INSPIRE fordert die Eingabe von Name der Organisation sowie -adresse und eine Rolle Metadata date stamp (M) Metadata date (M) ISO besagt, dass das Datum der Metadatenerfassung anzugeben ist. INSPIRE fordert das Metadatenerfassungs- oder Aktualisierungsdatum. - Resource type (M) INSPIRE ist restriktiver. Unique Resource Identifier (M) Keyword (M) INSPIRE ist restriktiver. Gilt für Datensätze und Datenserien. INSPIRE ist restriktiver. - Conformity (M) INSPIRE ist restriktiver. - Conditions for access and use (M) INSPIRE ist restriktiver. - Limitations on public access (M) INSPIRE ist restriktiver. Zu beachten ist, dass bei Metadaten für Dienste eine Erweiterung um ISO erforderlich ist sowie die Reduzierung des ISO Core Bereichs um einige Elemente. Die folgende Tabelle stellt die Metadatenelemente gegenüber. Tabelle 3: ISO- und INSPIRE-Metadatenelemente für Dienste ISO Core INSPIRE Kommentar Dataset title (M) Resource title (M) - Dataset reference date (M) Temporal reference ISO fordert ein Datum vom Typ creation, publication oder revision, während INSPIRE auch das Element Temporal Extent wertet Dataset responsible party (O) Responsible organisation (M) INSPIRE fordert die Eingabe von Name der Organisation sowie -adresse und eine Rolle Geographic location of the dataset (C) Geographic Bounding Box (M/C) ISO verwendet ein anderes Element zur Beschreibung der Ausdehnung. Dataset language (M) - Entfällt für Dienste

18 18 Dataset character set (C) - Entfällt für Dienste Dataset topic category (M) - Entfällt für Dienste Spatial resolution of the dataset (O) Abstract describing the dataset (M) Spatial resolution Resource abstract (M) - Distribution format (O) - - Additional extent information for the dataset (vertical and temporal) (O) - - Spatial representation type (O) - - Reference system (O) - - Lineage (O) - - Derzeit in ISO nicht abgebildet. Online resource (O) Resource locator (C) In INSPIRE verpflichtend, wenn Information hinterlegt werden kann Metadata file identifier (O) - - Metadata standard name (O) Metadata standard version (O) Metadata language (C) Metadata language (M) - Metadata character set (C) - ISO ist hier restriktiver Metadata point of contact (M) Metadata point of contact (M) INSPIRE fordert die Eingabe von Name der Organisation sowie -adresse und eine Rolle Metadata date stamp (M) Metadata date (M) ISO besagt, dass das Datum der Metadatenerfassung anzugeben ist. INSPIRE fordert das Metadatenerfassungs- oder Aktualisierungsdatum. - Resource type (M) INSPIRE ist restriktiver. - Coupled resource (C) - - Spatial data service type (M) INSPIRE ist restriktiver. Keyword (M) INSPIRE ist restriktiver. - Conformity (M) INSPIRE ist restriktiver. - Conditions for access and use (M) INSPIRE ist restriktiver. - Limitations on public access (M) INSPIRE ist restriktiver Zeitplan INSPIRE sieht für die Erfassung der Metadaten folgenden zeitlichen Ablauf vor. Tabelle 4: Termine zur Umsetzung des Bereichs Metadaten Meilensteine (Termine) Beschreibung 04. Dezember 2010 Bereitstellung der Metadaten der Annex-Themen I und II 04. Dezember 2013 Bereitstellung der Metadaten des Annex-Themas III

19 Geodaten-Spezifikationen Im Dezember 2008 wurden die notwendigen Grundlagen und der Modellierungsrahmen vom Drafting Team Data Specifications erarbeitet. In diesem Zuge wurden die Inhalte der Datenthemen beschrieben sowie das grundlegende konzeptionelle Modell und eine Vorgehens-Methodik entwickelt. Basierend auf diesen Grundlagen werden z.zt. konkrete Datenspezifikationen für die sogenannten INSPIRE Annex I Themen erstellt; diese umfassen: Coordinate reference systems Geographical grid systems Geographical names Administrative units Addresses Cadastral parcels Transport networks Hydrography Protected sites Die Datenspezifikationen beinhalten als wesentlichen Inhalt Anwendungsschemas - weitgehend analog zur Vorgehensweise der AdV mit dem AFIS-ALKIS-ATKIS- Anwendungsschema - ergänzt um weitere Spezifikationen z.b. zur Präsentation und zum Datenaustausch. Die Verabschiedung der ersten Version der Datenspezifikationen wird in 2009 erwartet. Die Geodatensätze werden gemäß der dann geltenden Durchführungsbestimmungen entweder durch Anpassung der bestehenden Geodatensätze oder durch Transformationsdienste verfügbar gemacht. D.h. es ist erforderlich, die neu gesammelten und/oder erheblich umstrukturierten Daten im Primärdatenbestand anzupassen oder einen INSPIRE-konformen Sekundärdatenbestand aufzubauen Themen Die Entwicklung harmonisierter Geodaten-Spezifikationen umfasst 34 Themen, unterteilt in drei Anhänge: Tabelle 5: Themen der Geodaten-Spezifikationen Annex I Annex II Annex III 1 Coordinate reference systems 2 Geographical grid systems 3 Geographical names 4 Administrative units 5 Addresses 6 Cadastral parcels 7 Transport networks 8 Hydrography 9 Protected sites 1 Elevation 2 Land cover 3 Orthoimagery 4 Geology 1 Statistical units 2 Buildings 3 Soil 4 Land use 5 Human health and safety 6 Utility and governmental services 7 Environmental monitoring Facilities 8 Production and industrial facilities

20 Zeitplan 9 Agricultural and aquaculture facilities 10 Population distribution and demography 11 Area management/restriction/regulation zones & reporting units 12 Natural risk zones 13 Atmospheric conditions 14 Meteorological geographical features 15 Oceanographic geographical features 16 Sea regions 17 Bio-geographical regions 18 Habitats and biotopes 19 Species distribution 20 Energy Resources 21 Mineral Resources Die Umsetzung der Daten-Spezifikationen erfolgt schrittweise. Zum einen werden die Metadaten sukzessive aufgebaut und bereit gestellt, zum anderen ist die Bereitstellung der INSPIRE konformen Daten notwendig. Der zeitliche Verlauf ist in der folgenden Tabelle wiedergegeben. Tabelle 6: Termine zur Umsetzung des Bereichs Daten-Spezifikationen Meilensteine (Termine) Beschreibung 04. Dezember 2010 Bereitstellung der Metadaten der Annex-Themen I und II Juni 2012 Bereitstellung der neu gesammelten /erheblich umstrukturierten Daten des Themenbereichs Annex I 04. Dezember 2013 Bereitstellung der Metadaten des Annex-Themas III 15. Mai 2014 Bereitstellung neu erhobener oder aktualisierter Geodaten Anhang II und III 15. Mai 2016 Bereitstellung verbleibender Daten der Annex I Themen 15. Mai 2019 Bereitstellung verbleibender Daten der Annex II und III Themen Siehe auch: Netzdienste Neben der Datenmodellierung stellt der Aspekt des Zugangs eine weitere, wesentliche Rolle. In INSPIRE erfolgt der Zugang über sog. Network Services, welche öffentlich zugänglich sein sollen. Zu den wichtigsten Aufgaben dieser zählen: die Recherche nach Geoinformationen (kostenfrei), die Visualisierung von Geoinformationen (eigentlich kostenfrei), der Zugriff auf Geodaten,

21 21 die Transformation von Geodaten und Einbindung in ecommerce Services. Abbildung 3: Übersicht der INSPIRE Network Services Generelle Anforderungen an INSPIRE Network Services werden über die sog. INSPIRE Network Service Architecture festgelegt. So basieren INSPIRE Network Services auf einer Service-orientierten Architektur (SOA), wobei Daten über Dienste für Verwendung in z.b. Web-Anwendungen bereitgestellt werden. Das Architekturkonzept besagt zudem, dass die technischen Richtlinien (sog. Technical Guidance) auf OGC Spezifikationen basieren, so dass existierende OGC Web Services (OWS) verwendet und ausgebaut werden. Bestehende Protokolle wie HTTP/GET, XML über HTTP/POST, SOAP über HTTP/POST und Kombinationen dieser sind auch Bestandteil und Grundlage der INSPIRE Architektur. In diesem Kontext besitzen die Network Services View und Discovery besondere Relevanz. Die finalen Spezifikationen für View und Discovery Service sind in der Version 2.0 im Juli 2009 zur Verfügung gestellt worden. Beide Spezifikationen orientieren sich weitgehend an vorhandenen OGC Spezifikationen, erweitern diese jedoch um ein INSPIRE-spezifisches SOAP-Binding, Multilingualität und weitere Aspekte. Im Folgenden werden die verschiedenen INSPIRE Network Services beschrieben INSPIRE Discovery Services INSPIRE Discovery Services entsprechen Katalog-Diensten zur Publikation, Suche, Evaluierung und Nutzung von INSPIRE Ressource (Daten, Dienste und Applikationen) durch Metadaten. Als Grundlage werden die folgenden Spezifikationen verwendet: Tabelle 7: Relevante Spezifikationen für INSPIRE Discovery Services OGC CSW CSW ISO AP OGC Catalogue Services Specification, Version (Corrigendum Release 2) OGC Catalogue Services Specification ISO Metadata Application Profile for CSW 2.0, Version (2007) Diese Vorgaben werden erweitert durch das sog. INSPIRE Profile of OGC CSW, welches die generellen Anforderungen an INSPIRE Network Services beinhaltet sowie weitere Discovery Service Funktionen und Queryables (Abfrageelemente). Die Operationen (Schnittstellen), die ein Discovery Service bereit stellt, sind:

22 22 Tabelle 8: Discovery Service Operationen INSPIRE Operation Get Discovery Service Metadata (M) Discover Metadata (M) Publish Metadata (C) Link Discovery Service (M) OGC Operation GetCapabilities (M) GetRecords (M) Manager.Transaction oder Manager.Harvest (C) Kombination von GetCapabilities und GetRecords (M) Bei sog. Queryables handelt es sich um Metadatenelemente, die explizit als Suchkriterium abfragbar sind. INSPIRE fordert, dass einige spezielle Metadatenelemente abgefragt werden können und als zusätzliche Suchkriterium dienen, dies sind: Degree Specification LimitationsOnPublicAccess ConditionApplyingToAccessAndUse Lineage Neben den zuvor genannten Festlegungen zur Umsetzung soll ein INSPIRE Discovery Service den allgemeinen Qualitätsansprüchen (sog. Quality of Service) von INSPIRE Network Services genügen. Tabelle 9: Quality of Service (INSPIRE Discovery Services) Qualitätskriterium Performanz Kapazität Verfügbarkeit Auflage In normalen Zeiten muss der erste Metadaten-Record einer Antwort in 3 Sekunden da sein Normale Zeiten sind Zeiten außerhalb des peak load und das soll 90% der Zeit sein 30 parallele Anfragen pro Sekunde 99% der Zeit INSPIRE View Services INSPIRE View Services entsprechen Darstellungsdiensten zur Visualisierung von Geoinformation auf einer Karte. Als Grundlage werden die folgenden Spezifikationen verwendet: Tabelle 10: Relevante Spezifikationen für INSPIRE View Services OGC WMS OGC SLD OGC Web Map Service (ISO 19128:2005(E)) OGC Styled Layer Descriptor Profile of the Web Map Service Implementation Specification (Corrigendum 1) Diese Vorgaben werden erweitert durch das sog. INSPIRE Profile of ISO 19128, welches die generellen Anforderungen an View Services sowie Erweiterungen (z.b. den zusätzlich erforderlichen Parameter language ) beinhaltet.

23 23 Die Operationen (Schnittstellen), die ein View Service bereit stellt, sind: Tabelle 11: View Service Operationen INSPIRE Operation Get Service Metadata (M) Get Map (M) Link View Service (M) OGC Operation GetCapabilities (M) GetMap (M) Discovery Service: Discover Metadata Operation Es wird empfohlen, dass ein INSPIRE-konformer View Service folgende Profile umsetzt: Basic profile: Unterstützung von HTTP GET und der in Tabelle 11 gelisteten Operationen Standard profile: Umsetzung des basic profile plus Unterstützung von der Operation GetFeatureInfo über HTTP GET SOAP profile: Umsetzung des basic profile plus SOAP/POST Unterstützung der drei verpflichtenden Operationen Advanced SOAP profile: Umsetzung des SOAP profile plus Unterstützung der Methode GetFeatureInfo via SOAP/POST Inhaltliche Erweiterungen, d.h. weitere und z.t. verpflichtende Angaben in den Metadaten eines Service, für die Get Service Metadata Operation sind, wie folgt vorgesehen: Kontaktinformationen: Adresse, , Telefon Layer: Name und Titel (verpflichtend) Koordinatenreferenzsysteme: Liste der CRS, mit ETRS89 (verpflichtend) Legende: Legenden-URL (verpflichtend), PNG oder HTML Visualisierung: Standard-Visualisierung, Möglichkeit der Auswahl alternativer Visualisierungen Metadaten: URL auf Metadaten-Dokument, Format text/xml (ISO19139) Sinnvolle Maßstabsbereiche: Minimal- und Maximal-Maßstäbe empfohlen (bezogen auf Themen und Raumbezugssystem) Neben den zuvor genannten Festlegungen zur Umsetzung soll ein INSPIRE View Service den allgemeinen Qualitätsansprüchen (sog. Quality of Service) von INSPIRE Network Services genügen. Tabelle 12: Quality of Service (INSPIRE View Services) Qualitätskriterium Performanz Kapazität Verfügbarkeit Auflage In normalen Zeiten soll eine 470 Kb Kartengrafik (800x600 pixels, 8 bits) in 5 Sekunden geliefert werden. Normale Zeiten sind Zeiten außerhalb des peak load und das soll 90% der Zeit sein 20 parallele Anfragen pro Sekunde 99% der Zeit

24 INSPIRE Download Services INSPIRE Download Services bieten Zugriffsfunktionen auf Daten der INSPIRE-Themen (Annex-Themen). Zwei Typen von Download Services sind vorgesehen, die das Herunterladen von und, wenn durchführbar, den direkten Zugriff auf Kopien vollständiger Geodatensätze oder Teile solcher Sätze ermöglichen: Pre-defined data Direct access download service Als Grundlage dienen die folgenden Spezifikationen: Tabelle 13: Relevante Spezifikationen für INSPIRE Download Services OGC WCS OGC WCS OpenGIS Web Coverage Service (WCS) Implementation Standard OGC WCS Corrigendum 2 for the OGC Standard Web Coverage Service 1.1 (1.1.2) OGC WFS OGC Filter Encoding OGC Web Feature Service (ISO/DIS Geographic information - Web feature service or, more precisely: 211N2632 Text of ISO for DIS, Geographic information - Web feature service) OGC Filter Encoding (ISO/DIS Geographic information - Filter encoding or, more precisely: 211N2633 Text of ISO for DIS, Geographic information - Filter encoding) Diese Vorgaben werden erweitert durch Applikationsprofile des OGC Web Processing Service (WPS) für Dataset Download Services und generelle Anforderungen an Network Services. Die Operationen (Schnittstellen), die ein Download Service bereit stellt, sind: Tabelle 14: Download Service Operationen INSPIRE Operation Get Download Service Metadata (M) Get Spatial Objects (M) Describe Spatial Object Types (C, M in case of direct access) Define Query (C, M in case of direct access) Link Download Service (M) Neben den zuvor genannten Festlegungen zur Umsetzung soll ein INSPIRE Download Service den allgemeinen Qualitätsansprüchen (sog. Quality of Service) von INSPIRE Network Services genügen. Tabelle 15: Quality of Service (INSPIRE Download Services) Qualitätskriterium Performanz Auflage Get Download Service Metadata Get Spatial Objects Describe Spatial Object 3 seconds 30 second initial response, then the service shall maintain a sustained response > 0,5 MB/s, alternatively 500 spatial objects/s 10 seconds initial response, then the service shall

25 25 Kapazität Verfügbarkeit Types Define Query 10 Verbindungen pro Sekunde 99% der Zeit maintain a sustained response > 0,5 MB/s, alternatively the attribute values of 500 spatial object types per s Performance criteria is not applicable INSPIRE Transformation Services INSPIRE Transformation Services dienen der Umwandlung von Geodatensätzen, um Interoperabilität zu erreichen und zu gewährleisten. Die Definition und Spezifikation befindet sich noch im Aufbau und soll letztlich Dienste behandeln, die Daten von einem Ursprungsformat in ein INSPIRE Format transformieren. Es kann sich neben Koordinatentransformationen auch um Format-Transformation, Übersetzung, Geometrische Transformation oder Schema-Transformation handeln. Als Grundlage dient derzeit folgende Spezifikation: Tabelle 16: Relevante Spezifikation für INSPIRE Transformation Services OGC WPS OGC Web Processing Service basierend auf dem Web Coordinate Transformation Service (WCTS) Die Operationen (Schnittstellen), die ein Transformation Service bereit stellt, sind: Tabelle 17: Transformation Service Operationen INSPIRE Operation Get Service Metadata (M) Transform (M) Is Transformable (M) Get Transformation (O) Put Transformation (O) OGC Operation GetCapabilities und DescribeProcess(TransformCoordinates) Execute(TransformCoordinates) TestTransformation parameter of the Execute(TransformCoordinates) operation Not implemented (optional) Not implemented (optional) Es gibt trotz der geringen Reifegrades dieses Network Service Festlegungen zur Umsetzung der allgemeinen Qualitätsansprüche. Tabelle 18: Quality of Service (INSPIRE Transformation Services) Qualitätskriterium Performanz Kapazität Verfügbarkeit Auflage Ist noch zu definieren (offen) 10 parallele Anfragen pro Sekunde 99% der Zeit INSPIRE Invoke Spatial Data Services INSPIRE Invoke Spatial Data Services ermöglichen den Aufruf von Geodatendiensten, die beides Dateneingabe und -abgabe bereit stellen. Die Erarbeitung von Implementing Rules sowie Technical Guidance beginnen im Herbst 2009.

26 Zeitplan INSPIRE sieht folgende Roadmap für Network Services vor: Tabelle 19: Termine zur Umsetzung der Network Services Meilensteine (Termine) Dezember 2009 Beschreibung Beschluss/Annahme von INSPIRE Regulation on discovery and view services 14. Dezember 2009 Entwurf der IR für Download und Transformation Services Oktober 2011 Juni 2012 Juni 2012 Discovery und View Services operativ Entwurf der IR für Invoke Spatial Data Services Download Services und Transformation Services operativ Gemeinsame Datennutzung INSPIRE vermag einen möglichst unkomplizierten Zugang zu umweltrelevanter Information für Behörden der EU und der Mitgliedstaaten zu realisieren. Es sollen aber folgende Aspekte gewahrt werden: keine Wettbewerbsverzerrung, kein Zugriff auf sicherheitsrelevante Informationen und geistiges Eigentum öffentlicher Stellen bleibt unberührt. Diesbezüglich soll ein Beschluss im Dezember 2009 folgen, welcher die Implementing Rules für Berechtigung und Nutzerrechte beinhaltet ( Adoption IR governing the access rights of use to spatial data sets and services for Community institutions and bodies ). Gebühren als Thema werden ebenso bedacht in Bezug auf: Gewährleistung der Qualität und angemessener Rendite und Selbstfinanzierungserfordernisse der Behörden Jedoch sollen keine Gebühren für Geodaten- und Dienste, die unter die EU- Umweltberichtspflichten fallen, verlangt werden. 3.2 GDI Deutschland Die Geodateninfrastruktur in Deutschland (GDI-DE) ist ein gemeinsames Vorhaben von Bund, Ländern und Kommunen, für den Aufbau einer nationalen Basis für den Zugriff auf dezentral verteilte Geodaten und Geodienste in Deutschland. Über Verwaltungsgrenzen hinweg sollen komplexe Entscheidungsprozesse in Verwaltung, Wirtschaft und Politik, z.b. bei Fragen des Umweltschutzes, der Sicherheit oder der Standortentscheidung effizient unterstützt werden. Der Aufbau und Betrieb der GDI-DE ist in internationale Entwicklungen und Rahmenbedingungen eingebettet, hier ist besonders die Europäische Richtlinie 02/2007/EG (INSPIRE) zu nennen. Aus diesem Grund sieht GDI-DE vor, folgende Diensttypen bereit zu stellen: Suchdienste für Metadatenkataloge,

27 27 Darstellungsdienste, Downloaddienste, Transformationsdienste, Dienste zum Abrufen von Geodatendiensten sowie Bereitstellung der Fachthemen der INSPIRE Annexes I-III. Die Architekturspezifikation der Geodateninfrastruktur Deutschland teilt die Anforderungen in drei Gruppen: obligatorisch, optional und zukünftig. Diese funktionalen Anforderungen werden im Folgenden genannt GDI-DE obligatorisch Es werden für Datenbereitstellungs- und Managementfunktionalitäten dieser Diensttypen gefordert: Metadatenkataloge für Registrierung und Recherche von Geodaten, Geodiensten und Anwendungen (Katalogdienste) Vektordatenbereitstellung (Feature Services) Rasterdatenbereitstellung (Coverage Services) Gazetteer Des Weiteren sind 2D-Visualisierungen (Mapping Services) als Bestandteil der Darstellungsfunktionalitäten obligatorisch. Die vier Informationsmodelle nationale Geodatenbasis (NGDB), definierte Raumbezugssysteme, Beschreibung von Geoinformationsressourcen und definierte Datenformate (Vektor, Raster) sind ebenfalls als verbindlich anzusehen. Die Beschreibung von Daten und Diensten über Metadaten ist ebenso vorzusehen und nach dem heutigen Stand der Technik sind OGC-konforme Dienste doppelt zu beschreiben. Zum Einen für das Auffinden eines Dienstes in einer serviceorientierten Architektur ist die Beschreibung des Dienstes in einem Metadatenkatalog bereitzustellen. Zum Anderen ist eine notwendige Voraussetzung für die Nutzung eines OGC-konformen Dienstes der Zugriff auf die Capabilities. Durch diese beschreibt ein Dienst näher, welche Funktionen er ausführt und welche Daten er enthält. Genau genommen, enthalten Capabilities weitere, z.t. redundante, Metadaten. Die folgende Tabelle gibt einen zusammenfassenden Überblick über die zu den Anforderungen zugehörigen obligatorischen Spezifikationen. Tabelle 20: Obligatorische Spezifikationen der GDI-DE Diensttyp bzw. Datenformat Katalogdienst Vektordatendienst GDI-DE obligatorisch OpenGIS Catalogue Service Specification ISO Metadata Application Profile, Version 1.0 (2007) OpenGIS Filter Encoding Implementation Specification 1.1 OpenGIS WFS Web Feature Service Implementation Specification OpenGIS WFS Web Feature Service Implementation Specification

28 28 Rasterdatendienst Visualisierungsdienst WMS-DE Version 1.0 Gazetteer-Dienst Koordinatenreferenzsysteme der Dienste Metadaten und Metadatenformate Vektordatenformate Rasterdatenformate OpenGIS WCS Web Coverage Service Implementation Specification OpenGIS Gazetteer Service - Application Profile of the Web Feature Service Implementation Specification ETRS89 mit der Abbildung UTM 32 (EPSG-Code: 25832) Geografische Koordinaten im WGS84 (EPSG-Code: 4326) ISO 19115:2003 Metadaten über Geodaten ISO 19119:2005/PDAM1 Geographic Information Services ISO/TS (RC2), Geographic Information - Metadata - Implementation Specification OpenGIS Geography Markup Language (GML) Encoding Specification OpenGIS Geography Markup Language (GML) Encoding Specification GeoTIFF (Geo Tagged Image File Format) HDF-EOS (Hierarchical Data Format - Earth Observing System) DTED (Digital Terrain Elevation Data) NITF (National Imagery Transmission) GML 3 (Geography Markup Language) GDI-DE optional Folgende Dienste, Datenformate und Applikationen werden als optional für die GDI-DE eingestuft, weil für diese trotz verfügbarer technischer Lösungen noch keine verabschiedeten Spezifikationen existieren. Tabelle 21: Optionale Spezifikationen der GDI-DE Diensttyp bzw. Datenformat 3D-Visualisierung (Web Terrain Servcie) Dienstemonitore Zugriffskontrolldienste Geoportale GDI-DE optional Empfohlene Implementierungsspezifikation: OpenGIS Web Terrain Server Für die automatische Überwachung von Diensten im Netz gibt es für Quality of Service Aspekte keine Spezifikation. Es wird empfohlen, dass Dienstebetreiber zunächst individuell Verfügbarkeit und Antwortzeit der Dienste kontrollieren. Empfohlene Implementierungsspezifikation: OASIS Security Assertion Markup Language (SAML) V2.0 OASIS extensible Access Control Markup Language (XACML) V2.0 OASIS Web-Service Security Core Specification 1.1 Einführendes Dokument: OpenGIS Geospatial Portal Reference Architecture 0.2 Neben optionalen Diensttypen werden auch Vorschläge zur Verbesserung der Interoperabilität gemacht, diese betreffen z.b. die Nutzung verteilter Katalogdienste und die Kombination von Geodaten. Es werden jedoch lediglich Empfehlungen und Lösungsansätze genannt.

29 GDI-DE zukünftig Weitere Themen zeigen Handlungsbedarf für zukünftige Aktivitäten. Zu beachten ist, dass diese z.t. Vorarbeiten bzw. Abstimmungen von erheblicher Dauer erfordern. Zu nennen sind: Thesauri: Wortnetze, deren Begriffe durch Relationen miteinander verbunden sind (INSPIRE empfiehlt den Einsatz von Thesauri) Register (auch als Registry bezeichnet): Informationssysteme, in denen Register gehalten, aktualisiert und ausgewertet werden ebusiness (Electronic Business): automatisierte elektronische Geschäftsprozesse für den Bezug von Geodaten, Lizenzierung, Preisermittlung und Abrechnung Sensordaten: insbesondere im Rahmen der Bereitstellung von Umweltdaten von großer Bedeutung Abweichungen zu INSPIRE GDI-DE versucht obligatorische, optionale und zukünftige Aspekte und Themen in INSPIRE einzufügen bzw. mit der INSPIRE Richtlinie umzusetzen. Die Versionen der Spezifikationen sollen soweit identisch sein, dennoch existiert eine Differenz in Bezug auf Visualisierungsdienste. Das GDI-DE WMS-DE Version 1.0 Applikationsprofil beruht noch auf der Version der Web Map Service Implementation Specification des OGC, während INSPIRE bereits die Version vorsieht. Dementsprechend sind derzeit Web Map Services in den Versionen sowie bereitzustellen, um INSPIRE und GDI-DE konforme Dienste zur Verfügung zu stellen. GDI- DE sieht aber eine Überarbeitung des Applikationsprofils vor. 3.3 GDI Berlin/Brandenburg Die Geodateninfrastruktur der Hauptstadtregion Berlin/Brandenburg (GDI-BE/BB) sieht drei Grundkomponenten in der Umsetzung vor: Geoanwendungen (Informationssysteme und Portale im Internet), Geodienste (Web Services im Internet) und Geodaten (im direkten Zugriff über die Geodienste). Die Grundsätze und Ziele entsprechen sowohl den Gedanken von INSPIRE als auch im Besonderen der GDI-DE durch die Orientierung an Richtlinien und Spezifikationen dieser Geodateninfrastrukturen. Die Anbindung an INSPIRE und die Integration in die GDI-DE sind grundlegend, weshalb auch die bereits bekannten Diensttypen als auch Funktionsbereiche (Anforderungen) bereit zu stellen sind.

30 30 Folgende Maßnahmen sind zeitnah vorgesehen: Tabelle 22: Termine zur Verfügbarmachung von Netzdiensten und Geodaten Meilensteine (Termine) Dezember 2009 November 2010 Mai 2011 Mai 2011 November 2012 Mai 2014 Beschreibung Ausbau des Angebotes von Geodiensten in der Region Berlin/Brandenburg: Erfassung der Planungen zum dienstebasierten Geodatenangebot in beiden Ländern Abstimmung gleichartiger Diensteangebote zwischen den Ländern Festlegung von Prioritäten optionale Überprüfung der Konformität der Dienste (auf Anfrage) Verfügbarkeit der Such- und Darstellungsdienste gemäß INSPIRE- Roadmap Verfügbarmachung neuer Daten der Anhang-I-Datenthemen der INSPIRE-Richtlinie Verfügbarkeit der Downloaddienste und des Koordinaten- Transformationsdienstes gemäß INSPIRE-Roadmap Verfügbarkeit der Dienste zum Abrufen von Geodatendiensten gemäß INSPIRE-Roadmap Verfügbarmachung neuer Daten der Anhang-II- und -III- Datenthemen der INSPIRE-Richtlinie Beachtung sind dem Berlin/Brandenburgischen Metadatenprofil und dem amtlichen Bezugssystem für das Land Brandenburg zu schenken, da dort Spezifika gegeben sind Metadaten Aufgrund der Durchführungsbestimmungen Draft Guidelines INSPIRE metadata implementing rules based on ISO and ISO vom wird das Berlin/Brandenburgische Profil der ISO 19115/19119, Version 1.0, Corrigendum vom aktuell überarbeitet. So basieren die Anforderungen auf dem Entwurf Berlin/Brandenburgisches Profil der ISO 19115/19119 mit INSPIRE - Version 2.0 Mindestanforderungen vom Es ist zu beachten, dass das Berlin/Brandenburgische Profil eine verpflichtende Erweiterung um ein Metadatenelement der geographischen Ausdehnung (extendtypecode), aufgrund der topologischen Besonderheit der Länder, vorsieht. D.h. für die korrekte räumliche Beschreibung Brandenburgs muss die Fläche Berlins von der Gesamtausdehnung Brandenburgs ausgenommen werden Amtliches Bezugssystem Für das Land Brandenburg ist das European Terrestrial Reference System 1989 (ETRS89) mit der Koordinatenreferenzfläche des GRS80 und der UTM-Abbildung in der UTM-Zone 33 als amtliches Bezugssystem der Lage definiert. Derzeit wird ein 7-stelliger Ostwert mit einer führenden Kennziffer 3 für die Zone 33 unterstützt, diese Besonderheit wird bis zur Umstellung des Geobasisinformationssystems im

31 31 Rahmen des AAA-Projektes im Jahr 2010 beibehalten. Aus der schriftlichen Benachrichtigung des Ministerium des Inneren des Landes Brandenburg Interministerieller Ausschuss für das Geoinformationswesen in Brandenburg betreffend der Anwendung des amtlichen Bezugssystems der Lage für das Land Brandenburg vom 21. Juli 2009 geht hervor, dass beim Aufbau von Geodateninfrastrukturen und zu diesem Zweck aufzubauenden Datenbanken und Geodiensten vom Runderlass III Nr. 13/1996 abgesehen werden kann. Für den Aufbau des geplanten Infrastrukturknotens soll daher auf die Unterstützung des 7- stelligen Ostwerts mit der führenden Kennziffer 3 verzichtet werden. 4 Spezifische Anforderungen des Landkreis Oberhavel Im folgenden Abschnitt sollen die spezifischen Anforderungen des Landkreis Oberhavel an den Infrastrukturknoten dargestellt werden. Die Anforderungen werden in die folgenden Kategorien unterteilt: Unterstützung kommunaler Partner (kreisangehöriger Gemeinden und kooperierende Landkreise) Integration der geplanten Fachportale des Landkreis Oberhavel Unterstützung externer globaler Geodienste/Geonetzwerke Bereitstellung von digitalen Geländemodellen und virtuellen Stadtmodellen (optional) Bereitstellung von ETL- und Geoprocessing Funktionen (optional) Zugriffskontrolle Die dargestellten Anforderungen bilden (neben den Anforderungen aus INSPIRE, GDI-DE und GDI-BE/BB) die Grundlage für den Funktionskatalog. 4.1 Unterstützung kommunaler Partner Ein wesentliches Ziel des Infrastrukturknotens ist die Unterstützung der kreisangehörigen Gemeinden und kooperierender Landkreise. Insbesondere bietet sich die Kooperation mit Landkreisen an, die zusammen mit dem Landkreis Oberhavel über eine gemeinsame GIS Leitstelle verfügen, z.b. den Landkreisen Uckermark und Barnim. Im Rahmen der Kooperation können z.b. auch Aufwände für den geplanten Infrastrukturknoten aufgeteilt werden. Die kommunalen Partner sollen unentgeltlich das Metadateninformationssystem, die Komponenten der Security-Dienste, die ETL-Komponenten und die Komponenten zur Bereitstellung von Geodiensten mit nutzen dürfen, auf Fachportale zugreifen können, freigegebene Dienste des Infrastrukturknotens konsumieren können und die Möglichkeit erhalten, Geodaten online zu editieren. Der Zugriff soll über das Internet oder VPN erfolgen. Eine geeignete Zugriffskontrolle ist daher vorzusehen.

32 Zugriff auf das Metadateninformationssystem Abbildung 4 zeigt die Anwendungsfälle, die beim Zugriff auf das Metadaten- Informationssystem unterstützt werden sollen: Suchen von Ressourcen (Anwendungen, Dienste, Daten) über eine Webanwendung. Die Suche soll ohne Anmeldung vom Informationssuchenden durchgeführt werden können, wobei alle freigegebenen Ressourcen gefunden werden. Publizieren und modifizieren von Metadatensätzen durch einen Datenpfleger einer kreisangehörigen Gemeinde über eine Webanwendung. Eine Anmeldung am System ist durchzuführen. Modifizieren und löschen von Metadatensätzen, die von Datenpflegern einer Gemeinde angelegt wurden. Dieser Vorgang soll durch einen übergeordneten Redakteur dieser Gemeinde erfolgen können. Eine Anmeldung am System ist durchzuführen. Vollzugriff auf alle Metadatensätze durch Administratoren der Kreisverwaltung Oberhavel. Der Zugriff erfolgt über dieselbe Webanwendung, eine Anmeldung am System ist durchzuführen. Abbildung 4: Anwendungsfälle für den Zugriff auf das Metadateninformationssystem Die Anmeldung am System soll mittels Benutzername und Passwort über ein zentrales Modul zur Zugriffssteuerung des Infrastrukturknotens erfolgen. Die Verwaltung der Benutzernamen, Benutzergruppen und Passwörter soll im zentralen Verzeichnisdienst der Kreisverwaltung Oberhavel erfolgen.

33 Zugriff auf Fachportale Der Infrastrukturknoten soll mehrere Fachportale (siehe Abschnitt 4.2) bereitstellen, die für kommunale Partner über das Internet zugreifbar sein sollen. Die Nutzung der Fachportale soll nur nach erfolgter Anmeldung möglich sein. Da die Fachportale Funktionen und Werkzeuge enthalten, die nur für bestimmte Nutzergruppen verfügbar sein sollen, sind für die Anmeldung von Akteuren kommunaler Partner mehrere Rollen mit vorzusehen (Abbildung 5). Die Berechtigungen für die einzelnen Rollen müssen zur Laufzeit des Systems definiert werden können. Abbildung 5: Anwendungsfälle Zugriff auf Fachportale Die Anmeldung am System soll mittels Benutzername und Passwort über ein zentrales Modul zur Zugriffssteuerung des Infrastrukturknotens erfolgen. Die Verwaltung der Benutzernamen, Benutzergruppen und Passwörter soll im zentralen Verzeichnisdienst der Kreisverwaltung Oberhavel erfolgen Zugriff auf Dienste Der Infrastrukturknoten soll eine Reihe von (standardisierten) Diensten zur Visualisierung, Verarbeitung und zum Bezug von Geodaten über das Internet bereitstellen. Bestimmte Inhalte oder Funktionen einiger Dienste sollen nur für bestimmte Akteure kommunaler Partner zugreifbar sein. Der Zugriff auf diese Dienste soll daher geschützt sein. Die geschützten Dienste sollen von Akteuren kommunaler Partner über geeignete Client-Software konsumiert werden können. Der Zugriff auf folgende (geschützte) Dienst-Typen des Infrastrukturknotens soll ermöglicht werden: OGC Web Map Service (WMS) OGC Web Feature Service - Transactional (WFS-T) OGC Web Coverage Service (WCS) OGC Catalogue Service (CSW) ArcGIS Server Map Services ArcGIS Server Geoprocessing Service ETL Dienste

34 34 Zur Authentifizierung und Autorisierung der Anmeldung soll ein zentrales Modul zur Zugriffssteuerung des Infrastrukturknotens verwendet werden. Die Verwaltung der Benutzernamen, Benutzergruppen und Passwörter soll im zentralen Verzeichnisdienst der Kreisverwaltung Oberhavel erfolgen. Abbildung 6: Anwendungsfälle für Zugriff auf Dienste Map Client und Online-Editierung (optional) Der Infrastrukturknoten soll Akteuren kommunaler Partner ein Werkzeug zur Verfügung stellen, mit dem das Editieren von (featurebasierten) Geodaten möglich ist. Dieses Werkzeug soll in einer Webanwendung über das Internet bereitgestellt werden. Folgende Funktionen sollen unterstützt werden: Visualisierung von Kartendiensten (WMS, WFS, ArcGIS Server Map Services) Unterstützung von Punkt-, Linien-, und Polygonobjekten Hinzufügen, Löschen, Verschieben einzelner Geoobjekte Hinzufügen, Entfernen, Verschieben einzelner Stützpunkte Modifizieren der Sachdaten Abbildung 7: Anwendungsfall Online Editierung Die Anmeldung am System soll mittels Benutzername und Passwort über ein zentrales Modul zur Zugriffssteuerung des Infrastrukturknotens erfolgen. Die Verwaltung der Benutzernamen, Benutzergruppen und Passwörter soll im zentralen Verzeichnisdienst der Kreisverwaltung Oberhavel erfolgen.

35 35 Die Visualisierung von Kartendiensten (ohne die Funktion der Online-Editierung) soll auch externen Nutzern außerhalb der kommunalen Partner ermöglicht werden. Dies soll durch den Internetzugriff auf eine Webanwendung zur Kartenvisualisierung erfolgen. 4.2 Integration der Fachportale des Landkreis Oberhavel Ein weiteres wichtiges Ziel des Infrastrukturknotens ist die Integration der geplanten bzw. beantragten Fachportale des Landkreis Oberhavel. Tabelle 23: Fachportale des Landkreis Oberhavel Fachportal Bemerkung Status Umwelt und Landwirtschaft XPlanung Bauen Katastrophenschutz Verkehr Soziodemografie Arbeitssuche Interaktives Kreisinformationssystem Themen: Natur, Umwelt, Abfallwirtschaft, Bodenschutz, Landwirtschaft, Wasserwirtschaft Übernahme der Lösung des Landkreis Elbe-Elster vorgesehen Umsetzung als eigenständiges Portal oder als weiterer XPlanungs-Kontext Themen: Gefahrenabwehr, Brand- und Katastrophenschutz, Zivilschutz, Katastrophenmanagement Themen: Jugend, Soziales, Schulentwicklung, Gesundheit, Grundsicherung geplant, Konzepterstellung beantragt geplant geplant beantragt und Konzepterstellung genehmigt geplant geplant; Konzepterstellung beantragt geplant geplant Abbildung 8: Anwendungsfälle Integration der Fachportale

36 36 Die Fachportale sollen die Dienste des Infrastrukturknotens und externe Geodienste verwenden. Der Zugriff auf folgende (geschützte und öffentliche) Dienst-Typen des Infrastrukturknotens soll ermöglicht werden: ArcGIS Server Map Service ArcGIS Server Geoprocessing Service OGC Web Map Service OGC Web Feature Service - Transactional (WFS-T) OGC Catalogue Service (CSW) ETL Service Weiterhin soll den Fachportalen die Nutzung der zentralen Zugriffssteuerung des Infrastrukturknotens ermöglicht werden. Dies beinhaltet insbesondere den Zugriff auf einen Authentifizierungs- und Autorisierungsdienst des Infrastrukturknotens. 4.3 Unterstützung externer globaler Geodienste/Geonetzwerke Um die Geoinformationen des Landkreis Oberhavel einem möglichst großen Benutzerkreis zur Verfügung zu stellen, sollen ausgewählte Geodaten zur Nutzung innerhalb externer globaler Geodienste bzw. Netzwerke bereitgestellt werden. Da die Bereitstellung der Geoinformationen über international standardisierte Geodienste wie z.b. WMS, WFS oder CSW erfolgen soll, können die Informationen bereits von einer Vielzahl an externen Clients (z.b. auch Google Earth) und mobilen Endgeräten genutzt werden. Zusätzlich soll aber die Bereitstellung der Geoinformationen des Landkreis Oberhavel auch über KML erfolgen, um die direkte Anzeige in Google Earth und die Integration in Google Maps zu ermöglichen. Abbildung 9: Unterstützung externer globaler Geodienste/Geonetzwerke 4.4 3D-Visualisierung (optional) Die Bereitstellung und Visualisierung von 3D-Geländemodellen und virtuellen Stadtmodellen spielen im zunehmenden Maß eine wichtige Rolle in Geodateninfrastrukturen. Aus diesem Grund soll der Infrastrukturknoten die Bereitstellung von 3D-Diensten unterstützen: Virtuelle Stadtmodelle sollen über einen Web-Feature-Service bereitgestellt werden, der das GML-Anwendungsschema CityGML unterstützt

37 37 Digitale Geländemodelle sollen über die Schnittstelle Web Terrain Server (WTS) bereitgestellt werden. Es sollen die Geländemodelle DGM25 und DGM50 unterstützt werden. Für den Aufbau des Infrastrukturknotens soll zumindest die Erweiterungsmöglichkeit für die Bereitstellung von 3D-Diensten bestehen. 4.5 ETL- und Geoprocessing Funktionen (optional) Geoprocessing-Funktionen stellen einen erheblichen Mehrwert in Geodateninfrastrukturen dar. Sie erlauben die Erzeugung von neuen, kontextspezifischen Informationen aus bestehenden Ressourcen. Um die Weiterverarbeitung der Geodaten des Landkreis Oberhavel für externe Nutzer (z.b. GIS-Spezialisten kreisangehöriger Gemeinden, Planungsbüros, wissenschaftliche Einrichtungen) zu ermöglichen, sollen ETL-Werkzeuge als Webservices veröffentlicht werden können. Folgende Funktionen sollen unterstützt werden: Geoprocessing-Modelle sollen mittels ArcGIS Desktop entworfen werden können Geoprocessing-Modelle sollen über ArcGIS Server Geoprocessing Services als Webservices veröffentlicht werden können ETL-Prozesse sollen mit einem graphischen Werkzeug modelliert werden können. Insbesondere sollen ETL-Prozesse zur Transformation von featurebasierten Geodaten (z.b. CityGML und XPlan-GML), sowie zur Transformation des Datenformats (z.b. bei Download-Diensten) unterstützt werden. ETL-Prozesse sollen als Webservices zur Nutzung im Internet bereitgestellt werden können (z.b. durch FME Server), um Extraktions- und Downloadfunktionen zu unterstützen ETL-Prozesse zur Transformation und Validierung der Geodaten zur Erfüllung INSPIRE-konformer Datenmodelle durch ein Desktop-basiertes ETL-Werkzeug (z.b. FME Workbench) 4.6 Zugriffskontrolle Aus der Bereitstellung der Dienste und Anwendungen für unterschiedliche Nutzer und Nutzergruppen ergeben sich aus Sicht des Infrastrukturknotens mehrere Anforderungen an die Zugriffskontrolle: Unterstützung einer zentralen Komponente zur Zugriffskontrolle mit der Möglichkeit der Anbindung an einen Verzeichnisdienst (LDAP) der Kreisverwaltung Oberhavel. Ausdrücklich soll die LDAP-basierte Anbindung von Verzeichnisdiensten möglich sein, die mehrere interne und externe Verzeichnisdienste (z.b. von kommunalen Partnern) bündeln. Unterstützung einer rollenbasierten Auswertung von Rechten: Konkrete Berechtigungen sollen immer an Rollen gebunden sein, die Zuweisung von Rollen zu Identitäten soll über die Standard-Werkzeuge der jeweiligen Verzeichnisdienste

38 38 erfolgen können. Die Komponenten zur Zugriffskontrolle müssen daher die Zuweisung von Rollen- bzw. Gruppennamen aus den Verzeichnisdiensten zu internen Rollenbezeichnern unterstützen. Die Zuweisung kann z.b. mittels einer statischen Zuweisungstabelle erfolgen, die bei Änderungen des Rollenmodells in den Verzeichnisdiensten angepasst werden muss. Bereitstellung von Diensten zur Authentifizierung und Autorisierung, die von den Fachportalen genutzt werden können Bereitstellung einer Gateway-Komponente, die den Zugang zu geschützten standardisierten Diensten von Clients aus ermöglicht, die keine Funktionen zur Kommunikation mit Authentifizierungs- und Autorisierungsdiensten beinhalten (z.b. Anwendungen der kreisangehörigen Kommunen). Die Gateway-Komponente muss sichere Zugangspunkte (verschlüsselte URLs) zu den geschützten Diensten bereitstellen, die von den Clients genutzt werden können

39 39 TEIL 3 AUFBAU UND BETRIEB DES INFRASTRUKTURKNOTENS 5 Funktionen und logische Komponenten Im folgenden Abschnitt Funktionen und logische Komponenten werden auf Grundlage des Anforderungskatalogs die logischen Bestandteile des Infrastrukturknotens beschrieben. Für jede Komponente werden die erforderlichen Funktionen dargestellt. 5.1 Komponentenübersicht Abbildung 10: Übersicht der logischen Komponenten des Infrastrukturknotens

40 Funktionen der Dienste INSPIRE Network Services Komponente Funktion Beschreibung INSPIRE View Service INSPIRE Discovery Service INSPIRE Download Service F Unterstützung für die Bereitstellung von INSPIRE View Services gemäß den finalen Spezifikationen Implementing Rules und Technical Guidance 5. Die folgenden Eigenschaften müssen unterstützt werden: Advanced SOAP profile (siehe INSPIRE 2009a) F Folgende Datenquellen müssen unterstützt werden ArcSDE, ab Version 9.2 ECW File-Cache (Rasterdaten) F Unterstützung für die Bereitstellung von INSPIRE Discovery Services gemäß den finalen Spezifikationen Implementing Rules und Technical Guidance 6. F Folgende Datenbanken müssen unterstützt werden MS SQL Server F Unterstützung für die Bereitstellung von INSPIRE Download Services gemäß den finalen Spezifikationen Implementing Rules und Technical Guidance 7. F Folgende Datenquellen müssen unterstützt werden ArcSDE, ab Version 9.2 ECW Native Mapping Dienste Komponente Funktion Beschreibung ArcGIS Server Map Service F Unterstützung von ArcGIS Server Map Service OGC Geoservices Komponente Funktion Beschreibung Web Map Service F Unterstützung für die Bereitstellung von OGC Web Map Services, Version Die folgenden Eigenschaften müssen unterstützt werden: Operation GetFeatureInfo WMS SLD 5 Die derzeit letzte Version ist Technical Guidance View Services v 2.0 (INSPIRE 2009a) 6 Die derzeit letzte Version ist Technical Guidance Discovery Services v 2.0 (INSPIRE 2009b) 7 Die derzeit letzte Version ist Draft Technical Guidance for INSPIRE Download Services v 1.0 (INSPIRE 2009c)

41 41 Web Feature Service Web Coverage Service KML Service Catalogue Service F Unterstützung für die Bereitstellung von OGC Web Map Services, Version Die folgenden Eigenschaften müssen unterstützt werden: Operation GetFeatureInfo F Folgende Datenquellen müssen unterstützt werden ArcSDE, ab Version 9.2 ECW File-Cache (Rasterdaten) F Unterstützung für die Bereitstellung von OGC Web Feature Services, Version Die folgenden Eigenschaften müssen unterstützt werden: Transactional WFS (GetGMLObject Operation nicht erforderlich) Unterstützung des GML (3.1.1) Anwendungsschemas CityGML F Folgende Datenquellen müssen unterstützt werden ArcSDE, Version 9.3 F Unterstützung für die Bereitstellung von OGC Web Coverage Services, Version 1.1 F Folgende Datenquellen müssen unterstützt werden ArcSDE, ab Version 9.2 ECW F Unterstützung für die Bereitstellung von OGC KML, Version F Folgende Datenquellen müssen unterstützt werden ArcSDE, ab Version 9.2 F Unterstützung für die Bereitstellung von OGC CSW, Version F Folgende Datenbanken müssen unterstützt werden MS SQL Server F Folgende Anwendungsschemas müssen unterstützt werden: ISO Metadata Application Profile v1.0 (ISO 19115/19119) DE-Profil für Catalog-Services D-, Geoprocessing- und ETL Services (optional) Komponente Funktion Beschreibung Web Terrain Service F Unterstützung für die Bereitstellung von Web Terrain Services gemäß dem OpenGIS Request for Comment - Web Terrain Service [OGC 2003]. F Operation zur (punktuellen) Höhenwertabfrage F Operation zur Generierung von Profilschnitten (z. B. ein Quer- oder Längsschnitt durch eine Geländeoberfläche) F Unterstützung von DGM 25-Modellen (25 m-raster) F Unterstützung von DGM 5-Modellen (5 m-raster) F Folgende Datenquellen müssen unterstützt werden: Arc ASCII-Grid

42 42 ArcGIS Server Geoprocessing Service F Unterstützung von ArcGIS Server Geoprocessing Services ETL Service F Unterstützung von Webservices, die ETL-Funktionen bereitstellen. Folgende ETL-Funktionen müssen mindestens unterstützt werden: Transformation zu CityGML und XPlan-GML Transformation von Datenformaten Security Services Komponente Funktion Beschreibung Web Authentication Service Web Security Service F Unterstützung einer passwort-basierten Authentifizierungsmethode F Unterstützung OASIS Security Assertion Markup Language (SAML) V2.0 für das Ausstellen von digitalen Identitäten F Anbindung externer Verzeichnisdienste über eine LDAP Schnittstelle F Unterstützung der folgender Authentifizierungsschemas: HTTP Basic Authentication WSS Protocol F Unterstützung von OASIS extensible Access Control Markup Language (XACML) V2.0 für die Definition von Berechtigungen F Unterstützung für datenbankbasierte Verwaltung der Berechtigungen. Folgende Datenbanken müssen unterstützt werden MS SQL Server F Modulares Interceptor-Konzept zur Absicherung verschiedener Dienste. Folgende Diensttypen müssen unterstützt werden: WMS (Versionen und 1.3.0) WFS-T (Version 1.1.0) CSW (Version 2.0.2) ArcGIS Server Map Services ETL-Services INSPIRE View Services INSPIRE Discovery Services INSPIRE Download Services 5.3 Funktionen der Anwendungen Online Editierung (optional) Komponente Funktion Beschreibung Map Client / Editor F Der Map Client muss als Web-Anwendung bereitgestellt werden. F Unterstützung für die Visualisierung von INSPIRE View Services.

43 43 F Unterstützung für die Visualisierung von OGC WMS Diensten F Unterstützung für die Visualisierung von OGC WMS Diensten F Unterstützung für die Visualisierung von OGC WFS Diensten (2D) F (optional) Unterstützung für die Visualisierung von digitalen Geländemodellen über den Web Terrain Service F Editieren von (featurebasierten) Geodaten über die WFS-T Schnittstelle. Die folgenden Eigenschaften müssen unterstützt werden: Unterstützung von Punkt-, Linien-, und Polygonobjekten Hinzufügen, Löschen, Verschieben einzelner Geoobjekte Hinzufügen, Entfernen, Verschieben einzelner Stützpunkte Editierung der Sachdaten F Einbindung von WMS und WFS Diensten, die über Web Security Services (WSS) zugriffsgeschützt sind. F Single-Sign-On: Die Anmeldung am Map Client muss für die eingebundenen (geschützten) Dienste verwendet werden können Metadatenverwaltung Komponente Funktion Beschreibung Metadaten- Editor Metadatensuche F Erfassung, Validierung und Veröffentlichung von Metadaten über Web-basierte Editoren F Erfassung von INSPIRE Metadatenelementen F Harvesting von Metadatensätzen. Folgende Quellen sollen unterstützt werden: Web-Verzeichnisse (XML Dokumente) CSW 2.0 Catalog Services F Rollenbasierte Nutzerverwaltung mit Unterstützung für die folgenden Rollen: Informationssuchender Datenpfleger Redakteur Administrator F Suche von Metadaten über eine Web-Anwendung F Recherche über thematische, zeitliche und räumliche Suchkriterien, Themenbrowser F Unterstützung sämtlicher INSPIRE Suchattribute F Räumliche Suche über Kartenfenster. Die Anbindung von folgenden Diensten muss unterstützt werden: WMS und F Ranking und Sortieren der Trefferliste F Metadatendetailanzeige F Speichern von Suchanfragen

44 44 F Import und Export von Metadaten (mit Benutzerinformationen und/oder on-the-fly Transformation über Stylesheets) F Statistikfunktionen F Protection Level Konzept zur Steuerung des Freigabestatus von Metadaten F Folgende Datenbanken müssen unterstützt werden MS SQL Server F Visualisieren von Daten und Diensten aus dem Metadatensystem in ArcGIS Zugriffskontrolle Komponente Funktion Beschreibung Nutzer/ Rechteverwaltung F Administration der Nutzer und Zugriffsrechte im Web- Browser F Unterstützung für datenbankbasierte Verwaltung der Berechtigungen. Folgende Datenbanken müssen unterstützt werden MS SQL Server F LDAP-basierte Verwaltung von Nutzern Gateway F Bereitstellung sicherer Zugangspunkte (verschlüsselte URLs) zu den geschützten Diensten F Web-basierte Administration zur Erzeugung sicherer Zugangspunkte 6 Realisierung des Infrastrukturknotens 6.1 IT-Infrastruktur der Kreisverwaltung Oberhavel Abbildung 11 zeigt die IT-Infrastruktur für GIS der Kreisverwaltung Oberhavel. Die Infrastruktur soll hinsichtlich der Integration des geplanten Infrastrukturknotens erweitert werden. Bestehende Komponenten, Dienste und Anwendungen sollen dabei nicht ersetzt werden. Die Verwaltung sämtlicher Geodaten (Kataster-, Vektor und Rasterdaten) erfolgt basierend auf ArcSDE 9.2. Das zugrundeliegende DBMS ist Microsoft SQL Server 2005, als Speicherressource wird das zentrale Speichernetzwerk (SAN) der Kreisverwaltung eingesetzt. Die Bereitstellung von Kartendiensten wird von ArcIMS 9.2 übernommen. Im Intranet werden die ArcIMS-Dienste von ArcGIS-Desktop- und Web-Clients sowie von der Webanwendung GIS-Portal genutzt. Für den Zugriff aus dem Internet wird im geschützten Netzwerkbereich (DMZ) ein zusätzlicher ArcIMS Application Server eingesetzt, der die externen Dienste bereitstellt. Über das Internet greifen auch die kommunalen Partner auf die Dienste zu. Der interne Netzwerkbereich ist durch eine Firewall von der DMZ abgekoppelt. Der Zugriff des ArcIMS Application Server in der DMZ auf den ArcIMS Spatial Server im Intranet erfolgt durch eine Ausnahme (TCP/IP 5353). Der Zugriff auf das Ausgabebild des Spatial

45 45 Server erfolgt über einen Disk Mount. Diese für Lösung für Internet-Kartenserver ist bei dem Einsatz von ArcIMS durchaus verbreitet. Für ArcGIS-Server basierte Lösungen kann diese Architektur hinsichtlich der Netzwerksicherheit nicht empfohlen werden, da der DCOM- Zugriff des Application Server (ArcGIS Server Object Manager) auf den Spatial Server (ArcGIS Server Object Container) durch mehrere dynamisch vergebene TCP/IP Ports erfolgt. In der Firewall-Konfiguration wäre die Regelung mehrerer Ausnahmen vonnöten. Ein wichtiger technischer Aspekt bei der IT-Infrastruktur der Kreisverwaltung Oberhavel ist der konsequente Einsatz von Virtualisierungs-Technologie (ESX-Server). Alle Anwendungs- Server im Intranet und der DMZ sind virtualisiert. Die Lastverteilung wird On-Demand mit Werkzeugen der Virtualisierungs-Server geregelt. Als Standard-Betriebssystem wird Suse Linux Enterprise, Version 10 eingesetzt. Falls technisch erforderlich, können auch Windowsbasierte Server eingesetzt werden. Das Netzwerk basiert auf einem 10-Gigabit-Ethernet (10GE). Abbildung 11: IT-Infrastruktur Kreisverwaltung Oberhavel