Übersicht:
Favoritenliste:
Favoritenseiten
Ihre Favoritenliste enthält derzeit keine Seiten. Sie fügen dieser Liste Seiten hinzu, indem Sie im Menü Extras der angezeigten Seite Favorit selektieren. |
Version: 4.0.0 |
Bezeichnung | Architektur der GDI-DE – Technik |
Autor | Arbeitskreis Architektur |
Erstellt am | 02.02.2023 |
Bearbeitungsstand | ☐ In Bearbeitung |
☐ Vorgelegt | |
☒ Abgestimmt | |
Dokumentablage | Kollaborationsplattform GDI-DE |
Beteiligte | Lukas Fingerhut (Landesbetrieb Geoinformation und Vermessung Hamburg) |
Die Autorinnen und Autoren danken den vielen Personen und Institutionen, die am Entwicklungsprozess des Architekturkonzepts aktiv beteiligt waren. Anker
Version | Datum | Änderung | Autor |
0.1 | 28.03.2013 | Erstfassung des Dokumentes zur Abstimmung im AK Architektur | AK Architektur |
0.8 | 14.08.2013 | Einarbeitung der Kommentare aus informellen Review, alle Kapitel | AK Architektur |
0.13 | 20.11.2013 | Einarbeitung der Kommentare aus öffentlichem Review, alle Kapitel | AK Architektur |
3.0.0 | 25.11.2013 | Aufbereitung als Vorlage zur Beschlussfassung im LG GDI-DE | AK Architektur |
3.0.0 | 25.02.2014 | Beschluss im LG | Kst. GDI-DE |
3.1.0 beta | 10.10.2014 | Aufbereitung als Vorlage zur Beschlussfassung im LG GDI-DE | AK Architektur |
3.1.0 | 26.11.2014 | Beschluss im LG GDI-DE | Kst. GDI-DE |
3.2.0 beta | 23.10.2015 | Fortschreibung als Vorlage zur Beschlussfassung im LG GDI-DE | AK Architektur |
3.2.0 | 27.01.2016 | Beschluss Nr. 92 im LG GDI-DE | Vorsitz LG |
3.3.0 beta | 22.04.2016 | Änderungsvorschlag bzgl. Geokodierung | AK Architektur |
3.3.0 | 01.08.2016 | Beschluss Nr. 96 im LG GDI-DE | Vorsitz LG |
3.4.0 beta | 10.10.2018 | Anpassungsvorschlag bzgl. VV GDI-DE sowie Fortschreibung der Geostandards | AK Architektur |
3.4.0 | 10.01.2019 | Beschluss Nr. 119 im LG GDI-DE | Vorsitz LG |
3.4.1 | 01.10.2019 | Redaktionelle Änderungen | AK Architektur |
4.0.0 alpha | 10.08.2021 | Vorlage zur Weiterentwicklung der Architektur der GDI-DE - Technik, Version 4.0 | AK Architektur |
4.0.0 beta | 12.12.2022 | Vorlage Architektur der GDI-DE - Technik, Version 4.0 zur Beschlussfassung im LG GDI-DE | AK Architektur |
4.0.0 | 02.02.2023 | Beschluss Nr. 159 im LG GDI-DE | Vorsitz LG |
...
...
Inhalt |
---|
...
...
...
3DPS | 3D Portrayal Service |
AAA | AFIS- |
...
ALKIS-ATKIS-Anwendungsschema für Geobasisdaten |
...
AAI | Authentifizierungs- und Autorisierungsinfrastruktur |
AdV |
...
Arbeitsgemeinschaft der Vermessungsverwaltungen der Länder der |
...
Bundesrepublik Deutschland |
...
AF | Anwendungsfall |
AFIS | Amtliches Festpunktinformationssystem |
AK | Arbeitskreis |
ALKIS | Amtliches Liegenschaftskatasterinformationssystem |
API | Application Program Interface |
ATKIS | Amtliches Topographisch-Kartographisches Informationssystem |
...
CEN | Comité européen de normalisation (European Committee for Standardization; |
...
Europäisches Komitee für Normung) |
...
CRS | Coordinate Reference System |
...
CSW | Catalogue Service |
...
DCP | Distributed Client Platform |
...
EG | Europäische Gemeinschaft |
...
EPSG | European Petroleum Standards Group |
...
ETRS89 | European Terrestrial Reference System (1989) |
ETRS89/ |
...
LAEA | European Terrestrial Reference System (1989)-Lambert Azimuthal Equal Area |
ETRS89/ |
...
LCC | European Terrestrial Reference System (1989)/Lambert Conformal Conic |
ETRS89/ |
...
TM | European Terrestrial Reference System (1989)/Transverse Mercator |
...
EVRF | Europäisches Vertikales Referenzsystem |
GDI- |
...
DE | Geodateninfrastruktur Deutschland |
GEOSS |
...
Global Earth Observation System of Systems |
...
GeoXACML | Geospatial eXtensible Access Control Markup Language |
GeoZG |
...
Gesetz über den Zugang zu digitalen Geodaten (Geodatenzugangsgesetz) |
...
GIS | Geoinformationssystem |
GIF | Graphics Interchange Format |
GML |
...
Geography Markup Language |
...
GSDI | Global Spatial Data Infrastructure |
GUI |
...
Graphic User Interface |
...
HTTP | Hypertext Transfer Protocol |
...
HTTPS | Hypertext Transfer Protocol Secure |
...
IDMVU | Infrastruktur-Daten-Management für Verkehrsunternehmen mit Schieneninfrastruktur |
...
IdP |
...
Identity-Provider |
IETF |
...
Internet Engineering Task Force |
...
INSPIRE | Infrastructure for Spatial Information in the European Community |
IOC- |
...
TF | Initial Operating Capability – Task Force |
...
IoT | Internet of Things |
...
ISO | International Organization for Standardization (Internationale Organisation |
...
für Normung) |
ISO/ |
...
TS | International Organization for Standardization/Technische Spezifikation |
...
JRC | Joint Research Centre |
...
JSON | JavaScript Object Notation |
...
KML | Keyhole Markup Language |
Kst. | Koordinierungsstelle |
...
LEFIS | Landentwicklungs-Fachinformationssystem |
LG | Lenkungsgremium |
...
NTK |
...
Nationale Technische Komponenten |
O& |
...
M | Observation and Measurement |
OAI- |
...
PMH | Open Archives Initiative Protocol for Metadata Harvesting |
...
OAPIF | OGC API - Features |
...
OASIS | Organization for the Advancement of Structured Information Standards |
OGC |
...
Open Geospatial Consortium |
...
OKSTRA | Objektkatalog für das Straßen- und Verkehrswesen |
...
OSI | Open Systems Interconnection Model / OSI-Referenzmodell |
OWS |
...
OGC Web Services |
...
PNG | Portable Network Graphics |
RDF |
...
Resource Description Framework |
...
REST | Representational State Transfer |
...
SAGA | Standards und Architekturen für E-Government-Anwendungen |
SAML |
...
Security Assertion Markup Language |
...
SE | Symbology Encoding |
SLD |
...
Styled Layer Descriptor |
...
SOA | Service-oriented Architecture |
...
SOAP | Simple Object Access Protocol |
...
SPARQL | SPARQL Protocol And RDF Query Language. |
...
STA | SensorThings API |
...
TIFF | Tagged Image File Format |
...
TLS | Transport Layer Security |
...
URI | Uniform Resource Identifier |
...
UTM | Universal Transverse Mercator |
VV |
...
Verwaltungsvereinbarung |
WCS |
...
Web Coverage Service |
WFS |
...
Web Feature Service |
WFS- |
...
G | Web Feature Service – Gazetteer |
...
WGS84 | World Geodetic System (1984) |
WMC |
...
Web Map Context |
WMS |
...
Web Map Service |
WMTS |
...
Web Map Tile Service |
...
WNS | Web Notification Service |
...
WPS | Web Processing Service |
WS- |
...
S | Web Service Security |
XACML | eXtensible Access Control Markup Language |
XML | eXtensible Markup Language |
XSD | XML Schema Definition Language |
...
Die Architektur der GDI-DE ist eingebettet in die organisatorischen und regulatorischen Rahmen-bedingungen 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.
Die Architektur der GDI-DE steht dabei in Bezug zur Nationalen Geoinformations-Strategie (NGIS) und ist im Besonderen an den Zielen dieser in 2015 beschlossenen Grundsatzstrategie ausgerichtet. Der IT-Planungsrat hatte im gleichen Jahr die NGIS „als wichtige Ergänzung der Nationalen E-Government-Strategie (NEGS)" angesehen und in seinen beiden Beschlüssen für die NGIS ihre „grundlegende Bedeutung für föderale IT- und E-Government-Infrastrukturen" herausgestellt und die „Umsetzung der NGIS insgesamt unterstützt".
Hinzu kommt, dass die Architektur der GDI-DE, Version 4.0 aufgrund der aktuellen Entwicklungen technisch einem gewissen Paradigmenwechsel in der Standardisierung des World Wide Web Consortium (W3C) und Open Geospatial Consortium (OGC) folgt bzw. folgen wird. Wichtige Ziele sind dabei die Vereinfachung des Zugriffs auf verteilte Geodaten, sowie die einfachere Integrierbarkeit in beliebige Webanwendungen und Prozesse. Dazu gehört insbesondere der Standard OGC API-Features. Die neue API-zentrierte Baseline der OGC Standards setzt dabei auf aktuelle technische Konzepte und bietet dadurch einen besseren Zugang zu den Nachbardomänen der GDI-DE. Die Umsetzung solcher Vorgaben besitzt zudem den Effekt, dass die GDI-DE technisch am aktuellen Stand orientiert ist und eine Öffnung zu Nachbardomänen ohne GDI-DE-Fachwissen relativ einfach ermöglicht wird, ohne dabei die Geo-IT-Domäne bei den Regelungen zu verlassen.
Hinzu kommt die Fragestellung, wie die Herausforderungen der Qualitätssicherung und des Monitorings in der GDI-DE und für INSPIRE in geeigneter Weise technisch unterstützt werden können. Hierzu wurde in der Architektur der GDI-DE, Version 4.0 ein Qualitätssicherungstool, der sog. GDI-DE Monitor eingeführt, für den gemäß den GDI-Kontaktstellen ein großer Bedarf besteht und den bisherigen Monitoring-Client der GDI-DE Registry ersetzt. Weitere Komponenten der Architektur, wie das Geoportal.de sollen zukünftig als Plattform weiterentwickelt sowie „Langzeitspeicherkomponenten" als Dezentrale Technische Komponenten der GDI-DE eingeführt werden.
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. Anker
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 Anker
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. Anker
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. Anker
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).
Abbildung 2: Notationselemente in einem Zustandsdiagramm
Der Ablauf der Klassifikation lässt sich gut mit einem UML Zustandsdiagramm verdeutlichen. Abbildung 2 erläutert kurz die wichtigsten Merkmale in einem Zustandsdiagramm.
Jedes Zustandsdiagramm beginnt mit genau einem definierten Startzustand (gefüllter Kreis). Die folgenden, möglichen Zustände werden als abgerundete Rechtecke symbolisiert. Ein Wechsel von einem Zustand zu einem anderen Zustand erfolgt über Transitionen (Pfeile), die über Ereignisse ausgelöst werden. Dabei kann ein Zustandsübergang auch auf den gleichen Zustand zurückführen. Bei zusammengesetzten Zuständen (komplexen Zuständen) kann der aktuelle Zwischenzustand beim Verlassen gespeichert werden. Bei Wiedereintritt in den komplexen Zustand wird an der zuvor verlassenen Stelle fortgesetzt. Diese „Merk-Funktion" wird durch den Historien-Zustand (History- Zustand in der Abbildung 2) gekennzeichnet.
Im Zustandsdiagramm in Abbildung 3 wird dargestellt, welche Klassifizierungszustände ein Standard im Rahmen der Fortschreibung der Architektur einnehmen kann. So kann ein neuer Standard in der Architektur der GDI-DE initial nur „unter Beobachtung", „optional" oder „grundlegend" eingestuft werden. Bei einer Neubewertung der Geostandards kann eine Änderung der Klassifizierung nur entlang der definierten Zustandsübergänge stattfinden, also kann beispielsweise ein „grundlegender" Standard nur als „auslaufend" oder wieder als „grundlegend" klassifiziert werden.
Abbildung 3: Klassifikation der Standards
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. Anker
...
...
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 Anker
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:
...
Anhand des Suchergebnisses kann der Anwender (Consumer) die gefundenen Ressourcen (zum Beispiel Geodaten bzw. Geodatendienste) des Anbieters (Provider) ansprechen und entsprechend der bereitgestellten Funktionalität und unter Berücksichtigung definierter Nutzungsbedingungen verwenden (bind).
Abbildung 5: Allgemeines Publish-Find-Bind-Muster
Die Übertragung des Publish-Find-Bind-Musters auf die Architektur der GDI-DE wird in Abbildung 6 schematisch dargestellt. Eine wesentliche Rolle spielen die dezentralen Suchdienste sowie der gemeinsame zentrale Suchdienst Geodatenkatalog.de (vgl. Kapitel 3.3), in dem der gemeinsame Suchdatenbestand aufgebaut wird.
Abbildung 6: Publish-Find-Bind-Muster – übertragen auf die Architektur der GDI-DE Anker
...
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, 2022) 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 7: Zusammenhang zwischen Geodaten mit Daten-Metadaten, Geodatendiensten mit Dienst-Metadaten und Capabilities, die direkt über den entsprechenden Dienst abgefragt werden können
Aus Sicht eines Geodatensatzes ist i.d.R. nicht erkennbar, über welche Geodatendienste er bereitgestellt wird. Daher wird gemäß (AK Metadaten, 2022) die Suche auf die Dienst-Metadatensätze erweitert und in diesen nach dem Vorkommen des Identifikators des Geodatensatzes gesucht. Über die GetCapabilities-URL bzw. die URL zum Service Feed (Atom) im Dienst-Metadatensatz ergibt sich die Referenz auf den Dienst (vgl. Abbildung 8).
Abbildung 8: Kopplung der Geodaten und Geodatendienste über Identifikatoren und Hyperlinks Anker
...
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. Anker
Die GDI-DE ist modular aus definierten nationalen und dezentralen IT-Komponenten aufgebaut, die in bestimmter Art und Weise miteinander interagieren:
...
Derzeit sind fünf NTK vom LG GDI-DE beschlossen, Tabelle 1:
Nationale Technische Komponenten der GDI-DE | Kurzbeschreibung | Status (2023) |
---|---|---|
Zentraler Suchdienst nach Geodaten und Geodatendiensten in Deutschland | Betrieb | |
GDI-DE Testsuite https://testsuite.gdi-de.org/gdi/![]() | Anwendung zur Überprüfung der Konformität von Metadaten, Geodaten und Geodatendiensten hinsichtlich der Vorgaben von INSPIRE und GDI-DE | Betrieb |
Geoportal.de https://www.geoportal.de/![]() | Plattform (früher: Anwendung), um Fachwissen in der Öffentlichkeit transparent zu machen, und um das Funktionieren der Konzepte und Empfehlungen der GDI-DE aufzuzeigen („Schaufenster" der GDI-DE) | Betrieb |
GDI-DE Registry https://registry.gdi-de.org/![]() | Dienst zur zentralen Verwaltung von Informationen, die vielfach in der GDI-DE verwendet werden und deren Einheitlichkeit sicherzustellen ist | Betrieb |
GDI-DE Monitor https://monitor.gdi-de.org/![]() | Komponente zur Unterstützung der Qualitätsmonitorings und Auswertung von Metadaten hinsichtlich definierter Qualitätsparameter. | Betrieb |
Tabelle 1: Kurzbeschreibung und Status der NTK der GDI-DE
Die Entwicklung, Weiterentwicklung und der Betrieb der Nationalen Technischen Komponenten der GDI-DE folgen den in der Verwaltungsvereinbarung zwischen Bund und Ländern zum gemeinsamen Ausbau und Betrieb der Geodateninfrastruktur Deutschland (Verwaltungsvereinbarung GDI-DE, 2017) getroffenen Festlegungen. Hingegen stehen die Entwicklung und Betrieb der Dezentralen Technischen Komponenten unter der Verantwortung einzelner Stellen bei Bundes-, Landes- oder Kommunalbehörden bzw. privater Unternehmen. Festlegungen der einzelnen Vereinbarungspartner der VV GDI-DE 2017 sind dort zu berücksichtigen. Eine nähere Beschreibung der Nationalen Technischen Komponenten der GDI-DE findet sich in diesem Technik-Dokument in Kapitel 3.3. In Tabelle 2 werden die häufigsten Arten von Dezentralen Technischen Komponenten (siehe Kapitel 3.4) anhand ihrer Funktionen klassifiziert:
Dezentrale Technische Komponenten der GDI-DE | Kurzbeschreibung |
---|---|
Metadatenkomponenten | Bündelung aller Funktionen, die der Erfassung, Speicherung und Verwaltung von Metadaten sowie ihrer Bereitstellung über eine standardisierte Suchdienstschnittstelle dienen |
Geodatendienstkomponenten | Bündelung aller Funktionen, die der Bereitstellung von Raster- oder Vektordaten über standardisierte Schnittstellen dienen. Dazu gehören insbesondere Darstellungs-, Download- und Geoprozessierungsdienste |
Geokodierungskomponenten | Dienen der Zuordnung von Koordinaten zu Fachobjekten in einem räumlichen Bezugssystem. Es wird unterschieden zwischen einer einfachen Ortssuche („Gazetteer"), der dauerhaften Zuordnung von Koordinaten zu Fachobjekten („Geokodierung") und der Ermittlung von Fachdaten aus Koordinaten („Reverse Geokodierung"). |
Zugriffsschutzkomponenten | Bündelung aller Funktionen, die dem Schutz vor unberechtigtem Zugriff auf Geodaten oder Geodatendienste sowie der Authentifizierung und Autorisierung bei berechtigtem Zugriff dienen |
Langzeitspeicherkomponenten | Komponenten, die eine revisionssichere Aufbewahrung, Erhaltung und Wiedernutzbarmachung von älteren, nicht mehr regelmäßig verwendeten elektronischen Dokumenten/Geodaten ermöglichen. |
Tabelle 2: Klassifizierung dezentraler Komponenten der GDI-DE
Über die genannten Dezentralen Technischen Komponenten hinaus gibt es in den dezentralen Geodateninfrastrukturen weitere Komponenten, insbesondere Geoportale von Ländern und Kommunen, Geoshops und andere Anwendungen.
Nationale und dezentrale Komponenten stehen in definierten Arten von Beziehungen zueinander, die sich vereinfacht wie folgt differenzieren lassen:
Beziehung | Beschreibung |
---|---|
Bereitstellen einer Schnittstelle | Eine Komponente der GDI-DE stellt Daten oder Funktionen über realisierte und standardisierte Schnittstellen bereit. |
Verwenden einer Schnittstelle | Eine Komponente der GDI-DE verwendet standardisierte Schnittstellen, die benötigt werden, um bestimmte Aufgabenstellungen zu erfüllen. |
Tabelle 3: Beschreibung der grundlegenden Arten von Beziehungen zwischen Komponenten der GDI-DE
Abbildung 10 beschreibt die verwendete Notation für die Darstellung der Beziehungen zwischen den beiden grundlegenden Komponentenarten der GDI-DE. In gleicher Weise wirken auch die Beziehungen zwischen zwei dezentralen oder zwei nationalen Komponenten.
Abbildung 10: Beziehungen zwischen einer nationalen und dezentralen Komponente
In den Kapiteln 3.3 bis 3.5 werden die Komponenten sowie die Beziehungen zwischen nationalen und dezentralen Komponenten näher beschrieben. Anker
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. Anker
...
...
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.
anchor
Abbildung 11: Komponentendiagramm Geodatenkatalog.de
Name der Schnittstelle | Art | Beschreibung | Standard |
---|---|---|---|
Metadaten einsammeln | benötigt | Metadaten dezentraler Metadatenkomponenten werden über mehrere „Catalogue Service"-Schnittstellen (CSW) eingesammelt | vgl. Kapitel 5.4.2 und 6.2 |
Metadaten anbieten | stellt bereit | Anwendungen und Dienste können über „Catalogue Service"-Schnittstellen (CSW) im Gesamtmetadatenbestand suchen | vgl. Kapitel 5.4.2 und 6.2 |
Tabelle 4: Schnittstellen des Geodatenkatalog.de Anker
...
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) Anker
...
...
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. Anker
Abbildung 12: Komponentendiagramm GDI-DE Testsuite
...
_Hlk115168809 | Name der Schnittstelle | Art | Beschreibung | Standard |
---|---|---|---|---|
Konformitätstest anbieten | stellt bereit | Anwendern, Anwendungen und Diensten wird zur Testdurchführung eine Nutzerschnittstelle (GUI) bzw. ein Application Program Interface (API) als Web Service bereitgestellt | vgl. Kapitel 6.1 | |
Geodatendienst testen | benötigt | Client-Schnittstelle zu Geodatendienstkomponenten | vgl. Kapitel 6.3.1, | |
Metadaten testen | benötigt | Client-Schnittstelle zu Metadatenkomponenten (Metadatenformate und Suchdienste) | vgl. Kapitel 5.4.2 | |
Geodaten testen | benötigt | Lesen von Geodatenformaten (noch nicht realisiert) | vgl. Kapitel 5.2 |
Tabelle 5: Schnittstellen der GDI-DE Testsuite Anker
...
Verfügbarkeit: 95 %
Zugriffszeit am Server: 3 Sekunden
Leistungsfähigkeit: 20 parallele Zugriffe pro Sekunde Anker
...
...
...
...
Abbildung 13: Komponentendiagramm Geoportal.de
Name der Schnittstelle | Art | Beschreibung | Standard |
---|---|---|---|
Metadaten | benötigt | Geoportal.de greift über die Schnittstelle | Metadaten |
Geodaten einbinden | benötigt | Geodaten über Geodatendienste (z. B. Darstellungsdienste) im Geoportal.de einbinden | vgl. Kapitel 6.3, 6.4, u. a. |
Geoportal.de anbieten | stellt bereit | Nutzerschnittstelle (GUI) | vgl. Kapitel 6.1 |
...
...
Verfügbarkeit: 99 %
Zugriffszeit am Server: 10 Sekunden
Leistungsfähigkeit: 20 parallele Zugriffe pro Sekunde
anchor
...
...
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.
anchor
Abbildung 14: Komponentendiagramm GDI-DE Registry
Name der Schnittstelle | Art | Beschreibung | Standard |
---|---|---|---|
Registerinhalt pflegen | stellt bereit | Nutzerschnittstelle (GUI) zur Pflege der Inhalte | vgl. Kapitel 6.1 |
Registerinhalt anbieten | stellt bereit | Inhalte werden über persistente URLs identifiziert | vgl. Kapitel 6.1 |
Tabelle 7: Schnittstellen der GDI-DE Registry _Toc117236646 Anker
...
Verfügbarkeit: 99 %
Zugriffszeit am Server: 3 Sekunden
Leistungsfähigkeit: 30 parallele Zugriffe pro Sekunde
anchor
...
...
...
...
Abbildung 15: Komponentendiagramm GDI-DE Monitor
Name der Schnittstelle | Art | Beschreibung | Standard |
---|---|---|---|
GDI-DE Monitor anbieten | stellt bereit | Nutzerschnittstelle (GUI) | vgl. Kapitel 6.1 |
Tests ausführen | benötigt | Konformitätstest werden über die GDI-DE Testsuite ausgeführt (RestAPI) | vgl. Kapitel 6.1 |
Metadaten | benötigt | Metadaten werden über den Geodatenkatalog.de eingebunden | vgl. Kapitel 5.4.2 und 6.2 |
Tabelle 8: Schnittstellen der GDI-DE Monitor Anker
...
Verfügbarkeit: 95 %
Zugriffszeit am Server: 3 Sekunden
Leistungsfähigkeit: 20 parallele Zugriffe pro Sekunde Anker
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. _Toc117236654 Anker
...
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).
anchor
...
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. Anker
...
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.
anchor
...
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. Anker
...
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. Anker
...
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). Anker
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).
Abbildung 16: Vereinfachte Darstellung von Kernprozess und Rollen in der GDI-DE
Der Kernprozess umfasst alle Tätigkeiten, die unmittelbar der Erreichung des oben genannten Hauptziels dienen. Diese Tätigkeiten werden aus dem in Abschnitt 3.1 beschriebenen Vorgehens- muster „Publish-Find-Bind" abgeleitet: Für Geodaten und Geodatendienste werden Metadaten erstellt und in einem Metadatenkatalog registriert, über einen Suchdienst gefunden sowie anschließend die Geodaten über einen Geodatendienst genutzt. Die Nutzung kann ggf. von der Zustimmung des Nutzers zu den veröffentlichten Nutzungsbedingungen abhängen. Die Tätigkeiten der Akteure werden in folgender Tabelle noch einmal kurz beschrieben:
Rolle | Beschreibung |
---|---|
Nutzer/in | Recherchiert und greift über Geodatendienste auf die in der GDI-DE verfügbaren Geodaten zu, um sie zu verwenden. |
Anbieter/in für die Nationalen Technischen Komponenten | Stellt die Abwicklung aller Prozesse der Nationalen Technischen Komponenten sicher sowie deren anforderungsgerechten Betrieb. Die Rolle kann auf mehrere verantwortliche Personen verteilt sein. |
Anbieter/in für die Dezentralen Technischen Komponenten | An der GDI-DE partizipieren viele Organisationen. Anbieter/innen für die dezentralen Komponenten einer Organisation muss die Abwicklung aller Prozesse der dezentralen Komponenten im Verantwortungsbereich sowie deren anforderungsgerechten Betrieb sicherstellen. Die Rolle kann auf mehrere verantwortliche Personen verteilt sein. |
Tabelle 9: Rollenbeschreibungen
Die Rollen für Anbieter/innen nationaler sowie dezentraler Komponenten können sich genauer spezialisieren, siehe Abbildung 17.
Abbildung 17: Spezialisierung nationaler und dezentraler Anbieterrollen
Nachfolgend werden die Interaktionen zwischen den Beteiligten sowie zwischen den Nationalen Technischen und den Dezentralen Technischen Komponenten im Hinblick auf das Erreichen des oben genannten Hauptziels detaillierter durch Soll-Prozesse in Form von Sequenzdiagrammen erläutert. Nachfolgende Abbildung 18 beschreibt die verwendete Notation.
Abbildung 18: UML Sequenzdiagramm zur Beschreibung von Interaktionen
Um alternative Abläufe zu kennzeichnen, werden verschiedene Operatoren eingesetzt. Diese Bereiche sind jeweils durch eine Box markiert. Folgende Operatoren können eingesetzt werden:
...
...
...
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.
Schritt 1 – Namensraum registrieren (optional)
Die INSPIRE-Richtlinie (EU-Kommission, 2007) fordert „einen gemeinsamen Rahmen für die einheitliche Identifizierung von Geo-Objekten, denen Identifikatoren aus den einzelstaatlichen Systemen zugeordnet werden können, um ihre Interoperabilität sicherzustellen" (Artikel 8, Abs. 2, Buchstabe a). Näheres regelt die Verordnung (EG) Nr. 1089/2010 der Kommission vom 23. November 2010 zur Durchführung der Richtlinie 2007/2/EG des Europäischen Parlaments und des Rates hinsichtlich der Interoperabilität von Geodatensätzen und -diensten (Anhang I, Ziffer 2.1) (EU-Kommission, 2010).
Um Objektidentifikatoren vergeben zu können, muss zuvor durch die jeweilige geodatenhaltende Stelle ein Namensraum beantragt und in die GDI-DE Registry eingetragen werden.
Schritt 2 – Geodaten speichern
Geodaten werden nach der Erfassung bzw. der Änderung durch die geodatenhaltende Stelle in einer dezentralen Geodatenkomponente gespeichert.
Schritt 3 – Geodaten auf Konformität testen
Die neu erfassten oder geänderten Geodaten werden von der geodatenhaltenden Stelle mit Hilfe der GDI-DE Testsuite auf Konformität geprüft. Bei negativem Testergebnis korrigiert die geodatenhaltende Stelle die Geodaten und wiederholt den Test. Nach bestandenem Test erfolgt die Freigabe der Geodaten durch die geodatenhaltende Stelle gemäß dem dort üblichen Verfahren.
Für die Konformitätsprüfung der Geodaten sind derzeit für die INSPIRE-Anhang Themen Tests in der GDI-DE Testsuite verfügbar.
Schritt 4 – Geodatendienst aufsetzen
Der Anbieter für die dezentralen Komponenten ist dafür verantwortlich mindestens einen Darstellungs- und einen Downloaddienst aufzusetzen, um die Geodaten darüber bereitzustellen.
Schritt 5 – Geodatendienst auf Konformität testen
Die aufgesetzten Geodatendienste werden mit Hilfe der GDI-DE Testsuite auf Konformität geprüft. Bei negativem Testergebnis korrigiert der Anbieter der dezentralen Komponenten die Geodatendienste und wiederholt den Test. Nach bestandenem Test erfolgt die Freigabe der Geodatendienste.
Schritt 6 – Metadaten speichern
Die Geodaten und die Geodatendienste sind vom dezentralen Anbieter mit Metadaten zu beschreiben. Dabei sollte ein möglichst hoher Anteil der Metainformationen aus den Geodaten und den Geodatendiensten automatisiert generiert werden. Die Nutzungsregelungen müssen in den Metadaten enthalten sein. Folgende Dokumente sind zu berücksichtigen:
...