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

 

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

GDI-DE Interoperabilitätskonzept

 

 

 

 

Arbeitsgruppe Geodaten

11.08.2017  

 

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

11.08.2017

Bearbeitungszustand

 

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

27.10.2016

Überarbeitung Abbildung 1;

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

Schlussredaktion und Formatierung;

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

Anja Litka,

Markus Seifert

1.0

11.08.2017

Überarbeitung im Rahmen des AK-übergreifenden Reviews

AG Geodaten

 


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

Dieser Bericht fasst die Ergebnisse der Architekturmaßnahme M1.1 zur Defintion von Interoperabilitätselementen in der GDI-DE zusammen. Aussagen daraus können nicht im Rahmen gesetzlicher Verpflichtungen und deren Umsetzung geltend gemacht werden. Dieser Bericht ist zur Vereinfachung der Lesbarkeit in der männlichen Form verfasst.


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 Kommunikation verschiedener Systeme unter Einhaltung gemeinsamer Standards verstanden.

Das Interoperabilitätskonzept verfolgt zwei Ziele:

  1. Die Identifikation und Beschreibung von Interoperabilitätselementen, die für eine einheitliche Definition und interoperable Bereitstellung von Geodatenbeständen in der GDI-DE erforderlich sind.
  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 und Fachverantwortliche in geodatenhaltenden Stellen, 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 konkreten Ziel einen bundesweit einheitlichen Datenbestand zur Unterstützung nationaler und internationaler Fragestellungen zu schaffen, soll anhand von konkreten Anwendungsfällen die Harmonisierung der Datenmodelle 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.

Im konkreten Fall der Harmonisierung der Daten zum Zwecke der Bereitstellung INSPIRE-konformer Datensätze wird die Identifizierung der zuständigen Fachgremien bereits von der GDI-DE im AK INSPIRE über die Betroffenheitsmatrix koordiniert. Weitere bundesweite Anwendungsfälle könnten von der GDI-DE (z. B. innerhalb von Fachnetzwerken, Arbeitskreisen) ebenfalls ü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 wenige 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 zu genügen sowie die fachlichen Berichtspflichten an die EU zu erfüllen.

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

Mit dem Interoperabilitätskonzept sollen keine verpflichtend umzusetzenden Datenspezifikationen analog zu INSPIRE vorbereitet, erstellt und/oder beschlossen werden. Dieses Dokument soll (vielmehr) (Handlungs-)Empfehlungen aufzeigen, wie Geodatenbestände einheitlich 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 ergänzt dieses Dokument das Architekturkonzept der GDI-DE als eigenständiges Modul und wird bei Bedarf fortgeschrieben. Damit unterstützt es ein wesentliches Ziel der Nationalen Geoinformationsstrategie (NGIS), die Geoinformationen auf Basis allgemein anerkannter Regeln interoperabel bereit zu stellen (Ziel 14).

Zur Priorisierung der in diesem Konzept vorrangig beschriebenen Interoperabilitätselemente wurden die zwei folgenden Szenarien exemplarisch herangezogen, die jedoch nicht Grundlage für den Aufbau dieses Konzepts sind:

  • Für eine Fachdomäne existiert bereits ein formalisiert beschriebenes Datenmodell und dieses soll durch vorhandene oder noch zu entwickelnde Interoperabilitätselemente der GDI-DE (z. B. Registry) angepasst oder ergänzt werden. Als Basis dient hierfür das AAA-Anwendungsschema der AdV.
  • 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 Vorgaben 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 sollten 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 sind von der AG Geodaten für die oben beschriebenen Szenarien priorisiert worden. Die einzelnen priorisierten Elemente sind in den nachfolgenden Kapiteln detailliert beschrieben. Durch andere mögliche Szenarien 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 diesen Interoperabilitätselementen zu finden, jeweils mit einer kurzen Beschreibung.

Abbildung 1 : Übersicht über die Interoperabilitätselemente in der GDI-DE (in Anlehnung [TÓTH ET AL. 2012])

Dieses Dokument basiert auf den von INSPIRE vorgeschlagenen Interoperabilitätselementen, ergänzt diese um einige für die GDI-DE relevanten Aspekte oder fasst verschiedene Elemente zweckmäßig zusammen. Es beschreibt für die priorisierten Elemente 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.

In 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.

Im 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 allgemeiner 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 innerhalb 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 aufgrund der eingangs erwähnten Szenarien (siehe Kap. 1) 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 anschaulicher Ü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

Zunächst sind die wesentlichen Akteure und deren Rollenverteilung anzugeben und entsprechende Beispiele anzuführen. Sofern bei allen Akteuren ein gemeinsames Verständnis zur „Interoperabilität“ für Datenmodelle vorliegt, muss der erforderliche Grad der Harmonisierung zwischen einer möglichst vollständig harmonisierten Datenmodellierung und geringen Formalisierung festgelegt werden. Anschließend lassen sich folgende Empfehlungen ableiten, die unterschieden werden in:

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

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

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

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

  • Datennutzer

Die Datennutzer von bereitgestellten Daten verwenden das Datenmodell zur Interpretation der Datenstruktur.

Beispiele : Nutzer von fachfremden Behörden oder Behörden anderer Kommunen und Länder, Nutzer auf der Bundes- und Europaebene, 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 und -bereitsteller mit ein. Die Zuständigkeit für die Verwaltung und Pflege der Ergebnisse ist abzustimmen.

Beispiel: Fachnetzwerke, Arbeitsgruppen der GDI-DE oder Einzelpersonen

  • Datenmodellierungsexperten

Die Datenmodellierungsexperten haben umfangreiche Erfahrungen in der Modellierung von (Geo-)Daten, kennen die spezifischen Anforderungen (z. B. aus INSPIRE) und sind dafür verantwortlich, dass Datenmodelle erzeugt werden, die einen realen Sachverhalt hinreichend genau beschreiben.

Sie begleiten aus fachlicher und technischer Sicht die Entwicklung der harmonisierten Datenmodelle mit der Konzeption, Programmierung und Implementierung von entsprechenden Softwarewerkzeugen zur Modellierung und Schematransformation, z. B. mit HALE oder FME.

Beispiel: Geoinformatikexperten aus Verwaltung, Wirtschaft, Wissenschaft und Forschung .

  • Fachexperten

Die Fachexperten, die vorhandene Fachsichten vor dem Hintergrund der Fachaufgabe einbringen und Kenntnisse über die abzubildenden fachlichen Realweltobjekte haben.

Beispiel: Wasserbauingenieure, Hydrologen, Biologen, Geologen

Empfehlungen für die Vorbereitung des Harmonisierungsprozesses

Hinweis: Die folgenden Schritte dienen der Vorbereitung und der Entwicklung des eigentlichen Harmonisierungsworkflows. Die  betroffenen Fachgremien (siehe 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, 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 existiert und ob bereits einheitliche Datenspezifikationen bzw. Anforderungen im Sinne von bundesweiten Vorgaben bzw. Vereinbarungen vorliegen (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. Ebenfalls sollte geklärt werden, auf welchen Ebenen die Zuständigkeiten für die Koordination und Moderation der Harmonisierung liegen.

Als Ergebnis sollte eine Liste von Standards und Spezifikationen erstellt werden, die für das jeweilige Thema bereits Verwendung findet 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 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. HALE oder FME) 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.

Da es für diesen Datenspezifikationsprozess im IT-Planungsrat mit der XÖV-Agenda schon ein etabliertes Vorgehen gibt, ist dessen Nachnutzung zu prüfen. Daher werden die folgenden Maßnahmen vorgeschlagen.

Maßnahmen für GDI-DE:

  • Evaluierung der Anwendung des XÖV-Prozesses zur Erstellung eines Datenmodells
  • Prüfung, ob die GDI-DE Datenmodelle 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 in einer Geodateninfrastruktur Akteure unterschiedliche Rollen (z.B. Nutzer, Entwickler) und dadurch 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 themenübergreifende Standards festgelegt, die zur Beschreibung der Geodaten verwendet werden sollen und Hinweise enthalten, wie sie konkret anzuwenden sind. In der Regel haben Geoinformationsstandards einen sehr breiten Anwendungsbereich und sind unabhängig von Verfahren zur Anwendungsentwicklung und Ansätzen zur Technologie Implementierung. Daher müssen diese Vorgaben für spezielle Anwendungen (z.B. Datenmodellierung) konkretisiert und angepasst werden. Das Ergebnis ist ein "Profil", welches die fachliche Spezifizierung eines allgemein nutzbaren Modells darstellt.

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 existieren im Architekturkonzept jedoch noch keine Vorgaben für die Erstellung eines Referenzmodells. Im entsprechenden Technik-Dokument 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, was konkret zu beachten ist und/oder welche Standards (ggf. Profile) einzusetzen sind. Ohne eine solche Konkretisierung kann aber ein einheitliches Vorgehen bei der Spezifizierung von Geodaten nicht erreicht werden, sodass jede Community ihre eigenen Vorgaben macht, welche 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 Szenarien des Interoperabilitätskonzepts (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 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 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 der INSPIRE-Modellierungsregeln 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).

Im Gegensatz zum Interoperabilitätselement „Referenzmodell“ werden in diesem Abschnitt Regeln für die Bildung und Beschreibung von Datenmodellen der Geodaten beschrieben. Ein Referenzmodell hingegen enthält in erster Linie auf Angaben zu relevanten Standards und wie diese genutzt werden. Zwischen beiden Interoperabilitätselementen gibt es gewisse gegenseitige Abhängigkeiten, z.B. wenn Standards bereits Regeln für die Erstellung von Anwendungsschemata enthalten. Dennoch sind es zwei unterschiedliche Elemente, die auch getrennt voneinander betrachtet werden. 

 

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 ist, 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 derzeit kein explizites UML-Profil für die GDI-DE, allenfalls implizit in Fachmodellen in verschiedenen Anwendungen (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 Wikis 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 umsetzen 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

Es sind Festlegungen erforderlich, 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 Identifkatoren für Metadatensätze, für Geodatenressourcen und Codes für Referenzsysteme. Codes werden in Registern abgelegt.

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.

Üblicherweise 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 sogenannter „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:

Name-space

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 für GDI-DE:

Realisierung eines Prozesses zur Vergabe und Registrierung von Objektidentifikatoren, die folgenden 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 semantisch oder geometrisch 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.

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. ermöglichen, 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:

  • 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 (z.B. CSW) 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  Vorschläge. 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.

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

  • http://oid.gdi-de.org/de.sn.lfulg/12345

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

  • http://oid.gdi-de.org/de.sn.lfulg.np/12345

(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. Um Geodaten in der GDI-DE operabel bereit zu stellen, werden sie mit Hilfe von Metadaten beschrieben. Metadaten und Geodaten werden über Dienste zugänglich gemacht. Metadaten schaffen in einem Geoportal die grundlegende Voraussetzung, dass Geodaten gefunden und genutzt werden können.

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. In vielen nationalen Geodateninfrastrukturen erfolgt derzeit das Bereitstellen dieser Basisinformationen typischerweise über Catalogue Services (Katalogdienste) nach dem ISO 19115/19119 Application Profile.

Hingegen wird für die Beschreibung von Geodaten 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 um Metadaten, auch wenn diese vom klassischen Metadatenbegriff nicht erfasst werden. Bei diesen Ressourcen ist ebenfalls eine Pflege nach wohldefinierten Prozeduren erforderlich. Geänderte oder historisierte Ressourcen sind weiterhin zur Verfügung zu stellen, da diese für in der Vergangenheit erfasste Datenbestände gültig sind und entsprechend zugänglich sein müssen. Außerdem muss jede Ressource mit einem eindeutigen und permanenten Objektidentifikator assoziiert werden. ISO 19135 verwendet hierfür den Begriff Registry . Die Inhalte einer 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 der als allgemeines Dateiübertragungsprotokoll sehr verbreitete HTTP-Aufruf ausreichend ist. Die in Registern verwalteten Ressourcen sind häufig eng mit der Spezifikation und deren Entwicklung verbunden. 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 als zentraler Bestandteil des Aufbaus einer Geodateninfrastruktur entwickelt und festgeschrieben werden muss.

Ebenfalls sinnvoll für eine interoperable Bereitstellung ist eine Komponente zum Test der Konformität der Daten zu den jeweiligen Datenspezifikationen, da oft schon sehr geringe Abweichungen von den Vorgaben die gemeinsame Verwendung von Daten erschwert. Die Kommunikation mit einer solchen Testsuite kann online über das Internet erfolgen. Neben einer geeigneten Software 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. Die Testsuite hat die grundlegende Aufgabe, die Interoperabilität der Geodaten und Metadaten zu prüfen. Es ergibt sich daher die Notwendigkeit, Tests für Metadaten, Darstellungs- und Downloaddienste sowie Datenmodelle bereit zu halten, die nicht von dem INSPIRE Test-Tool abgedeckt werden.

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 Metadaten und Geodatendiensten
  • Der Suchdienst Geodatenkatalog.de, über den alle in der GDI-DE verfügbaren Geodaten und Dienste gefunden werden können
  • Die Webseite Geoportal.de (http://www.geoportal.de/) bietet Anwendern die Möglichkeit, ohne Kenntnis der Request-Parameter für eine CSW-Schnittstelle, im Geodatenkatalog.de zu recherchieren, welche Geodaten und Geodatendienste innerhalb der GDI-DE zur Verfügung stehen
  • Das Auskunftssystem GDI-DE Registry ( https://registry.gdi-de.org/ ) zur Ressourcenverwaltung.

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.

Bei INSPIRE wurden bzw. werden ebenfalls zentrale Komponenten aufgebaut. Die INSPIRE-Registry dient jedoch ausschließlich zur Bereitstellung der eigenen INSPIRE-Ressourcen. Eine Erweiterbarkeit durch die Mitgliedsstaaten ist nicht vorgesehen. Das Gleiche gilt für die im Aufbau befindliche 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 Tests von nationalen und/oder anwenderspezifischen Profilen 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 (z.B. SLD) als Ressource in zentralen Registern in vorgegebenen Formaten abgelegt und zugänglich gemacht werden.

3.5.3     Bewertung und Handlungsbedarf

Die zentralen Komponenten stehen schon weitgehend zur Nutzung bereit und werden stetig weiterentwickelt. 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 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 Registry Owner ist die verantwortliche Stelle für den Betrieb der (jeweiligen) Registry (z. B. GDI-DE).
  • 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.
  • 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 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 in der Regel 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.
  • Erarbeitung eines Workflows zur Codelistenerweiterung durch die betroffenen Stellen
  • Abstimmung bei Codelistenerweiterungen mit international festgelegten Codelisten und Ermittlung der Möglichkeiten für den technischen Zugriff darauf, wie z.B. der INSPIRE-Codelisten-Federation (siehe [INSPIRE Registry Federation]).
  • 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: http://epsg-registry.org ) erfasst und bereitgestellt. Die EPSG ( European Petroleum Survey Group Geodesy) ist eine Arbeitsgruppe der europäischen Öl- und Gaserkundungsunternehmen. 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, die als Ressource in einer Registry abgelegt werden können:

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 :

  • 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 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

Bei OGC, INSPIRE und XÖV werden XML-Schemata in einfachen dateibasierten Repositories über WebServer bereitgestellt. Im Bereich der GDI-DE ist für XML-Schemata ein vergleichbares Repository einzurichten.

Für einzelne Datenanbieter existiert bereits beispielhaft ein XML-Schemaregister. 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.

 


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, 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 eine der 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 Modellierung 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

  • [AB MP GDI-DE Registry 2012]: Abschlussbericht Modellprojekt GDI-DE Registry, Version 1.0. http://www.geoportal.de/SharedDocs/Downloads/DE/GDI-DE/Abschlussbericht_Registry_V1.pdf?__blob=publicationFile
  • [GEOINFODOC]: Dokumentation zur Modellierung der Geoinformationen des amtlichen Vermessungswesens (GeoInfoDok), Version 6.0.1, http://www.adv-online.de/icc/extdeu/broker.jsp?uMen=4b370024-769d-8801-e1f3-351ec0023010
  • [INSPIRE D2.6 2008]: Drafting Team „Data Specifications“ - deliverable D2.6: Methodology for the development of data specifications (Text No. D2.6_v3.0.pdf). INSPIRE Drafting Team „Data Specifications“.
  • [INSPIRE GL ENCODING 2012]: INSPIRE Guidelines for the encoding of spatial data, Version 3.3rc2, http://inspire.jrc.ec.europa.eu/documents/Data_Specifications/D2.7_v3.3rc2.pdf
  • [INSPIRE GCM 2014]: INSPIRE D2.5: Generic Conceptual Model, Version 3.4. http://inspire.ec.europa.eu/documents/Data_Specifications/D2.5_v3.4.pdf [KRÖGER ET AL. 2012]: Kröger, R., Klisch, M., Patzsch, S., Gros, D., Ulbricht, T., Weiß, U., … Zerbe, U. (2012). Geodaten in Kommunen - Leitfaden zur Betroffenheit und Pflichten der Kommunen im Rahmen der europäischen Geodateninfrastruktur. Schriftenreihe des Städte- und Gemeindetages Mecklenburg-Vorpommern e.V., Band 35. Abgerufen von http://www.ego-mv.de/fileadmin/Daten_Infos/Dokumente/GEODATEN_PDF_VERSION.pdf

 

  • [INSPIRE Registry Federation]: Best Practices for registers and registries & Technical Guidelines for the INSPIRE register federation, https://inspire.ec.europa.eu/id/document/tg/registers-and-register-federation
  •    [ KBSt 2006]: Bundesministerium des Inneren, SAGA3 2006 BMI-KBSt: Standards und Architekturen für E-Government-Anwendungen Version 3.0, Berlin, 2006
  •    [OOG 2003]: Open Geospatial Consortium, 2003. The OGC Reference Model. [Online] http://www.opengeospatial.org/
  • [TÓTH ET AL. 2012]: 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. http://inspire.jrc.ec.europa.eu/documents/Data_Specifications/IES_Spatial_Data_Infrastructures_(online).pdf

 

 


Anhang 1: Weitere, noch zu spezifizierende Interoperabilitätselemente

 

Element

Kurzbeschreibung

Abschätzung der derzeitigen Situation in der GDI-DE (nicht abschließend)

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

Derzeit sind keine übergreifenden konkreten Vorgaben bzw. detaillierte Regelungen in der GDI-DE vorhanden. Beispiele sind im Bereich der Raumplanung (Crossdata (CILC3)-Projekt) zu finden oder EIONET Gemet Thesaurus. Dieser umfasst bereits  alle 24 offiziellen Sprachen der EU und bildet damit einen Ausgangspunkt für die Nutzung von mehrsprachigen Daten.

Nutzung von Ontologien

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

Derzeit keine Nutzung.

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. Dies umfasst auch die Kodierung von Daten.

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 diskutiert

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 für Geodaten. Die Datenqualität kann in den Metadaten angegeben werden, soweit bekannt.

Qualitätsangaben können derzeit noch nicht automatisch ausgewertet werden.

Metadaten (auch fachspezifisch)

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

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

Darüber hinaus gibt es im Dokument "Architektur der Geodateninfrastruktur Deutschland - Konventionen zu Metadaten“ konkrete Vorgaben zu einzelnen Metadaten-Elementen.

Konformität

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

In GDI-DE derzeit für Geodaten nicht vorhanden

Erfassungs-kriterien und Datenpflege

Festlegungen zur Erfassung und Fortführung (Datenpflege) 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.

Regeln zur Datenpflege (Aktualität, Informationen über Datenänderungen) werden in der Regel in Produktspezifikationen festgelegt.  GDI-DE könnte allgemeine Grundsätze zur Information über Datenänderungen vorgeben.

 

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

Methodik zur Spezifikation und Organisation von Darstellungsregeln

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

 

 


[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 )