Regeln für Teilnehmer:
Ich bin mit den Regeln einverstanden

Übersicht:

Favoritenliste:

Favourite Pages

There are currently no pages on your favourites list. You can add pages to this list by selecting Favourite from the Tools menu on the page you're viewing.
Child pages
  • Interoperabilitätskonzept

 

gdi-de_logo_300dpi.tif

Interoperabilitätskonzept für Geodaten in der GDI-DE  

GDI-DE Interoperabilitätskonzept

 

 

ENTWURF

 

 

Arbeitsgruppe Geodaten

26.10.2016  

 

Dieses Dokument enthält ein Konzept zu den Anforderungen für die interoperable Bereitstellung von Geodaten in der Geodateninfrastruktur Deutschland (GDI-DE).


Dokumenteninformation

Bezeichnung

GDI-DE Interoperabilitätskonzept

Autor

AG Geodaten

Erstellt am

01.02.2016

Zuletzt geändert

26 20 . 10 09 .2016

Bearbeitungszustand

x

in Bearbeitung

X

Vorgelegt

 

Abgestimmt

Dokumentablage

Kollaborationsplattform GDI-DE

V-Modell-XT Version

Versio n 1.3 (Bund)

Mitwirkend

Mitglieder der AG Geodaten

Änderungsverzeichnis

Version

Datum

Änderung

Ersteller

0.1

01.02.2016

Initialfassung

AG Geodaten

0.2

01.02.2016

Ergänzungen Kapitel 3.1 Organisation; Kapitel 3.2 Anwendungsschemata und Kapitel 3.3 Identifikatoren

Stephan Mäs, Matthias Müller, Johannes Brauner

0.3

29.02.2016

Ergänzung der Kapitel 3.4 Registry und 3.5 Bereitstellung von Schemadateien und der Anhänge (Erweiterung von Codelisten und CRS);

Bearbeitung von Anmerkungen aus der 3. Sitzung der AG Geodaten

Markus Seifert

 

Stephan Mäs

0.4

01.04.2016

Überarbeitung nach Review in der AG Geodaten und AK Architektur

AG Geodaten

0.5

28.04.2016

Ergänzung Kapitel Ausblick. Review des Dokuments, redaktionelle Verbesserungen

Anja Litka

AG Geodaten

0.6

14.07.2016

Redaktionelle Änderungen

Anja Litka

0.7

20.09.2016

Ergänzung der Kapitel Referenzmodell und zentrale Komponenten

 

Markus Seifert

0.8

06.10.2016

Überarbeitung sowie redaktionelle Änderungen /Anpassungen

AG Geodaten

0.9

26.10.2016

Überarbeitung Abbildung 1;

Hinweis auf Ziel 14 der NGIS in der Ein führung ergänzt;

Schlussredaktion und Formatierung ;

Unterscheidung von  Maßnahmen für GDI-DE und Empfehlungen für Datenanbieter

Anita Litka ,

Markus Seifert

 


Inhalt

Dokumenteninformation

Änderungsverzeichnis

1 Ziele des Interoperabilitätskonzepts

2 Einführung

3 Interoperabilitätselemente

3.1 Organisatorische Anforderungen

3.1.1 Beschreibung

3.1.2 Aktueller Stand in INSPIRE und der GDI-DE

3.1.3 Bewertung, Handlungsbedarf und Empfehlungen

3.2 Referenzmodell

3.2.1 Beschreibung

3.2.2 Aktueller Stand in INSPIRE und der GDI-DE

3.2.3 Bewertung und Handlungsbedarf

3.3 Regeln für das Anwendungsschema

3.3.1 Beschreibung

3.3.2 Aktueller Stand in INSPIRE und der GDI-DE

3.3.3 Bewertung und Handlungsbedarf

3.4 Identifikatormanagement

3.4.1 Beschreibung

3.4.2 Aktueller Stand in INSPIRE und der GDI-DE

3.4.3 Bewertung und Handlungsbedarf

3.5 Nutzung zentraler Komponenten der GDI-DE

3.5.1 Beschreibung

3.5.2 Aktueller Stand in INSPIRE und der GDI-DE

3.5.3 Bewertung und Handlungsbedarf

3.6 Registry

3.6.1 Beschreibung

3.6.2 Aktueller Stand in GDI-DE und Handlungsbedarf

3.7 Verwaltung und Bereitstellung von Schemadateien

3.7.1 Beschreibung

3.7.2 Aktueller Stand in INSPIRE und der GDI-DE

3.7.3 Bewertung und Handlungsbedarf

4 Ausblick

Referenzen

Anhang 1: Weitere, noch zu spezifizierende Interoperabilitätselemente

Dokumenteninformation ................................................................................................. 2

Änderungsverzeichnis ..................................................................................................... 2

1 Ziele des Interoperabilitätskonzepts ..................................................................... 5

2 Einführung ................................................................................................................. 6

3 Interoperabilitätselemente ...................................................................................... 8

3.1 Organisatorische Anforderungen .................................................................... 8

3.1.1 Beschreibung ............................................................................................... 8

3.1.2 Aktueller Stand in INSPIRE und der GDI-DE ......................................... 8

3.1.3 Bewertung, Handlungsbedarf und Empfehlungen ................................ 9

3.2 Referenzmodell ................................................................................................ 12

3.2.1 Beschreibung ............................................................................................. 12

3.2.2 Aktueller Stand in INSPIRE und der GDI-DE ....................................... 13

3.2.3 Bewertung und Handlungsbedarf .......................................................... 13

3.3 Regeln für das Anwendungsschema ............................................................. 14

3.3.1 Beschreibung ............................................................................................. 14

3.3.2 Aktueller Stand in INSPIRE und der GDI-DE ....................................... 14

3.3.3 Bewertung und Handlungsbedarf .......................................................... 15

3.4 Identifikatormanagement ............................................................................... 16

3.4.1 Beschreibung ............................................................................................. 16

3.4.2 Aktueller Stand in INSPIRE und der GDI-DE ....................................... 17

3.4.3 Bewertung und Handlungsbedarf .......................................................... 18

3.5 Nutzung zentraler Komponenten der GDI-DE ............................................. 20

3.5.1 Beschreibung ............................................................................................. 21

3.5.2 Aktueller Stand in INSPIRE und der GDI-DE ....................................... 22

3.5.3 Bewertung und Handlungsbedarf .......................................................... 22

3.6 Registry ............................................................................................................. 23

3.6.1 Beschreibung ............................................................................................. 23

3.6.2 Aktueller Stand in GDI-DE und Handlungsbedarf ............................... 24

3.7 Verwaltung und Bereitstellung von Schemadateien .................................. 27

3.7.1 Beschreibung ............................................................................................. 27

3.7.2 Aktueller Stand in INSPIRE und der GDI-DE ....................................... 27

3.7.3 Bewertung und Handlungsbedarf .......................................................... 27

4 Ausblick .................................................................................................................... 29

Referenzen ...................................................................................................................... 30

Anhang 1: Weitere noch zu spezifizierende Interoperabilitätselemente .............. 32


1         Ziele des Interoperabilitätskonzepts

Die zentrale Aufgabe der GDI-DE ist es, Geodaten verschiedener Herkunft interoperabel verfügbar zu machen. Unter dem Begriff "Interoperabilität" wird die Kombinierbarkeit von Daten bzw. die Kombinierbarkeit und Interaktionsfähigkeit verschiedener Systeme unter Einhaltung gemeinsamer Standards verstanden. Das vorliegende Dokument verfolgt zwei Ziele:

  1. Die Identifikation von Elementen, deren einheitliche Festlegung für eine interoperable Bereitstellung von Geodaten in der GDI-DE erforderlich sind (Interoperabilitätselemente).
  2. Die Erarbeitung einer Methodik, die für eine schrittweise Harmonisierung vorhandener Datenbestände und Datenmodelle innerhalb der GDI-DE erforderlich ist.

Dieses Dokument richtet sich mit seinen Empfehlungen in erster Linie an:

  • GDI-Kontakt- und Koordinierungsstellen des Bundes sowie der Länder
  • Fachgremien der Arbeitsgemeinschaften der Fachministerkonferenzen, die mit der Formalisierung von Geodaten betraut wurden
  • Fachgremien der Kommunalen Spitzenverbände , die im Rahmen ihrer Aufgaben als kommunale Geodatenanbieter ebenfalls die interoperable Bereitstellung und Nutzung von Geodaten in der GDI-DE anstreben.

Mit dem Ziel der   Harmonisierung der Datenmodell e   einen bundesweit einheitlichen Datenbestand zur Unterstützung nationaler und internationaler Fragestellungen zu schaffen, soll anhand von konkreten Anwendungsfällen die Harmonisierung der Datenmodell e   angegangen werden, indem zunächst die oben genannten betroffenen Fachgremien identifiziert (z.B. LAWA, LANA, KOSIS/KORIS ), die Koordination festlegt und erst dann die in diesem Dokument beschriebene Methodik angewendet wird. Die Koordination bundesweiter Anwendungsfälle könnte von der GDI-DE (z. B. innerhalb von Fachnetzwerken, Arbeitskreisen) übernommen werden.

Eine Ergänzung oder Erweiterung der harmonisierten Datenmodelle auf regionaler oder lokaler Ebene ist möglich, solange die Kompatibilität sichergestellt ist.

Mit dem vorliegenden Dokument wird die Grundlage für ein gemeinsames Verständnis von „Interoperabilität“ für Datenmodelle im Rahmen der GDI-DE hergestellt. Das daraus resultierende Spannungsfeld ergibt sich einerseits aus einer möglichst vollständig harmonisierten Datenmodellierung und andererseits aus einer möglichst geringen Formalisierung, die nur wenig e Anforderungen an eine Koordination zwischen den beteiligten Fachgebieten (Basisdaten, Umwelt, Statistik, Verkehr, etc.) stellt, aber unterschiedliche Modellierungsansätze für ähnliche Inhalte zulässt. Aus diesen Überlegungen heraus, sollte vor der Anwendung des Interoperabilitätskonzeptes der erforderliche Harmonisierungsbedarf ermittelt und festgelegt werden. Die in diesem Zusammenhang zu klärende Fragestellung ist somit, was zwischen den einzelnen Themen und Fachdaten innerhalb der GDI-DE harmonisiert werden soll, um damit den Anforderungen an die angestrebten fachlichen Produkte auf nationaler, regionaler oder lokaler Ebene sein oder auch Produkte im Rahmen der Berichtspflichten an die EU zu genügen. Dies können Produkte auf nationaler, regionaler oder lokaler Ebene sein oder auch Produkte im Rahmen der Berichtspflichten an die EU.

Zur Umsetzung dieser Anforderungen sollten entsprechend benötigte zentrale Aspekte identifiziert und festgelegt werden, sowie die Klärung und ggf. Festlegung in wessen Verantwortungsbereich die Definition und Umsetzung dieser Aspekte fällt. Ein Einbeziehen und Koordinieren der bestehenden INSPIRE-Fachgremien wäre hierbei sinnvoll.

Keinesfalls sollen m M it dem Interoperabilitätskonzept sollen keine verpflichtend umzusetzende n Datenspezifikationen analog zu INSPIRE vorbereitet, erstellt und /oder beschlossen werden. Dieses Dokument zeigt soll (vielmehr)       (Handlungs-)Empfehlungen auf zeigen , wie Geodatenbestände formal beschrieben und ggf. harmonisiert bereitgestellt werden können, um eine interoperable Datenbereitstellung innerhalb der GDI-DE und die Nutzung der zentralen Komponenten der GDI-DE (z.B. Registry) zu fördern.

Weiterhin soll D d ieses Dokument soll das Architekturkonzept der GDI-DE als eigenständiges Modul ergänzen und bedarfsweise entsprechend fortgeschrieben werden. Damit unterstützt es ein wesentliches Ziel der Nationalen Geoinformationsstrategie (NGIS), die Geoinformationen auf Basis allgemein anerkannter Reg eln interoperabel bereit zu stellen (Ziel 14).

Zur Priorisierung der in diesem Konzept vorrangig beschriebenen Interoperabilitätselemente wurden zwei Anwendungsfälle exemplarisch dargestellt:

  • Für eine Fachdomäne existiert bereits ein formalisiert beschriebenes Datenmodell und dieses soll durch vorhandene oder noch zu entwickelnde Interoperabilitätselemente n der GDI-DE (z. B. Registry) angepasst oder ergänzt werden. Als Basis dient H h ierfür wurde das AAA-Anwendungsschema der AdV herangezogen .
  • Für eine Fachdomäne existiert noch kein formalisiert beschriebenes Datenmodell und es soll ein neues Datenmodell erstellt oder, z.B. das entsprechende INSPIRE-Kerndatenmodell erweitert / verfeinert werden. Hierfür wurde das LAWA-Datenmodell verwendet.

In jedem Fall sind vor der Anwendung der beschriebenen Elemente die erforderlichen Ressourcen (Personal, Technik, Finanzen) abzuschätzen und dem zu erwartenden Nutzen/Mehrwert gegenüberzustellen.

2         Einführung

Die INSPIRE-Richtlinie beinhaltet bereits detaillierte Vorg a ben zur interoperablen Bereitstellung von Geodaten. Um diese INSPIRE-relevanten Geodaten themen-, maßstabs- und länderübergreifend interoperabel verfügbar machen zu können, wurde ein sog. Interoperabilitätsrahmen („INSPIRE Interoperability Framework“) entwickelt. Eine verallgemeinerte Dokumentation dazu ist 2012 in einem       JRC Reference Report "A Conceptual Model for Developing Interoperability Specifications in Spatial Data Infrastructures" [TÓTH ET AL. 2012] veröffentlicht worden. Dieser konzeptionelle Ansatz identifiziert, welche Aspekte für die Interoperabilität und ggf. auch Harmonisierung der Geodaten betrachtet werden sollte und legt entsprechende Anforderungen sowie Empfehlungen fest.

Die dort genannten Punkte gelten im Wesentlichen auch für andere Rahmenbedingungen und werden in diesem Dokument auf die interoperable Bereitstellung von Geodaten in der GDI-DE übertragen. Die im vorliegenden Dokument vorgeschlagenen Aspekte eines Interoperabilitätskonzepts basieren auf dem „INSPIRE Interoperability Framework“. Die Abbildung 1 stellt eine Übersicht über die für die interoperable Bereitstellung von Geodaten erforderlichen Elemente dar. Die in Abbildung 1 farblich (orange) hervorgehobenen Elemente (orange)   sind von der AG Geodaten priorisiert und für die oben beschriebenen Anwendungsfälle als unbedingt notwendig erachtet worden. Die einzelnen priorisierten Elemente sind in den nachfolgenden Kapiteln detailliert beschrieben. Durch andere mögliche Anwendungsfälle können auch zusätzliche oder abweichende Interoperabilitätselemente als wichtig priorisiert werden.

Die umfassende Beschreibung der übrigen Interoperabilitätselemente soll schrittweise erfolgen. Im Anhang 1       ist eine Übersicht zu den anderen/restlichen diesen Interoperabilitätselemente n zu finden, jeweils mit einer kurzen Beschreibung sowie einer Kategorisierung   für die weitere Spezifizierung .

Abbildung 1 : Übersicht über die Interoperabilitätselemente in der GDI-DE

Dieses Dokument basiert auf den von INSPIRE vorgeschlagenen Interoperabilitätselementen, ergänzt diese um einige für die GDI-DE relevanten Aspekte (siehe Abb. 1) und beschreibt kurz   für die priorisierten Element die daraus abgeleiteten konkreten Maßnahmen für die GDI-DE bzw. Handlungsempfehlungen für Datenanbieter . Die Ergebnisse sollten auch in die GDI-DE Architektur einfließen und schrittweise umgesetzt werden.

Grundsätzlich ist   d ie GDI-DE für die Bereitstellung von nicht-INSPIRE-Daten offen i I n Bezug auf bereits gebräuchliche Datenspezifikationen, Semantik und Datenformate ist die GDI-DE grundsätzlich offen für die Bereitstellung von nicht-INSPIRE-Daten . Die vorgeschlagenen Interoperabilitätselemente definieren somit einen grundlegenden Rahmen, der für eine interoperable Modellierung und Bereitstellung von Geodaten aller Fachdisziplinen innerhalb der GDI-DE genutzt werden sollte.

Für die GDI-DE wird i I m Folgenden wird fü r die GDI-DE definiert, welche Festlegungen für Geodaten gelten sollten. Es wurde grundsätzlich darauf geachtet, dass die Vorgaben in Bezug auf die Bereitstellung von interoperablen Datensätzen deutlich weniger detailliert sind als bei INSPIRE, da bereits durch die Richtlinie       sehr strikte Vorgaben bestehen, die für nicht-INSPIRE-Daten in der GDI-DE derzeit nicht zwingend erforderlich sind. Präzise Anforderungen werden nur bei Interoperabilitätselementen vorgegeben, bei denen die GDI-DE bereits konkrete Lösungen (z. B. zentrale Betriebskomponenten) hat oder verfolgt, die auf die speziellen Rahmenbedingungen in nerhalb der GDI-DE zugeschnitten sind.

Grundsätzlich beziehen sich die Interoperabilitätselemente auf Datenmodelle, die für eine übergreifende Geodatennutzung vorgesehen sind (sog. Bereitstellungsmodelle). Auch die INSPIRE-Datenmodelle gelten als derartige Bereitstellungsmodelle. Abweichend und unabhängig von den Interoperabilitätselementen der GDI-DE können Datenmodelle spezifiziert werden, die innerhalb eines Fachbereichs für die Datenführung implementiert werden, solange die Kompatibilität zu den jeweiligen Bereitstellungsmodellen sichergestellt ist.

3         Interoperabilitätselemente

Nachfolgend werden die von der AG Geodaten priorisierten Interoperabilitätselemente beschrieben (vgl. Abbildung 1 ), der aktuelle Stand bewertet und mögliche Maßnahmen formuliert.

3.1     Organisatorische Anforderungen

3.1.1     Beschreibung

Bevor die Datenmodellierung für eine Fachdomäne begonnen wird, gilt es einige zentrale organisatorische Anforderungen zu beachten, die den Prozess vorbereiten und begleiten sowie sicherstellen, dass qualitativ hochwertige, akzeptierte und dauerhaft nutzbare Ergebnisse erzielt werden.

Dies bezieht sich insbesondere auf die Rollenverteilung bei der Modellerstellung bzw. der Erweiterung/Verfeinerung der INSPIRE-Kerndatenmodelle, die Identifikation und Bestimmung der jeweils in den Datenthemen und Anwendungsdomänen hauptverantwortlichen Datenprovider und die Sicherstellung, dass diese auch in den Prozess eingebunden werden. Zusätzlich muss geklärt werden,

  • wer die Nutzer der Datenmodelle für die Datenbereitstellung sind,
  • wer die Nutzer der bereitgestellten Daten bzw. Dienste sind,
  • wer der Moderator der Prozesse (z.B. die Kst. GDI-DE, die AG Geodaten, der AK Architektur) ist und in welcher Form dies erfolgt und
  • wie die Erfüllung der Nutzeranforderungen überprüft wird. Dies ist in erster Linie für Datenmodelle relevant, die aufgrund konkreter Anwendungsfälle länder- und/oder datenanbieterübergreifend abgestimmt werden sollen.

3.1.2     Aktueller Stand in INSPIRE und der GDI-DE

Auf europäischer Ebene wird für INSPIRE das Vorgehen durch die jeweiligen Organisationsmodelle beschrieben. Ein guter Überblick über den Prozess und die Anforderungen wird im JRC Reference Report 2012 zum Conceptual Model gegeben. Zusätzliche Details können aus den definierten Methoden des INSPIRE Drafting Teams „Data Specification“ (deliverable D2.6) [ INSPIRE D2.6 2008 ] entnommen werden. Insbesondere werden in INSPIRE D2.6 2008 die organisatorischen Aspekte (Abschnitt 5) beschrieben, inkl. des dazugehörigen Rollenmodells (Abschnitt 5.3), eine Schritt-für-Schritt-Anleitung (Abschnitt 6) sowie eine Interoperabilitätscheckliste für Datenmodelle.

Unter Berücksichtigung der föderalen Besonderheiten und Zuständigkeiten in Deutschland wird mit diesem Interoperabilitätskonzept ein einheitliches Vorgehen im Rahmen der GDI-DE, der Länder-GDIs sowie auf regionaler und kommunaler Ebene definiert.

3.1.3     Bewertung, Handlungsbedarf und Empfehlungen

Sofern bei allen Akteuren ein gemeinsames Verständnis zur „Interoperabilität“ für Datenmodelle vorliegt und sowie   der erforderliche Grad der Harmonisierung zwischen einer möglichst vollständig harmonisierten Datenmodellierung und geringen Formalisierung festgelegt wurde, lassen sich folgende Empfehlungen ableiten , die unterschieden werden . Eine Unterscheidung erfolgt hierbei in:

  • Empfehlungen zur Vorbereitung und Entwicklung genereller Best Practices bei der Modellerstellung und
  • in die (konkrete) Datenmodellharmonisierung.

Zuvor sind die wesentlichen Akteure und deren Rollenverteilung anzugeben und entsprechende Beispiele anzuführen.

Empfehlungen für die Rollenverteilung im Harmonisierungsprozess von Datenmodellen

Folgenden Rollen und deren Motivation lassen sich identifizieren und sind in den Harmonisierungsprozess von Datenmodellen mit einzubinden:

  • Datenbereitsteller

Datenbereitsteller sind für die modellkonforme Datenbereitstellung und die Abbildung fachlich-inhaltlicher Informationen zuständig.

Beispiel: Die Umweltfachämter der Kommunen, die verantwortlich für die Datenbereitstellung von Landschaftsschutzgebieten verantwortlich sind.

  • Datennutzer

Datennutzer arbeiten mit den bereitgestellten Daten und verwenden das Datenmodell bei Bedarf als Metainformation.

Beispiel 1: Nutzer von fachfremden Behörden oder Behörden anderer Kommunen und Länder

Beispiel 2: Nutzer auf der Bundes- und Europaebene

Beispiel 3: Nutzer aus der Wirtschaft, Wissenschaft und der Öffentlichkeit bzw. Privatpersonen.

  • Koordinatoren/Moderatoren

Die Koordinatoren/Moderatoren sind für den eigentlichen Prozess verantwortlich, steuern diesen, beziehen die notwendigen Geodatennutzer mit ein , und sowie verwalten und pflegen die Ergebnisse.

Beispiel: Fachnetzwerke, Arbeitsgruppen der GDI-DE oder Einzelpersonen

  • Generelle Datenmodellierungsexperten

Die generellen Datenmodellierungsexperten haben umfangreiche Erfahrung en in der Modellierung von (Geo-)Daten, kennen die spezifischen Anforderungen (z. B. aus INSPIRE) und sind dafür verantwortlich, dass qualitativ hochwertige Datenmodelle erzeugt werden.

Beispiel: Modellierungsexperten aus der Geoinformatikwissenschaft.

  • Technische Datenmodellierungsexperten

Die technischen Datenmodellierungsexperten begleiten die Entwicklung der harmonisierten Datenmodelle mit der Konzeption, Programmierung und Implementierung von entsprechenden Softwarewerkzeugen zur Modellierung und Schematransformation, z. B. mit der FME.

Beispiel: Geoinformatikexperten aus Wissenschaft und Forschung.

Empfehlungen für die Vorbereitung des Harmonisierungsprozesses

Hinweis: Die folgenden Schritte dienen der Vorbereitung und der Entwicklung des eigentlichen Harmonisierungsworkflows. Die       betroffenen Fachgremien (siehe oben Kap. 1 ) sollen in die Vorbereitung mit einbezogen werden.

  1. Identifizierung eines Anwendungsfalls

Vor den nachfolgenden Schritten sollten ein oder mehrere Anwendungsfälle beschrieben werden, die auf einer Ist-Analyse basieren. Die darauf aufbauend zu entwickelnden Anwendungsfälle sollten     die Implementierung inklusive des entsprechenden Testens und Validierens umfassen sowie Schritte für das Fortschreiben des Datenmodells vorgeben. Für die letztgenannten Schritte sollten die Koordinatoren/Moderatoren verantwortlich sein. Die Aktivitäten sollten sich am bestehenden Prozess für die Erstellung der INSPIRE-Datenspezifikationen orientieren und Analysen bezüglich allgemeiner Nutzeranforderungen enthalten.

  1. Liste der verantwortlichen Datenprovider und Datennutzer

Um sicherzustellen, dass alle relevanten Akteure in den Modellierungsprozess mit einbezogen sind, sollten unter Berücksichtigung der föderalen Strukturen die verantwortlichen Datenprovider und Datennutzer der Fachdomäne mit involviert werden. Bei der Zusammenstellung sollten   vorhandene Strukturen, wie z. B. die Fachnetzwerke für die Erweiterung von INSPIRE-Datenmodellen oder vorhandene Listen mit den geodatenhaltenden Stellen für die INSPIRE-Annexthemen, genutzt werden. Die Fachnetzwerke könnten bei der Erstellung entsprechende Koordinierungsaufgaben übernehmen.

  1. Liste möglicher fachlicher Ansprechpartner

Es sollte ein Netzwerk fachlicher Ansprechpartner für die Harmonisierung der Datenmodelle erstellt werden, aus der fachlich kompetente Experten zum einen für die weitergehenden Ist- als auch Defizitanalysen   ausgesucht werden k önnen , zum anderen auch für die spätere Harmonisierung der Datenmodelle   ausgesucht werden k önnen . Für die Kommunikation innerhalb dieser Ansprechpartner wird eine zentral organisierte Kooperationsplattform (Wiki) vorgeschlagen.

  1. Analyse bestehender Datensätze/-spezifikationen (unterschiedlicher) Behörden

Anhand von ausgewählten Beispieldatensätzen sollte evaluiert werden, zu welchen Aspekten     aufgrund der zurzeit unterschiedlich verwendeten Datensätze Harmonisierungsbedarf existier en t und ob bereits einheitliche Datenspezifikationen bzw. Anforderungen im Sinne von bundesweiten Vorgaben bzw. Vereinbarungen vorlieg en t (z. B. die Verwaltungsvereinbarung zum Austausch von Umweltdaten oder abgestimmte Datenmodelle für das Reporting und elektronische Berichterstattung). Hierzu sollten Datensätze von vergleichbaren Landesbehörden unterschiedlicher Bundesländer, als auch Bezirksregierungen und Kommunen untersucht werden, um später eine harmonisierte Datenbereitstellung für eine Erhöhung der wechselseitigen Nachnutzbarkeit zu gewährleisten. Hierbei Ebenfalls   sollte ebenfalls geklärt werden, auf welchen Ebenen die Zuständigkeiten für die Koordination und Moderation der Harmonisierung liegen sollen .

Als Ergebnis sollte eine Liste von Standards und Spezifikationen erstellt werden, die für das jeweilige Thema bereits Verwendung finden und bestehende inhaltliche und technische Anforderungen an das harmonisierte Datenmodell darstellen , . . Weiterhin sollten Datensätze für die weitere Untersuchung gesammelt werden, um daraus einen oder mehrere Anwendungsfälle (-beispiele) für den Harmonisierungsprozess ableiten zu können.

Empfehlungen für den Datenspezifikationsprozess

Es wird empfohlen, sich bei der Spezifikation des harmonisierten Datenmodelles Datenmodells an den aus INSPIRE bekannten Schritten für den Datenspezifikationsprozess zu orientieren (siehe Abb. 2; INSPIRE D2.6 2008; [TÓTH ET AL. 2012] ) . Anhand der Best Practice -Vorgaben (Kapitel 3.2.3 ) und den Ergebnissen sowie den Anforderungen aus den vorhergehenden Empfehlungen zur Vorbereitung, sollen bestehende Datenmodelle fortgeführt und erweitert bzw. neue Datenmodelle entwickelt werden. Die Modellierung sollte sich immer an konkreten Anwendungsfällen orientieren. Zur Ergebnisvalidierung sollten die Anwendungsfälle gemeinsam mit den Datenprovidern, Datenmodellierungsexperten und den für die Softwareumsetzung geschulten Experten (z. B. FME) die Anwendungsfälle beispielhaft durchgespielt werden.

 

C:\Users\Markus.NB2914\Pictures\Bild1wewewe.png

Abbildung 2 : Mögliche Schritte bei der Erstellung von Datenspezifikationen (DIN CEN/TR 15449-3 2014)

In Abstimmung mit allen Akteuren ist ein realistischer Zeitplan für den Prozess aufzustellen, welcher die Umsetzung begleitet und überwacht.

 

Maßnahmen für GDI-DE :

  • Evaluierung der Anwendung des XÖV-Prozesses zur Erstellung eines Datenmodell e s
  • Prüfung, ob die GDI-DE Datenmodelle auch als XÖV-Standards für Geodaten eingebracht werden können
  • Prüfung, welche XÖV-Komponenten von der GDI-DE nachgenutzt und ggf. erweitert werden können.  

 

3.2     Referenzmodell

 

3.2.1     Beschreibung

Ein Referenzmodell enthält grundsätzliche, abstrakte und fachneutrale Vorgaben, wie bestimmte Vorgänge und Gegebenheiten formalisiert zu beschreiben sind. Im Rahmen der Entwicklung von Geodateninfrastrukturen kann das Referenzmodell für offene, verteilte Datenverarbeitung (Reference Model for Open Distributed Processing, RM-ODP) als Basis verwendet werden. RM-ODP ist Gegenstand des Standards ISO 10746 und liefert die grundlegenden Konzepte für die Normenserie ISO 19100. Beispielsweise verwendet das Open Geospatial Consortium (OGC) das RM-ODP als Grundlage für das OGC-Referenzmodell [OGC 2003]. SAGA empfiehlt den Einsatz von RM-ODP zur Beschreibung von E-Government-Anwendungen [KBSt 2006]. Dieser Ansatz lässt sich auf die Erkenntnis zurückführen, dass Akteure in einer Geodateninfrastruktur Akteure unterschiedliche Rollen (z.B. Nutzer, Entwickler) und da durch mit unterschiedliche verschiedene   Sichten auf diese Infrastruktur haben können.

Ein zukünftiges Referenzmodell der GDI-DE wird aus verschiedenen Sichtweisen und Abstraktionsebenen spezifiziert werden. Bei der Erstellung und Anwendung eines Referenzmodells ist daher zunächst dessen Zielsetzung und Anwendungsbereich festzulegen. Das in diesem Interoperabilitätskonzept vorgeschlagene Referenzmodell bezieht sich schwerpunktmäßig auf die formale Beschreibung von Geodaten und die Integration in bestehende eGovernment-Prozesse. Die Beschreibung umfasst auch die logischen, zeitlichen, räumlichen und semantischen Zusammenhänge und dient der Standardisierung und Dokumentation der beschriebenen Objekte der realen fachlichen Welt.

3.2.2     Aktueller Stand in INSPIRE und der GDI-DE

Bei der Entwicklung der INSPIRE-Datenspezifikationen wurden T t hemen - übergreifend e diejenigen Standards festgelegt, die zur Beschreibung der Geodaten verwendet werden sollen und wie sie konkret anzuwenden sind. In der Regel haben Da Geoinformationsstandards in der Regel einen sehr breiten Anwendungsbereich   haben sowie und unabhängig von Verfahren zur Anwendungsentwicklung und Ansätzen zur Technologie Implementierung sind, gilt es, diese Vorgaben für spezielle Anwendungen (z.B. Datenmodellierung) zu konkretisieren und anzupassen. Das Ergebnis eines solchen Prozesses wird dann auch als sogenanntes ‚ Profil bezeichnet.

INSPIRE hat für sein Referenzmodell die Verwendung von ISO 19101 empfohlen. Dieses sehr abstrakte Referenzmodell dient als Grundlage für die themenspezifischen Datenspezifikationen. Dabei werden noch zwei weitere Komponenten festgelegt:

  • Die Interoperabilitätskomponenten von INSPIRE, die auch diesem Dokument zugrunde liegen
  • Vorgaben zur Erstellung von Produktspezifikationen nach ISO 19131.

Das INSPIRE Generic Conceptual Model [INSPIRE GCM 2014] kann als Referenzmodell für die Erstellung von Datenspezifikationen betrachtet werden. Darin sind bereits die für die standardisierte Beschreibung von Geodaten notwendigen Elemente fachneutral beschrieben, um sie in allen themenspezifischen Datenmodellen gleichermaßen zu verwenden. Es bietet sich daher an, auf Grundlage dieses INSPIRE Generic Conceptual Models ein Referenzmodell für die GDI-DE zu erstellen.

Derzeit macht existiert das im Architekturkonzept jedoch noch keine Vorgaben für die Erstellung eines Referenzmodells. Im entsprechenden Technik - d D okument wird lediglich empfohlen, bei der Entwicklung neuer Geodatenspezifikationen innerhalb der GDI-DE grundsätzlich auf der Normenserie ISO 19100 aufzusetzen. Es erfolgt aber keine nähere Beschreibung, W w as konkret zu beachten ist und /oder welche Standards (ggf. Profile) einzusetzen sind , wird nicht näher beschrieben . Ohne eine solche Konkretisierung wird   kann aber ein einheitliches Vorgehen bei der Spezifizierung von Geodaten nicht erreicht werden , was bedeutet, so dass jede Community ihre eigenen Vorgaben macht, w elche as zu unkalkulierbaren Aufwänden bei der Zusammenführung von Daten aus unterschiedlichen Quellen führen kann. Um interoperable Geodaten in der GDI-DE zu erreichen, wird daher die Erstellung eines fachneutralen, für möglichst viele Fachanwendungen verwendbares Referenzmodell auf der Basis der einschlägigen ISO-Standards als erforderlich betrachtet.

3.2.3     Bewertung und Handlungsbedarf

Für die beiden definierten Anwendungsfälle des Interoperabilitätsrahmens (siehe Kap. 1) sind abgestimmte Vorgaben (durch Fachgremien) für die Modellierung eine wichtige Grundlage. Optimal ist in diesem Zusammenhang ein fachneutraler Modellierungsrahmen, der als Basis für alle Fachdaten in UML nach ISO 19109 zusammen mit einem GDI-DE-UML-Profil angewendet wird. Mit einem derartigen Referenzmodell wird festgelegt, welche ISO/TC 211 Standards erfüllt werden müssen bzw. sollten und Hilfestellungen bzgl. der Nutzung von Standards geben. Darüber hinaus sollen zukünftig Methoden und Vorgaben zu den Inhalten der Modelldokumentation und zur Ableitung von Objektartenkatalogen aus dem UML-Modell festgelegt werden.

Maßnahmen für GDI-DE :

  • Festlegung von ISO 19101 als Grundlage für die standardisierte n Beschreibung der Geodaten im Technikdokument der GDI-DE
  • Entwicklung eines Referenzmodells für die Datenmodellierung für die GDI-DE auf Basis des INSPIRE Generic Conceptual Model [INSPIRE GCM 2014]
  • Prüfung zur Übernahme eines GDI-DE-Referenzmodells (z.B. Geometrieaspekte) durch die KosIT

 

3.3     Regeln für das Anwendungsschema

Dieses, im Folgenden beschriebene Interoperabilitätselement ist nur dann anzuwenden, wenn ein Datenmodell unter Verwendung der gleichen Modellierungsgrundsätze und Methodik wie bei INSPIRE gewollt ist. Ferner ist dieses Element Voraussetzung für den Anwendungsfall „Erweiterung von INSPIRE“, da eine fachliche Erweiterung der INSPIRE-Datenmodelle nur unter Berücksichtigung derselben Modellierungsmethodik möglich ist.

3.3.1     Beschreibung

Anwendungsschemata sind konzeptionelle Datenmodelle, die für eine bestimmte Applikation oder ein Datenthema entwickelt wurden. Es werden Objektklassen definiert, die die (räumlichen) Objekttypen, Attribute, Relationen und Integritätsregeln zwischen den Objekten festlegen. Zur Repräsentation von konzeptionellen Datenmodellen werden in der Regel maschinenlesbare Notationen wie UML verwendet, um die automatische Ableitung von Encodingschemata (z. B. in XSD) zu ermöglichen. Eigenschafts- bzw. Feature-Kataloge sind eine äquivalente Präsentation der Informationen aus den Anwendungsschemata. Sie unterstützen die textuelle Dokumentation, die Mehrsprachigkeit, sowie die Suche und den Zugriff auf einzelne Elemente der Anwendungsschemata.

Die Regeln für Anwendungsschemata liefern Festlegungen, wie Datenmodelle von Geodaten zur Repräsentation von Realweltobjekten gebildet und beschrieben (Inhalt und Struktur, Modellkonstrukte) bzw. wie existierende Anwendungsschemata erweitert werden (z. B. INSPIRE Schemata).

3.3.2     Aktueller Stand in INSPIRE und der GDI-DE

In INSPIRE erfolgt die Modellierung der Anwendungsschemata in UML nach ISO 19109 unter Verwendung eines INSPIRE-UML-Profils. Die Objektartenkataloge sind aus dem UML-Modell abgeleitet. In den referenzierten Dokumenten findet sich eine Reihe von weiteren detaillierteren Vorgaben, von denen hier nur Einige beispielhaft aufgeführt werden:

INSPIRE Generic Conceptual Model [INSPIRE GCM 2014]

  • Definition des allgemeinen Rahmens zur Entwicklung von harmonisierten Datenspezifikationen:
    • Relationen zu den ISO 19xxx Standards
    • Raum-zeitliche Repräsentationen räumlicher Objekte über verschiedene Auflösungsstufen
    • Raum-zeitliche Beziehungen zwischen räumlichen Objekten
    • Identifikatoren
    • Mehrsprachigkeit
    • Verwendung von gemeinsamen Vokabularen

Drafting Team "Data Specifications" – deliverable D2.6, insbesondere Kapitel 6 [INSPIRE D2.6 2008]

  • Festlegung von verpflichtenden und optionalen Attributen:

Verpflichtende Attribute sind als solche festzulegen, wenn die Features ohne sie keine Aussagekraft hätten oder nur eingeschränkt nutzbar sind.

  • Wenn       Modellierungsalternativen existieren, sind jeweils Empfehlungen zur Verwendung der unterschiedlichen Optionen anzugeben. Bevorzugt anzuwendende Lösungen sind zu empfehlen.
  • Vermeidung von Enumerationen (nicht erweiterbare Aufzählungen) mit vordefinierten quantitativen Intervallen.
  • Empfehlung zur Nutzung von hierarchischen Klassifikationen, sofern die Unterklassen immer nur durch ein Unterscheidungsmerkmal festgelegt sind, nicht durch mehrere.

JRC Reference Report 2012 [ TÓTH ET AL. 2012]

  • Bedingungen zur Entwicklung von mehreren Anwendungsschemata für ein Datenthema:
    • wenn das Thema sehr umfangreich oder eine logische Aufteilung nach unterschiedlichen Sichten nicht möglich   , wie z. B. beim INSPIRE Thema „Transport Netze“ mit der Unterteilung nach Straßen-, Schienen- und Wasserverkehr, etc.
    • bei rechtlich bindenden Kernkomponenten des Modells, während Erweiterungen nur einen empfehlenden Charakter haben
    • bei expliziter Modellierung verschiedener Auflösungs- oder Skalierungsstufen.

Derzeit gibt es innerhalb der GDI-DE keine mit den INSPIRE Daten Spezifikationen vergleichbaren, konkreten Vorgaben und es sind bisher im Rahmen der Nationalen Geodatenbasis (NGDB) auch keine geplant. Das GDI-DE-Architekturkonzept empfiehlt bislang nur sehr allgemein die Beachtung der INSPIRE-Grundsätze. Des Weiteren existiert explizit derzeit kein explizites UML-Profil für die GDI-DE, allenfalls implizit in Fachmodellen in verschiedenen Anwendungen in Fachmodellen (z. B. AAA-Datenmodell der AdV).

3.3.3     Bewertung und Handlungsbedarf

Die Erweiterung der INSPIRE-Modelle aus den Durchführungsbestimmungen ist grundsätzlich die Aufgabe von Modellierungsexperten mit entsprechendem INSPIRE-Hintergrundwissen. In der Praxis verfügen die Modellierer jedoch nicht immer über dieses Wissen. Eine Leitlinie zum Vorgehen für die Erstellung von Modellen wäre an dieser Stelle hilfreich, z. B. in Form eines frei zugänglichen Wiki s mit Beispielen, Leitfäden, einer Sammlung weiterführender Links, Diskussionsforum etc., ähnlich wie:

https://github.com/ISO-TC211/UML-Best-Practices/wiki

Zum Erreichen einer interoperablen Bereitstellung von Geodaten in der GDI-DE sollten unter anderem Folgendes inhaltlich geklärt werden:

  • Allgemeine Fragen zur Modellierung:
    • Welche Vorteile hat ein auf internationalen Standards basierendes Datenmodell?
    • Welche Alternativen gibt es und welche       Vorteile/Nachteile haben diese?
    • Welche Software wird genutzt bzw. eingesetzt (UML Modellierung, Ableitung des XML Schemata, etc.)?
    • Welche Modellkonstrukte sind zu vermeiden (z. B. Assoziation Classes)?
    • Wie könnte eine Dokumentation der Modelle aussehen?
    • Wie kann die GDI-DE Registry bei der Modellierung mit eingebunden bzw. genutzt werden (z. B. Registrierung der Codelisten)?
    • Wie sind Integritätsregeln zu definieren (z. B. OCL)?
  • Vorgaben zur Modellierung der Maßstabsabhängigkeit:
    • Welche Maßstäbe und Repräsentationen sind in welchen Anwendungen relevant?
    • Ist die Repräsentation eines Objekts in verschiedenen Maßstäben erforderlich?
  • Notwendiges Hintergrundwissen zu INSPIRE (Entscheidungshilfe/-fragen):
    • Für wen sind die Vorgaben von INSPIRE bzw. aus dem GDI-DE Interoperabilitätskonzept (nicht) relevant?
    • Wie können weitere Datenanbieter von genereller Bedeutung gewonnen werden, auch ohne die Verpflichtungen der INSPIRE-Vorgaben um zu setzen zu müssen ?
    • Welche INSPIRE Packages sind relevant? Wie sind diese einzubinden bzw . , zu erweitern?
    • Welche vorgegebenen INSPIRE-Klassen sind wann und wie zu übernehmen?
    • Besonderheiten der INSPIRE Modellierung wie z.B.   :
      • NULL-Attribute
      • Unterscheidung von featuretype (geographisch referenziert) und datatype : ( Wo ist eine geographische Referenz notwendig? )
      • Unterscheidung von Codelisten und Enumerationen
      • Beschreibung der Prozesse zur Erweiterung der INSPIRE-Datenmodelle (Objektarten, Codelisten, …)

 

Maßnahmen für GDI-DE :

  • Erstellung von abgestimmten Modellierungsvorgaben für Datenmodelle der GDI-DE
  • Einbringen der Ergebnisse in bestehende eGovernment-Prozesse    

 

3.4     Identifikatormanagement

3.4.1     Beschreibung

Festlegungen, ob und wie Geoobjekte in der realen Welt abgebildet und dauerhaft identifiziert werden können. Dies beinhaltet darüber hinaus auch die Definition von Namensräumen. Identifikatoren für Geoobjekte werden in diesem Konzept als Objektidentifikatoren (OI) bezeichnet. Darüber hinaus gibt es auch Identifikatoren für andere Ressourcen (z.B. Metadatensätze, CRS).

 

Ziele für die Interoperabilität von Geodaten:

  • Eindeutige Identifikation und Auffindbarkeit von Geoobjekten
  • Lebenszyklus-Management und Versionierung von Geoobjekten
  • Unterstützung der Mehrfachverwendung von Geoobjekten; (eindeutige) Objektidentifikatoren erlauben bzw. ermöglichten den Zugriff auf die Geoobjekte, z. B. zum Verlinken von externen Daten auf die Geoobjekte.

3.4.2     Aktueller Stand in INSPIRE und der GDI-DE

 

INSPIRE-Vorgaben

-           INSPIRE hat hier Grundlagenarbeit geleistet (insb. [ INSPIRE GCM 2014] )

-           Nationale Regelungen beruhen oft auf INSPIRE-Vorgaben

-           Grundlegende Probleme zu Lebenszyklen und Versionierung werden angerissen, aber nicht im Detail gelöst

Geltungsbereich für Objektidentifikatoren

In der INSPIRE Richtlinie sind identifizierbare Objekte sog. „spatial objects“, im Folgenden Geoobjekte genannt [1] . Ein Objektidentifikator     bezieht sich nicht auf ein real-weltliches Phänomen (z. B. einen bestimmten Baum oder See), sondern auf dessen Abstraktion (= ein Geoobjekt). Unterschiedliche Abstraktionen des gleichen real-weltlichen Phänomens erhalten unterschiedliche Objektidentifikatoren.

Üblich er weise wird die Art der Abstraktion in einer Vorschrift zur Objektbildung bzw. über eine Erfassungsvorschrift bei der Objektaufnahme im Feld oder über fernerkundliche Hilfsmittel festgelegt (siehe auch Interoperabilitätselement „Erfassungskriterien“). Die Anwendung sog en annter „spatial object types“ mit verpflichtenden und optionalen thematischen, geometrischen, topologischen und temporalen Attributen sind ein gängiges Instrument zur normativen Objektbildung. Ebenso legen Qualitätsvorgaben bei der Erfassung (Straßen als Linien oder Flächen, Lagegenauigkeit etc.) grundsätzlich die Art der Abstraktion fest. Unterschiedliche Abstraktionsniveaus können jedoch leicht in der Erfassung, Vorverarbeitung und Weitergabe der Daten (z. B. durch zwischengeschaltete Generalisierungsstufen) entstehen. Solche Einflüsse werden im INSPIRE GCM 2014 jedoch nicht im Detail diskutiert.

 

Anforderungen an Objektidentifikatoren

Das INSPIRE GCM 2014 stellt vier Anforderungen an Objektidentifikatoren:

  • Eindeutigkeit ( uniqueness )
  • Persistenz ( persistence )
  • Rückverfolgbarkeit ( traceability ) und
  • Machbarkeit ( feasibility ).

3.4.3     Bewertung und Handlungsbedarf

3.4.3.1 Eindeutigkeit

Die Eindeutigkeit von Objektidentifikatoren wird im INSPIRE GCM 2014 wie folgt definiert:

(1)   Ein Objektidentifikator bezeichnet genau ein Geoobjekt.

(2)   Die Eindeutigkeit dieses Objektidentifikators muss innerhalb des Geltungsbereiches garantiert sein (z. B. eindeutig innerhalb der Menge aller INSPIRE-Geoobjekte).

(3)   Unterschiedliche Versionen oder Kopien des gleichen Geoobjektes (d.h. gleiche Abstraktion des gleichen real-weltlichen Phänomens) haben den gleichen Objektidentifikator.

(4)   Objektidentifikatoren dürfen nicht wiederverwendet werden. Falls ein Geoobjekt permanent aus dem Datenbestand entfernt wird, bezeichnet dessen Objektidentifikator immer noch dieses (   dennoch nicht mehr vorhandene) Geoobjekt.

Geoobjekte können versioniert werden, um z. B. nachträgliche Korrekturen oder Änderungen an Attributfeldern transparenter zu kennzeichnen. Obwohl Versionen nicht Bestandteil des Objektidentifikators eines Geoobjekts sind, wird im INSPIRE GCM 2014 ein versionierter Datentyp für Objektidentifikatoren vorgeschlagen (siehe Tabelle 1 ). Ein Namespace und eine LocalId bilden den eindeutigen Objektidentifikator, das Versionsfeld kann eine fortlaufende Nummer sein oder einen Zeitstempel enthalten. Zudem kann dieser Identifikator-Datentyp auch für die interne Datenhaltung genutzt werden.

Tabelle 1 : Auszug aus dem Generic Conceptual Model von INSPIRE

Class: <<datatype>> Base Types.Identifier (INSPIRE GCM 2014, Clause 9.8.2.3.1)

Attribute:

LocalId

Definition: A local identifier, assigned by the data provider. The local identifier is unique within the namespace, i.e. no other spatial object carries the same unique identifier.

Description: It is the responsibility of the data provider to guarantee uniqueness of the local identifier within the namespace.

Attribute:

Namespace

Definition: Namespace uniquely identifying the data source of the spatial object.

Description: The namespace value will be owned by the data provider of the spatial object and will be registered in the INSPIRE External Object Identifier Namespaces Register.

Attribute:

VersionID

Definition: The identifier of the particular version of the spatial object, with a maximum length of 25 characters. If the specification of a spatial object type with an external object identifier includes life-cycle information, the version identifier is used to distinguish between the different versions of a spatial object. Within the set of all versions of a spatial object, the version identifier is unique.

Description: The maximum length has been selected to allow for time stamps based on ISO 8601, for example, "2007-02-12T12:12:12+05:30" as the version identifier.

The property is void, if the spatial data set does not distinguish between different versions of the spatial object. It is missing, if the spatial object type does not support any life-cycle information.

 

 

Maßnahmen Maßnahmen für GDI-DE :

  • Realisierung eines Prozesses zur Vergabe und Registrierung von Objektidentifikatoren, der folgende Anforderungen erfüllt:

-          Ein Objektidentifikator für ein Geoobjekt darf bzw. kann nur einmal vergeben werden.

-          Die Verknüpfung zwischen Geoobjekt und dessen Objektidentifikator muss auflösbar (d.h. rückverfolgbar) sein.

-          „Verfallene“ Objektidentifikatoren müssen erfasst bleiben, damit diese nicht irrtümlich erneut vergeben werden können.

-           Eine klare Benennung der verantwortlichen Stellen für die Pflege der Objektidentifikatoren ist zwingend erforderlich. Ihnen obliegt die Durchsetzung bzw. Einhaltung dieser Anforderungen.

3.4.3.2 Persistenz

Die Persistenz von Objektidentifikatoren wird im INSPIRE GCM 2014 wie folgt beschrieben:

(1)   Für den gesamten Lebenszyklus eines Geoobjektes bleibt der Objektidentifikator unverändert.

(2)   Die Regeln zum Lebenszyklus von Geoobjekten variieren zwischen verschiedenen Datenprovidern. Daher sind in den INSPIRE-Datenspezifikationen keine definitiven Vorschriften zum Lebenszyklus-Management für Geoobjekte vorgenommen.

Im Bereich der INSPIRE-Datenthemen gibt es in den Mitgliedsstaaten keine flächendeckende Unterstützung für die Abbildung von Lebenszyklen oder Versionen. Daher bleiben das INSPIRE Generic Conceptual Model und die darauf aufbauenden Datenspezifikationen hier eher abstrakt. Folgende Aspekte sind jedoch als Regeln für einen Lebenszyklus eines Geoobjektes zu berücksichtigen:

(3)   Es muss fachlich geklärt sein, wie stark ein Geoobjekt verändert werden kann, um immer noch als das gleiche Geoobjekt zu gelten.

(4)   Sofern Nutzer die Weitergabe von Lebenszyklusinformationen fordern, sollten diese auf der Ebene des Geoobjekttyps festgelegt werden. Genauere Aussagen dazu sind im INSPIRE GCM 2014, Kapitel 9.7 zu finden bzw. nachzulesen.

Maßnahmen Empfehlungen für Datenanbieter :

  • Klärung der Frage, ob Informationen zum Lebenszyklus des Geoobjekts generell nötig sind.
  • Wenn ja:

-           Definition von Regeln zum Lebenszyklus- Management auf fachlicher Ebene

-           Definition einer entsprechenden Vorschrift zur Versionierung für Objektidentifikatoren.

3.4.3.3 Rückverfolgbarkeit

INSPIRE fordert einen Mechanismus zur Auffindbarkeit von Geoobjekten, basierend auf dem jeweils dazugehörigen Objektidentifikator. Ein Objektidentifikator muss daher Informationen zur Herkunft (im englischen Text source ) des Geoobjektes beinhalten. Diese Informationen sollen u. a. dabei helfen, einen geeigneten Downloaddienst für das Geoobjekt zu finden.

Das Generic Conceptual Model von INSPIRE spricht hier von sog. “ interoperability arrangements“ , d. h. es wird nicht gefordert, dass der Objektidentifikator direkt auf den Speicherort des Geoobjektes zeigt. Vielmehr ähnelt der Zugriffsmechanismus der Auflösung eines Digitalen Objektbezeichners (DOI). Über den Namensraum des Objektidentifikators lässt sich der Datenprovider identifizieren und in dessen Bestand (Katalog) das Geoobjekt finden.

Empfehlungen für Datenanbieter Maßnahmen :

  • Verknüpfung zwischen dem Datenprovider und dessen Namensraum muss definiert und diese Information in einer geeigneten Registry hinterlegt werden.
  • Zusätzlich muss ein interoperabler Dienst bereitgestellt werden, der das Auffinden von Downloaddiensten für die von ihm bereitgestellten Geoobjekte ermöglicht.

-           Es kann auch auf höherer Ebene (z. B. Bund, Land) ein solcher Dienst bereitgestellt werden, der stellvertretend für mehrere Datenprovider Geoobjekte auffindbar macht.

-           Der Zugriff auf vorangegangene Versionen eines Geoobjektes ist optional. Der Suchende muss aber erkennen können, welche Version des Geoobjektes über den Datenzugriffsdienst bezogen werden kann.

3.4.3.4 Machbarkeit

INSPIRE-Objektidentifikatoren müssen so aufgebaut sein, dass sie auf existierende nationale Objektidentifikatoren abgebildet werden können. Hierfür existieren in Deutschland bereits zahlreiche, machbare Vorschläge aus der AdV und den Landesvermessungen. Sie definieren syntaktische Vorgaben für den Aufbau von Namensräumen auf verschiedenen föderalen Ebenen. Mit der GDI-DE Registry gibt es bereits ein entsprechendes Instrument (siehe
https://registry.gdi-de.org/register/namespace/ ), das dafür verwendet werden kann und ggf. angepasst werden muss.

Beispiel Nationalpark (Vorschlag aus dem Abschlussbericht Modellprojekt GDI-DE Registry (2012) [AB MP GDI-DE Registry 2012] für das OID- Namensraum-Register):

(bei eindeutigen lokalen IDs innerhalb der gesamten Behörde)

(bei nicht einheitlichen lokalen IDs innerhalb der gesamten Behörde)

Konzeptionelle Probleme ergeben sich typischerweise an administrativen Grenzen oder an überlappenden fachlichen Zuständigkeiten. Hierbei sind folgende Fragen zu klären:

  • Was passiert mit Geoobjekten, welche die Ländergrenzen schneiden?
  • Hört die Objektbildung grundsätzlich an der Ländergrenze auf?
    • Das ist in großen Teilen zwar gängige Praxis (z. B. überregionale Flussläufe, grenzüberscheitende Schutzgebiete), aber aus Anwendersicht oft verwirrend und schwer nachvollziehbar.
  • In wessen Zuständigkeit fällt die Bildung (bestimmter) grenznaher oder -überschreitender Geoobjekte (z. B. Flussläufe) für welchen Anwendungsfall?

Maßnahmen für GDI-DE :

  • Klärung der oben genannten Fragen zur Vergabe und Führung von Objektidentifikatoren. Die Lösungsansätze sind zu erproben und ggf. weiterzuentwickeln. Die in der GDI-DE bereits geleisteten Vorarbeiten zum syntaktischen Aufbau von Namensräumen und Registries sind im Wesentlichen noch umzusetzen.

3.5     Nutzung zentraler Komponenten der GDI-DE

3.5.1     Beschreibung

Eine zentrale Komponente der GDI-DE ist ein Werkzeug, das alle Akteure der GDI-DE benötigen. Durch die zentrale Bereitstellung und Pflege entfällt der mehrfache Implementierungs- und Pflegeaufwand bei den jeweiligen Datenanbietern. Wenn Geodaten in der GDI-DE interoperabel bereitgestellt werden sollen, dann müssen sie über die anderen Komponenten einer GDI (Metadaten, Dienste) zugänglich gemacht werden.

Komponenten können für verschiedenen Zwecke erstellt und bereitgestellt werden. Sie können das Suchen und Finden von Geodaten unterstützen, wie z.B. ein Metadaten-Informationssystem in einem Geoportal, aber auch die korrekte Interpretation von Geodaten ermöglichen (siehe Abschnitt zur Registry) oder die Einhaltung der Implementierungsvorgaben (siehe Abschnitt Konformität) überprüfen. So unterschiedlich die Anwendungsbereiche sind, so vielfältig ist auch die Art der Kommunikation mit diesen Komponenten. Metadaten-Informationssysteme werden über Webdienste vernetzt, die Aktualisierung erfolgt automatisch. I n vielen nationalen Geodateninfrastrukturen erfolgt derzeit D d as Bereitstellen dieser Basisinformationen erfolgt in vielen nationalen Geodateninfrastrukturen derzeit typischerweise über Catalogue Services (Katalogdienste) nach dem ISO 19115/19119 Application Profile.

Hingegen wird F f ür die Beschreibung von Geodaten werden hingegen eine Reihe weiterer zentraler Komponenten benötigt, um eine ordnungsgemäße Weiterverarbeitung und Interpretation von Daten zu ermöglichen; im eigentlichen Sinne handelt es sich somit auch um Metadaten , auch wenn diese vo m n klassischen Metadatenbegriff nicht erfasst werden. Auch b B ei diesen Ressourcen ist ebenfalls eine Pflege nach wohldefinierten Prozeduren erforderlich. Auch müssen g G eänderte oder historisierte Ressourcen sind   weiterhin zur Verfügung zu stellen stehen , da diese natürlich weiterhin für in der Vergangenheit erfasste Datenbestände gültig sind und entsprechend zugänglich sein müssen. Außerdem muss J j ede Ressource muss außerdem mit einem eindeutigen und permanenten Objekti I dentifikator assoziiert werden. ISO 19135 verwendet hierfür den Begriff Registry . Die Inhalte eine r s Registry werden über das Internet online verfügbar gemacht (Näheres siehe im Abschnitt Registry). Spezielle Registry-Dienste werden aus heutiger Sicht nicht benötigt, da der es reicht der als allgemeines Dateiübertragungsprotokoll sehr verbreitete HTTP-Aufruf ausreichend ist . Die I i n Registern verwaltete Ressourcen sind häufig Ressourcen, die eng mit der Spezifikation en und deren Entwicklung verbunden sind . Die Anzahl der Register, die letztlich in einer Geodateninfrastruktur verwaltet werden müssen, wird typischerweise erheblich sein. Als Konsequenz ergibt sich daraus , dass ein klares, nachhaltiges Organisationsmodell hierfür als zentraler Bestandteil des Aufbaus einer Geodateninfrastruktur entwickelt und festgeschrieben werden muss.

Ebenfalls sinnvoll F f ür eine interoperable Bereitstellung ist auch eine Komponente zum Test der Konformität der Daten zu den jeweiligen Datenspezifikationen sinnvoll , da oft schon sehr geringe Abweichungen von den Vorgaben die gemeinsame Verwendung von Daten unmöglich macht erschwert . Die Kommunikation mit einer solchen Testsuite kann online über das Internet erfolgen. Neben einer geeigneten Software (Testframework) ist die Spezifikation der Testfälle, die eine Testsuite abdecken soll, unbedingt erforderlich. Dies muss zwar von jedem Datenanbieter selbst erledigt werden, die zentrale Komponente muss aber in der Lage sein, diese spezifischen Testfälle auch zu implementieren, d.h. sie muss anwenderspezifisch erweitert werden können.

3.5.2     Aktueller Stand in INSPIRE und der GDI-DE

Die GDI-DE stellt den Datenanbietern und Datennutzern folgende Komponenten zentral zur Verfügung:    

  • Die Anwendung GDI-DE Testsuite ( https://testsuite.gdi-de.org/gdi/ ) zur Überprüfung der Konformität von Geodatendiensten
  • Der Suchdienst Geodatenkatalog.de, über den alle in der GDI-DE verfügbaren Geodaten und Dienste gefunden werden können
  • Die Website Geoportal.de ( http://www.geoportal.de/ ) , die Anwendern einfache Möglichkeiten bietet, Geodaten zu recherchieren, zu verknüpfen und in Karten anzeigen zu lassen
  • Das Auskunftssystem GDI-DE Registry ( https://registry.gdi-de.org/ ) zur Verwaltung und technischen Unterstützung übergreifender Konzepte.

Die GDI-DE Testsuite und GDI-DE Registry richten sich primär an Geodaten-Anbieter , . Ü ü ber das Geoportal.de und Geodatenkatalog.de können Nutzer auf die Daten zugreifen.

Auch b B ei INSPIRE wurden , bzw. werden ebenfalls zentrale Komponenten aufgebaut. Die INSPIRE-Registry dient jedoch ausschließlich zur Bereitstellung der eigenen Ressourcen. Eine Erweiterbarkeit durch die Mitgliedsstaaten ist nicht vorgesehen. Das g G leiche gilt für die im Aufbau befindlichen INSPIRE-Testsuite, die zwar gleichermaßen Dienste und Daten testen kann, jedoch nur die INSPIRE-Konformität prüft. Daher müssen auch künftig die Der Test s von nationalen und /oder anwenderspezifischen Profilen muss daher auch künftig von der GDI-DE-Testsuite durchgeführt werden.

In Geodateninfrastrukturen werden Geodaten mit Hilfe von Diensten über das Internet bezogen, die unterschiedliche Funktionen haben können. Die Spezifikationen von interoperablen Geodaten müssen somit auch die verschiedenen Charakteristika von Netzdiensten berücksichtigen. So könnte beispielsweise ein Darstellungsdienst in bestimmten Koordinatenreferenzsystemen bereitgestellt werden oder bestimmte, vordefinierte Visualisierungen vorgegeben sein, die in zentralen Registern in vorgegebenen Formaten abgelegt und zugänglich gemacht werden müssen.

3.5.3     Bewertung und Handlungsbedarf

Die zentralen Komponenten stehen schon weitgehend bereit und sind zu nutzen. Dabei sind die jeweiligen Schnittstellen zu berücksichtigen.


 

Maßnahmen für GDI-DE :

  • Es muss ein klares, nachhaltiges Organisationsmodell für alle zentralen Komponenten als Bestandteil des Aufbaus einer Geodateninfrastruktur entwickelt und festgeschrieben werden.
  • Die GDI-DE Testsuite ist zu erweitern, damit künftig auch Datentests möglich sind. Die Erweiterbarkeit von anwenderspezifischen Testfällen ist zu berücksichtigen.
  • Prüfung der Möglichkeit zur Verknüpfung mit anderen eGovernment-Komponenten

 

3.6     Registry

In diesem Kapitel werden die speziellen Anforderungen der Datenmodellierung und -bereitstellung an eine Registry beschrieben. Andere funktionale Aspekte, wie z. B. das INSPIRE-Monitoring, werden in diesem Zusammenhang nicht behandelt.

3.6.1     Beschreibung

Registries nehmen in Geodateninfrastrukturen eine zentrale Rolle ein, da sie das Verwalten, Auffinden und Nutzen von vorhandenen Geoinformationsressourcen innerhalb der Infrastruktur ermöglichen. Dazu gehören beispielsweise Datenprodukte, Dienste, Anwendungsschemata (in UML/XML), Koordinatenreferenzsysteme, Maßeinheiten, Codelisten, Daten- und Objektarten, Dienstetypen oder auch Zeichenvorschriften und Symbole sowie die Schemadateien.

Gemäß ISO 19135 „Geographic information – Procedures for item registration“ ist eine Registry ein Informationssystem, in dem ein oder mehrere Register geführt werden. Ein Register wiederum ist eine Zuordnung von sog. Identifikatoren zu Ressourcen und deren Beschreibungen. Eine Ressource ist in diesem Sinne ein Sachverhalt, der in Abgrenzung zu anderen Sachverhalten Anwendungsfällen   eindeutig beschrieben werden kann. Ein Identifikator ermöglicht es, Ressourcen der Registry eindeutig zu referenzieren.

Abbildung 3 : Organisationsmodell einer Registry nach ISO 19135

Entscheidend für einen geordneten Betrieb einer Registry ist die Festlegung der verschiedenen Rollen, unabhängig von der technischen Realisierung einer Registry, wie z. B. (vgl. Abbildung 3 ):

  • Der Control Body entscheidet über die Eintragung einer neuen Ressource (Item) in ein Register sowie die Gültigkeit der vorhandenen Einträge. Somit sind in einem Registry System verschiedene Control Bodies für verschiedenen Register und Subregister möglich.
  • Der Registry Owner ist die verantwortliche Stelle für den Betrieb der (jeweiligen) Registry (z. B. GDI-DE).
  • Die Submitting Organization ist die Stelle, welche Änderungen sammelt und zur Eintragung weiterleiten darf.

Ohne die verbindliche Festlegung dieser Rollen wird eine Registry auf Dauer aber nicht funktionieren.

Maßnahmen für GDI-DE :

  • Festlegung der Rollen gemäß ISO 19135 und der entsprechenden verantwortlichen Akteure für jedes Register der GDI-DE.
  • Ermittlung der zusätzlich zu registrierenden Ressourcen in einer Registry, z.B. Darstellungsregeln und Symbole.
  • Abstimmung der gemeinsamen Nutzung zentraler Komponenten von XÖV .

3.6.2     Aktueller Stand in GDI-DE und Handlungsbedarf

Eine Registry kann unterschiedliche Ressourcen enthalten. Der Begriff einer Codelisten-Registry wird verwendet, wenn die Ressourcen die Codelisten eines Datenmodells sind.

 

3.6.2.1 Codelisten-Registry

Häufig verwendete oder nach einem vorgegebenen Konzept beschriebene Eigenschaften von Geoobjekten werden in Datenmodellen häufig durch Codes abgebildet. Die Menge der möglichen Werte ist in einer sog. Codeliste aufgeführt. Die Codeliste wird meist gemeinsam mit dem Datenmodell veröffentlicht. Dem Datenerheber muss diese Codeliste, die Bedeutung der einzelnen Codes sowie der Pflege- und Qualitätszustand bekannt sein, um für die Erfassung den passenden Wert auswählen zu können.

In den INSPIRE-Datenmodellen wird mitunter nur die gemeinsame Sicht abgedeckt, aber nicht die länderspezifischen Bedürfnisse (Erweiterungen). Teilweise sind die in einer Codeliste verfügbaren Codes bewusst leer oder unvollständig gelassen worden, z.B. bei Schutzgebieten die „nationally designated areas“. In diesem Fall ist von der GDI-DE vorgesehen, dass bestimmte Codelisten auch länderspezifisch erweitert werden können. Um die Vergabe von unterschiedlichen Codes und damit inkonsistente Datenbestände zu vermeiden, ist es notwendig, die Pflege der länderspezifischen Codelisten fachlich und organisatorisch zu regeln. Hierbei unterstützt der Einsatz eines Registers für Codelisten:

  • die zuständigen Stellen, bei der Pflege der Codelisten und der enthaltenen Codes,
  • die Datenerfasser, bei der Auswahl eines geeigneten Codes zur Erstellung von harmonisierten Geodatensätzen sowie
  • die Anwender, bei der Interpretation der Codes in einem Datensatz.

Die Anforderungen an eine Codelisten-Registry sind vielschichtig und oft zwischen den Datenanbietern unterschiedlich. In der Regel verursachen spezielle Anforderungen eine Weiterentwicklung der GDI-DE-Codelisten-Registry. Ideen und Vorschläge werden derzeit in einem Wiki unter http://redmine.gdi-de.org/projects/gdi-de-registry/wiki/Anforderungen_Codelisten-Register gesammelt und im Rahmen eines Anforderungsmanagements bei der Weiterentwicklung der Registry berücksichtigt.

Maßnahmen für GDI-DE :

  • Analyse der Anforderung der verschiedenen Datenanbieter und ggf. anschließende Weiterentwicklung der Codelisten-Registry. Ferner sind die Prozesse zu definieren, wie ein Nutzersystem mit einer Registry kommuniziert (z. B. wie Registryinhalte recherchiert und ausgewertet werden können).
  • Diskussion über die verschiedenen Aspekte bei der Erweiterung von Codelisten in den Fachgremien erforderlich.
  • Abstimmung bei Codelistenerweiterungen mit international festgelegten Codelisten und Ermittlung der Möglichkeiten für den technischen Zugriff darauf.
  • Festlegung von Abstimmungsprozessen zwischen unterschiedlichen Registern, die ähnlich Inhalte verwalten (z.B. XÖV-Codelisten).

 

3.6.2.2 CRS-Registry

Geodaten können in verschiedenen Koordinatenreferenzsystemen (CRS) erfasst und gespeichert werden. Für eine gemeinsame Verwendung, z. B. die Darstellung mehrerer Geodatensätze auf einer Karte, müssen die Einzeldaten durch eine entsprechende Transformation in ein einheitliches CRS gebracht werden.

Die Verknüpfung der Geometrien eines Datensatzes mit einem CRS erfolgt jeweils über einen CRS-Identifikator. Um die erforderlichen Parameter für eine Transformation zu erhalten, müssen Anwendungen in der Lage sein, die dem Identifikator zugeordneten Parameter des CRS zu interpretieren bzw. auswerten zu können. Um die CRS-Parameter verlässlich nutzen zu können, müssen diese durch eine autorisierte Stelle bereitgestellt und gepflegt werden. Derzeit werden CRS üblicherweise in einer Online-Datenbank (EPSG-Registry) erfasst und bereitgestellt. Die EPSG ( European Petroleum Survey Group Geodesy) ist eine Arbeitsgruppe der europäischen Öl- und Gaserkundungsunternehmen, und keine amtliche Institution. Der EPSG-Code ist ein System weltweit eindeutiger, 4- bis 5-stelliger Schlüsselnummern für Koordinatenreferenzsysteme und anderer geodätischer Datensätze, wie Referenzellipsoide oder Projektionen. Es wird unter gleichem Namen von der Nachfolgeorganisation OGP (Surveying and Positioning Committee der International Association of Oil & Gas Producers) weitergeführt.

Maßnahmen für GDI-DE :  

  • Entwicklung und der Betrieb eines, von allen Datenanbietern nutzbares CRS-Registers für die GDI-DE, über das alle Anwendungen über einen CRS-Identifikator exakt die gleichen CRS-Parameter erhalten.
  • Durch die Nutzung und Pflege dieses Registers muss gewährleistet werden, dass Transformationen, die über externe Dienste bereitgestellt werden, oder Anwendungen, die selbst transformieren oder für andere Zwecke CRS-konforme Informationen benötigen, im Ergebnis zu den gleichen Resultaten kommen.

Steht die CRS-Registry der GDI-DE zur Verfügung, sind sämtliche von der GDI-DE den Datenanbietern zum Zwecke der interoperablen Bereitstellung verwendete Koordinatenreferenzsysteme zu erfassen und einzutragen.

Maßnahme für GDI-DE :

  • Das Zusammenwirken der GDI-DE Registry und der EPSG-Datenbank ist zu klären, insbesondere, ob und wie CRS erfasst werden, die derzeit noch nicht in der EPSG-Datenbank geführt werden.

3.6.2.3 Registry für Maßeinheiten

In einem Datenmodell muss für jeden quantitativen Wert dessen Maßeinheit angegeben sein. In diesem Abschnitt werden die dafür zu verwendenden Kurzbezeichnungen definiert, die auch in den jeweiligen XML-Schemadateien Verwendung finden. Zur Interpretation dieser Kurzbezeichnungen wird die exakte Definition der verwendeten Maßeinheit in einer zentralen Registry benötigt. Die Angabe der Maßeinheit (UoM - Unit of Measure) in einer XML-Datei (GML) hat den Datentypen "anyURI". Damit sind sowohl URL- als auch URN-Angaben erlaubt. Die URL-Variante setzt eine explizite XML-Beschreibung der verwendeten Maßeinheit in einem GML-Dictionary voraus.

Die folgende Tabelle (Tab. 2) enthält exemplarisch einige gebräuchliche Maßeinheiten:

Tabelle 2 : gebräuchliche Maßeinheiten

Maßeinheit

Kurzbezeichnung

Meter

m

Millimeter

mm

Kilometer

km

Quadratmeter

m2

Kubikmeter

m3

Grad, dezimal (Altgrad)

grad

Gon, dezimal

gon

Radians

rad

m/s 2

ms-2

m 2 /s 2

m2s-2

 

Empfehlungen für Datenanbieter Maßnahmen :

  • Erfassung und Beschreibung der verwendeten Maßeinheiten in einer Registry (UoM-Registry) durch die jeweiligen Fachgremien. Sollte zukünftig durch ISO, das Open Geospatial Consortium (OGC) oder eine andere Stelle ein entsprechendes Register von Maßeinheiten mit Kurzbezeichnungen geführt werden, so sind die Bezeichnungen auf die dort definierten Einträge umzustellen.

3.7     Verwaltung und Bereitstellung von Schemadateien

3.7.1     Beschreibung

Dieses Interoperabilitätselement enthält Festlegungen, wie Datenmodelle und Schemata in Registries verwaltet und sowie   veröffentlicht werden sollen.

Um interoperabel Daten übertragen zu können, muss eine XSD-Datei veröffentlicht werden, d.h. im Internet über eine URL (Verweis auf die Schema-Location) erreichbar sein. Dadurch sind Anwendungen in der Lage, diese XSD-Datei direkt online zu verwenden bzw. abzurufen oder zur lokalen Speicherung herunterzuladen.

3.7.2     Aktueller Stand in INSPIRE und der GDI-DE

XML-Schemata werden bei OGC und INSPIRE in einfachen dateibasierten Repositories über WebServer bereitgestellt. Diese Zurverfügungstellung ist für die Zwecke der GDI-DE ausreichend. Hier wird kein nach ISO-19135 aufgebautes Register benötigt. Da die GDI-DE bereits ein entsprechendes Register aufgebaut hat, werden die einschlägigen Schemadateien der Datenanbieter dort eingestellt:

Siehe http://repository.gdi-de.org/schemas/

Im Gegensatz zu den XML-Schemadateien wird aufgrund der unterschiedlichen Ansätze und Lösungen bei den Datenanbietern eine zentrale Bereitstellung der Datenmodelle in einem von der GDI-DE geführten Register als nicht notwendig erachtet. Es ist jedoch sicherzustellen, dass diese Datenspezifikationen an geeigneter Stelle online zur Verfügung stehen.

3.7.3     Bewertung und Handlungsbedarf

Das Schema-Repository für XML-Dokumente wird bereits betrieben. Die GDI-DE sollte darauf hinwirken, dass dieses Repository von allen Datenanbietern innerhalb der GDI-DE verwendet wird und langfristig zur Verfügung steht.

Maßnahmen für GDI-DE :

  • Zentrale Bereitstellung aller erforderlichen Schemadateien durch die jeweiligen Datenanbieter, welche interoperable Daten in der GDI-DE nach einheitlichen Regeln spezifizieren.
  • Damit das Einstellen der Schemadateien und deren Strukturierung in den Verzeichnissen der Registry nach einheitlichen Regeln   erfolgt, ist die Festlegung entsprechender Regelungen für den   Namensraum von Schemata durch den AK Architektur erforderlich.  

 

Damit das Einstellen der Schemadateien und deren Strukturierung in den Verzeichnissen der Registry nach einheitlichen Regeln   erfolgt , ist die Festlegung entsprechender Regelungen für den   Namensraum von Schemata durch den AK Architektur erforderlich.  

 


4         Ausblick

Das vorliegende Konzept definiert schrittweise die Interoperabilitätsanforderungen an Geodaten innerhalb der GDI-DE, deren Umsetzung in einzelnen Fachdisziplinen oftmals auf Freiwilligkeit basiert und sinnvollerweise nur dann angegangen werden können, wenn es konkrete Anforderungen und ein gemeinsames Verständnis der erforderlichen Interoperabilität gibt. Liegen diese Voraussetzungen aber vor, besteht der dringende Bedarf an einer Reihe von Vorgaben und (Handlungs-)Empfehlungen zur interoperablen Spezifizierung und Bereitstellung von Geodaten in der GDI-DE.

Aus diesen Überlegungen heraus wurde die Entwicklung des Interoperabilitätskonzepts anhand von konkreten Elementen begonnen, welches einen Lösungsweg vorschlägt, wie Geodaten aus unterschiedlichen Themenkomplexen und innerhalb der GDI-DE harmonisiert werden könnten. Zur Umsetzung dieser Empfehlungen wurden die benötigten, zentral bereitzustellenden Komponenten identifiziert und festgelegt sowie konkrete Maßnahmen, sofern nötig, vorgeschlagen.

Aufbauend auf diesem vorgelegten Entwurf des GDI-DE-Interoperabilitätskonzepts werden folgende weitere Schritte vorgeschlagen:

  • Evaluierung des vorgeschlagenen Ansatzes und der vorgebrachten Maßnahmen durch die Akteure der GDI-DE (Arbeitskreise, Kontaktstellen, Fachgremien etc.)
  • Fortschreibung und Ergänzung des Konzeptes, um die weiteren, vorrangig zu behandelnden Interoperabilitätselemente (siehe Anhang 1)
  • Beschluss und schrittweise Umsetzung der vorgeschlagenen Maßnahmen mit Festlegung der Akteure, die diesen Prozess koordinieren bzw. mit begleiten sollen (z.B. Koordinierungsstelle GDI-DE, AK Architektur etc.).

Geodaten sind die zentralen Ressourcen einer Geodateninfrastruktur. Mit diesem Entwurf für ein GDI-DE Interoperabilitätskonzept entsteht ein wichtiger Leitfaden für eine standardkonforme Beschreibung und Bereitstellung von Geodaten in der GDI-DE. Dieses Dokument definiert derzeit aber nur den Rahmen der       notwendigen weiteren Arbeiten für die Spezifizierung der Interoperabilitätselemente. Aus diesem Grund müssen die Arbeiten daran fortgesetzt werden. Zudem ist die Umsetzung und Begleitung der vorgeschlagenen Maßnahmen zu organisieren. Hierzu sind insbesondere auch die Fachgremien einzubeziehen.

Ebenso besteht bei der weiteren Entwicklung des Interoperabilitätskonzeptes ein dringender Bedarf an einer engen Abstimmung mit den XÖV-Standards, um ggf. vorhandene Interoperabilitätskomponenten gemeinsam nutzen und die ggf. unterschiedlichen Methoden und Konzepte einander angleichen zu können.

Durch die von der EU Kommission geänderte Priorisierung bei der Bereitstellung von INSPIRE-Datensätzen für EU-Berichtspflichten entsteht künftig innerhalb der GDI-DE ein erheblicher Abstimmungsbedarf bei der Spezifizierung von möglicherweise zentral bereitgestellten und harmonisierten (interoperablen) Geodatensätzen. Insbesondere Fragen der Granularität, des Grades der geforderten Interoperabilität und der methodischen Beschreibung solcher „EU-Produkte“ sind dann in den Fachgremien zu klären und in diesem Interoperabilitätskonzept festzuhalten. Auch hier sieht die AG Geodaten ein weiteres wichtiges Betätigungsfeld.


Referenzen

 

 

 


Anhang 1: Weitere , noch zu spezifizierende Interoperabilitätselemente

 

Element

Kurzbeschreibung

Abschätzung der derzeitigen Situation in der GDI-DE

Modellierungs-grundsätze

Zusammenstellung der grundlegenden Modellierungsp rinzipien und –methodiken für Geodaten in der GDI

 

Bisher nur grobe und allgemeingültige Vorgaben im Architekturkonzept

INSPIRE-Erwägungsgründe gelten unmittelbar auch für GDI-DE

Allerdings fehlen bisher Ansätze zur Modellierung und Sicherstellung von Nutzeranforderungen (vgl. Element Organisatorische Anforderungen)

Referenzmodell

Festlegungen, welche GIS- und GDI- Standards relevant sind und wie sie genutzt werden

In GDI-DE bisher nicht als Referenzmodell vorhanden

Nutzung zentraler Komponenten der GDI-DE

Festlegungen, wie Geodaten mit anderen Komponenten der GDI zusammenhängen .

Bezug zum Organisationsmodell: Was sind global genutzte Komponenten im Interoperabilitäts - rahmen? Welche müssen dezentral vorhanden sein, damit die Architektur später auch funktioniert?

Welche Rolle spielen hier andere Open-Government-Dienste und -Standards?

Bisherige Festlegungen des Architekturkonzepts müssen entsprechend ergänzt werden.

Für Dienste werden derzeit von der GDI-DE verschiedene Profile (Handlungsempfehlungen) erarbeitet, die auch das Zusammenwirken mit den Geodaten behandeln.

Terminologie

Festlegungen von wesentlichen Begriffen und deren Definition

In GDI-DE derzeit nicht vorhanden

Mehrsprachigkeit

Festlegungen, wie grenz- und sprachübergreifend Geodaten bereitgestellt und verarbeitet werden können

In GDI-DE derzeit nicht vorhanden

Objekt-referenzierung

Festlegungen, wie indirekte Georeferenzierung von Objekten unterstützt wird

Derzeit keine konkreten Vorgaben. Allerdings besteht ein technisches Konzept für einen Geokodierungsdienst der AdV, der eine indirekte Georeferenzierung von Objekten unterstützt

Räumliche und zeitliche Modellierung

Festlegungen, 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.

Im Technikdokument der GDI-DE-Architektur sind derzeit keine detaillierten Regelungen vorhanden, wie räumliche und zeitliche Aspekte zu berücksichtigen sind. Vorgaben sind nur indirekt gemacht, . z.B. über Austauschformate (z.B. GML), die geometrische Repräsentierungen vorschreiben.

Beispiele für zeitliche Aspekte gibt es in INSPIRE mit der Möglichkeit zur Führung von Lebenszeitintervallen bei Objekten, was auch die Führung historischer Daten ermöglicht.

Verwendung fachübergreifender Modellelemente

 

Festlegungen, wie mit übergreifend genutzten Modellelementen umgegangen wird

In GDI-DE derzeit nicht vorhanden

Umgang mit Maßstäben

Festlegungen, wie mit unterschiedlichen Maßstäben umgegangen wird

In GDI-DE derzeit nicht vorhanden

 

 

Modell-erweiterungen

(Leitfäden)

Festlegungen, wie vorhandene Datenspezifikationen (z.B. von INSPIRE) erweitert werden können, ohne die Interoperabilität zu verlieren

In GDI-DE derzeit nicht vorhanden

Datenkonsistenz (auch an Ländergrenzen)

Festlegungen zu Anforderungen an die Konsistenz von Daten – auch datensatzübergreifend und länderübergreifend

In GDI-DE derzeit keine Vorgaben oder Empfehlungen, aber von INSPIRE gefordert.

Grenzübergreifende Harmonisierung offen (Aufgabe der Datenanbieter)

Datensatzübergreifende Konsistenz ebenfalls offen

 

Datenqualität (auch Aktualität)

Festlegungen, welche Anforderungen an die Datenqualität gestellt werden und wie die Qualität der Daten kommuniziert und sichergestellt wird.

Es gibt derzeit keine expliziten Qualitätsvorgaben. Die Datenqualität könnte in den Metadaten angegeben werden, soweit bekannt.

Metadaten (auch fachspezifisch)

Festlegungen, wie und welche Metadaten zu Objekten und Datensätzen geführt werden

Es gibt derzeit kein ISO-19115-Metadatenprofil der GDI-DE, sondern nur eine Übersetzung der englischen Begriffe und Definitionen. In verschiedenen Fachnetzwerken sind (ggf. unterschiedliche) Metadatenprofile vorhanden.

Konformität

Festlegungen, welche Konformitätsklassen existieren und wie diese geprüft werden können

In GDI-DE derzeit für Geodaten nicht vorhanden

Erfassungskriterien

Festlegungen zu den Erfassungsregeln von Geodaten

In GDI-DE derzeit nicht vorhanden. Muss in erster Linie von den Datenanbietern gemacht werden. Regelungen zur Dokumentation müsste von GDI-DE vorgeben werden.

Modelltrans-formationen (auch die Ableitung von Produkten)

Festlegungen, wie Daten aus der Datenhaltung in die festgelegten Austauschformate (z.B. von INSPIRE) transformiert werden

In GDI-DE derzeit nicht vorhanden

Präsentation

Festlegungen zur Darstellung von Geodaten in Karten

In GDI-DE derzeit nicht vorhanden

Ontologien

Festlegungen, wie Ontologien genutzt werden, um semantische Unterschiede zu überbrücken

Derzeit keine Nutzung.

 

 


[1] “Spatial object: abstract representation of a real-world phenomenon related to a specific location or geographical area [INSPIRE Directive]. […] It is also synonymous with "(geographic) feature" as used in the ISO 19100 series. (Quelle: INSPIRE D2.5 V 3.4 )