Architektur der
Geodateninfrastruktur
Deutschland
Anker |
---|
| _Toc117236611 |
---|
| _Toc117236611 |
---|
|
h1.Architektur der GDI-DE – Technik Arbeitskreis Architektur der GDI-DEVersion: 4.0.0 Datum: 02.02.2023 Dieses Dokument gibt eine Übersicht über die technischen Aspekte der Architektur der Geodateninfrastruktur Deutschland (GDI-DE). Es verweist u. a. auf Normen, Standards und Spezifikationen sowie detaillierende Dokumente. Als Einführung in die grundlegenden Aspekte der Architektur der GDI-DE dient das Dokument Architektur der GDI-DE – Ziele und Grundlagen. |
Anker |
---|
| _Toc303949290 |
---|
| _Toc303949290 |
---|
|
Anker |
---|
| _Toc115190808 |
---|
| _Toc115190808 |
---|
|
Anker |
---|
| _Toc117236612 |
---|
| _Toc117236612 |
---|
|
DokumentinformationenBezeichnung | 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) Manuel Fischer (Betrieb GDI-DE, Bundesamt für Kartographie und Geodäsie) Nicole Heinrich (Senatsverwaltung für Stadtentwicklung und Wohnen Berlin) Dieter Heß (Ministerium für Landesentwicklung und Wohnen Baden-Württemberg) Tillmann Lübker (Landesvermessung und Geobasisinformation Brandenburg) Holger Meuel (Landesamt für Geoinformation und Landesvermessung Niedersachsen) Katrin Pinkert (Landesamt für Geoinformation und Landesvermessung Niedersachsen) Michael Riedel (Landesamt für Vermessung und Geoinformation Schleswig-Holstein) Burkhard Schlegel (Gst. GDI-NW, Bezirksregierung Köln) Markus Schaffert (Hochschule Mainz) Anja Schupp (Hessisches Landesamt für Bodenmanagement und Geoinformation) Markus Seifert (Gst. GDI-Bayern, Landesamt für Digitalisierung, Breitband und Vermessung) Mark Stscherbina (Informationszentrum Bund) René Wiesner (Ministerium für Infrastruktur und Digitales des Landes Sachsen-Anhalt) Falk Würriehausen (Kst. GDI-DE, Bundesamt für Kartographie und Geodäsie)
|
Die Autorinnen und Autoren danken den vielen Personen und Institutionen, die am Entwicklungsprozess des Architekturkonzepts aktiv beteiligt waren.
Anker |
---|
| _Toc115190809 |
---|
| _Toc115190809 |
---|
|
Anker |
---|
| _Toc117236613 |
---|
| _Toc117236613 |
---|
|
ÄnderungshistorieVersion | 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 |
Anker |
---|
| _Toc115190810 |
---|
| _Toc115190810 |
---|
|
Anker |
---|
| _Toc117236614 |
---|
| _Toc117236614 |
---|
|
Inhalt Dokumentinformationen Änderungshistorie Inhalt Abkürzungsverzeichnis Management Summary 1 Einführung 2 Klassifizierung der Geostandards 2.1 Klassifizierung 2.2 Lebenszyklus 3 Architektur der GDI-DE 3.1 Grundlagen der Architektur 3.1.1 Publish-Find-Bind-Muster 3.1.2 Kopplung der Metadaten von Geodaten und Geodatendiensten 3.1.3 Authentifizierungs- und Autorisierungsinfrastruktur 3.2 Modularer Aufbau der GDI-DE 3.3 Nationale Technische Komponenten 3.3.1 Geodatenkatalog.de 3.3.1.1 Zweck 3.3.1.2 Schnittstellen 3.3.1.3 Anforderungen 3.3.1.4 Qualitätsmerkmale 3.3.2 GDI-DE Testsuite 3.3.2.1 Zweck 3.3.2.2 Schnittstellen 3.3.2.3 Anforderungen 3.3.2.4 Qualitätsmerkmale 3.3.3 Geoportal.de 3.3.3.1 Zweck 3.3.3.2 Schnittstellen 3.3.3.3 Anforderungen 3.3.3.4 Qualitätsmerkmale 3.3.4 GDI-DE Registry 3.3.4.1 Zweck 3.3.4.2 Schnittstellen 3.3.4.3 Anforderungen 3.3.4.4 Qualitätsmerkmale 3.3.5 GDI-DE Monitor 3.3.5.1 Zweck 3.3.5.2 Schnittstellen 3.3.5.3 Anforderungen 3.3.5.4 Qualitätsmerkmale 3.4 Dezentrale Technische Komponenten 3.4.1 Metadatenkomponenten 3.4.2 Geodatendienstekomponenten 3.4.3 Geokodierungskomponenten 3.4.4 Geodatenkomponenten 3.4.5 Zugriffsschutzkomponenten 3.4.6 Langzeitspeicherkomponenten 3.5 Interaktionen zwischen nationalen und dezentralen Komponenten 3.5.1 Bereitstellungsprozesse 3.5.1.1 Bereitstellung von Geodaten über Geodatendienste 3.5.1.2 Bereitstellung von Metadaten über Geodatenkatalog.de 3.5.2 Rechercheprozess 3.5.2.1 Aufbau des Metadaten-Index im Geoportal.de 3.5.2.2 Recherche in Geoportal.de 3.5.2.3 Recherche in Geodatenkatalog.de 3.5.3 Einbindungsprozess 4 Standards für Raumbezugssysteme 5 Standards für Geodaten und Metadaten 5.1 Interoperabilität 5.2 Geodatenspezifikationen 5.3 Datentransformation 5.4 Datenformate 5.4.1 Formate für Geodaten 5.4.1.1 Formate für Vektordaten 5.4.1.1 Formate für Rasterdaten 5.4.2 Formate für Metadaten 5.4.3 Formate der Visualisierungsvorschriften für Geodaten 5.4.4 Formate für eine Kartenzusammenstellung 5.4.5 Formate für Anwendungsschemata 6 Standards für Geodatendienste 6.1 Kommunikationsprotokolle und -verfahren 6.1.1 Hypertext Transfer Protocol 6.1.2 Representational State Transfer 6.2 Suchdienste 6.3 Darstellungsdienste 6.3.1 Web Map Service 6.3.2 3D Portrayal Service 6.4 Downloaddienste 6.4.1 Web Feature Service 6.4.2 Downloaddienste für vordefinierte Datensätze 6.4.3 Downloaddienste basierend auf OGC API-Features 6.4.4 Downloaddienste basierend auf SensorThings API 6.4.5 Web Coverage Service 6.5 Weitere Geodatendienste 6.5.1 Dienst zur geografischen Namenssuche (Gazetteer-Service) 6.5.2 Prozessdienste 6.5.3 Dienst zur räumlichen Abfrage von RDF-Daten (GeoSPARQL) 7 Standards zur Absicherung von Geodaten und Geodatendiensten 7.1 Sicherheitsanforderungen 7.2 Standards 7.2.1 Hypertext Transfer Protocol Secure 7.2.2 Security Assertion Markup Language 7.2.3 eXtensible Access Control Markup Language 7.2.4 Geospatial eXtensible Access Control Markup Language 7.2.5 Web Service Security 8 Verzeichnis der referenzierten Geostandards 9 Literaturverzeichnis Impressum Anker |
---|
| _Toc117236615 |
---|
| _Toc117236615 |
---|
|
Abkürzungsverzeichnis 3DPS3D Portrayal Service AAAAFIS-ALKIS-ATKIS-Anwendungsschema für Geobasisdaten AAIAuthentifizierungs- und Autorisierungsinfrastruktur AdVArbeitsgemeinschaft der Vermessungsverwaltungen der Länder der Bundesrepublik Deutschland AFAnwendungsfall AFISAmtliches Festpunktinformationssystem AKArbeitskreis ALKISAmtliches Liegenschaftskatasterinformationssystem APIApplication Program Interface ATKISAmtliches Topographisch-Kartographisches Informationssystem CENComité européen de normalisation (European Committee for Standardization; Europäisches Komitee für Normung) CRSCoordinate Reference System CSWCatalogue Service DCPDistributed Client Platform EGEuropäische Gemeinschaft EPSGEuropean Petroleum Standards Group ETRS89European Terrestrial Reference System (1989) ETRS89/LAEAEuropean Terrestrial Reference System (1989)-Lambert Azimuthal Equal Area ETRS89/LCCEuropean Terrestrial Reference System (1989)/Lambert Conformal Conic ETRS89/TMEuropean Terrestrial Reference System (1989)/Transverse Mercator EVRFEuropäisches Vertikales Referenzsystem GDI-DEGeodateninfrastruktur Deutschland GEOSSGlobal Earth Observation System of Systems GeoXACMLGeospatial eXtensible Access Control Markup Language GeoZGGesetz über den Zugang zu digitalen Geodaten (Geodatenzugangsgesetz) GISGeoinformationssystem GIFGraphics Interchange Format GMLGeography Markup Language GSDIGlobal Spatial Data Infrastructure GUIGraphic User Interface HTTPHypertext Transfer Protocol HTTPSHypertext Transfer Protocol Secure IDMVUInfrastruktur-Daten-Management für Verkehrsunternehmen mit Schieneninfrastruktur IdPIdentity-Provider IETFInternet Engineering Task Force INSPIREInfrastructure for Spatial Information in the European Community IOC-TFInitial Operating Capability – Task Force IoTInternet of Things ISOInternational Organization for Standardization (Internationale Organisation für Normung) ISO/TSInternational Organization for Standardization/Technische Spezifikation JRCJoint Research Centre JSONJavaScript Object Notation KMLKeyhole Markup Language Kst.Koordinierungsstelle LEFISLandentwicklungs-Fachinformationssystem LGLenkungsgremium NTKNationale Technische Komponenten O&MObservation and Measurement OAI-PMHOpen Archives Initiative Protocol for Metadata Harvesting OAPIFOGC API - Features OASISOrganization for the Advancement of Structured Information Standards OGCOpen Geospatial Consortium OKSTRAObjektkatalog für das Straßen- und Verkehrswesen OSIOpen Systems Interconnection Model / OSI-Referenzmodell OWSOGC Web Services PNGPortable Network Graphics RDFResource Description Framework RESTRepresentational State Transfer SAGAStandards und Architekturen für E-Government-Anwendungen SAMLSecurity Assertion Markup Language SESymbology Encoding SLDStyled Layer Descriptor SOAService-oriented Architecture SOAPSimple Object Access Protocol SPARQLSPARQL Protocol And RDF Query Language. STASensorThings API TIFFTagged Image File Format TLSTransport Layer Security URIUniform Resource Identifier UTMUniversal Transverse Mercator VVVerwaltungsvereinbarung WCSWeb Coverage Service WFSWeb Feature Service WFS-GWeb Feature Service – Gazetteer WGS84World Geodetic System (1984) WMCWeb Map Context WMSWeb Map Service WMTSWeb Map Tile Service WNSWeb Notification Service WPSWeb Processing Service WS-SWeb Service Security XACMLeXtensible Access Control Markup Language XMLeXtensible Markup Language XSDXML Schema Definition Language Anker |
---|
| _Toc115190811 |
---|
| _Toc115190811 |
---|
|
Anker |
---|
| _Toc115190812 |
---|
| _Toc115190812 |
---|
|
Anker |
---|
| _Toc117236616 |
---|
| _Toc117236616 |
---|
|
Management Summary 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 |
---|
| _Toc115190813 |
---|
| _Toc115190813 |
---|
|
Anker |
---|
| _Toc117236617 |
---|
| _Toc117236617 |
---|
|
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).
Image Added Abbildung 1: Architekturkonzept der GDI-DE – Übersicht über die Architekturdokumente Anker |
---|
| _Toc115190814 |
---|
| _Toc115190814 |
---|
|
Anker |
---|
| _Toc117236618 |
---|
| _Toc117236618 |
---|
|
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:- sie auf gesicherten Erkenntnissen von Wissenschaft, Technik und Erfahrung basieren,
- sie veröffentlicht sind,
- ihre praktische Eignung als gesichert erscheinen und
- sie wirtschaftlich realisierbar sind.
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 |
---|
| _Toc117236619 |
---|
| _Toc117236619 |
---|
|
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. Anker |
---|
| _Toc117236620 |
---|
| _Toc117236620 |
---|
|
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).
Image Added 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.
Image Added 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 |
---|
| _Toc115190815 |
---|
| _Toc115190815 |
---|
|
Anker |
---|
| _Toc117236621 |
---|
| _Toc117236621 |
---|
|
3 Architektur der GDI-DE Anker |
---|
| _Toc117236622 |
---|
| _Toc117236622 |
---|
|
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.
Image Added Abbildung 4: Schematische Darstellung der Architektur der GDI-DE Anker |
---|
| _Toc117236623 |
---|
| _Toc117236623 |
---|
|
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:- Geodaten, Geodatendienste oder andere Ressourcen werden vom Anbieter (Provider) bereitgestellt und mit Metadaten beschrieben. Durch den Eintrag der Metadaten in einem Katalog werden sie veröffentlicht (publish). Darüber hinaus können Ressourcen veröffentlicht werden, indem die Metadaten direkt in die zu veröffentlichenden Dienste-Capabilities aufgenommen werden, so dass sie von Suchmaschinen indiziert werden können.
- Nach der Veröffentlichung sind die Ressourcen für den Anwender (Consumer) recherchierbar: Der Anwender durchsucht den Katalog nach Beschreibungen von Ressourcen (z. B. Geodaten oder Geodatendiensten) und bekommt vom Katalog ein Suchergebnis zurückgeliefert (find). Sind die Metadaten von einer Suchmaschine indiziert worden, so können sie zusätzlich über diese Suchmaschine gefunden werden.
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).
Image Added
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.
Image Added
Abbildung 6: Publish-Find-Bind-Muster – übertragen auf die Architektur der GDI-DE
Anker |
---|
| _Toc117236624 |
---|
| _Toc117236624 |
---|
|
3.1.2Kopplung 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, 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).
Image Added 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).
Image Added Abbildung 8: Kopplung der Geodaten und Geodatendienste über Identifikatoren und Hyperlinks Anker |
---|
| _Toc117236625 |
---|
| _Toc117236625 |
---|
|
3.1.3Authentifizierungs- 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).
Image Added 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 |
---|
| _Toc117236626 |
---|
| _Toc117236626 |
---|
|
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: - Als Nationale Technische Komponenten der GDI-DE werden Komponenten verstanden, die innerhalb der GDI-DE nur einmal und an zentraler Stelle im BKG betrieben werden, während
- Dezentrale Technische Komponenten der GDI-DE innerhalb der GDI-DE mit gleichen oder vergleichbaren Funktionen mehrmals und an verschiedenen Stellen betrieben werden.
Derzeit sind fünf NTK vom LG GDI-DE beschlossen, Tabelle 1:
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.
Image Added
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 |
---|
| _Toc115190816 |
---|
| _Toc115190816 |
---|
|
Anker |
---|
| _Toc117236627 |
---|
| _Toc117236627 |
---|
|
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. Anker |
---|
| _Toc117236628 |
---|
| _Toc117236628 |
---|
|
3.3.1Geodatenkatalog.de Anker |
---|
| _Toc117236629 |
---|
| _Toc117236629 |
---|
|
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. Anker |
---|
| _Toc117236630 |
---|
| _Toc117236630 |
---|
|
3.3.1.2 Schnittstellen
Image Added Abbildung 11: Komponentendiagramm Geodatenkatalog.deName 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 |
---|
| _Toc117236631 |
---|
| _Toc117236631 |
---|
|
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)
Anker |
---|
| _Toc117236632 |
---|
| _Toc117236632 |
---|
|
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) Anker |
---|
| _Toc117236633 |
---|
| _Toc117236633 |
---|
|
3.3.2GDI-DE Testsuite Anker |
---|
| _Toc117236634 |
---|
| _Toc117236634 |
---|
|
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. Anker |
---|
| _Toc117236635 |
---|
| _Toc117236635 |
---|
|
3.3.2.2 Schnittstellen
Image Added Abbildung 12: Komponentendiagramm GDI-DE Testsuite Anker |
---|
| _Hlk115168809 |
---|
| _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 |
---|
| _Toc117236636 |
---|
| _Toc117236636 |
---|
|
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)
Anker |
---|
| _Toc117236637 |
---|
| _Toc117236637 |
---|
|
3.3.2.4 Qualitätsmerkmale Verfügbarkeit: 95 % Zugriffszeit am Server: 3 Sekunden Leistungsfähigkeit: 20 parallele Zugriffe pro Sekunde Anker |
---|
| _Toc117236638 |
---|
| _Toc117236638 |
---|
|
3.3.3Geoportal.de Anker |
---|
| _Toc117236639 |
---|
| _Toc117236639 |
---|
|
3.3.3.1 Zweck Anker |
---|
| _Hlk115168154 |
---|
| _Hlk115168154 |
---|
|
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). Anker |
---|
| _Toc117236640 |
---|
| _Toc117236640 |
---|
|
3.3.3.2 Schnittstellen
Image Added Abbildung 13: Komponentendiagramm Geoportal.de Name der Schnittstelle | Art | Beschreibung | Standard |
Metadaten verwenden | benötigt | Geoportal.de greift über die Schnittstelle | Metadaten verwenden |
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 |
Tabelle 6: Schnittstellen des Geoportal.de
Anker |
---|
| _Toc117236641 |
---|
| _Toc117236641 |
---|
|
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
Anker |
---|
| _Toc117236642 |
---|
| _Toc117236642 |
---|
|
3.3.3.4 Qualitätsmerkmale Verfügbarkeit: 99 % Zugriffszeit am Server: 10 Sekunden Leistungsfähigkeit: 20 parallele Zugriffe pro Sekunde Anker |
---|
| _Toc117236643 |
---|
| _Toc117236643 |
---|
|
3.3.4GDI-DE Registry Anker |
---|
| _Toc117236644 |
---|
| _Toc117236644 |
---|
|
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. Anker |
---|
| _Toc117236645 |
---|
| _Toc117236645 |
---|
|
3.3.4.2 Schnittstellen
Image Added Abbildung 14: Komponentendiagramm GDI-DE RegistryName 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
Anker |
---|
| _Toc117236646 |
---|
| _Toc117236646 |
---|
|
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
Anker |
---|
| _Toc117236647 |
---|
| _Toc117236647 |
---|
|
3.3.4.4 Qualitätsmerkmale Verfügbarkeit: 99 % Zugriffszeit am Server: 3 Sekunden Leistungsfähigkeit: 30 parallele Zugriffe pro Sekunde Anker |
---|
| _Toc117236648 |
---|
| _Toc117236648 |
---|
|
3.3.5GDI-DE Monitor Anker |
---|
| _Toc117236649 |
---|
| _Toc117236649 |
---|
|
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. Anker |
---|
| _Toc117236650 |
---|
| _Toc117236650 |
---|
|
3.3.5.2 Schnittstellen
Image Added Abbildung 15: Komponentendiagramm GDI-DE MonitorName 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 verwenden | 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 |
---|
| _Toc117236651 |
---|
| _Toc117236651 |
---|
|
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)
Anker |
---|
| _Toc117236652 |
---|
| _Toc117236652 |
---|
|
3.3.5.4 Qualitätsmerkmale Verfügbarkeit: 95 % Zugriffszeit am Server: 3 Sekunden Leistungsfähigkeit: 20 parallele Zugriffe pro Sekunde Anker |
---|
| _Toc117236653 |
---|
| _Toc117236653 |
---|
|
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. Anker |
---|
| _Toc117236654 |
---|
| _Toc117236654 |
---|
|
3.4.1Metadatenkomponenten 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). Anker |
---|
| _Toc117236655 |
---|
| _Toc117236655 |
---|
|
3.4.2Geodatendienstekomponenten 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 |
---|
| _Toc117236656 |
---|
| _Toc117236656 |
---|
|
3.4.3Geokodierungskomponenten 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. Anker |
---|
| _Toc117236657 |
---|
| _Toc117236657 |
---|
|
3.4.4Geodatenkomponenten 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 |
---|
| _Toc117236658 |
---|
| _Toc117236658 |
---|
|
3.4.5Zugriffsschutzkomponenten 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 |
---|
| _Toc117236659 |
---|
| _Toc117236659 |
---|
|
3.4.6Langzeitspeicherkomponenten 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 |
---|
| _Toc117236660 |
---|
| _Toc117236660 |
---|
|
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).
Image Added 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.
Image Added
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.
Image Added
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:
- 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.
Anker |
---|
| _Toc117236661 |
---|
| _Toc117236661 |
---|
|
3.5.1Bereitstellungsprozesse Anker |
---|
| _Toc117236662 |
---|
| _Toc117236662 |
---|
|
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. 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:- Konventionen zu Metadaten in der GDI-DE (AK Metadaten, 2022)
- Qualitativ hochwertige Metadaten pflegen und verarbeiten (AK Metadaten, 2018)
Wiki-Markup |
---|
*Schritt 7 – Metadaten auf Konformität testen*
Die erstellten Metadaten werden vom dezentralen Anbieter mit Hilfe der GDI-DE Testsuite auf Konformität geprüft. Bei negativem Testergebnis werden Korrekturen an den Metadaten vorgenommen und der Test wird erneut durchgeführt.
!worddav6897b51a3a2da55f58a86105d699a1a4.png|height=859,width=560!
<span style="color: #9d9d9d"><strong>Abbildung 19: Sequenzdiagramm „Geodaten bereitstellen"</strong></span>
\\
*Schritt 8 – Zugriffsrechte festlegen (optional)*
Falls Funktionen eines Geodatendienstes oder Inhalte von Geodaten geschützt werden sollen, sind die Regeln für den Zugriff auf die Geodaten bzw. den Geodatendienst vom dezentralen Anbieter festzulegen.
*Schritt 9 – Route zu Downloaddienst registrieren (optional)*
Der Verantwortliche für die dezentrale Komponente kann bei Bedarf die Geoobjekte über eine persistente URL eindeutig identifizierbar machen, indem für den Namensraum eine entsprechende Route in der GDI-DE Registry eingetragen wird.
*Schritt 10 – Metadaten über Geodatenkatalog.de veröffentlichen*
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).
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="563c5f68-7cef-4cb8-bd97-6d74bce705ff"><ac:parameter ac:name="">_Toc117236663</ac:parameter></ac:structured-macro>{*}3.5.1.2* *Bereitstellung von Metadaten über Geodatenkatalog.de*
Beteiligt sind ein dezentraler Metadatenkatalog, der Geodatenkatalog.de und die GDI-DE Testsuite.
*Schritt 1 – Metadatenkomponente auf Konformität testen*
Die dezentrale Metadatenkomponente wird mit Hilfe der GDI-DE Testsuite auf ihre Konformität geprüft und kontinuierlich überwacht. Bei negativem Testergebnis werden Korrekturen vorgenommen und der Test wird erneut durchgeführt.
Hinweis: Alle nachfolgenden Schritte werden nur durchlaufen, wenn zuvor der Test der Metadatenkomponente bestanden wurde (im Diagramm illustriert als „alt \[Testergebnis==bestanden\]").
*Schritt 2 – Abrufintervall der Metadaten festlegen*
Der Verantwortliche für die dezentrale Metadatenkomponente legt zusammen mit dem Verantwortlichen für den Geodatenkatalog.de das Intervall zum Abrufen der Metadatensätze fest.
Der Verantwortliche für den Geodatenkatalog.de registriert die dezentrale Metadatenkomponente mit dem vereinbarten Abrufintervall im Geodatenkatalog.de.
!worddave2f7bb277fd746cde6318556f3b4b3bd.png|height=495,width=562!
<span style="color: #9d9d9d"><strong>Abbildung 20: Sequenzdiagramm „Metadaten zentral bereitstellen"</strong></span>
Hinweis: Der nachfolgende Schritt wird iterativ immer wieder durchlaufen, sobald das vereinbarte Zeitintervall erreicht ist (im Diagramm illustriert als „loop (Zeitpunkt==\[Abrufintervall\])").
*Schritt 3 – Metadatenabfrage starten und Metadaten übermitteln*
Die Komponente Geodatenkatalog.de ruft alle Metadaten der dezentralen Metadatenkomponente ab. Die dezentrale Metadatenkomponente liefert die angeforderten Metadaten an den Geodatenkatalog.de.
Bei dem automatisierten INSPIRE-Monitoring werden alle erforderlichen Informationen aus den Metadaten abgeleitet. Die Übermittlung der Metadaten für das INSPIRE-Monitoring erfolgt in Deutschland zentral über den Geodatenkatalog.de
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.
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="c4d4e851-0b42-470c-ab05-f788cd0ce5db"><ac:parameter ac:name="">_Toc117236664</ac:parameter></ac:structured-macro> \\
*3.5.2Rechercheprozess*
!worddav03034e0bf89f3a80d71710dd77225520.png|height=595,width=592! Der Rechercheprozess beschreibt, wie Nutzende, d. h. ein Mensch oder ein System, nach Geodaten in der GDI-DE suchen können.
<span style="color: #9d9d9d"><strong>Abbildung 21: Sequenzdiagramm „Geodaten suchen"</strong></span>
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="b0124bc2-4fa8-4fd6-991f-19c9cc05c9e9"><ac:parameter ac:name="">_Toc117236665</ac:parameter></ac:structured-macro>{*}3.5.2.1* *Aufbau des Metadaten-Index im Geoportal.de*
Die Schritte 1 und 2 werden täglich durchgeführt.
*Schritt 1 – alle Metadaten abfragen*
Geoportal.de fordert einmal täglich alle Metadateneinträge des Geodatenkatalog.de an. Die Metadaten werden an das Geoportal.de übermittelt.
*Schritt 2 – Suchindex erstellen*
Auf Basis der empfangenen Metadaten wird ein aktualisierter Suchindex für eine performante Geodatensuche im Geoportal.de erstellt.
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="280bbd56-dcad-418b-b7db-705a4aebf3b8"><ac:parameter ac:name="">_Toc117236666</ac:parameter></ac:structured-macro>{*}3.5.2.2* *Recherche in Geoportal.de*
Alternative Mensch: Der Nutzer ist ein Mensch (im Diagramm „alt \[Nutzer==Mensch\]").
*Schritt 3a – Suchbegriff absenden*
Der Nutzer setzt seine Suchanfrage auf dem Geoportal.de ab und erhält eine Trefferliste. Der Index unterstützt eine schnelle Suche.
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="3e625797-65c1-4bdd-bf3c-35f1da10d4d5"><ac:parameter ac:name="">_Toc117236667</ac:parameter></ac:structured-macro>{*}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.
*Schritt 3b – Suchanfrage absenden*
Das System setzt eine Suchanfrage auf dem Geodatenkatalog.de ab und erhält eine Trefferliste.
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="cd95e7bd-ff42-45f6-a2a3-f445f4251d53"><ac:parameter ac:name="">_Toc117236668</ac:parameter></ac:structured-macro>{*}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.
!worddavc573affbce29031b2ef72b70c51b66de.png|height=437,width=581!
<span style="color: #9d9d9d"><strong>Abbildung 22: Sequenzdiagramm „Geodaten einbinden"</strong></span>
<span style="color: #c00000"><strong>Alternative Nutzung durch Mensch:</strong></span>
*Schritt 1a – gefundenen Datensatz aufrufen*
Der oder die Nutzende wählt aus einer Trefferliste seinen Datensatz aus und ruft ihn im Geoportal.de auf.
*Schritt 2a – Geodatendienst anfragen*
Das Geoportal.de stellt eine Anfrage an die dezentrale Geodatendienstkomponente. Bei zugriffs- geschützten Geodatendiensten kann sich ein Authentifizierungs- und Autorisierungszyklus anschließen.
*Schritt 3a – Geodaten ausliefern*
Die dezentrale Geodatendienstkomponente liefert die angefragten Daten über das Geoportal.de direkt an den Nutzer aus.
<span style="color: #c00000"><strong>Alternative Nutzung durch System:</strong></span>
*Schritt 1b – Geodatendienst aufrufen*
Der oder die Nutzende ermittelt über die Daten-Dienste-Kopplung in den Metadaten die Geodatendienste, die die gesuchten Geodaten bereitstellen (in Abbildung 22 nicht dargestellt). Über eine Anfrage an die dezentrale Geodatendienstkomponente können die Geodaten bezogen werden. Bei zugriffsgeschützten Geodatendiensten kann sich ein Authentifizierungs- und Autorisierungszyklus anschließen.
*Schritt 2b – Geodaten ausliefern*
Die dezentrale Geodatendienstkomponente liefert die angefragten Daten an das IT-System des oder der Nutzenden aus.
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="be7fd1b9-f8f6-43e7-b55b-84f26a0b9744"><ac:parameter ac:name="">_Toc115190817</ac:parameter></ac:structured-macro><ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="216867fe-ce67-418b-ab00-7ab54962d242"><ac:parameter ac:name="">_Toc117236669</ac:parameter></ac:structured-macro><span style="color: #bd181d"><strong>4</strong></span> <span style="color: #bd181d"><strong>Standards für Raumbezugssysteme</strong></span>
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.
Die geforderten Koordinatenreferenzsysteme und Projektionen (s.u.) sollen von den Geodatendiensten so unterstützt werden, dass Anfragen und Antworten in den Koordinaten- referenzsystemen und Projektionen der anfragenden Anwendung erfolgen können, auch wenn die Daten intern in einem anderen Koordinatenreferenzsystem oder in einer anderen Projektion gespeichert sind. Gleichwohl ist es nicht erforderlich, dass ein System sämtliche geforderten Koordinatenreferenzsysteme und Projektionen unterstützt. Für die interne Datenspeicherung beim Dienstbereitsteller werden keine Koordinatenreferenzsysteme oder Projektionen vorgeschrieben, der Geodatendienst muss aber intern die jeweils erforderlichen Transformationen in die angebotenen Koordinatenreferenzsysteme unterstützen.
Für alle in der Architektur geforderten Koordinatenreferenzsysteme wird einheitlich das europäische geodätische Datum ETRS89 verwendet (Europäisches Terrestrisches Referenzsystem 1989). Für globale Anwendungen der Architektur (z.B. Positionierungsdiensten) soll das World Geodetic System 1984 (WGS84) unterstützt werden.
\\
*Festlegungen für Koordinatenreferenzsysteme und Projektionen* |
Anker |
---|
| _Hlk115173214 |
---|
| _Hlk115173214 |
---|
| INSPIRE-grundlegend und GDI-DE-grundlegend Standard für zweidimensionale Koordinatenreferenzsysteme: Darstellungsdienste im Sinne von INSPIRE müssen in der Lage sein, folgendes geodätisches Koordinatenreferenzsystem zu unterstützen:
|
GDI-DE-optional Zusätzliche weitere Koordinatenreferenzsysteme und Projektionen: Als zusätzliche weitere Koordinatenreferenzsysteme und Projektionen sollen je nach Anwendungsfall unterstützt werden:
- WGS84/geographisch 2D (EPSG: 4326) –
http://www.opengis.net/def/crs/epsg/0/4326
- WGS84/geographisch 3D (EPSG: 4979) –
http://www.opengis.net/def/crs/epsg/0/4979
- WGS84/Pseudo-Mercator (EPSG: 3857) –
http://www.opengis.net/def/crs/epsg/0/3857 Hinweis: Einzelheiten zu den zu unterstützenden Referenzsystemen bei Datensätzen, Darstellungs- und Downloaddiensten regeln die jeweiligen Anwendungsprofile der GDI-DE. Bereitstellung von Definitionen und Parametern von Koordinatenreferenzsystemen oder Projektionen: Zur Bereitstellung von Definitionen und Parametern der Koordinatenreferenzsysteme oder Projektionen soll OGC-GML Version 3.2 oder höher als Format verwendet werden. Die Bereitstellung der Definitionen und Parameter soll über die GDI-DE Registry erfolgen.
|
Anker |
---|
| _Toc115190818 |
---|
| _Toc115190818 |
---|
|
Anker |
---|
| _Toc117236670 |
---|
| _Toc117236670 |
---|
|
5 Standards für Geodaten und Metadaten Anker |
---|
| _Toc117236671 |
---|
| _Toc117236671 |
---|
|
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. Die INSPIRE-Richtlinie und die INSPIRE-Durchführungsbestimmungen enthalten konkrete Vorgaben zur Interoperabilität und, wenn durchführbar, zur Harmonisierung von Geodaten, Metadaten und Geodatendiensten. INSPIRE-Datenmodelle konzentrieren sich dabei primär auf zweidimensionale Daten. Es gibt vielversprechende Verfahren, zwei- und dreidimensionale Geodaten miteinander zu verschneiden, kombiniert darzustellen oder auszuwerten. Auch hier gelten die Anforderungen der Interoperabilität. Um Geodaten gemäß INSPIRE themen-, maßstabs- und länderübergreifend interoperabel verfügbar machen zu können, wurde für INSPIRE ein sog. Interoperabilitätsrahmen entwickelt. Dieser identifiziert, welche Aspekte für die Interoperabilität und ggf. auch bei der Harmonisierung von Geodaten in INSPIRE betrachtet werden müssen, legt Anforderungskriterien fest und gibt Empfehlungen. Die einzelnen Aspekte, auch Interoperabilitätselemente genannt, können grundsätzlich für die GDI-DE übernommen werden. Die in Tóth et al. (2012) genannten Punkte werden im Interoperabilitätskonzept (AK Geodaten, 2022) auf die interoperable Bereitstellung von Geodaten in der GDI-DE übertragen. Für die einzelnen Elemente können innerhalb der GDI-DE Vorgaben oder Empfehlungen gemacht werden.Interoperabilitätselement | Kurzbeschreibung |
Organisatorische Anforderungen | Zusammenstellung der grundlegenden Anforderungen für die Bereitstellung von Geodaten in der GDI |
Referenzmodell | Angaben zu relevanten Standards und wie diese genutzt werden |
Nutzung Nationaler Technischer Komponenten der GDI-DE | Angaben zum Zusammenhang zwischen den Geodaten und den Nationalen Technischen Komponenten der GDI-DE |
Terminologie | Wesentliche Begriffe und deren Definition |
Mehrsprachigkeit | Angaben zur Unterstützung für die mehrsprachige Bereitstellung und Verarbeitung von Geodaten |
Nutzung von Ontologien | Angaben, ob und wie Ontologien genutzt werden, um semantische Unterschiede zu überbrücken |
CRS, Maßeinheiten | Angaben zu Referenzsystemen für die Georeferenzierung von Objekten und zu verwendeten Maßeinheiten |
Objektreferenzierung | Angaben, ob und wie indirekte Georeferenzierung von Objekten unterstützt wird |
Registry | Angaben, welche Informationen in Registern (d. h. nach wohldefinierten Abläufen mit wohldefinierten Rollen und Verantwortlichkeiten) und in welchen Registries geführt werden; Informationen in Registern werden in aller Regel nie gelöscht, da sie aus existierenden Daten referenziert werden.
|
Räumliche und zeitliche Modellierung | Angaben, wie räumliche und zeitliche Sachverhalte in Objekten beschrieben werden; dies umfasst auch Festlegungen zu den verschiedenen Repräsentierungen als Vektordaten, Coverages (z. B. Rasterdaten) oder Beobachtungen/Messungen |
Regeln für Anwendungs-schema | Regeln für die Bildung und Beschreibung von Datenmodellen der Geodaten |
Verwendung fachübergreifender Modellelemente | Angaben, wie mit übergreifend genutzten Modellelementen umgegangen wird |
Verwaltung und Bereitstellung von Schemadateien | Angaben, wie abgestimmte Datenmodelle und Schemata für den Datenaustausch verwaltet und veröffentlicht werden
|
Umgang mit Maßstäben | Angaben, wie mit unterschiedlichen Maßstäben umgegangen wird |
Modellerweiterungen (Leitfäden) | Angaben, wie Datenspezifikationen erweitert werden können, ohne die Interoperabilität zu verlieren |
Identifikatormanagement | Angaben, ob und wie Dinge in der realen Welt und Objekte dauerhaft identifiziert werden können |
Datenqualität (auch Aktualität) | Angaben zur Datenqualität einschließlich der Qualitätsmaße wie Aktualität |
Metadaten (auch fachspezifisch) | Angaben, wie und welche Metadaten zu Objekten und Datensätzen geführt werden – auch fachspezifisch |
Konformität | Angaben, welche Konformitätsklassen für Geodaten existieren und wie diese geprüft werden können |
Erfassungskriterien und Datenpflege | Erfassungsregeln für Geodaten und Regeln zur Datenpflege (Aktualität, Informationen über Datenänderungen) |
Modelltransformation (auch Ableitung von Produkten) | Anleitung, wie Daten aus der Datenhaltung in die festgelegten Austauschformate transformiert werden – auch Ableitung von Produkten |
Präsentation | Darstellung der Geodaten in Karten |
Datenkonsistenz (auch an der Ländergrenze) | Angaben zur Konsistenz von Daten – auch an der Landesgrenze |
Tabelle 9: Kurzbeschreibung der Interoperabilitätselemente in der GDI-DE
Anker |
---|
| _Toc117236672 |
---|
| _Toc117236672 |
---|
|
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. In der Praxis kann sich das Fehlen von explizit dokumentierten Geodatenspezifikationen negativ auf die Interoperabilität dieser Geodaten auswirken. Sofern zum Beispiel nicht bestimmt werden kann, in welchem Koordinatenreferenzsystem Geometrien gespeichert sind, können diese Geodaten nicht zusammen mit anderen Geodaten präsentiert oder analysiert werden. Für INSPIRE-Geodaten liegen bereits Geodatenspezifikationen vor. INSPIRE-GeodatenspezifikationenINSPIRE-grundlegend Geodatensätze, die unter die INSPIRE-Richtlinie fallen, sind unter Einhaltung der in Art. 7 Abs. 3 der INSPIRE-Richtlinie (EU-Kommission, 2007) genannten Fristen konform zur Verordnung (EG) Nr. 1089/2010 zur Interoperabilität (EU-Kommission, 2010) unter Beachtung der schon veröffentlichten und künftigen Ergänzungen (Amendments) und der einschlägigen Teile der Verordnung zu Metadaten (EU-Kommission, 2008) bereitzustellen. Hinweis: Nicht alle Geodatenspezifikationen in den INSPIRE-Vorgaben („Technical Guidance") sind verpflichtend anzuwenden. Deshalb ist im Einzelfall zu prüfen, ob und ggf. welche Teile davon für die Mitgliedstaaten als verpflichtend gelten. Angaben (z. B. Attribute) in den INSPIRE-Vorgaben („Technical Guidance"), die nicht in der Verordnung (EG) Nr. 1089/2010 enthalten sind, sind als GDI- DE-unter-Beobachtung anzusehen. |
Wiki-Markup |
---|
In Deutschland sind in weiteren Geodatenspezifikationen Anwendungsschemata und Datenformate zu bestimmten Zwecken standardisiert worden und im Gebrauch. Eine nicht abschließende Übersicht hierzu wird im GDI-DE Wiki geführt. Es wird empfohlen, für die Bereitstellung von Geodaten soweit möglich auf die im Wiki beschriebenen Anwendungsschemata und Datenformate zurückzugreifen, sofern die Geodatensätze nicht unter die INSPIRE-Richtlinie fallen oder die Daten zusätzlich zur INSPIRE-konformen Bereitstellung in weiteren Repräsentationen angeboten werden sollen. Ferner wird empfohlen, die o. g. Anwendungsschemata in der GDI-DE Registry zu registrieren.
Für die Entwicklung neuer Geodatenspezifikationen innerhalb der GDI-DE wird grundsätzlich empfohlen, auf der Grundlage der Normenserie ISO 19100 aufzusetzen. Gründe und Beispiele hierfür sind insbesondere:
In der INSPIRE-Richtlinie wird die besondere Rolle der internationalen Standards herausgestellt (Erwägungsgründe 16 und 28 der Richtlinie).
Die Normen der ISO 19100-Serie wurden in einem weltweiten Konsensprozess erstellt und sind weithin bei Datenanbietern, Nutzern und Herstellern akzeptiert.
Viele fachspezifische Anwendungsschemata folgen schon jetzt diesem Ansatz, beispielsweise das Landentwicklungs-Fachinformationssystem (LEFIS), das Infrastruktur-Daten-Management für Verkehrsunternehmen mit Schieneninfrastruktur (IDMVU-Datenmodell) und der Objektkatalog für das Straßen- und Verkehrswesen (OKSTRA).
Das AFIS-ALKIS-ATKIS-Anwendungsschema (AAA-Anwendungsschema) für Geobasisdaten basiert ebenfalls auf der Normenserie ISO 19100.
Die konsequente Anwendung der ISO-Standards wird in einer Reihe von internationalen Leitfäden zum Aufbau von Geodateninfrastrukturen empfohlen, z. B. in CEN/TR 15449 oder GSDI \[2004\].
Die ISO-basierte Modellierung ist unabhängig von Implementierungen und flexibel im Hinblick auf künftige Anforderungen (z. B. der Datenabgabe im Kontext des „Linked Data"- Ansatzes unter Verwendung des Resource Description Framework, RDF).
Der in Kapitel [5.1|_bookmark43] 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.
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="223d3a8d-f786-4e00-89c5-36ed8a2510c6"><ac:parameter ac:name="">_Toc117236673</ac:parameter></ac:structured-macro>{*}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.
Wenn Quell- und Zielformat der Daten auf dem gleichen Anwendungsschema basieren, muss i. d. R. nur eine Formatkonvertierung durchgeführt werden. Dabei werden die Daten anhand festgelegter Regeln in das Zielformat überführt (syntaktische Transformation). Ein Beispiel hierfür ist die Transformation eines Shapefile in eine GML-Datei.
Wenn sich die Anwendungsschemata der Quell- und Zieldaten nach Inhalt, Struktur und Bedeutung unterscheiden, wird zusätzlich zur syntaktischen auch eine semantische Transformation notwendig. In diesem Fall ist die genaue Kenntnis der Semantik sowie deren formale Beschreibung in beiden Anwendungsschemata erforderlich. Bei einer semantischen Transformation können auch Fälle auftreten, in denen aufgrund der Heterogenität der Schemata gar keine oder nur eine mit Ungenauigkeiten oder Verlusten behaftete Abbildung zwischen Elementen der Schemata definiert werden kann, was dazu führt, dass die Schemaabbildung nicht vollständig ist.
\\
*Ein Transformationsprozess umfasst üblicherweise zwei Hauptphasen:* |
- Definitionsphase (Schemaabbildung)
In dieser Phase wird eine Abbildung zwischen Quell- und Zielschema definiert. Dabei werden Korrespondenzen zwischen Elementen im Quell- und Zielschema ggf. unter Verwendung von Transformationsfunktionen (z. B. Datentypumwandlung) hergestellt und in Form von Abbildungsregeln beschrieben.
- Ausführungsphase (Datentransformation)
Unter Verwendung der Abbildungsregeln aus Phase 1 werden die Daten aus dem Quellformat in das dem Zielschema entsprechende Zielformat transformiert.
Eine Transformation kann offline unter Verwendung verschiedener Software-Werkzeuge oder dienstbasiert – ggf. auch „on-the-fly" – über ein Netzwerk geschehen.
Für Geodatensätze, die unter die INSPIRE-Richtlinie fallen, kann die Konformität zur Verordnung (EG) Nr. 1089/2010 entweder durch die Anpassung der bestehenden Geodatensätze oder durch den Einsatz von Transformationsdiensten erreicht werden.
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.
Anker |
---|
| _Toc117236674 |
---|
| _Toc117236674 |
---|
|
5.4 Datenformate Anker |
---|
| _Toc117236675 |
---|
| _Toc117236675 |
---|
|
5.4.1 Formate für Geodaten Anker |
---|
| _Toc117236676 |
---|
| _Toc117236676 |
---|
|
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. Standardformate für VektordatenINSPIRE-grundlegend und GDI-DE-grundlegend OGC Geography Markup Language (GML) Bei bestehenden Datenmodellen ist die jeweils im GML-Anwendungsschema als Basis genutzte Version der GML maßgebend. Für die Modellierung neuer Anwendungsschemata ist GML Version 3.3 heranzuziehen:
- OGC Geography Markup Language (GML) - Extended schemas and encoding rules, Version 3.3, Open Geospatial Consortium, 2012
Dieser Standard ist 2015 als ISO 19136-2 veröffentlicht worden. Erweiterung für Coverages
- OGC GML Application Schema – Coverages, Version 1.0.1, Open Geospatial Consortium, 2012,
Dieser Standard ist 2018 als ISO 19123-2 veröffentlicht worden. Hinweis: INSPIRE führt unter {+}http://inspire.ec.europa.eu/media-types+ Image Added eine Liste von Formaten von Vektor- und Rasterdaten, die in INSPIRE-Download-Diensten verwendet werden. GDI-DE-grundlegend Werden Vektordaten in den Formaten GeoPackage bzw. GeoJSON bereitgestellt, müssen folgende Standards unterstützt werden:
- OGC GeoPackage Encoding Standard, Version 1.3, 2021
- GeoJSON, RFC7946
Anker |
---|
| _Ref116548205 |
---|
| _Ref116548205 |
---|
| https://tools.ietf.org/html/rfc7946 Image Added , Internet Engineering Task Force (IETF), 2016
GDI-DE-optional Sollen Geodaten, die in der GDI-DE bereitgestellt werden, zusätzlich in interaktiven KML- verarbeitenden Betrachtern, als 3D-Stadtmodell oder 3D-Tiles im Web genutzt werden können, wird empfohlen, zusätzlich folgende Formate zu unterstützen:
- OGC City Geography Markup Language (CityGML) Part 1: Conceptual Model Standard, 2021
- OGC 3D Tiles Specification, Version 1.0, 2019
- OGC KML, Version 2.3, 2015
Hinweis: Aufgrund einiger Einschränkungen kann mit CityGML, den 3D Tiles und KML keine vollständige Konformität mit den Vorgaben für INSPIRE erreicht werden. Angesichts der weiten Verbreitung wurden diese Standards jedoch für die GDI-DE aufgenommen, um trotz Einschränkungen eine zusätzliche Option für Bereitstellung von Geodaten für diese Anwendungsfälle aufzuzeigen.
|
Anker |
---|
| _Toc117236677 |
---|
| _Toc117236677 |
---|
|
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) Standardformate für RasterdatenGDI-DE-grundlegend Für die fachunabhängige Bereitstellung von Rasterdaten sind folgende Formate zulässig:
- OGC GeoPackage Encoding Standard, Version 1.3, 2021
- GeoTIFF(Geo Tagged Image File Format)
GDI-DE-unter Beobachtung
- Cloud optimized GeoTIFF (COG)
Hinweis: Die Bereitstellung von Rasterdaten in weiteren Rasterdatenformaten – z. B. für spezielle Anwendungen – ist zusätzlich möglich. INSPIRE führt unter http://inspire.ec.europa.eu/media-types Image Added eine Liste von Formaten von Vektor- und Rasterdaten, die in INSPIRE-Download-Diensten verwendet werden.
|
Anker |
---|
| _Toc114850645 |
---|
| _Toc114850645 |
---|
|
Anker |
---|
| _Toc114858601 |
---|
| _Toc114858601 |
---|
|
Anker |
---|
| _Toc114850646 |
---|
| _Toc114850646 |
---|
|
Anker |
---|
| _Toc114858602 |
---|
| _Toc114858602 |
---|
|
Anker |
---|
| _Toc114850647 |
---|
| _Toc114850647 |
---|
|
Anker |
---|
| _Toc114858603 |
---|
| _Toc114858603 |
---|
|
Anker |
---|
| _Toc114850648 |
---|
| _Toc114850648 |
---|
|
Anker |
---|
| _Toc114858604 |
---|
| _Toc114858604 |
---|
|
Anker |
---|
| _Toc114850649 |
---|
| _Toc114850649 |
---|
|
Anker |
---|
| _Toc114858605 |
---|
| _Toc114858605 |
---|
|
Anker |
---|
| _Toc114850650 |
---|
| _Toc114850650 |
---|
|
Anker |
---|
| _Toc114858606 |
---|
| _Toc114858606 |
---|
|
Anker |
---|
| _Toc114850651 |
---|
| _Toc114850651 |
---|
|
Anker |
---|
| _Toc114858607 |
---|
| _Toc114858607 |
---|
|
Anker |
---|
| _Toc114850652 |
---|
| _Toc114850652 |
---|
|
Anker |
---|
| _Toc114858608 |
---|
| _Toc114858608 |
---|
|
Anker |
---|
| _Toc114850653 |
---|
| _Toc114850653 |
---|
|
Anker |
---|
| _Toc114858609 |
---|
| _Toc114858609 |
---|
|
Anker |
---|
| _Toc114850654 |
---|
| _Toc114850654 |
---|
|
Anker |
---|
| _Toc114858610 |
---|
| _Toc114858610 |
---|
|
Anker |
---|
| _Toc114850655 |
---|
| _Toc114850655 |
---|
|
Anker |
---|
| _Toc114858611 |
---|
| _Toc114858611 |
---|
|
Anker |
---|
| _Toc114850656 |
---|
| _Toc114850656 |
---|
|
Anker |
---|
| _Toc114858612 |
---|
| _Toc114858612 |
---|
|
Anker |
---|
| _Toc114850657 |
---|
| _Toc114850657 |
---|
|
Anker |
---|
| _Toc114858613 |
---|
| _Toc114858613 |
---|
|
Anker |
---|
| _Toc114850658 |
---|
| _Toc114850658 |
---|
|
Anker |
---|
| _Toc114858614 |
---|
| _Toc114858614 |
---|
|
Anker |
---|
| _Toc114850660 |
---|
| _Toc114850660 |
---|
|
Anker |
---|
| _Toc114858616 |
---|
| _Toc114858616 |
---|
|
Anker |
---|
| _Toc114850661 |
---|
| _Toc114850661 |
---|
|
Anker |
---|
| _Toc114858617 |
---|
| _Toc114858617 |
---|
|
Anker |
---|
| _Toc114850662 |
---|
| _Toc114850662 |
---|
|
Anker |
---|
| _Toc114858618 |
---|
| _Toc114858618 |
---|
|
Anker |
---|
| _Toc114850663 |
---|
| _Toc114850663 |
---|
|
Anker |
---|
| _Toc114858619 |
---|
| _Toc114858619 |
---|
|
Anker |
---|
| _Toc114850664 |
---|
| _Toc114850664 |
---|
|
Anker |
---|
| _Toc114858620 |
---|
| _Toc114858620 |
---|
|
Anker |
---|
| _Toc114850665 |
---|
| _Toc114850665 |
---|
|
Anker |
---|
| _Toc114858621 |
---|
| _Toc114858621 |
---|
|
Anker |
---|
| _Toc114850666 |
---|
| _Toc114850666 |
---|
|
Anker |
---|
| _Toc114858622 |
---|
| _Toc114858622 |
---|
|
Anker |
---|
| _Toc114850667 |
---|
| _Toc114850667 |
---|
|
Anker |
---|
| _Toc114858623 |
---|
| _Toc114858623 |
---|
|
Anker |
---|
| _Toc114850668 |
---|
| _Toc114850668 |
---|
|
Anker |
---|
| _Toc114858624 |
---|
| _Toc114858624 |
---|
|
Anker |
---|
| _Toc114850669 |
---|
| _Toc114850669 |
---|
|
Anker |
---|
| _Toc114858625 |
---|
| _Toc114858625 |
---|
|
Anker |
---|
| _Toc114850670 |
---|
| _Toc114850670 |
---|
|
Anker |
---|
| _Toc114858626 |
---|
| _Toc114858626 |
---|
|
Anker |
---|
| _Toc114850671 |
---|
| _Toc114850671 |
---|
|
Anker |
---|
| _Toc114858627 |
---|
| _Toc114858627 |
---|
|
Anker |
---|
| _Toc114850672 |
---|
| _Toc114850672 |
---|
|
Anker |
---|
| _Toc114858628 |
---|
| _Toc114858628 |
---|
|
Anker |
---|
| _Toc114850674 |
---|
| _Toc114850674 |
---|
|
Anker |
---|
| _Toc114858630 |
---|
| _Toc114858630 |
---|
|
Anker |
---|
| _Toc114850675 |
---|
| _Toc114850675 |
---|
|
Anker |
---|
| _Toc114858631 |
---|
| _Toc114858631 |
---|
|
Anker |
---|
| _Toc114850676 |
---|
| _Toc114850676 |
---|
|
Anker |
---|
| _Toc114858632 |
---|
| _Toc114858632 |
---|
|
Anker |
---|
| _Toc114850677 |
---|
| _Toc114850677 |
---|
|
Anker |
---|
| _Toc114858633 |
---|
| _Toc114858633 |
---|
|
Anker |
---|
| _Toc114850678 |
---|
| _Toc114850678 |
---|
|
Anker |
---|
| _Toc114858634 |
---|
| _Toc114858634 |
---|
|
Anker |
---|
| _Toc114850679 |
---|
| _Toc114850679 |
---|
|
Anker |
---|
| _Toc114858635 |
---|
| _Toc114858635 |
---|
|
Anker |
---|
| _Toc114850680 |
---|
| _Toc114850680 |
---|
|
Anker |
---|
| _Toc114858636 |
---|
| _Toc114858636 |
---|
|
Anker |
---|
| _Toc114850681 |
---|
| _Toc114850681 |
---|
|
Anker |
---|
| _Toc114858637 |
---|
| _Toc114858637 |
---|
|
Anker |
---|
| _Toc114850682 |
---|
| _Toc114850682 |
---|
|
Anker |
---|
| _Toc114858638 |
---|
| _Toc114858638 |
---|
|
Anker |
---|
| _Toc114850684 |
---|
| _Toc114850684 |
---|
|
Anker |
---|
| _Toc114858640 |
---|
| _Toc114858640 |
---|
|
Anker |
---|
| _Toc117236678 |
---|
| _Toc117236678 |
---|
|
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. In der GDI-DE werden Geodatensätze grundsätzlich über Geodatendienste bereitgestellt. Um die Funktionsfähigkeit zu gewährleisten, ist eine Synchronisierung zwischen Geodaten, Metadaten und Geodatendiensten erforderlich. Daher gehört zu einer vollständigen Metadatenbeschreibung auch die Information, über welche Geodatendienste die Geodatensätze verfügbar sind. Die Recherche von Metadaten erfolgt über Suchdienste. Standardformat für MetadatenGDI-DE-grundlegend
- ISO/TS 19139:2007 Geographic Information – Metadata – XML Schema Implementation
- XML-Schema für den CSW 2.0.2 unter http://schemas.opengis.net/csw/2.0.2/
GDI-DE-optional
- GoodPractice: GeoDCAT-AP (Erweiterung von DCAT-AP)
- DCAT-AP.de (dt. Adaption von DCAT-AP)
GDI-DE-unter Beobachtung
- ISO/TS 19115-3:2016 Geographic information – Metadata – Part 3: XML schema implementation for fundamental concepts
INSPIRE-grundlegend
- Technical Guidance for the implementation of INSPIRE dataset and service metadata based on ISO/TS 19139:2007
Konformitätsprüfung Die Konformität der Metadaten zu den Vorgaben der GDI-DE und INSPIRE können mit der GDI-DE Testsuite überprüfen werden. Folgende Testklassen stehen zur Verfügung:
- GDI-DE Konventionen für GDI-DE-konforme Metadaten (v2.0)
- GDI-DE Konventionen für INSPIRE-konforme Metadaten (v2.0)
- INSPIRE Metadata TG 2.0 – data sets and data sets series
- INSPIRE Metadata TG 2.0 – network services
- INSPIRE Metadata TG 2.0 – invocable spatial data services
Zudem sind weitere länderspezifische Testklassen in der GDI-DE Testsuite (z.B. Metadatenprofil GDI-BW Version 2.1) verfügbar. Hinweis: Für die konkrete Umsetzung ist das im Standard OGC-CSW AP ISO 1.0.1 definierte Datenformat zu verwenden. Die Standards für Suchdienste sind zu berücksichtigen (vgl. Kapitel 6.2). Wiki-Markup |
---|
Für Metadaten im Geltungsbereich von INSPIRE sind die Verordnungen (EG) Nr. 1205/2008 \[INSPIRE-Metadaten 2008\] und (EG) Nr. 1089/2010 \[INSPIRE-Interoperabilität 2010\] und die zugehörigen INSPIRE-Umsetzungsanleitungen zu berücksichtigen. | Detaildokumente (erarbeitet durch den AK Metadaten der GDI-DE):
- Deutsche Übersetzung der Metadatenfelder des ISO 19115 Geographic Information – Metadata (AK Metadaten, 2008)
- Architektur der Geodateninfrastruktur Deutschland – Konventionen zu Metadaten (AK Metadaten, 2022)
- Qualitativ hochwertige Metadaten pflegen und verarbeiten (AK Metadaten, 2018)
- - Checkliste - Fachliche Konventionen (Semantik) für Metadaten (fortlaufende Aktualisierung im GDI-DE Wiki https://wiki.gdi-de.org/x/CYBNKw
Image Added )
|
Anker |
---|
| _Toc117236679 |
---|
| _Toc117236679 |
---|
|
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. Standards für VisualisierungsvorschriftenGDI-DE-grundlegend für WMS 1.3.0 - basierte Darstellungsdienste
- SLD Version 1.1.0, OpenGIS Styled Layer Descriptor Profile of the Web Map Service Implementation Specification
- SE Version 1.1.0, OpenGIS Symbology Encoding Implementation Specification
GDI-DE-unter-Beobachtung
- OGC API-Styles -draft
|
Anker |
---|
| _Toc117236680 |
---|
| _Toc117236680 |
---|
|
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. Standard für KartenzusammenstellungenGDI-DE-grundlegend
- OWS Context Version 1.0, OGC OWS Context Conceptual Model
- OWS Context Version 1.0, OGC OWS Context Atom Encoding Standard
- OWS Context Version 1.0, OGC OWS Context GeoJSON Encoding Standard
|
Anker |
---|
| _Toc114850688 |
---|
| _Toc114850688 |
---|
|
Anker |
---|
| _Toc114858644 |
---|
| _Toc114858644 |
---|
|
Anker |
---|
| _Toc114850689 |
---|
| _Toc114850689 |
---|
|
Anker |
---|
| _Toc114858645 |
---|
| _Toc114858645 |
---|
|
Anker |
---|
| _Toc114850690 |
---|
| _Toc114850690 |
---|
|
Anker |
---|
| _Toc114858646 |
---|
| _Toc114858646 |
---|
|
Anker |
---|
| _Toc114850691 |
---|
| _Toc114850691 |
---|
|
Anker |
---|
| _Toc114858647 |
---|
| _Toc114858647 |
---|
|
Anker |
---|
| _Toc114850692 |
---|
| _Toc114850692 |
---|
|
Anker |
---|
| _Toc114858648 |
---|
| _Toc114858648 |
---|
|
Anker |
---|
| _Toc114850693 |
---|
| _Toc114850693 |
---|
|
Anker |
---|
| _Toc114858649 |
---|
| _Toc114858649 |
---|
|
Anker |
---|
| _Toc114850694 |
---|
| _Toc114850694 |
---|
|
Anker |
---|
| _Toc114858650 |
---|
| _Toc114858650 |
---|
|
Anker |
---|
| _Toc114850695 |
---|
| _Toc114850695 |
---|
|
Anker |
---|
| _Toc114858651 |
---|
| _Toc114858651 |
---|
|
Anker |
---|
| _Toc114850697 |
---|
| _Toc114850697 |
---|
|
Anker |
---|
| _Toc114858653 |
---|
| _Toc114858653 |
---|
|
Anker |
---|
| _Toc114850699 |
---|
| _Toc114850699 |
---|
|
Anker |
---|
| _Toc114858655 |
---|
| _Toc114858655 |
---|
|
Anker |
---|
| _Toc117236681 |
---|
| _Toc117236681 |
---|
|
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. Standard für AnwendungsschemataINSPIRE-grundlegend und GDI-DE-grundlegend Für GML-basierte Anwendungsschemata:
- Geographic information - Reference model - Part 1: Fundamentals (ISO 19101-1:2014)
- XML Schema Definition Language (XSD) 1.1
Für JSON-basierte Schemata:
- JSON Schema specification, 2020-12
|
Anker |
---|
| _Toc114850701 |
---|
| _Toc114850701 |
---|
|
Anker |
---|
| _Toc114858657 |
---|
| _Toc114858657 |
---|
|
Anker |
---|
| _Toc114850702 |
---|
| _Toc114850702 |
---|
|
Anker |
---|
| _Toc114858658 |
---|
| _Toc114858658 |
---|
|
Anker |
---|
| _Toc115190819 |
---|
| _Toc115190819 |
---|
|
Anker |
---|
| _Toc117236682 |
---|
| _Toc117236682 |
---|
|
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. Neben den von den Geodatendiensten zu erfüllenden Normen, Standards und Spezifikationen werden in diesem Kapitel auch die Qualitätsanforderungen (Leistung, Verfügbarkeit und Kapazität) der INSPIRE-Durchführungsbestimmungen genannt. Diese Anforderungen sind für die volle Betriebsfähigkeit der INSPIRE-konformen Netzdienste rechtlich vorgeschrieben. Für alle weiteren Dienste in der GDI-DE sind diese Qualitätsanforderungen als Empfehlung anzusehen. Implementierungskonzepte zur Erfüllung der Qualitätsanforderungen sind nicht Gegenstand der Architektur der GDI-DE, es sei aber auf Möglichkeiten wie Caching, Clustering, redundante Bereitstellung sowie Replikation hingewiesen. 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). Anker |
---|
| _Toc117236683 |
---|
| _Toc117236683 |
---|
|
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. Anker |
---|
| _Toc117236684 |
---|
| _Toc117236684 |
---|
|
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). Das Hypertext Transfer Protocol Secure (HTTPS) wird zur sicheren Übertragung verwendet (vgl. Kapitel 7.2.1). Anker |
---|
| _Toc117236685 |
---|
| _Toc117236685 |
---|
|
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. Anker |
---|
| _Toc117236686 |
---|
| _Toc117236686 |
---|
|
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). Standard für einen SuchdienstGDI-DE-grundlegend
- OGC-CSW OpenGIS® Catalogue Service Specification 2.0.2 - ISO Metadata Application Profile, Version 1.0.1
GDI-DE-optional
- OAI-PMH, Version 2.0
GDI-DE-unter Beobachtung
- OGC API-Records – draft
INSPIRE-grundlegend Für INSPIRE müssen Suchdienste die folgenden Anforderungen erfüllen:
- Technical Guidance for the implementation of INSPIRE Discovery Services
Konformitätsprüfung Die Konformität eines Suchdienstes zu den Vorgaben der GDI-DE und INSPIRE lässt sich anhand der GDI-DE Testsuite überprüfen. Folgende Testklassen stehen zur Verfügung:
- OGC CSW 2.0.2 API ISO 1.0
- INSPIRE Discovery Service – CSW
Hinweis: INSPIRE-konforme Suchdienste sind zugleich konform zur GDI-DE. Die jeweils aktuelle Version der INSPIRE-Umsetzungsanleitung für Suchdienste ist auf den INSPIRE-Internetseiten veröffentlicht. Die dort aktuelle Version ist maßgebend.
|
Anforderungen an die Dienstqualität
Die GDI-DE empfiehlt, alle relevanten Geodatenkataloge der GDI-DE an Geodatenkatalog.de anzuschließen. Die CSW-Schnittstelle des Geodatenkatalog.de erfüllt für den Mitgliedstaat Deutschland die nachstehenden Anforderungen, die INSPIRE an die Dienstqualität stellt. Die an Geodatenkatalog.de angeschlossenen Katalogdienste brauchen deshalb diese Anforderungen nicht zu erfüllen.
INSPIRE-grundlegend Zugriffszeit am Server: Die Zugriffszeit für das Senden eines ersten Ergebnisses auf eine Suchdienstanfrage am Server beträgt in einer normalen Situation höchstens 3 Sekunden. Mit einer normalen Situation ist ein Zeitraum ohne Spitzenbelastung gemeint. Eine normale Situation ist 90 % der Zeit zu gewährleisten. Leistungsfähigkeit: Pro Sekunde können gemäß der Leistungsqualität des Dienstes mindestens 30 Anfragen von einem Suchdienst gleichzeitig bearbeitet werden. Verfügbarkeit: 99 % |
Anker |
---|
| _Toc117236687 |
---|
| _Toc117236687 |
---|
|
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). Anker |
---|
| _Toc117236688 |
---|
| _Toc117236688 |
---|
|
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. Standards für KartendiensteGDI-DE-grundlegend: GDI-DE-konforme Darstellungsdienste müssen in der Lage sein, mindestens eine der folgenden Schnittstellen zu unterstützen:
- OGC-WMS Version 1.3.0, OpenGIS® Web Map Service (WMS) Implementation Specification (ISO 19128:2005 Geographic information – Web map server interface)
- OGC-WMTS Version 1.0.0, OpenGIS® Web Map Tile Service Implementation Standard sowie Vorgaben der GDI-DE zur Bereitstellung von Darstellungsdiensten (AK Geodienste, 2019)
GDI-DE-unter Beobachtung
- OGC API-Maps - draft
- OGC API-Tiles - draft
INSPIRE-grundlegend: Für INSPIRE müssen Darstellungsdienste darüber hinaus die folgenden Anforderungen erfüllen:
- Technical Guidance for the implementation of INSPIRE View Services (IOC-TF, 2013)
- Handlungsempfehlungen für die Bereitstellung INSPIRE konformer Darstellungsdienste (AK Geodienste, 2011)
Konformitätsprüfung: Die Konformität eines Kartendienstes zu den Vorgaben der GDI-DE und INSPIRE lässt sich anhand der GDI-DE Testsuite überprüfen. Folgende Testklassen stehen zur Verfügung:
- INSPIRE View Services – WMS 1.3.0
- INSPIRE View Services – WMTS
Hinweis: Für Geodaten, die aufgrund der INSPIRE-Richtlinie bereitgestellt werden, gelten die Anforderungen unter INSPIRE-grundlegend. Die INSPIRE-Umsetzungsanleitung für Darstellungsdienste profiliert die Standards OGC-WMS Version 1.1.1, OGC-WMS 1.3.0 und OGC-WMTS 1.0.0 durch einige OGC- konforme Erweiterungen. Diese INSPIRE-konformen Darstellungsdienste sind folglich konform zur GDI-DE. Die INSPIRE-Erweiterungen betreffen vor allem zusätzliche Funktionalitäten der Dienstschnittstellen, z. B. Mehrsprachigkeit, wobei Einsprachigkeit weiterhin zugelassen ist. Client- Anwendungen, die für die Basis-Standards entwickelt wurden, können – soweit auf INSPIRE- spezifische Erweiterungen wie z. B. die Mehrsprachigkeit verzichtet werden kann – weiter genutzt werden. Die jeweils aktuelle Version der INSPIRE-Umsetzungsanleitung für Darstellungsdienste ist auf den INSPIRE-Internetseiten veröffentlicht. Die dort aktuelle Version ist maßgebend. Eine deutschsprachige Handlungsempfehlung für die Bereitstellung INSPIRE konformer Darstellungs- dienste in der GDI-DE auf Basis der INSPIRE-Umsetzungsanleitung wurde verfasst und auf der Internetseite der GDI-DE veröffentlicht.
|
Anforderungen an die Dienstqualität
Die nachstehenden Anforderungen gelten nur für solche Dienste, mit denen Geodaten im INSPIRE- Kontext bereitgestellt werden.
INSPIRE-grundlegend Zugriffszeit am Server: Für ein Bild mit 470 Kilobyte (z. B. 800 x 600 Pixel mit einer Farbtiefe von 8 Bit) beträgt die Zugriffszeit für das Senden eines ersten Ergebnisses auf eine „Get Map"-Anfrage an einen Darstellungsdienst in einer normalen Situation höchstens 5 Sekunden. Mit einer normalen Situation ist ein Zeitraum ohne Spitzenbelastung gemeint. Eine normale Situation ist 90 % der Zeit zu gewährleisten. Leistungsfähigkeit: Pro Sekunde können gemäß der Leistungsqualität des Dienstes mindestens 20 Anfragen von einem Darstellungsdienst gleichzeitig bearbeitet werden. Verfügbarkeit: 99 % |
Anker |
---|
| _Toc117236689 |
---|
| _Toc117236689 |
---|
|
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. Standard für einen Dienst zur Erstellung von perspektivischen AnsichtenGDI-DE-grundlegend
- OGC 3D Portrayal Service 1.0
GDI-DE-unter-Beobachtung
- OGC API - 3D GeoVolumes - draft
|
Anker |
---|
| _Toc117236690 |
---|
| _Toc117236690 |
---|
|
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. Anker |
---|
| _Toc117236691 |
---|
| _Toc117236691 |
---|
|
6.4.1 Web Feature Service Mit einem Web Feature Service (WFS) wird ein webbasierter Zugriff auf vektorbasierte Objekte bzw. Sachdaten ermöglicht. Standards für Downloaddienste für vektorbasierte ObjekteGDI-DE-grundlegend GDI-DE-konforme Downloaddienste, die einen direkten Zugriff auf vektorbasierte Objekte gewähren oder das Herunterladen von Geodatensätzen ermöglichen, müssen folgende Schnittstelle unterstützen:
- OGC Web Feature Service 2.0 Interface Standard – With Corrigendum, Open Geospatial Consortium, 2014, http://docs.opengeospatial.org/is/09-025r2/09-025r2.html
Image Added
- Die Version 2.0.0 dieses Standards ist als ISO 19142 veröffentlicht.
- Konformitätsklasse: Basic WFS
INSPIRE-grundlegend Für INSPIRE müssen Downloaddienste die folgenden Anforderungen erfüllen:
- Technical Guidance for the implementation of INSPIRE Download Services (IOC-TF, 2013)
- Handlungsempfehlungen für die Bereitstellung INSPIRE konformer Downloaddienste (AK Geodienste, 2016)
Hinweis: Die jeweils aktuelle Version der INSPIRE-Umsetzungsanleitung für Downloaddienste wird auf den INSPIRE-Internetseiten veröffentlicht. Die dort aktuelle Version ist maßgebend. Eine deutsch- sprachige Handlungsempfehlung für die Bereitstellung INSPIRE konformer Downloaddienste in der GDI-DE auf Basis der INSPIRE-Umsetzungsanleitung wurde verfasst und auf der Internetseite der GDI-DE veröffentlicht. Konformitätsprüfung: Die Konformität eines Downloaddienstes zu den Vorgaben der GDI-DE und INSPIRE lässt sich anhand der GDI-DE Testsuite überprüfen. Folgende Testklasse steht zurzeit zur Verfügung:
- INSPIRE Download Service – Direct WFS
|
Anforderungen an die Dienstqualität
INSPIRE-grundlegend Zugriffszeit am Server: Für eine Operation „Get Download Service Metadata" beträgt die Zugriffszeit bis zur ersten Antwort in einer normalen Situation höchstens 10 Sekunden. Für die Operation „Get Spatial Data Set" und für die Operation „Get Spatial Object" sowie für eine Suchanfrage, die ausschließlich ein geografisches Begrenzungsrechteck umfasst, beträgt die Zeit bis zur ersten Antwort in einer normalen Situation höchstens 30 Sekunden, dann, ebenfalls in einer normalen Situation, beträgt die ständige Übertragungsrate mehr als 0,5 Megabytes pro Sekunde oder mehr als 500 Geo-Objekte pro Sekunde. Für die Operation „Describe Spatial Data Set" und für die Operation „Describe Spatial Object Type" beträgt die Zeit bis zur ersten Antwort in einer normalen Situation höchstens 10 Sekunden, dann, ebenfalls in einer normalen Situation, beträgt die ständige Übertragungsrate mehr als 0,5 Megabytes pro Sekunde oder mehr als 500 Beschreibungen von Geo-Objekten pro Sekunde. Mit einer normalen Situation ist ein Zeitraum ohne Spitzenbelastung gemeint. Eine normale Situation ist 90 % der Zeit zu gewährleisten. Leistungsfähigkeit: Pro Sekunde müssen mindestens 10 Anfragen an einen Downloaddienst in Einklang mit den Dienstqualitätskriterien gleichzeitig bearbeitet werden können. Die Zahl der gleichzeitig bearbeiteten Anfragen kann auf 50 beschränkt werden. Verfügbarkeit: 99 % |
Anker |
---|
| _Toc117236692 |
---|
| _Toc117236692 |
---|
|
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. Standards für Downloaddienste für vordefinierte DatensätzeGDI-DE-grundlegend GDI-DE-konforme Downloaddienste für vordefinierte Datensätze müssen in der Lage sein, mindestens eine der folgenden Schnittstellen zu unterstützen:
- OGC-WFS Version 2.0, OpenGIS® Web Feature Service (WFS) Implementation Specification, (ISO/DIS 19142 Geographic information – Web Feature Service) Konformitätsklasse Simple WFS
- ATOM (The Atom Syndication Format, RFC4287, IETF 2005)
Hinweise: Downloaddienste für vordefinierte Datensätze auf Basis von ATOM bzw. WFS 2.0 (als Simple WFS) sollen die Handlungsempfehlungen für die Bereitstellung INSPIRE konformer Downloaddienste (AK Geodienste, 2016) berücksichtigen. Downloaddienste für vordefinierte Datensätze auf Basis von WFS 2.0 können mit Stored Queries bereitgestellt werden. INSPIRE-grundlegend Für INSPIRE müssen Downloaddienste für vordefinierte Datensätze folgende Anforderungen erfüllen:
- Technical Guidance for the implementation of INSPIRE Download Services (IOC-TF, 2013)
- Handlungsempfehlungen für die Bereitstellung INSPIRE konformer Downloaddienste (AK Geodienste, 2016)
Hinweis: Die jeweils aktuelle Version der INSPIRE-Umsetzungsanleitung für Downloaddienste wird auf den INSPIRE-Internetseiten veröffentlicht. Die dort aktuelle Version ist für GDI-DE maßgebend. Eine deutschsprachige Handlungsempfehlung für die Bereitstellung INSPIRE konformer Downloaddienste in der GDI-DE auf Basis der INSPIRE-Umsetzungsanleitung wurde verfasst und auf der Internetseite der GDI-DE veröffentlicht. Konformitätsprüfung: Die Konformität eines Downloaddienstes zu den Vorgaben der GDI-DE und INSPIRE lässt sich anhand der GDI-DE Testsuite überprüfen. Folgende Testklassen stehen zurzeit zur Verfügung:
- INSPIRE Download Service – Pre-Defined WFS
- INSPIRE Download Service – Pre-Defined Atom
|
Anforderungen an die Dienstqualität
Vgl. Kapitel 6.4.1 Web Feature Service.
Anker |
---|
| _Toc117236693 |
---|
| _Toc117236693 |
---|
|
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. Standards für Downloaddienste basierend auf OGC API - FeaturesGDI-DE-grundlegend GDI-DE-konforme Downloaddienste basierend auf OGC API - Features müssen in der Lage sein, mindestens die folgenden Teile der Spezifikation zu unterstützen:
- OGC API - Features - Part 1: Core
(ISO 19168-1:2020 Geographic information - Geospatial API for features - Part 1: Core)
- OGC API - Features - Part 2: Coordinate Reference Systems by Reference
GDI-DE-unter-Beobachtung Weitere Teile der OGC API - Features Spezifikation liegen in einer draft-Version vor und sind daher unter Beobachtung
- OGC API - Features - Part 3: Filtering and the Common Query Language (CQL) - draft
- OGC API - Features - Part 4: Simple Transactions - draft
INSPIRE-grundlegend Für INSPIRE müssen Downloaddienste basierend auf OGC API-Features folgende Anforderungen erfüllen:
- Good Practice: INSPIRE download services based on OGC API - Features
Konformitätsprüfung: Die Konformität eines OGC API-Features basierten Downloaddienstes zu den Vorgaben der GDI-DE und INSPIRE soll sich anhand der GDI-DE Testsuite überprüfen lassen. Folgende Testklasse steht zur Verfügung:
- INSPIRE Download Service – OGC API-Features
|
Anker |
---|
| _Toc117236694 |
---|
| _Toc117236694 |
---|
| 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. Standards für Downloaddienste basierend auf SensorThings API |
GDI-DE-grundlegend GDI-DE-konforme Downloaddienste basierend auf OGC SensorThings API müssen in der Lage sein, mindestens die folgenden Teile der Spezifikation zu unterstützen:
- OGC SensorThings API Part 1: Sensing Version 1.1, 2021
INSPIRE-grundlegend Für INSPIRE müssen Downloaddienste basierend auf OGC SensorThings API folgende Anforderungen erfüllen:
- Good Practice: OGC SensorThings API as an INSPIRE download service
Konformitätsprüfung: Die Konformität eines OGC SensorThings API basierten Downloaddienstes zu den Vorgaben der GDI-DE und INSPIRE soll sich anhand der GDI-DE Testsuite überprüfen lassen. Folgende Testklasse ist in Planung:
- INSPIRE Download Service – STA (geplant)
|
Anker |
---|
| _Toc117236695 |
---|
| _Toc117236695 |
---|
|
Anker |
---|
| _Hlk114847333 |
---|
| _Hlk114847333 |
---|
|
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. Standard für einen Dienst zur Bereitstellung mehrdimensionaler DatenbeständeGDI-DE-grundlegend GDI-DE-konforme Downloaddienste für den Download von Rasterdatenbeständen müssen in der Lage sein, die folgende Schnittstelle zu unterstützen bzw. Anforderungen erfüllen:
- OGC Web Coverage Service (WCS) 2.1 Interface Standard - Core, version 2.1
INSPIRE-grundlegend Für INSPIRE müssen Downloaddienste für den Download von Rasterdatenbeständen die folgenden Anforderungen erfüllen:
|
- Technical Guidance for the implementation of INSPIRE Download Services using Web Coverage Services (WCS) (Temporary MIG subgroup for action MIWP-7b, 2016)
- Handlungsempfehlungen für die Bereitstellung INSPIRE konformer Downloaddienste (AK Geodienste, 2016)
- Good Practice: OGC compliant INSPIRE Coverage data and service implantation
Konformitätsprüfung
- INSPIRE Download Service – WCS
GDI-DE-unter Beobachtung
- OGC API-Coverages - draft
|
Anker |
---|
| _Toc117236696 |
---|
| _Toc117236696 |
---|
|
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. Anker |
---|
| _Toc117236697 |
---|
| _Toc117236697 |
---|
|
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. Anker |
---|
| _Toc117236698 |
---|
| _Toc117236698 |
---|
|
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. Anker |
---|
| _Toc117236699 |
---|
| _Toc117236699 |
---|
|
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). Standard für die räumliche Abfrage von RDF-DatenGDI-DE-grundlegend Ein Dienst zur räumlichen Abfrage von RDF-Daten muss die folgende Schnittstelle unterstützen bzw. Anforderungen erfüllen:
- OGC GeoSPARQL – A Geographic Query Language for RDF-Data, Version 1.0, 2012
|
Anker |
---|
| _Toc115190820 |
---|
| _Toc115190820 |
---|
|
Anker |
---|
| _Toc117236700 |
---|
| _Toc117236700 |
---|
|
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). Anker |
---|
| _Toc117236701 |
---|
| _Toc117236701 |
---|
|
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:- ISO 10181-2: Authentifizierung
- ISO 10181-3: Zugriffskontrolle
- ISO 10181-4: Nichtabstreitbarkeit
- ISO 10181-5: Vertraulichkeit
- ISO 10181-6: Integrität
- ISO 10181-7: Protokollierung
Authentifizierung ermöglicht es, den Beweis zu führen, dass die behauptete Identität stimmt (vgl. ISO 10181-2).
Zugriffskontrolle ist eine Schutzfunktion, die unerlaubte Aktionen, wie die unberechtigte Veröffentlichung, Veränderung oder Löschung geschützter Ressourcen blockiert (vgl. ISO 10181-3).
Nichtabstreitbarkeit hat gemäß der Empfehlung der Internationalen Fernmeldeunion (ITU) für die Sicherheit in der Kommunikation Offener Systeme (Open Systems Interconnection Model / OSI- Referenzmodell) zwei Erscheinungsformen (vgl. ITU X.800):
Nichtabstreitbarkeit der Herkunft bedeutet, dass der Empfänger von Information die Identität des Senders eindeutig nachprüfen kann. Dies schützt davor, dass der Sender erfolgreich abstreiten kann, bestimmte Informationen gesendet zu haben.
Nichtabstreitbarkeit des Erhalts bedeutet, dass der Sender von Informationen eine Empfangsbestätigung für die erfolgreiche Zustellung erhält. Dies schützt den Sender davor, dass der Empfänger erfolgreich abstreiten kann, die Informationen erhalten zu haben.
Vertraulichkeit definiert Anforderungen an ein System, die erfüllt sein müssen, damit Informationen nicht unerlaubt veröffentlicht werden können – weder an Personen, noch an andere Systeme oder Prozesse (vgl. ITU X.800).
Integrität definiert die Anforderung an ein System, die erfüllt sein müssen, damit Informationen nicht unbemerkt geändert werden können (vgl. ITU X.800).
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).
Anker |
---|
| _Toc117236702 |
---|
| _Toc117236702 |
---|
|
7.2 Standards Anker |
---|
| _Toc117236703 |
---|
| _Toc117236703 |
---|
|
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, sollte eine sichere Übertragung über das verschlüsselte HTTP-Protokoll erfolgen (HTTPS, wie in RFC2817 und RFC2818 beschrieben). Die entsprechende Spezifikation für HTTP Authentication ist die Basic and Digest Access Authentication (siehe RFC2616 und RFC2617). Standards für AnwendungsprotokolleGDI-DE-grundlegend Da Geodatendienste auf Basis von HTTP spezifiziert sind, können auch die Absicherungsmethoden auf dieser Protokollebene genutzt werden. Für diese Absicherung müssen Geodatendienste und deren Clients die vier genannten Spezifikationen unterstützen.
- Hypertext Transfer Protocol – HTTP/1.1, RFC2616, IETF 1999
- HTTP Authentication: Basic and Digest Access Authentication, RFC2617, IETF 1999
- Upgrading to TLS Within HTTP/1.1, RFC2817, IETF 2000
- HTTP over TLS, RFC2818, IETF 2000
|
Anker |
---|
| _Toc117236704 |
---|
| _Toc117236704 |
---|
|
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. Standard für den Austausch von Authentifizierungs- und AutorisierungsinformationenGDI-DE-grundlegend
- OASIS Security Assertion Markup Language (SAML) Version 2.0
|
Anker |
---|
| _Toc117236705 |
---|
| _Toc117236705 |
---|
|
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. Standardformat zur Deklaration von ZugriffsrechtenGDI-DE-grundlegend
- OASIS eXtensible Access Control Markup Language (XACML) Version 2.0
GDI-DE-optional
- OASIS eXtensible Access Control Markup Language (XACML) Version 3.0
|
Anker |
---|
| _Toc117236706 |
---|
| _Toc117236706 |
---|
|
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). Standardformate zur Deklaration von Zugriffsrechten für Geodaten und GeodatendiensteGDI-DE-optional
- OGC Geospatial eXtensible Access Control Markup Language (GeoXACML) Version 1 Corrigendum 1.0.1
- OGC Geospatial eXtensible Access Control Markup Language (GeoXACML) Extension A – GML 2 Encoding Version 1.0
- OGC Geospatial eXtensible Access Control Markup Language (GeoXACML) Extension B – GML 3 Encoding Version 1.0
|
Anker |
---|
| _Toc117236707 |
---|
| _Toc117236707 |
---|
|
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. Standard für den integren und vertraulichen Austausch von SOAP-NachrichtenGDI-DE-grundlegend
- WS-S Version 1.1.1, OASIS Web Service Security
Hinweise: Dieser Standard wird nicht bei der Kommunikation zwischen OGC-Client und OGC-Service eingesetzt. In einer Geodateninfrastruktur wird WS-S auf Dienstebene eingesetzt, um die mit einer Anfrage (z. B. GetMapRequest) empfangenen Behauptungen, wie z. B. Identität oder Rechte auf geschützte Ressourcen bei einem vertrauenswürdigen Dienst (z. B. Identity-Provider) zu überprüfen und weitere Entscheidungsmerkmale dort abzufragen.
|
Anker |
---|
| _Toc115190821 |
---|
| _Toc115190821 |
---|
|
Anker |
---|
| _Toc117236708 |
---|
| _Toc117236708 |
---|
|
8 Verzeichnis der referenzierten Geostandards Dieses Verzeichnis beinhaltet alle in "Architektur der GDI-DE - Technik, Version 4.0.0" 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+
Image Added Thema | Standard | Klassifikation |
Standards für Raumbezugssysteme | ETRS89 (EPSG:4258) – geographische Koordinaten 2D (Breite/Länge) http://www.opengis.net/def/crs/epsg/0/4258 Image Added ETRS89 (EPSG:4937) – geographische Koordinaten 3D (Breite/Länge/ellipsoidische Höhe) http://www.opengis.net/def/crs/epsg/0/4937 Image Added ETRS89 + EVRF2000 height (EPSG:7409) http://www.opengis.net/def/crs/epsg/0/7409 Image AddedETRS89 + EVRF2007 height (EPSG:7423) http://www.opengis.net/def/crs/epsg/0/7423 Image AddedETRS89 + EVRF2019 height (EPSG:9422) http://www.opengis.net/def/crs/EPSG/0/9422 Image Added ETRS89/LAEA Europe (EPSG:3035) http://www.opengis.net/def/crs/epsg/0/3035 Image AddedETRS89/LCC Europe (EPSG:3034) http://www.opengis.net/def/crs/epsg/0/3034 Image Added ETRS89/TM32 (EPSG:3044) http://www.opengis.net/def/crs/epsg/0/3044 Image Added oder ETRS89/TM33 (EPSG:3045) http://www.opengis.net/def/crs/epsg/0/3045 Image Added ETRS89/UTM zone 32 N (EPSG:25832) http://www.opengis.net/def/crs/epsg/0/25832 Image Added oderETRS89/UTM zone 33 N (EPSG:25833) http://www.opengis.net/def/crs/epsg/0/25833 Image Added | INSPIRE- grundlegendGDI-DE- grundlegend
|
| WGS84/geographisch 2D (EPSG:4326) http://www.opengis.net/def/crs/epsg/0/4326 Image Added WGS84/geographisch 3D (EPSG: 4979) http://www.opengis.net/def/crs/epsg/0/4979 Image Added WGS84/Pseudo-Mercator (EPSG:3857) http://www.opengis.net/def/crs/epsg/0/3857 Image Added | GDI-DE- optional |
Standardformate für Vektordaten | OGC Geography Markup Language (GML) - Extended schemas and encoding rules, Version 3.3, Open Geospatial Consortium, 2012 OGC GML Application Schema – Coverages, Version 1.1, Open Geospatial Consortium, 2017 | INSPIRE- grundlegend GDI-DE- grundlegend |
| GeoJSON, RFC7946, Internet Engineering Task Force (IETF), 2016 OGC GeoPackage Encoding Standard, Version 1.3, 2021 | GDI-DE- grundlegend |
| OGC City Geography Markup Language (CityGML) Part 1: Conceptual Model Standard, 2021 OGC 3D Tiles Specification, Version 1.0, 2019 OGC KML, Version 2.3, 2015 | GDI-DE- optional |
Standardformate für Rasterdaten | GeoTIFF, Geo Tagged Image File Format OGC GeoPackage Encoding Standard, Version 1.3, 2021 | GDI-DE- grundlegend |
| Cloud optimized GeoTIFF (COG) | GDI-DE-unter-Beobachtung |
Standardformat für Metadaten | ISO/TS 19139:2007 Geographic Information – Metadata – XML Schema Implementation XML-Schema für den CSW 2.0.2 unter http://schemas.opengis.net/csw/2.0.2/ Image Added | GDI-DE- grundlegend |
| ISO/TS 19115-3:2016 Geographic information – Metadata – Part 3: XML schema implementation for fundamental concepts | GDI-DE-unter-Beobachtung |
| Technical Guidance for the implementation of INSPIRE dataset and service metadata ba-sed on ISO/TS 19139:2007 | INSPIRE- grundlegend |
| Good Practice: GeoDCAT-AP (Erweiterung von DCAT-AP) DCAT-AP.de (dt. Adaption von DCAT-AP) | GDI-DE- optional |
Standards für Visualisierungsvorschriften | SLD Version 1.1.0, OpenGIS Styled Layer Descriptor Profile of the Web Map Service Implementation Specification[ SE Version 1.1.0, OpenGIS Symbology Encoding Implementation Specification | http://www.opengeospatial.org/standards/se] | GDI-DE- grundlegend |
| OGC API-Styles - draft | GDI-DE-unter-Beobachtung |
Standard für Kartenzusammenstellungen | OWS Context Version 1.0, OGC OWS Context Conceptual Model OWS Context Version 1.0, OGC OWS Context Atom Encoding Standard OWS Context Version 1.0, OGC OWS Context GeoJSON Encoding Standard | GDI-DE- grundlegend |
Standard für Anwendungsschemata | Für GML-basierte Schemata: Geographic information - Reference model - Part 1: Fundamentals (ISO 19101-1:2014) XML Schema Definition Language (XSD) 1.1 Für JSON-basierte Schemata: JSON Schema specification, 2020-12 | INSPIRE- grundlegend GDI-DE- grundlegend |
Standard für einen Suchdienst | OGC Catalogue Services Specification 2.0.2 - ISO Metadata Application Profile (1.0.1) | GDI-DE- grundlegend |
| OAI-PMH, Version 2.0 | GDI-DE- optional |
| OGC API-Records - draft | GDI-DE-unter-Beobachtung |
| Technical Guidance for the implementation of INSPIRE Discovery Services (IOC-TF, 2011) | INSPIRE- grundlegend |
Standards für Kartendienste | OGC-WMS Version 1.3.0, OpenGIS Web Map Service (WMS) Implementation Specification (ISO 19128:2005 Geographic information – Web map server interface) OGC-WMTS Version 1.0.0, OpenGIS Web Map Tile Service Implementation Standard Vorgaben der GDI-DE zur Bereitstellung von Darstellungsdiensten (AK Geodienste, 2019) | GDI-DE- grundlegend |
| OGC API-Maps - draft OGC API-Tiles - draft | GDI-DE-unter-Beobachtung |
| Technical Guidance for the implementation of INSPIRE View Services (IOC-TF, 2013) Handlungsempfehlungen für die Bereitstellung INSPIRE konformer Darstellungsdienste (AK Geodienste, 2011) | INSPIRE- grundlegend |
Standard für einen Dienst zur Erstellung von perspektivischen Ansichten | OGC 3D Portrayal Service 1.0 | GDI-DE- grundlegend |
| OGC API - 3D GeoVolumes - draft | GDI-DE-unter-Beobachtung |
Standards für Downloaddienste für vektorbasierte Objekte | OGC Web Feature Service 2.0 Interface Standard – With Corrigendum, Open Geospatial Consortium, 2014 | GDI-DE- grundlegend |
| Technical Guidance for the implementation of INSPIRE Download Services (IOC-TF, 2013) Handlungsempfehlungen für die Bereitstellung INSPIRE konformer Downloaddienste (AK Geodienste, 2016) | INSPIRE-grundlegend |
Standards für Downloaddienste für vordefinierte Datensätze | OGC Web Feature Service 2.0 Interface Standard – With Corrigendum, Open Geospatial Consortium, 2014ATOM (The Atom Syndication Format, RFC 4287, IETF 2005) | GDI-DE- grundlegend |
| Technical Guidance for the implementation of INSPIRE Download Services (IOC-TF, 2013) Handlungsempfehlungen für die Bereitstellung INSPIRE konformer Downloaddienste (AK Geodienste, 2016) | INSPIRE- grundlegend |
Standards für Downloaddienste basierend auf OGC API - Features | OGC API - Features - Part 1: Core (ISO 19168-1:2020 Geographic information - Geospatial API for features - Part 1: Core) OGC API - Features - Part 2: Coordinate Reference Systems by Reference | GDI-DE- grundlegend |
| OGC API - Features - Part 3: Filtering and the Common Query Language (CQL) - draft OGC API - Features - Part 4: Simple Transactions - draft | GDI-DE-unter-Beobachtung |
| Good Practice: INSPIRE download services based on OGC API - Features | INSPIRE- grundlegend |
Standards für Downloaddienste basierend auf SensorThings API | OGC SensorThings API Part 1: Sensing Version 1.1, 2021 | GDI-DE- grundlegend |
| Good Practice: OGC SensorThings API as an INSPIRE download service | INSPIRE- grundlegend |
Standard für einen Dienst zur Bereitstellung mehrdimensionaler Datenbestände
| OGC Web Coverage Service (WCS) 2.1 Interface Standard - Core, 2018 | GDI-DE- grundlegend |
| Technical Guidance for the implementation of INSPIRE Download Services using Web Coverage Services (WCS) (Temporary MIG subgroup for action MIWP-7b, 2016) Handlungsempfehlungen für die Bereitstellung INSPIRE konformer Downloaddienste (AK Geodienste, 2016) Good Practice: OGC compliant INSPIRE Coverage data and service implementation | INSPIRE- grundlegend |
| OGC API - Coverages - draft | GDI-DE-unter-Beobachtung |
Standard für die räumliche Abfrage von RDF-Daten | OGC GeoSPARQL - A Geographic Query Language for RDF Data, Version 1.0, 2012 | GDI-DE- grundlegend |
Standards für Anwendungsprotokolle | Hypertext Transfer Protocol – HTTP/1.1, RFC2616, IETF 1999 HTTP Authentication: Basic and Digest Access Authentication, RFC2617, IETF 1999 Upgrading to TLS Within HTTP/1.1, RFC2817, IETF 2000 HTTP over TLS, RFC 2818, IETF 2000 | GDI-DE- grundlegend |
Standard für den Austausch von Authentifizierungs- und Autorisierungsinformationen | OASIS Security Assertion Markup Language (SAML) Version 2.0 | GDI-DE- grundlegend |
Standardformat zur Deklaration von Zugriffsrechten | OASIS eXtensible Access Control Markup Language (XACML) Version 2.0 | GDI-DE- grundlegend |
| OASIS eXtensible Access Control Markup Language (XACML) Version 3.0 | GDI-DE- optional |
Standardformate zur Deklaration von Zugriffsrechten für Geodaten und Geodatendienste | OGC Geospatial eXtensible Access Control Markup Language (GeoXACML) Version 1 Corrigendum 1.0.1 OGC Geospatial eXtensible Access Control Markup Language (GeoXACML) Extension A – GML 2 Encoding Version 1.0 OGC Geospatial eXtensible Access Control Markup Language (GeoXACML) Extension B – GML 3 Encoding Version 1.0 | GDI-DE- optional |
Die Klassifizierung ist in Kapitel 2.1 auf Seite 13 erläutert und wird hier des besseren Übersicht halber erneut wiedergegeben:
Klassifikation | Beschreibung |
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 |
---|
| _Toc117236709 |
---|
| _Toc117236709 |
---|
|
Anker |
---|
| _Toc115190822 |
---|
| _Toc115190822 |
---|
|
9 Literaturverzeichnis AK Geodaten. (2022). Interoperabilitätskonzept für Geodaten in der GDI-DE. Von https://www.gdi-de.org/download/AG_Geodaten_Interoperabilit%C3%A4tskonzept_Geodaten_GDI-DE.pdf
Image Added abgerufen AK Geodienste. (19. Dezember 2011). Handlungsempfehlungen für die Bereitstellung von INSPIRE konformen Darstellungsdiensten (INSPIRE View Services). Von https://www.gdi-de.org/download/AK_Geodienste_Handlungsempfehlungen_INSPIRE_Darstellungsdienste.pdf
Image Added abgerufen AK Geodienste. (23. März 2016). Handlungsempfehlungen für die Bereitstellung von INSPIRE konformen Downloaddiensten (INSPIRE Download Services), Version 1.3.0. Von https://www.gdi-de.org/download/AK_Geodienste_Handlungsempfehlungen_INSPIRE_Downloadservices.pdf
Image Added abgerufen AK Geodienste. (2019). Vorgaben der GDI-DE zur Bereitstellung von Darstellungsdiensten. Von https://www.gdi-de.org/download/AK_Geodienste_Architektur_GDI-DE_Bereitstellung_Darstellungsdienste.pdf
Image Added abgerufen AK Metadaten. (8. Dezember 2008). Deutsche Übersetzung der Metadatenfelder des ISO 19115. Von https://www.gdi-de.org/download/AK_Metadaten_Deutsche_Uebersetzung_ISO-Felder.pdf
Image Added abgerufen AK Metadaten. (2018). Qualitativ hochwertige Metadaten pflegen und verarbeiten (Version 1.0.). Von https://www.gdi-de.org/download/AK_Metadaten_Handlungsempfehlung_Metadaten_pflegen.pdf
Image Added AK Metadaten. (2022). Architektur der Geodateninfrastruktur Deutschland - Konventionen zu Metadaten. Von https://www.gdi-de.org/download/AK_Metadaten_Konventionen_zu_Metadaten.pdf
Image Added abgerufen Arbeitskreis Architektur der GDI-DE. (2019). Architektur der GDI-DE - Ziele und Grundlagen. Bundesamt für Kartographie und Geodäsie. (2017). Leistungskatalog der Nationalen Technischen Komponenten der GDI-DE. Bundesministerium der Justiz. (2008). Handbuch der Rechtsförmlichkeit. 3. neu überarbeitete Auflage. EGovG. (2013). Gesetz zur Förderung der elektronischen Verwaltung (E-Government-Gesetz - EGovG). EU Kommission. (20. Oktober 2009). Verordnung (EG) Nr. 976/2009 der Kommission vom 19. Oktober 2009 zur Durchführung der Richtlinie 2007/2/EG des Europäischen Parlaments und des Rates hinsichtlich der Netzdienste. Abgerufen von Amtsblatt der Europäischen Union, L 274: https://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2009:274:0009:0018:DE:PDF
Image Added EU Kommission. (10. Dezember 2013). Verordnung (EU) Nr. 1253/2013 der Kommission vom 21. Oktober 2013 zur Änderung der Verordnung (EU) Nr. 1089/2010 zur Durchführung der Richtlinie 2007/2/EG hinsichtlich der Interoperabilität von Geodatensätzen und -diensten. Abgerufen von Amtsblatt der Europäischen Union,: https://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2013:331:0001:0267:DE:PDF
Image Added EU Kommission. (11. Dezember 2014). Verordnung (EG) Nr. 1311/2014 der Kommission vom 10. Dezember 2014 zur zur Änderung der Verordnung (EG) Nr. 976/2009 hinsichtlich der Definition des Begriffs INSPIRE- Metadatenelement. Von Amtsblatt der Europäischen Union, L 354: https://eur-lex.europa.eu/legal-content/DE/TXT/PDF/?uri=CELEX:32014R1311&from=DE
Image Added EU Kommission. (11. Dezember 2014). Verordnung (EU) Nr. 1312/2014 der Kommission vom 10. Dezember 2014 zur Änderung der Verordnung (EU) Nr. 1089/2010 zur Durchführung der Richtlinie 2007/2/EG des Europäischen Parlaments und des Rates hinsichtlich der Interoperabilität von Geodatendiensten. Abgerufen von Amtsblatt der Europäischen Union, L 354: http://eur-lex.europa.eu/legal-content/DE/TXT/PDF/?uri=CELEX:32014R1312
Image Added EU-Kommission. (25. April 2007). Richtlinie 2007/2/EG des Europäischen Parlaments und des Rates vom 14. März 2007 zur Schaffung einer Geodateninfrastruktur in der Europäischen Gemeinschaft (INSPIRE). Von Amtsblatt der Europäischen Union, L 108: https://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2007:108:0001:0014:DE:PDF
Image Added abgerufen EU-Kommission. (4. Dezember 2008). Verordnung (EG) Nr. 1205/2008 der Kommission vom 3. Dezember 2008 zur Durchführung der Richtlinie 2007/2/EG des Europäischen Parlaments und des Rates hinsichtlich Metadaten. Von Amtsblatt der Europäischen Union, L 326/12: https://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2008:326:0012:0030:DE:PDF
Image Added abgerufen EU-Kommission. (11. Juni 2009). Entscheidung der Kommission vom 5. Juni 2009 zur Durchführung der Richtlinie 2007/2/EG des Europäischen Parlaments und des Rates hinsichtlich Überwachung und Berichterstattung. Von Amtsblatt der Europäischen Union, ISSN 1725-2539 L 148, 52. Jahrgang: https://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2009:148:0018:0026:DE:PDF
Image Added abgerufen EU-Kommission. (20. Oktober 2009). Verordnung (EG) Nr. 976/2009 der Kommission vom 19. Oktober 2009 zur Durchführung der Richtlinie 2007/2/EG des Europäischen Parlaments und des Rates hinsichtlich Netzdiensten (inklusive aller Änderungsverordnungen). Von Amtsblatt der Europäischen Union. L 274/9: https://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2009:274:0009:0018:DE:PDF
Image Added abgerufen EU-Kommission. (8. Dezember 2010). 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. Von Amtsblatt der Europäischen Union, L323/11: https://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CONSLEG:2010R1089:20110225:DE:PDF
Image Added abgerufen IOC-TF. (7. November 2011). Technical Guidance for the implementation of INSPIRE Discovery. Von Initial Operating Capability Task Force for Network Services: https://inspire.jrc.ec.europa.eu/documents/Network_Services/TechnicalGuidance_DiscoveryServices_v3.1.pdf
Image Added abgerufen IOC-TF. (9. August 2013). Technical Guidance for the implementation of INSPIRE Download Services. Von Initial Operating Capability Task Force for Network Services: https://inspire.jrc.ec.europa.eu/documents/Network_Services/Technical_Guidance_Download_Services_v3.1.pdf
Image Added abgerufen IOC-TF. (4. April 2013). Technical Guidance for the implementation of INSPIRE View Services. Von Initial Operating Capability Task Force Network Services: https://inspire.jrc.ec.europa.eu/documents/Network_Services/TechnicalGuidance_ViewServices_v3.11.pdf
Image Added abgerufen Kst. GDI-DE. (9. November 2009). Konzept einer Zugriffskontrolle für die Geodateninfrastruktur Deutschland. Von https://wiki.gdi-de.org/x/MANe
Image Added abgerufen MIG sub-group MIWP-7a. (16. Dezember 2016). Technical Guidance for implementing download services using the OGC Sensor Observation Service and ISO 19143 Filter Encoding. Von INSPIRE Maintenance and Implementation Group (MIG): https://inspire.ec.europa.eu/file/1639/download?token=To5FISaB
Image Added abgerufen NGIS. (2015). Nationale GeoInformations-Strategie, Version 1.0. Von https://www.gdi-de.org/download/NGIS_Nationale_Geoinformationsstrategie_V1.pdf
Image Added abgerufen OGC. (18. April 2012). Architecture of an Access Management Federation for Spatial Data and Services in Germany. Von Open Geospatial Consortium. White Paper. OGC 12-026: https://portal.opengeospatial.org/files/?artifact_id=47848
Image Added abgerufen SAGA 5. (2011). SAGA-Modul Grundlagen, Version de.bund 5.1.0. Von Die Beauftragte der Bundesregierung für Informationstechnik (BfIT): https://www.cio.bund.de/SharedDocs/downloads/Webs/CIO/DE/digitaler-wandel/architekturen-standard/AM_SAGA_Grundlagen.html
Image Added abgerufen Temporary MIG subgroup for action MIWP-7a. (16. Dezember 2016). Guidelines for the use of Observations & Measurements and Sensor Web Enablement-related standards in INSPIRE. Von INSPIRE Maintenance and Implementation Group (MIG): https://inspire.ec.europa.eu/file/1638/download?token=EtGplOtQ
Image Added abgerufen Temporary MIG subgroup for action MIWP-7b. (16. Dezember 2016). Technical Guidance for the implementation of INSPIRE Download Services using Web Coverage Services (WCS). Von INSPIRE Maintenance and Implementation Group (MIG): https://inspire.ec.europa.eu/file/1635/download?token=7m3PXp4a
Image Added abgerufen Tóth, K., Portele, C., Illert, A., Lutz, M., & Nunes de Lima, V. (2012). JRC Reference Reports: A Conceptual Model for Developing Interoperability Specifications in Spatial Data Infrastructures. Von https://inspire.jrc.ec.europa.eu/documents/Data_Specifications/IES_Spatial_Data_Infrastructures_(online).pdf
Image Added abgerufen Verwaltungsvereinbarung GDI-DE. (11. Dezember 2017). Vereinbarung zwischen dem Bund und den Ländern zum gemeinsamen Aufbau und Betrieb der Geodateninfrastruktur Deutschland. Anker |
---|
| _Toc115190823 |
---|
| _Toc115190823 |
---|
|
Anker |
---|
| _Toc117236710 |
---|
| _Toc117236710 |
---|
|
Impressum Das Werk einschließlich aller Inhalte ist urheberrechtlich geschützt. Die Reproduktion oder Weiterverwendung dieser Publikation im Ganzen oder auszugsweise in irgendeiner Form oder unter Verwendung elektronischer Systeme ist nur mit der ausdrücklichen Genehmigung und Nennung des Herausgebers gestattet. Die in dem vorliegenden Dokument dargestellten Sachverhalte und zur Verfügung gestellten Angaben bzw. Daten erheben trotz sorgfältiger Prüfung keinen Anspruch auf Vollständigkeit und Richtigkeit. Die Benutzung dieses Dokuments und die Umsetzung der darin enthaltenen Informationen erfolgen ausdrücklich auf eigenes Risiko, Haftungsansprüche für Schäden materieller oder ideeller Art, die durch die Nutzung oder Nichtnutzung der Informationen bzw. durch die Nutzung fehlerhafter und/oder unvollständiger Informationen verursacht wurden, sind grundsätzlich ausgeschlossen. Für die Inhalte von den in diesem Dokument aufgeführten Internetseiten sind ausschließlich die Betreiber der jeweiligen Internetseiten verantwortlich. Aufgeführte Marken und Markennamen sind Eigentum der jeweiligen Hersteller. Herausgeber, Bearbeitung, Gestaltung und Redaktion: AK Architektur der GDI-DE Kontakt über Koordinierungsstelle GDI-DE Bundesamt für Kartographie und Geodäsie Richard-Strauss-Allee 11, 60598 Frankfurt am Main Telefon: + 49 (0) 69 6333-258, Fax: + 49 (0) 69 6333-441 support@gdi-de.org www.gdi-de.org www.geoportal.de wiki.gdi-de.org www.twitter.com/gdi_de Abbildungsnachweis: Alle Abbildungen/Grafiken – Copyright: © Koordinierungsstelle GDI-DE (Kst. GDI-DE) Copyright: Bundesamt für Kartographie und Geodäsie Richard-Strauss-Allee 11, 60598 Frankfurt am Main mailbox@bkg.bund.de {+}http://www.bkg.bund.de+
Image Added Dieses Dokument kann kostenfrei unter www.gdi-de.org heruntergeladen werden.