...

Dokumentinformationen

Die Autorinnen und Autoren danken den vielen Personen und Institutionen, die am Entwicklungsprozess des Architekturkonzepts aktiv beteiligt waren.

Änderungshistorie

Inhalt

Abkürzungsverzeichnis

Management Summary

Die Architektur der GDI-DE ist eingebettet in die organisatorischen und regulatorischen Rahmenbedingungen der Bund-Länder-Kooperation der GDI-DE. Die Architektur der GDI-DE beschreibt die technischen Regeln und Komponenten, die dem Betrieb der GDI-DE zugrunde liegen, sowie deren Ausbau und Weiterentwicklung. Um ein reibungsloses Zusammenwirken der technischen Komponenten der GDI-DE zu ermöglichen, sind organisatorische und technische Rahmenvorgaben erforderlich, die zusammenfassend als Architekturkonzept der GDI-DE bezeichnet werden. Die Architektur wurde in einem breit angelegten Konsensprozess mit den Beteiligten (Stakeholdern) abgestimmt und dient den Akteuren der GDI-DE als gemeinsame Handlungsgrundlage. Die Architektur der GDI-DE richtet sich an Entscheider, Fachexperten, Projektleiter und IT-Spezialisten aus öffentlicher Verwaltung, Wirtschaft und Wissenschaft sowie alle Interessierte, die zum Betrieb und Ausbau der GDI-DE beitragen.

...

Mit Beschluss der "Architektur der GDI-DE - Technik, Version 4.0" und der Einführung neuer Komponenten, wie dem GDI-DE Monitor, kann die Architektur der GDI-DE erfolgreich weiterentwickelt werden.

1 Einführung

Das Architekturkonzept der GDI-DE ist – wie in Abbildung 1 dargestellt –aus einzelnen Dokumenten bzw. Modulen aufgebaut. In den drei Hauptmodulen werden grundsätzliche Festlegungen getroffen. Während das Modul „Architektur der GDI-DE – Ziele und Grundlagen" die strategischen Ziele, fachliche und technische Grundsätze sowie rechtliche und organisatorische Rahmenbedingungen der GDI-DE darstellt, beschreibt das hier vorliegende Modul „Architektur der GDI-DE – Technik" die Architekturkomponenten und referenziert hierfür relevante Standards, Normen und Spezifikationen für die Architektur der GDI-DE. Ergänzend zeigt das Modul „Architektur der GDI-DE – Maßnahmenplan" die für die künftige Entwicklung der GDI-DE erforderlichen Schritte.
Die technischen Aspekte der Architektur der GDI-DE, Version 4.0 betreffen insbesondere das Zusammenspiel und die Weiterentwicklung von IT-Systemen unterschiedlicher Betreiber im Netz, das nur unter Einhaltung technischer Standards funktionieren kann. Die systematische Klassifizierung von Standards soll Akteure der GDI-DE in die Lage versetzen, ihre IT-Systeme funktionsfähig einzurichten und zu nutzen. Für die erfolgreiche Partizipation an der GDI-DE ist das Architekturkonzept bei Ausschreibungen oder Eigenentwicklungen zu berücksichtigen. Das Architekturkonzept der GDI-DE wird durch das Lenkungsgremium GDI-DE unter Beteiligung von Bund, Ländern und Kommunen beschlossen. Der IT-Planungsrat erhält durch regelmäßige Berichte des Lenkungsgremiums GDI-DE Kenntnis von den Entwicklungen und Maßnahmen in der GDI-DE. Eine Unterstützung des o. g. Mandatsträgers erfolgt durch die Koordinierungsstelle GDI-DE (Kst. GDI-DE).

Abbildung 1: Architekturkonzept der GDI-DE – Übersicht über die Architekturdokumente

2 Klassifizierung der Geostandards

Die Einstufung der zu verwendenden Geostandards orientiert sich am aktuellen Stand der Technik. Lösungen und Konzepte entsprechen dem Stand der Technik (Bundesministerium der Justiz, 2008), wenn:

...

Darüber hinaus werden Geostandards hinsichtlich der Erfüllung von Mindestanforderungen an die Offenheit nach SAGA 5 bewertet (SAGA 5, 2011). Dies ist ein wichtiges Prüfkriterium, um u. a. den Architekturgrundsatz der Offenheit besser zu erreichen (vgl. Abschnitt 3.3, Arbeitskreis Architektur der GDI-DE, 2019). Offene Spezifikationen schaffen eine transparente Basis für die öffentliche Verwaltung einerseits und die Lieferanten von Informationstechnik andererseits. Damit unterstützet die Architektur der GDI-DE das Prinzip der Nachhaltigkeit für die Informationstechnik in der öffentlichen Verwaltung und fördern zugleich die Erhöhung des Wettbewerbs sowie die Verbreitungsgeschwindigkeit innovativer Technologien in der IT-Branche.

2.1 Klassifizierung

In der Architektur der Geodateninfrastruktur Deutschland (GDI-DE) werden Geostandards nach ihrer Übereinstimmung mit dem Stand der Technik den folgenden Stufen unterschiedlicher Verbindlichkeit zugeordnet: GDI-DE-grundlegend, GDI-DE-optional, GDI-DE-unter-Beobachtung, GDI-DE-auslaufend und INSPIRE-grundlegend.
GDI-DE-grundlegend
Geostandards sind GDI-DE-grundlegend, wenn sie dem Stand der Technik entsprechen. Sie gewährleisten die für die Umsetzung der Architektur der GDI-DE erforderliche Interoperabilität, daher ist die Verwendung innerhalb der GDI-DE obligatorisch.
GDI-DE-auslaufend
Geostandards sind GDI-DE-auslaufend, wenn sie zuvor als GDI-DE-grundlegend klassifiziert waren, jedoch aufgrund der Weiterentwicklung des Stands der Technik überholt sind und durch aktuellere ersetzt werden können. Geostandards, die als GDI-DE-auslaufend klassifiziert sind, werden in einer der Nachfolgeversionen des Architekturkonzepts nicht mehr aufgeführt. Es wird deshalb empfohlen, sie nicht für Neuentwicklungen von Software und Systemen einzusetzen.
GDI-DE-optional
Geostandards sind GDI-DE-optional, wenn es bereits praxiserprobte Umsetzungen gibt, diese aber eine zusätzliche Variante darstellen und auf gesicherten Erkenntnissen von Wissenschaft, Technik und Erfahrung basieren.
In Bereichen, in denen mit optionalen Lösungsansätzen Interoperabilität in Teilen erreicht werden kann, ist diesen der Vorzug vor nicht in der Architektur berücksichtigten Geostandards zu geben.
GDI-DE-unter-Beobachtung
Es gibt Anforderungen, die derzeit weder durch etablierte noch durch im laufenden Betrieb einsetzbare Geostandards bedient werden können. Die Entwicklungen zugehöriger Lösungsansätze sollen frühzeitig innerhalb der GDI-DE diskutiert werden und stehen unter Beobachtung.
INSPIRE-grundlegend
Metadaten, Geodaten und Geodatendienste, die im Geltungsbereich der INSPIRE-Richtlinie bereitzustellen sind, unterliegen den in den INSPIRE-Durchführungsbestimmungen und in den INSPIRE-Umsetzungsanleitungen oder INSPIRE GoodPractice Dokumenten genannten zusätzlichen Anforderungen.

2.2 Lebenszyklus

Bereits klassifizierte sowie neue Geostandards werden jährlich nach dem aktuellen Stand der Technik und ihrer Offenheit bewertet. Die Ergebnisse werden in diesem Technikdokument entsprechend aktualisiert. Dabei kann ein Standard seine Klassifikation behalten oder neu klassifiziert werden. Eine erneute Bewertung kann auch bedeuten, dass ein Standard nicht mehr empfohlen und erwähnt wird.
Zur Wahrung der Investitionssicherheit werden als GDI-DE-grundlegend klassifizierte Geostandards in der Regel langfristig beibehalten. In einer Wiederbewertung kann lediglich festgelegt werden, dass sie ggf. nicht mehr empfohlen werden (GDI-DE-auslaufend).

...

Die in den folgenden Kapiteln referenzierten Geostandards für Datenbestände und Anwendungen (vgl. Kapitel 5) und für Dienste (vgl. Kapitel 6) sind je einer der oben genannten Verbindlichkeitsstufen zugeordnet. Geostandards, die in den Geltungsbereich von INSPIRE fallen, werden immer als INSPIRE-grundlegend gekennzeichnet.

3 Architektur der GDI-DE

3.1 Grundlagen der Architektur

Das Konzept der dienstorientierten Architektur (engl. service-oriented architecture, SOA) basiert auf dem Prinzip der Nutzung verteilt vorliegender Ressourcen (Daten und Funktionalitäten), die über standardisierte Schnittstellen im Internet ausgetauscht werden (vgl. Abbildung 4).
Geodatendienste können unterschiedliche Datenquellen (z. B. Datenbanken) so anbinden, dass die Geodaten über die standardisierten Schnittstellen der Dienste interoperabel im Internet bereitgestellt werden. Die Vorgaben der Architektur der GDI-DE enden auf der Schnittstellenebene, die Umsetzung einer Schnittstellendefinition in Software ist nicht Gegenstand der Architektur.

Abbildung 4: Schematische Darstellung der Architektur der GDI-DE

3.1.1 Publish-Find-Bind-Muster

Das Konzept der dienstorientierten Architektur bildet die technische Grundlage, um die Ziele und Grundsätze der GDI-DE umzusetzen. Um die verteilten Ressourcen über webbasierte Dienste bereitzustellen und nutzbar zu machen, wird das Publish-Find- Bind-Muster (vgl. Abbildung 5) verwendet. Im Folgenden wird dessen Ablauf kurz beschrieben:

...

Abbildung 6: Publish-Find-Bind-Muster – übertragen auf die Architektur der GDI-DE

3.1.2 Kopplung der Metadaten von Geodaten und Geodatendiensten

Ein wesentlicher Baustein, um das Publish-Find-Bind-Muster erfolgreich umzusetzen, ist die Verknüpfung der Metadaten von Geodaten und Geodatendiensten. Eine ausführliche Beschreibung der Kopplung wird in den „Konventionen zu Metadaten in der GDI-DE" (AK Metadaten, 2024) erläutert. An dieser Stelle erfolgt nur die prinzipielle Beschreibung.
Ein Geodatensatz kann über einen oder mehrere Geodatendienste bereitgestellt werden. Jeder Datensatz und jeder Dienst ist dabei mit Metadaten beschrieben, damit er für die Suche in einem Katalog veröffentlicht werden kann. Ein Geodatendienst besitzt, zusätzlich zu seiner Metadaten- beschreibung im Katalog, eine technische Beschreibung seiner Funktionalitäten in Form eines Capabilities-Dokuments, welches im Bind-Schritt verarbeitet wird (vgl. Abbildung 7).

...

Abbildung 8: Kopplung der Geodaten und Geodatendienste über Identifikatoren und Hyperlinks

3.1.3 Authentifizierungs- und Autorisierungsinfrastruktur

Die Authentifizierungs- und Autorisierungsinfrastruktur ist derzeit nur konzeptioneller Teil der Architektur der GDI-DE und nicht realisiert. Das Konzept bietet für die Nutzung zugriffsgeschützter Geodaten und Geodatendienste in der GDI-DE perspektivisch die Möglichkeit, die Identität eines Nutzers nachzuweisen und die Vertraulichkeit von Informationen durch entsprechende Autorisierung zu sichern. Dabei verwaltet eine dezentrale Organisation die Identität der ihr zugeordneten Nutzer (Authentifikation). Die Rechtedurchsetzung (Autorisierung) erfolgt dann durch jene dezentrale Organisation, die dem Nutzer eine geschützte Ressource bereitstellt.
Eine Entkopplung der Authentifizierungsfunktion von der Autorisierungsfunktion senkt den Aufwand für Pflege und Wartung bei allen beteiligten Organisationen. Keine Organisation muss organisationsfremde Nutzer verwalten und Zugriffsrechte auf Ressourcen können aufgrund abgestimmter Rollen und Attribute formuliert werden. Voraussetzung hierfür ist aber, dass sich Organisationen vorab gegenseitig Vertrauen aussprechen, so dass z. B. eine Organisation A allen Nutzern, deren Authentizität durch Organisation B nachgewiesen wurde, vertraut. Dadurch entsteht eine Vertrauensdomäne (trusted domain).

Abbildung 9: Schematische Abbildung einer Authentifizierungs- und Autorisierungsinfrastruktur (AAI)

Die Service-Provider (SP) stellen geschützte Ressourcen, d. h. verschiedene Geodaten und Geodatendienste, innerhalb der Vertrauensdomäne bereit und entscheiden, ob einem Zugriff stattgegeben wird oder nicht. Eine zentrale Stelle (Coordinating Centre, vgl. Abb. 9) unterstützt die Föderation organisatorisch; hier werden Verträge verwaltet und Bedingungen für den Beitritt geprüft. Die Authentifizierung erfolgt innerhalb der Vertrauensdomäne durch Identity-Provider (Authentifizierungsstellen, IdP). Jeder Nutzer, der auf geschützte Ressourcen zugreifen will, muss sich über die Authentifizierungsstelle seiner Organisation anmelden, dort erfolgt die Verwaltung seines Nutzerkontos und seiner Rollen (Berechtigungsklassen). Der Lokalisierungsdienst (in Abb. 9 nicht dargestellt) ist das zentrale technische Bindeglied der Authentifizierungs- und Autorisierungsinfrastruktur (AAI), das alle Service- und Identity-Provider zu einer Vertrauensdomäne zusammenschließt. Wesentliche Funktion dieses Dienstes ist es, den Nutzer zum Identity-Provider seiner Heimatorganisation weiterzuleiten, wenn er unangemeldet auf eine geschützte Ressource eines Service-Providers aus der Föderation zugreifen möchte.
Weitere Informationen können dem „Konzept einer Zugriffskontrolle in der GDI-DE" " (Kst. GDI-DE, 2009) sowie dem OGC Whitepaper „Architecture of an Access Management Federation for Spatial Data and Services in Germany" (OGC, 2012) entnommen werden.

3.2 Modularer Aufbau der GDI-DE

Die GDI-DE ist modular aus definierten nationalen und dezentralen IT-Komponenten aufgebaut, die in bestimmter Art und Weise miteinander interagieren:

...

In den Kapiteln 3.3 bis 3.5 werden die Komponenten sowie die Beziehungen zwischen nationalen und dezentralen Komponenten näher beschrieben.

3.3 Nationale Technische Komponenten

In diesem Kapitel werden der Zweck, die Anforderungen sowie Schnittstellen und Leistungsmerkmale der Nationalen Technischen Komponenten (NTK) beschrieben. Tabelle 1 (in Kap. 3.2) gibt einen Überblick über ihren Realisierungsstand.

3.3.1 Geodatenkatalog.de

3.3.1.1 Zweck

Der Geodatenkatalog.de stellt Metadaten über Geodaten, Geodatendienste und weitere IT-gestützte Geodatenanwendungen deutschlandweit über eine einheitliche Schnittstelle zur Suche bereit. Geodatenkatalog.de bezieht die in ihm enthaltenen Metadaten durch Zugriff auf andere Kataloge des Bundes und der Länder über eine standardisierte Austauschschnittstelle (Catalogue Service, CSW) und baut daraus einen konsolidierten, übergreifenden Metadatenbestand auf.
Der Geodatenkatalog.de wird u. a. im Geoportal.de für die Recherche genutzt sowie als INSPIRE- konformer Suchdienst (vgl. Kapitel 6.2) bereitgestellt. Er steht zur freien Verfügung im Internet und wird auch von weiteren Infrastrukturen, wie z. B. dem dem Europäischen Datenportal, Global Earth Observation System of Systems (GEOSS) und anderen Anwendungen genutzt.

3.3.1.2 Schnittstellen

Abbildung 11: Komponentendiagramm Geodatenkatalog.de

...

Tabelle 4: Schnittstellen des Geodatenkatalog.de

3.3.1.3 Anforderungen

• Geodatenkatalog-AF 1 „Metadaten durchsuchen"
  • Suche in Metadaten über eine gemäß INSPIRE-Vorgaben standardisierte Webschnittstelle (Maschine-Maschine-Kommunikation)
• Geodatenkatalog-AF 2 „Metadaten bereitstellen und einsammeln"
  • Bereitstellung von standardisierten Metadaten aus dezentralen Metadatenkatalogen
  • Harvesting dieser dezentralen Metadaten durch Geodatenkatalog.de
  • Technical Guidance for the implementation of INSPIRE Discovery Services (IOC-TF, 2011)

3.3.1.4 Qualitätsmerkmale

Verfügbarkeit: 99 %
Zugriffszeit am Server: 3 Sekunden
Leistungsfähigkeit: 30 parallele Zugriffe pro Sekunde; gemäß Verordnung (EG) Nr. 976/2009 zu INSPIRE-Netzdiensten (Suchdienst)

3.3.2 GDI-DE Testsuite

3.3.2.1 Zweck

Mit Hilfe der GDI-DE Testsuite können Metadaten, Geodaten und Geodatendienste hinsichtlich ihrer Konformität zu Standards und Vorgaben der GDI-DE und INSPIRE überprüft werden. Anbietende Stellen werden durch dieses Werkzeug bei der konformen Bereitstellung ihrer Ressourcen in der GDI-DE sowie bei der Umsetzung der INSPIRE-Richtlinie durch Nachnutzung des INSPIRE Validators unterstützt.

3.3.2.2 Schnittstellen

Abbildung 12: Komponentendiagramm GDI-DE Testsuite

...

Tabelle 5: Schnittstellen der GDI-DE Testsuite

3.3.2.3 Anforderungen

• Testsuite-AF 1 „Test einrichten"
  • Einrichtungen eines Tests unter Angabe des zu testenden Datensatzes bzw. Dienstes und des anzuwendenden Konformitätstests über eine grafische Benutzeroberfläche (Mensch-Maschine-Kommunikation) oder über eine Web-Service-Schnittstelle (Maschine-Maschine-Kommunikation)
• Testsuite-AF 2 „Test ausführen"
  • Ausführen eines zuvor eingerichteten Tests über eine grafische Benutzeroberfläche (Mensch-Maschine-Kommunikation) oder über eine Web-Service-Schnittstelle (Maschine-Maschine-Kommunikation)
• Konformitätsprüfung auf
  • INSPIRE Metadata TG 2.0 – data sets and data sets series / network services / invocable spatial data services
  • Konventionen der GDI-DE für INSPIRE-konforme Metadaten (vgl. Kapitel 5.4.2)
  • Konventionen der GDI-DE für GDI-DE-konforme Metadaten (vgl. Kapitel 5.4.2)
  • OGC CSW 2.0.2 AP ISO 1.0 (vgl. Kapitel 6.2)
  • INSPIRE Discovery Service – CSW (vgl. Kapitel 6.2)
  • INSPIRE View Service – WMS 1.3.0 (vgl. Kapitel 6.3)
  • INSPIRE View Service – WMTS
  • INSPIRE Download Service – Direct WFS (vgl. Kapitel 6.4)
  • INSPIRE Download Service – Pre-Defined WFS
  • INSPIRE Download Service – Pre-Defined Atom
  • INSPIRE Download Service – WCS
  • INSPIRE Download Service – OAPIF
  • INSPIRE Download Service – STA (vorgesehen)
  • INSPIRE Datenthemen (vgl. Kapitel 5.2)

3.3.2.4 Qualitätsmerkmale

Verfügbarkeit: 95 %
Zugriffszeit am Server: 3 Sekunden
Leistungsfähigkeit: 20 parallele Zugriffe pro Sekunde

3.3.3 Geoportal.de

3.3.3.1 Zweck

Das Geoportal.de bietet als Plattform einen zentralen Zugang zu den Daten und Diensten der GDI-DE. Es trägt dazu bei, die dienstorientierte Architektur der GDI-DE umzusetzen und übergreifende Empfehlungen und Konzepte zu erproben. Darüber hinaus dient das Geoportal.de über den gesetzlichen Auftrag nach §19 GeoZG hinaus auch der unmittelbaren Nutzung von Geodaten durch Bereitstellung von Geo-Features (z.B. 3D-Ansicht).

3.3.3.2 Schnittstellen

Abbildung 13: Komponentendiagramm Geoportal.de

...

Tabelle 6: Schnittstellen des Geoportal.de

3.3.3.3 Anforderungen

• Suche nach Geodaten und Geodatendiensten über deren Metadaten
• Nutzung/Einbindung/Anzeige/Bereitstellung von standardisierten interaktiven Kartendiensten
• Suche nach Orten und Adressen in ganz Deutschland
• Bereitstellung von Geo-Features (z.B. 3D-Ansicht)
• Bereitstellung von allgemeinen Informationen über die GDI-DE für die Öffentlichkeit

3.3.3.4 Qualitätsmerkmale

Verfügbarkeit: 99 %
Zugriffszeit am Server: 10 Sekunden
Leistungsfähigkeit: 20 parallele Zugriffe pro Sekunde

3.3.4 GDI-DE Registry

3.3.4.1 Zweck

Die GDI-DE Registry verwaltet Informationen, die mehrfach in der GDI-DE verwendet werden und deren Einheitlichkeit sicherzustellen ist. Sie dient als Werkzeug, um beispielsweise die Identität von Objekten dauerhaft zu gewährleisten. Die Registry ist erweiterbar, um über die unten genannten Register hinaus zusätzliche Informationen verwalten zu können.

3.3.4.2 Schnittstellen

Abbildung 14: Komponentendiagramm GDI-DE Registry

...

Tabelle 7: Schnittstellen der GDI-DE Registry

3.3.4.3 Anforderungen

• Registry-AF 1 „Registerinhalte pflegen"
  • Es werden unterschiedliche Aufgaben zur Pflege von Verantwortlichen bei Bund und Ländern (ggf. auch Kommunen und Dritten) wahrgenommen, über einen webbasierten Registry-Clienten.
• Registry-AF 2 „auf Registerinhalte und registerspezifische Funktionen zugreifen"
  • Registry-Element-Identifikator auflösen: liefert zu einem Identifikator (URI) ein Registry-Element (Registry, Register, Subregister, ItemClass oder Item)
  • INSPIRE-ID auflösen: liefert zu einer INSPIRE-ID (URI) die URL zum Geo-Objekt
  • CodeList-ID auflösen: liefert zu einer CodeList-ID (URI) die CodeListe
  • Folgende Informationen werden in Registern geführt:
    • Namensraum-Register zur Verwaltung von Namensräumen für INSPIRE-IDs
    • Codelisten-Register zur Verwaltung und Bereitstellung von Codelisten
    • Organisations-Register zur Verwaltung der Koordinierungsstruktur der GDI-DE und aller für die Prozesse der GDI-DE Registry relevanten Organisationen
    • CRS-Register zur Verwaltung und Veröffentlichung von Parametern zu Koordinatenreferenzsystemen (CRS) und CRS-Transformationen
    • XML-Schema-Repository zur Verwaltung und Bereitstellung von Encoding-Vorschriften für Datenmodelle

3.3.4.4 Qualitätsmerkmale

Verfügbarkeit: 99 %
Zugriffszeit am Server: 3 Sekunden
Leistungsfähigkeit: 30 parallele Zugriffe pro Sekunde

3.3.5 GDI-DE Monitor

3.3.5.1 Zweck

Der GDI-DE Monitor ist eine Komponente zur Unterstützung des Qualitätsmonitorings und Auswertung von Metadaten hinsichtlich definierter Qualitätsparameter. Mit Unterstützung des GDI-DE Monitor können Auswertungen zur Zugänglichkeit und Nutzbarkeit von Georessourcen erstellt werden sowie die Erfüllung von gesetzlichen Anforderungen (z. B. der INSPIRE-Richtlinie) durchgängig überwacht werden.

3.3.5.2 Schnittstellen

Abbildung 15: Komponentendiagramm GDI-DE Monitor

...

Tabelle 8: Schnittstellen der GDI-DE Monitor

3.3.5.3 Anforderungen

• Monitor-AF 1 „GDI-DE Monitor anbieten"

  • Die Ergebnisse des INSPIRE-Monitorings (Liste mit Ressourcen und Indikatoren) für alle Ressourcen aus Deutschland oder für eine bestimmte Auswahl an Ressourcen in einer Nutzeroberfläche (GUI) darzustellen

  • Zur Anzeige, Konfiguration und Speicherung von spezifischen Auswertungen sind Nutzerkonten für Katalogbetreiber, geodatenhaltende Stellen und weitere Akteure (z.B. Kst. GDI-DE, Kontaktstellen, AK der GDI-DE) bereitzustellen.

  • Integration der Harvesting-Zusammenfassung für Katalogbetreiber in den GDI-DE Monitor (vorgesehen)

• Monitor-AF 2 „Tests ausführen"

  • Prüfung der Metadaten im Geodatenkatalog.de mit der GDI-DE Testsuite

• Monitor-AF 3 „Metadaten verwenden"

  • Metadaten über Katalogschnittstelle importieren

  • Ergebnisse des Metadaten-Imports auswerten

  • Berechnung der Indikatorwerte für das INSPIRE-Monitoring gemäß der von der EU verwendeten Methodik für eine bestimmte Auswahl an Ressourcen (Ressourcen des Bundes, Ressourcen eines Landes, Ressourcen einer Kommune, Ressourcen einer geodatenhaltenden Stelle)

  • Für die im Geodatenkatalog.de verwendeten Metadaten:

    • Auflistung der Zeitpunkte des Harvestings in den Geodatenkatalog.de + letztes erfolgreiches Harvesting, Harvesting-Intervall, Anzahl geharvesteter Daten, Anzahl Veränderung im Vergleich zum letzten Harvesting (Hinzufügungen, Löschungen, Aktualisierungen)

    • Darstellung der Anzahl valider und invalider Daten beim letzten Harvesting (aufgeschlüsselt nach geharvesteten Katalogen, Datenbereitstellern)

    • Ableitung von Indikatoren zur Bewertung der Konformität, Qualität und Vollständigkeit der Metadaten im Geodatenkatalog.de bzw. in der GDI-DE.

    • Folgende Auswertungen werden im GDI-DE Monitor bereitgestellt:

    • Analyse der Monitoring-Ergebnisse: automatische Ableitung von Diagrammen, Grafiken (z.B. Karten) und Tabellen für alle erfassten Monitoring-Jahre

    • Für die Fehleranalyse werden von der EU (JRC) Fehlerlisten mit den Ergebnissen der Validierung der Metadatensätze herausgegeben ("Summary of metadata failing validation").

    • Auswertung der Flächendeckung (optional, Umsetzung wird geprüft)

3.3.5.4 Qualitätsmerkmale

Verfügbarkeit: 95 %
Zugriffszeit am Server: 3 Sekunden
Leistungsfähigkeit: 20 parallele Zugriffe pro Sekunde

3.4 Dezentrale Technische Komponenten

Die Dezentralen Technischen Komponenten, wie in Tabelle 2 aufgelistet, werden von unterschiedlichen Akteuren der GDI-DE betrieben und stellen definierte Schnittstellen und Dienstequalitäten (siehe Kapitel 6) bereit, um eine Interoperabilität innerhalb der GDI-DE zu gewährleisten.

3.4.1 Metadatenkomponenten

Hierunter werden alle Komponenten verstanden, die der Erfassung, Speicherung, Verwaltung und Bereitstellung von Metadaten in der GDI-DE dienen. Die verteilten Metadatenkomponenten sind die Grundlage für die zentrale Suche mit dem Geodatenkatalog.de (siehe Kapitel 3.3.1), welcher auf diese Komponenten zurückgreift. Dabei sind die Inhalte entsprechend der „Formate für Metadaten" (Kapitel 5.4.2) strukturiert – die Dienste folgen den Vorgaben für Suchdienste (Kapitel 6.2).

3.4.2 Geodatendienstekomponenten

Geodatendienstekomponenten dienen der dienstebasierten Bereitstellung von Geodaten in der GDI-DE in der Form von Raster- oder Vektordaten dienen. Dies sind einerseits reine Datendienste, wie die sogenannten „Downloaddienste" für Vektordaten (siehe Kapitel 6.4.1und 6.4.2) oder für Rasterdaten (siehe Kapitel 6.4.3), andererseits aber auch Dienste, welche Daten als Bilddaten, zumeist als Karte oder Kartenlayer, darstellen (siehe 6.3.1).
Diese Dienstekomponenten, die sowohl Geobasis- als auch Geofachdaten bereitstellen, bilden die Basis der GDI-DE.

3.4.3 Geokodierungskomponenten

Eine Sonderform der Geodatendienste stellen die Geokodierungsdienste dar. Mit Hilfe von diesen Diensten lassen sich Adressen, Flurstücksnummern, geographische Namen oder andere indirekt georeferenzierte Objekte einer räumlichen Lage zuordnen oder umgekehrt. Die Dienste folgen dabei den Vorgaben der Downloaddienste für Vektordaten (Kapitel 6.4.1).
Die Geokodierung erhält durch §14 des E-Government-Gesetzes eine besondere Bedeutung, indem die Vorgaben zur Georeferenzierung in elektronischen Registern definiert werden. Ein Dienst, der eine solche Georeferenzierung auf Basis amtlicher Geobasisdaten durchführt und damit qualitativ hochwertige Koordinaten liefert, ist der Geokodierungsdienst der AdV.

3.4.4 Geodatenkomponenten

Hierunter werden Komponenten verstanden, die der Speicherung und Verwaltung oder Aufbereitung von Geodaten dienen, aber keine direkten Geodatendienstekomponenten darstellen. Vertreter dieser Gruppe können z.B. spezifische Geoprozessierungsdienste (siehe Kapitel 6.5.2), wie Koordinatentransformationen oder Datenaggregationskomponenten sein.

3.4.5 Zugriffsschutzkomponenten

Der Großteil der Daten und Dienste in der GDI-DE steht allen Nutzern frei und unentgeltlich zur Verfügung. Dennoch gibt es Informationen oder Dienste, die aus unterschiedlichen Gründen vor unberechtigtem Zugriff geschützt werden müssen. Zum Schutz solcher Zugriffe werden Komponenten verwendet, die den Vorgaben in Kapitel 7 genügen.

3.4.6 Langzeitspeicherkomponenten

Für eine revisionssichere Aufbewahrung, Erhaltung und Wiedernutzbarmachung von älteren, nicht mehr regelmäßig verwendeten elektronischen Dokumenten/Geodaten werden Langzeitspeicherkomponenten verwendet. Nähere Ausführungen zu den Anforderungen finden sich in den Leitlinien für die Fortführung und die Langzeitspeicherung von Geoinformationen (AK Architektur, 2021).

3.5 Interaktionen zwischen nationalen und dezentralen Komponenten

Aus den definierten Grundsätzen der GDI-DE (Arbeitskreis Architektur der GDI-DE, 2019) lässt sich folgendes Hauptziel herleiten:
„Geodaten über Geodatendienste interoperabel verfügbar machen."
Für die Beschreibung der erforderlichen Interaktionen zwischen nationalen und dezentralen Komponenten wird zunächst der Kernprozess der GDI-DE sehr abstrakt in einem Anwendungsfalldiagramm beschrieben (vgl. Abbildung 16).

...

• alt – beschreibt eine Verzweigung zu einer von mehreren Varianten, wobei jede Verzweigung durch eine Bedingung – in eckigen Klammern – gekennzeichnet wird (Bsp. Abb. 18).
• opt – beschreibt eine optionale Ausführung des gekennzeichneten Bereichs, wenn die angegebene Bedingung wahr ist.
• loop – kennzeichnet eine Mehrfachausführung des gekennzeichneten Bereichs, solange die angegebene Bedingung wahr ist.

3.5.1 Bereitstellungsprozesse

3.5.1.1 Bereitstellung von Geodaten über Geodatendienste

Um Geodaten über Geodatendienste in der GDI-DE verfügbar zu machen, müssen zunächst die Geodaten veröffentlicht werden. Der Prozess wird in Abbildung 19 dargestellt und die einzelnen Schritte nachfolgend erläutert.

...

Die konformen Metadaten wurden zunächst in der dezentralen Metadatenkomponente veröffentlicht. Die Bereitstellung in der GDI-DE erfolgt nun über den Anschluss der dezentralen Metadatenkomponente an den Geodatenkatalog.de (vgl. 3.3.1.2).

3.5.1.2 Bereitstellung von Metadaten über Geodatenkatalog.de

Beteiligt sind ein dezentraler Metadatenkatalog, der Geodatenkatalog.de und die GDI-DE Testsuite.

...

D.h. für das INSPIRE-Monitoring werden nur Ressourcen erfasst, die mit Metadaten beschrieben und über den Geodatenkatalog.de zugänglich sind. Zudem werden nur Ressourcen im INSPIRE-Monitoring erfasst, deren Metadaten das Schlüsselwort "inspireidentifiziert" beinhalten.

3.5.2 Rechercheprozess

Der Rechercheprozess beschreibt, wie Nutzende, d. h. ein Mensch oder ein System, nach Geodaten in der GDI-DE suchen können.

...

Abbildung 21: Sequenzdiagramm „Geodaten suchen"

3.5.2.1 Aufbau des Metadaten-Index im Geoportal.de

Die Schritte 1 und 2 werden täglich durchgeführt.

...

Auf Basis der empfangenen Metadaten wird ein aktualisierter Suchindex für eine performante Geodatensuche im Geoportal.de erstellt. 

3.5.2.2 Recherche in Geoportal.de

Alternative Mensch: Der Nutzer ist ein Mensch (im Diagramm „alt [Nutzer==Mensch]").

...

Der Nutzer setzt seine Suchanfrage auf dem Geoportal.de ab und erhält eine Trefferliste. Der Index unterstützt eine schnelle Suche.

3.5.2.3 Recherche in Geodatenkatalog.de

Alternative System: Der Nutzer ist ein System (im Diagramm „alt [else if Nutzer==System]"). Es hat keinen Zugriff auf das Geoportal.de.

...

Das System setzt eine Suchanfrage auf dem Geodatenkatalog.de ab und erhält eine Trefferliste.

3.5.3 Einbindungsprozess

Dieser Prozess beschreibt grob, wie ein gefundener Datensatz ausgeliefert und eingebunden werden kann. Dabei wird beim Nutzenden zwischen Mensch und System unterschieden. Bei zugriffsgeschützten Geodatendiensten schließt sich eine Authentifizierung und Autorisierung vor der Auslieferung an. Ein möglicher Ablauf der Interaktion für zugriffsgeschützte Geodatendienste wird im „Konzept einer Zugriffskontrolle für die GDI-DE" (Kst. GDI-DE, 2009) beschrieben.

...

Die dezentrale Geodatendienstkomponente liefert die angefragten Daten an das IT-System des oder der Nutzenden aus.

4 Standards für Raumbezugssysteme

Ein Geodatendienst ist hinsichtlich des Raumbezugs zur GDI-DE konform, wenn die geometrische Kombinierbarkeit der bereitgestellten Geodaten aus Deutschland (GDI-DE) und Europa (INSPIRE) sichergestellt ist. Daher wird gefordert, dass Geodatendienste bei der Bereitstellung bestimmte Koordinatenreferenzsysteme mit ihren Projektionen unterstützen. Der Standard für den geodätischen Raumbezug in Deutschland ist das amtliche Bezugssystem. Dies ist aktuell das Europäische Terrestrische Referenzsystem 1989 (European Terrestrial Reference System – ETRS89) mit dem Abbildungssystem UTM (Universal Transverse Mercator) [Quelle: AdV-Beschluss TOP 4.4 der 96. Tagung 1995]. Zusätzliche weitere Koordinatenreferenzsysteme und Projektionen können gegebenenfalls durch Anwendungsprofile sowie sonstige fachliche oder regionale Festlegungen vorgeschrieben sein. Allgemein wird die Unterstützung zusätzlicher Koordinatenreferenzsysteme und Projektionen begrüßt, wie z. B. EPSG:4326 und EPSG:3857.

...

5 Standards für Geodaten und Metadaten

5.1 Interoperabilität

Die zentrale Aufgabe der GDI-DE ist es, Geodaten verschiedener Herkunft interoperabel verfügbar zu machen. Unter dem Begriff "Interoperabilität" wird nach § 3 Abs. 4 GeoZG die Kombinierbarkeit von Daten bzw. die Kombinierbarkeit und Interaktionsfähigkeit verschiedener Systeme und Techniken unter Einhaltung gemeinsamer Standards verstanden.

...

Tabelle 9: Kurzbeschreibung der Interoperabilitätselemente in der GDI-DE

5.2 Geodatenspezifikationen

Eine Geodatenspezifikation beschreibt die erforderlichen Informationen zu einem Geodatensatz, damit dieser von Anbietern konsistent bereitgestellt und vom Anwender verarbeitet werden kann, der Geodatensatz also als „interoperabel" gilt. Die Interoperabilitätselemente bieten einen Rahmen für die Erstellung von Geodatenspezifikationen in der GDI-DE.

...

Der in Kapitel 5.1 beschriebene Interoperabilitätsrahmen akzeptiert die vorhandene Vielfalt der Datenspezifikationen verschiedener Datenanbieter und -nutzer. Eine vollständige Harmonisierung der Geodatenspezifikationen ist nicht Ziel dieses Interoperabilitätsrahmens. Er greift jedoch die bei INSPIRE relevanten Aspekte auf, wie die grenzübergreifende Datenbereitstellung sowie die Integration in den IT-Mainstream und E-Government-Initiativen.

5.3 Datentransformation

In der Praxis werden Daten oft in verschiedenen Formaten angeboten, um unterschiedlichen Nutzeranforderungen gerecht zu werden. Aus Daten in einem bestimmten Quellformat werden die gewünschten Zielformate durch Transformation erzeugt. Je nach Zielformat ist der Aufwand für die Transformation unterschiedlich hoch.

...

Die Transformation der Geodatensätze kann beispielsweise durch Vorprozessierung bei einer geodatenhaltenden Stelle erfolgen. Die transformierten Daten können anschließend in einer sekundären Datenhaltung gespeichert und beispielsweise über einen INSPIRE-Downloaddienst bereitgestellt werden.

5.4 Datenformate

5.4.1 Formate für Geodaten

5.4.1.1 Formate für Vektordaten

Die Übertragung vektorbasierter räumlicher Daten erfolgt in einer Geodateninfrastruktur konform zur Geography Markup Language (GML). Der Hauptanwendungsbereich von GML betrifft Vektordaten, ab GML-Version 3 erfolgte eine Erweiterung, z. B. auf Coverages. Neben GML gewinnen aktuell die Formate GeoPackage und GeoJSON immer mehr an Bedeutung – beispielsweise im Kontext von APIs. Die Unterstützung dieser beiden Formate wird daher ausdrücklich empfohlen.

...

5.4.1.1 Formate für Rasterdaten

Rasterdaten sind mehrdimensionale raumbezogene Daten, die sich aus einzelnen, oft in Gitterform angeordneten Informationen, wie z. B. Messwerten, zusammensetzen. Typische Anwendungsbereiche sind die Meteorologie, die Photogrammetrie, die Fernerkundung, die thematische Kartographie oder auch die digitale Geländemodellierung. Je nach Fachgebiet kommen daher unterschiedliche Rasterdatenformate zum Einsatz, wie z. B. Hierarchical Data Format – Earth Observing System (HDF-EOS), Digital Terrain Elevation Data (DTED), National Imagery Transmission Format (NITF) oder Climate and Forecast Metadata Convention – Network Common Data Form (CF-NetCDF)

...

5.4.2 Formate für Metadaten

Um die Suche nach vorhandenen Geodatensätzen und -diensten sowie die Prüfung ihrer Eignung für einen bestimmten Anwendungszweck zu ermöglichen, sind Beschreibungen in Form von Metadaten erforderlich. Die konzeptionelle Grundlage der Metadatenformate für Geodatensätze und -dienste bilden die Normen ISO 19115 Geographic Information – Metadata und ISO 19119 Geographic Information – Services. Die Kodierung der Metadaten erfolgt anhand der ISO 19139 Geographic Information – XML Schema Implementation. Werden Geo-Metadaten in allgemeinen (Open) Data Portalen in Deutschland (z.B. Govdata.de) veröffentlicht, so muss dies konform zum vom IT-Planungsrat beschlossenen Standard DCAT-AP.de erfolgen. Die Konformität kann i.d.R. durch eine automatisierte Transformation der Metadaten aus den in der GDI-DE obligatorischen Standards sichergestellt werden.

...

5.4.3 Formate der Visualisierungsvorschriften für Geodaten

Die Standards Symbology Encoding (SE) und Styled Layer Descriptor (SLD) definieren XML-Formate für die Beschreibung von Visualisierungsvorschriften. Diese Formate kommen beim Einsatz von Darstellungsdiensten (vgl. Kapitel 6.3) zur Anwendung. Basierend auf der Version des eingesetzten Darstellungsdienstes ist der passende Standard auszuwählen.

...

5.4.4 Formate für eine Kartenzusammenstellung

Das OGC-Webdienst-Kontextdokument (OWS-Context) wurde erstellt, um zu ermöglichen, dass ein Satz konfigurierter Informationsressourcen (Dienstsatz) hauptsächlich als Sammlung von Diensten zwischen Anwendungen weitergegeben wird. Das Ziel dieses Standards ist es, ein Kernmodell bereitzustellen, das erweitert und kodiert wird, wie es in den Erweiterungen dieses Standards definiert ist. Ein „Kontextdokument" spezifiziert einen vollständig konfigurierten Dienstsatz, der (mit einer konsistenten Interpretation) zwischen Clients ausgetauscht werden kann, die den Standard unterstützen.

...

5.4.5 Formate für Anwendungsschemata

Anwendungsschemata dienen der strukturierten Beschreibung raumbezogener Daten für einen speziellen Anwendungsbereich mit Hilfe von GML. Dieses Schema beschreibt die Objekttypen, deren Daten präsentiert und die von der Anwendung verarbeitet werden sollen.

...

6 Standards für Geodatendienste

Die Bereitstellung von Geodaten oder Funktionen mit Raumbezug erfolgt innerhalb der GDI-DE grundsätzlich über Geodatendienste. Die Nutzbarkeit der Geodatendienste wird durch vereinbarte Schnittstellen, d. h. durch die Einhaltung von Standards oder Implementierungsspezifikationen, sichergestellt. Die Schnittstellen definieren das Kommunikationsformat und das Verhalten eines Geodatendienstes. Die mit diesem Geodatendienst kommunizierenden Client-Anwendungen (oder andere Dienste) müssen ihrerseits den Anforderungen an die Schnittstellen genügen.

...

Client-Anwendungen (oder andere Dienste) müssen abfragen können, ob ein angesprochener Dienst zur Verfügung steht und die geforderte Dienstqualität liefert. Grundsätzlich ist es Aufgabe der Dienstbetreiber, die von ihnen angebotenen Dienste zu überwachen. Den Vorgaben von INSPIRE entsprechend wird die Dienstqualität ohne das Netz gemessen. Die Handlungsempfehlungen der GDI-DE und die Technical Guidance-Dokumente zu den INSPIRE-Such-, - Darstellungs- und -Downloaddiensten geben Hinweise zur Messung der Dienstqualität. Die GDI-DE Testsuite bietet einen Test zur Messung der Dienstqualität nach den Empfehlungen der Technical Guidance-Dokumente (vgl. 3.3.2).

6.1 Kommunikationsprotokolle und -verfahren

Das OSI-Modell (Open Systems Interconnection Model) ist ein Referenzmodell und beschreibt in der ISO 7498-1 „Information Technology – Open Systems Interconnection – Basic Reference Model: The Basic Model" die Kommunikation zwischen Systemen. Um eine Nachricht auf Anwendungsebene über ein physikalisches Medium zu einem anderen System übertragen zu können, werden mehrere verschiedene Protokolle benötigt. Diese legen syntaktische Regeln, semantische Regeln und Formate fest, die das Kommunikationsverhalten bestimmen (vgl. ISO 7498-1 Kapitel 5.2.1.9). Da bei der Kommunikation unterschiedliche Anforderungen zu berücksichtigen sind, werden im OSI-Referenzmodell sieben Schichten definiert: die Bitübertragungsschicht, die Sicherungsschicht, die Transportschicht, die Netzwerkschicht, die Sitzungsschicht, die Präsentationsschicht und die Anwendungsschicht. Protokolle definieren die Kommunikation von einem Sender zu einem Empfänger auf der jeweiligen Kommunikationsschicht.

6.1.1 Hypertext Transfer Protocol

Das Hypertext Transfer Protocol (HTTP) ist ein generisches Kommunikationsprotokoll auf der Anwendungsebene (Sitzungsschicht, Präsentationsschicht und Anwendungsschicht), um Nachrichten zwischen verteilten, kollaborativen Informationssystemen auszutauschen. Es erlaubt verschiedensten Applikationen einen einfachen Zugang zu Ressourcen. Das Open Geospatial Consortium (OGC) schreibt für OGC Web Services HTTP als Distributed Client Platform (DCP) vor (vgl. OGC 06-121r9, dort Kapitel 7.4.6 und Tabelle 14, S. 32). Zur Wahrung der Schutzziele der Informationssicherheit muss bei Geodatendiensten die Nutzung von HTTPS erfolgen. Weitere Hinweise dazu finden sich in Kapitel 7.2.1.

6.1.2 Representational State Transfer

Representational State Transfer (REST) beschreibt eine einfache Zugriffsmethode auf Ressourcen, die das Hypertext Transfer Protocol (HTTP) und das Konzept Unified Ressource Identifier (URI) benutzt. Einige Eigenschaften von sog. „RESTful"-Diensten sind z. B. die direkte Adressierbarkeit über eine eindeutige Adresse (URL), die unterschiedliche Repräsentation von Ressourcen durch Content Negotiation oder auch die Zustandslosigkeit der Dienste. Für Daten, die frei zur Verfügung gestellt werden, eröffnet sich mit REST ein relativ einfacher Weg, sowohl auf der Anbieter- als auch auf der Nutzerseite.

6.2 Suchdienste

Suchdienste sind Geodatendienste, die es ermöglichen, „auf der Grundlage des Inhalts entsprechender Metadaten nach Geodaten und Geodatendiensten zu suchen …" (EU-Kommission, 2007).

...

6.3 Darstellungsdienste

Darstellungsdienste sind Geodatendienste, die es ermöglichen, darstellbare Geodaten anzuzeigen, in ihnen zu navigieren, ihre Darstellung zu vergrößern oder zu verkleinern, zu verschieben, Daten zu überlagern sowie Informationen aus Legenden und sonstige relevante Inhalte von Metadaten anzuzeigen (EU-Kommission, 2007).

6.3.1 Web Map Service

Ein Web Map Service (WMS) stellt Geodaten in Form von georeferenzierten Bilddaten in Raster- bzw. Vektorbildformaten dar, beispielsweise als Portable Network Graphics (PNG) oder Graphics Interchange Format (GIF) bzw. Scalable Vector Graphics (SVG). In einer Ausbaustufe des WMS können auch zu einer Bildkoordinate hinterlegte Sachinformationen abgefragt werden.

...

6.3.2 3D Portrayal Service

Der 3D Portrayal Service (3DPS) ist ein OGC Standard zur interoperablen 3D-Visualisierung. Ein 3D Portrayal Service liefert eine perspektivische dreidimensionale Ansicht in einem vorgegebenen geografischen Bereich. Der 3DPS beschreibt, wie Client und Server darüber verhandeln, welche Daten in welcher Form ausgeliefert werden. Der Nutzer kann entscheiden, ob die Daten je nach Kamerawinkel gestreamt oder die ganze Szene auf einmal ausgeliefert wird. Die Darstellung des 3D-Szenengrafen wird somit je nach Anwendungsfall optimiert Client- oder Serverseitig berechnet und visualisiert. Dadurch wird eine interoperable Darstellung von 3D-Geoinformationen ermöglicht. Eine API-basierte Implementierung ist mit OGC API - 3D GeoVolumes geplant.

...

6.4 Downloaddienste

Downloaddienste sind Dienste, mit denen Kopien von vollständigen Geodatensätzen oder Teilen solcher Sätze heruntergeladen werden können oder die gegebenenfalls den direkten Zugriff darauf ermöglichen (EU-Kommission, 2009). Ein Downloaddienst unterstützt entweder die vollständige Übertragung eines Geodatensatzes oder den Zugriff auf einzelne Objekte (Direktzugriffs-Download). Die heruntergeladenen Daten stehen dem oder der Nutzenden auf dem eigenen IT-System zur Verfügung und können weiter verarbeitet werden, wenn entsprechende Rechte gewährt wurden.

6.4.1 Web Feature Service

Mit einem Web Feature Service (WFS) wird ein webbasierter Zugriff auf vektorbasierte Objekte bzw. Sachdaten ermöglicht.

...

6.4.2 Downloaddienste für vordefinierte Datensätze

Downloaddienste für vordefinierte Datensätze bieten das Herunterladen von Datensätzen an, ohne weitere individuelle Abfrage- bzw. Auswahlmöglichkeit der Inhalte zu ermöglichen.

...

Vgl. Kapitel 6.4.1 Web Feature Service.

6.4.3 Downloaddienste basierend auf OGC API-Features

OGC API – Features (kurz: OAPIF) ist ein Standard der basierend auf der Open API-Spezifikation die Bereitstellung von Features im Web ermöglicht.

...

6.4.4 Downloaddienste basierend auf SensorThings API

SensorThings API (kurz: STA) ist eine vom OGC entwickelte Anwendungsprogrammierschnittstelle zum Management von Sensoren und Aktoren im Internet der Dinge (IoT). Die SensorThings API bietet hierbei eine offene, raumbezogene und einheitliche Möglichkeit zur Verbindung von IoT-Geräten, Daten und Anwendungen über das Internet.

...

6.4.5 Web Coverage Service

Der Web Coverage Service (WCS) dient der standardisierten Bereitstellung von georeferenzierten Rasterbilddaten sowie insbesondere von mehrdimensionalen Datenbeständen, sog. Coverages, die Phänomene mit räumlicher oder zeitlicher Variabilität repräsentieren. Dazu gehören beispielsweise Erdbeobachtungen, Temperaturverteilungen oder Höhenmodelle.

...

6.5 Weitere Geodatendienste

Weitere Geodatendienste über Such-, Darstellungs- und Downloaddienste hinaus sind u. a. Dienste zur geografischen Namenssuche, Dienste zur Transformation und Prozessierung von Geodaten.

6.5.1 Dienst zur geografischen Namenssuche (Gazetteer-Service)

Einen speziellen Anwendungsfall für den WFS bildet der Gazetteer-Service, welcher den Raumbezug zu geografischen Bezeichnern, z. B. Namen oder Adressen, liefert. Konzeptionelle Basis hierfür ist ISO 19112 Geographic information – Spatial referencing by geographic identifiers.

6.5.2 Prozessdienste

Prozessdienste sind Geodatendienste, die Bearbeitungsaufträge entgegennehmen und abarbeiten können. Ein Bearbeitungsauftrag besteht typischerweise aus einem Satz von Eingabedaten und Steuerparametern für die Bearbeitungsmethode. Die Ergebnisse werden je nach Prozessdienst und Aufwand entweder direkt zurückgeliefert (synchrone Bearbeitung) oder – bei zeitaufwändigen Prozessen – nach der Bearbeitung bereitgestellt (asynchrone Bearbeitung).

6.5.2.1 Koordinatentransformationsdienste

Grundsätzlich sollen für die GDI-DE eventuell erforderliche Koordinatentransformationen durch den Datenanbieter vorgenommen werden. Dies kann z. B. im Daten bereitstellenden Dienst erfolgen. Deshalb werden zurzeit für die GDI-DE keine eigenständigen Koordinatentransformationsdienste empfohlen. Parallel dazu werden die Nachfragesituation nach Koordinatentransformationsdiensten in Deutschland sowie die Entwicklungen bei INSPIRE beobachtet.

6.5.2.2 Modelltransformationsdienste

Modelltransformationsdienste dienen dazu, Datensätze von einem Datenmodell in ein anderes zu überführen. Das Thema wird in aktuellen Forschungsprojekten adressiert und steht in GDI-DE unter Beobachtung.

6.5.3 Dienst zur räumlichen Abfrage von RDF-Daten (GeoSPARQL)

Für die räumliche Abfrage von RDF-Daten wird die Schnittstelle GeoSPARQL verwendet. GeoSPARQL ist ein OGC Standard und definiert eine Ontologie zur Repräsentation von räumlichen Daten (z.B. Features, Geometrien, usw.) im Semantic Web. Außerdem erweitert es die Abfragesprache SPARQL um räumliche Abfragen und Funktionen (vgl. OGC, 2012).

...

7 Standards zur Absicherung von Geodaten und Geodatendiensten

Voraussetzung für eine nachhaltige und zuverlässige Nutzung von Geodaten ist eine geeignete Einbettung der verteilten GDI-Strukturkomponenten in bestehende IT-Sicherheitsarchitekturen.

Während im Bereich der Geodaten und Geodatendienste im Wesentlichen geospezifische Standards eine Rolle spielen, werden im Bereich der IT- und Informationssicherheit allgemeine IT-Standards eingesetzt. Hierzu gehören auch Standards und Normen für das Management von Informationssicherheitssystemen, wie die Standards des Bundesamtes für Sicherheit in der Informationstechnik, BSI- Standard 100-1 bis 100-3, und die Normen ISO 27001 und ISO 27002 (SAGA 5, 2011).

7.1 Sicherheitsanforderungen

Die charakteristischen Sicherheitsanforderungen, die für die Beschreibung einer Zugriffskontrolle relevant sind, werden für sog. „Open Systems" in ISO 10181 Open Systems Interconnection Model (kurz OSI-Referenzmodell) definiert:

...

Protokollierung dient der gezielten Speicherung von Aktivitäten eines Systems, um nachträglich festzustellen, ob ein System die definierten Schutzziele umsetzt oder ob bisher unbekannte Mängel aufgetreten sind. Die daraus resultierenden Informationen können verwendet werden, um ggf. definierte Sicherheitsrichtlinien anzupassen (vgl. ITU X.800).

7.2 Standards

7.2.1 Hypertext Transfer Protocol Secure

Sofortige Schutzmaßnahmen können für die gesicherte Übertragung von Daten und Passwörtern auf Basis des Hypertext Transfer Protocol (vgl. Kapitel 6.1.1) ergriffen werden. Die Verwendung dieser Spezifikation ist die Grundlage dafür, einen nachhaltigen Zugriffsschutz für OGC Web Services (OWS) zu implementieren. Für die Übertragung der Authentisierungsdaten gemäß HTTP Authentication wird ein HTTP Header verwendet. Das Verfahren wird derzeit von einer Vielzahl der am Markt verfügbaren Server- sowie Clientsoftware implementiert und stellt somit derzeit den gängigen Weg zur Absicherung von OWS dar. Es kommt dabei ohne Installation von spezieller Software bei den Nutzern aus. Um das Ausspähen von Authentifizierungsdaten und Passwörtern einzuschränken, muss eine sichere Übertragung über das verschlüsselte HTTP-Protokoll erfolgen (HTTPS, wie in RFC2817 und RFC2818 beschrieben). Dies gilt unabhängig davon, ob Authentifizierungsdaten übermittelt werden oder nicht. Die Verwendung von HTTPS stellt sicher, dass die Anforderungen an Vertraulichkeit, Integrität und Authentizität bei allen übertragenen Informationen erfüllt werden. Die entsprechendeSpezifikation für HTTP Authentication ist die Basic and Digest Access Authentication (siehe RFC2616 und RFC2617).

...

7.2.2 Security Assertion Markup Language

Die Security Assertion Markup Language (SAML) dient dem Austausch von Authentifizierungs- und Autorisierungsinformationen. Mit ihr können vertrauenswürdige Aussagen (Zusicherungen) über Eigenschaften von Entitäten ausgetauscht werden.

...

7.2.3 eXtensible Access Control Markup Language

Die eXtensible Access Control Markup Language (XACML) ist eine Sprache, um Zugriffsrechte zu deklarieren und durchzusetzen. Zudem ermöglicht XACML eine fach- und organisationsübergreifende Abstimmung von Zugriffsrechten.

...

7.2.4 Geospatial eXtensible Access Control Markup Language

Die Geospatial eXtensible Access Control Markup Language (GeoXACML) definiert geospezifische Erweiterungen für XACML, um Zugriffsrechte für Geodaten und Geodatendienste zu deklarieren und durchzusetzen (z. B. raumbezogene Filterung: Begrenzung auf Bounding-Boxes, thematische Filterung: nach Feature Types).

...

7.2.5 Web Service Security

Web Service Security (WS-S) beschreibt, wie in XML strukturierte Nachrichten, die mittels Simple Object Access Protocol (SOAP) übertragen werden, integer und vertraulich ausgetauscht werden können. Es bietet eine allgemeine Lösung, um Behauptungen wie Name, Identität, Schlüssel, etc. mit Nachrichteninhalten zu verbinden.

...

8 Verzeichnis der referenzierten Geostandards

Dieses Verzeichnis beinhaltet alle in "Architektur der GDI-DE - Technik, Version 4.0.1" referenzierten Standards. Es wird zur Übersicht geführt und findet sich zusätzlich im Wiki der GDI-DE unter:
https://wiki.gdi-de.org/display/Arch/Verzeichnis+GDI-DE+Standards

...

9 Literaturverzeichnis

AK Geodaten. (2023). Interoperabilitätskonzept für Geodaten in der GDI-DE. Von https://www.gdi-de.org/download/AG_Geodaten_Interoperabilitaetskonzept_Geodaten_GDI-DE.pdf abgerufen

...

Verwaltungsvereinbarung GDI-DE. (11. Dezember 2017). Vereinbarung zwischen dem Bund und den Ländern zum gemeinsamen Aufbau und Betrieb der Geodateninfrastruktur Deutschland.

Impressum

Das Werk einschließlich aller Inhalte ist urheberrechtlich geschützt.

...