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

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

28 .04.2016 20.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

 

 

 

 

 

 

 

 

 


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

2 Einführung ................................................................................................................. 5

3 Interoperabilitätselemente ...................................................................................... 7

3.1 Organisatorische Anforderungen .................................................................... 7

3.1.1 Beschreibung ............................................................................................... 7

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

3.1.3 Bewertung, Handlungsbedarf und Empfehlungen ................................ 8

3.2 Regeln für das Anwendungsschema ............................................................. 11 10

3.2.1 Beschreibung ............................................................................................. 11

3.2.2 Aktueller Stand in INSPIRE und der GDI-DE ....................................... 12 11

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

3.3 Identifikatormanagement ............................................................................... 14 13

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

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

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

3.4 Registry ............................................................................................................. 18 17

3.4.1 Beschreibung ............................................................................................. 18 17

3.4.2 Aktueller Stand in GDI-DE und Handlungsbedarf ............................... 19 18

3.5 Verwaltung und Bereitstellung von Schemadateien .................................. 22 21

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

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

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

4 Ausblick .................................................................................................................... 24 22

Referenzen ...................................................................................................................... 25 23

Anhang 1: Weitere noch zu spezifizierende Interoperabilitätselemente .............. 27 24


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 sind 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 Datenmodelle einen bundesweit einheitlichen Datenbestand zur Unterstützung nationaler und internationaler Fragestellungen zu schaffen, soll       anhand von konkreten Anwendungsfällen angegangen werden, indem zunächst die oben genannten betroffenen oben genannten 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 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, , der sich mit der Frage beschäftigt, was sollte wie stark zwischen den einzelnen Themen und Fachdaten innerhalb der GDI-DE harmonisiert werden soll , soll , um damit den Anforderungen an die angestrebten fachlichen Produkte 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 dazu hierbei   sinnvoll.

Keinesfalls sollen mit dem Interoperabilitätskonzept verpflichtend umzusetzende Datenspezifikationen analog zu INSPIRE vorbereitet, erstellt und beschlossen werden. Dieses Dokument macht zeigt   lediglich Vorschläge (Handlungs-)Empfehlungen auf , 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.

Dieses Dokument soll das Architekturkonzept der GDI-DE       als eigenständiges Modul ergänzen und bedarfsweise entsprechend fortgeschrieben werden.

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ätselementen der GDI-DE (z. B. Registry) angepasst oder ergänzt werden. Hierfü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 als 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 müssen sollte   und legt entsprechende Anforderungen sowie Empfehlungen fest.

Die se dort genannten Aspekte 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 enthält stellt eine Übersicht über die für die interoperable Bereitstellung von Geodaten erforderlichen Elemente dar . Die farblich hervorgehobenen Elemente (orange) sind von der AG Geodaten priorisiert und für die oben beschriebenen Anwendungsfälle als unbedingt notwendig erachtet worden. Weiterhin sind d D ie einzelnen priorisierten       Elemente sind in den nachfolgenden Kapiteln detailliert beschrieben. Durch weitere andere mögliche Anwendungsfälle können auch zusätzliche       oder abweichende Interoperabilitätselemente als hoch wichtig priorisiert werden.

Die umfassende Beschreibung der übrigen Interoperabilitätselemente soll schrittweise erfolgen. Im Anhang 1 wurden z unächst     überblicksartig   ist eine Übersicht zu den die anderen/restlichen Interoperabilitätselemente zu finden, jeweils mit einer kurzen Beschreibung sowie einer Katgeorie Kategorisierung n   beschrieben und für die weitere Spezifizierung kategorisiert .

 

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

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

Grundsätzlich sollte   ist   die GDI-DE für die Bereitstellung von nicht-INSPIRE-Daten offen gemäß bereits gebräuchlicher Datenspezifikationen offen sein   , sowohl in Bezug auf bereits gebräuchliche Datenspezifikationen ,   die Semantik und als auch auf   die Datenformate. Die vorgeschlagenen Interoperabilitätselemente definieren legen somit nur einen grundlegenden Rahmen fest , der für eine interoperable Modellierung und Bereitstellung von Geodaten aller Fachdisziplinen innerhalb der GDI-DE angelegt genutzt   werden sollte.

Für die GDI-DE wird im Folgenden 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 in bei   INSPIRE , da bereits durch die Richtlinie     (wo durch die Vorgaben der Richtlinie bereits recht sehr strikte Vorgaben bestehen, die für nicht-INSPIRE-Daten in der GDI-DE derzeit   so nicht sinnvoll zwingend erforderlich   sind ) . Präzise Anforderungen werden nur bei Interoperabilitätselementen vorgegeben gemacht , bei denen die GDI-DE bereits konkrete Lösungen (z. B. zentrale Betriebskomponenten) hat oder verfolgt, die auf die speziellen Rahmenbedingungen in der GDI-DE zugeschnitten sind.

Grundsätzlich beziehen sich die Interoperabilitätselemente auf Datenmodelle, die für eine übergreifende Geodatennutzung vorgesehen sind (sog. Bereitstellungsmodell e ). Auch die INSPIRE-Datenmodelle gelten als derartige Bereitstellungsmodelle. Völlig anders Abweichen d 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 für die GDI-DE priorisierten Interoperabilitätselemente beschrieben (vgl. Abbildung 1 ) ,     sowie 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       Prozess e       (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 en gute n r Ü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   diesem Dokument   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.

Vor allem U u nter Berücksichtigung der föderalen Besonderheiten und Zuständigkeiten in Deutschland ist wird mit diesem Interoperabilitätskonzept ein vergleichbares einheitliches   Vorgehen im Rahmen der GDI-DE, der Länder-GDIs sowie auf regionaler und kommunaler Ebene noch nicht beschrieben definiert .

3.1.3     Bewertung, Handlungsbedarf und Empfehlungen

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

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

Zuvor sind die wesentlichen Akteure und deren Rollenverteilung an zu ge geben und entsprechende Beispiele an zu ge führ en t .

Empfehlungen für die Rollenverteilung im Harmonisierungsprozess von Datenmodellen

Die f F olgenden 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 sind.

  • Datennutzer

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

Beispiel 1: Datennutzer N utzer 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 de r m Privatbürgertum Öffentlichkeit bzw. Privatpersonen .

  • Koordinatoren/Moderatoren

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

Beispiel: Fachnetzwerke, Arbeitsgruppen der GDI-DE oder Einzelpersonen

  • Generelle Datenmodellierungsexperten

Die generellen Datenmodellierungsexperten haben weitreichende umfangreiche   Erfahrung 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 Entwicklung 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 INSPIRE-Fachnetzwerke   betroffenen Fachgremien (siehe oben) sollen in die Vorbereitung mit einbezogen werden.

  1. Identifizierung eines Anwendungsfalls

Vor den nach folgenden Schritten soll t en ein oder mehrere Anwendungsfälle beschrieben werden, die auf einer Ist-Analyse basieren. Die darauf aufbauend zu entwickelnden Anwendungsfälle soll t en auch die eigentliche Implementierung inklusive des entsprechenden Testens und Validierens umfassen sowie Schritte für das Fortschreiben des Datenmodells vorgeben. Für die letzteren letztgenannten   Schritte soll t en die Koordinatoren/Moderatoren verantwortlich sein. Die Aktivitäten soll t en 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 unter Berücksichtigung der föderalen Strukturen   involviert werden. Bei der Zusammenstellung Erstellung der Liste sollten   vorhandene Strukturen, wie z. B. die Fachnetzwerke für die Erweiterung von INSPIRE-Datenmodellen oder vorhandene Listen mit den geodatenhaltende n r Stellen für die INSPIRE-Annexthemen, genutzt werden. Die Fachnetzwerke könn t en bei der Listenerstellung E rstellung 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, als zum anderen   auch für die spätere Harmonisierung der Datenmodell e   harmonisierung . 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 es aufgrund der zurzeit unterschiedlich verwendeten Datensätze Harmonisierungsbedarf existiert und ob bereits eine einheitliche Datenspezifikationen bzw. Anforderungen im Sinne von bundesweiten Vorgaben bzw. Vereinbarungen vorliegt (z. B. die Verwaltungsvereinbarung zum Austausch von Umweltdaten oder abgestimmte Datenmodelle für das Reporting und elektronische Berichterstattung). Hierzu soll t en 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 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 r inhaltliche r und technische r Anforderungen an das harmonisierte Datenmodell darstell en , erstellt werden . Weiterhin soll t en 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 an den aus INSPIRE bekannten Schritten für den Datenspezifikationsprozess zu orientieren (siehe Abb. 2; INSPIRE , D2.6 2008; [TÓTH ET AL. 2012] Tóth u. a., 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       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:

  • Evaluierung der Anwendung des XÖV- Prozesses zur Erstellung eines Datenmodelles
  • Prüfung, ob 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.

 

Referenzmodell

 

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 d as Open Geospatial   Consortium (OGC) benutzt 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 unterschiedliche Rollen (z.B. Nutzer, Entwickler ) ) haben kann und damit unterschiedliche Sichten auf diese Infrastruktur haben werden können . Jede Gruppe von Akteuren wird das System oder die Infrastruktur aus ihrem individuellen Blickwinkel (viewpoint) sehen .

E E in zukünftiges Referenzmodell der GDI-DE wird kann somit aus verschiedenen Blickwinkeln 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 ausschließlich schwerpunktmäßig auf die formale Beschreibung von Geodaten und die Integration in bestehende eGovernment -Prozesse .   Die Beschreibung s e umfasst beispielsweise auch die logischen, zeitlichen, räumlichen und semantischen Zusammenh änge und dient der Standardisierung und Dokumentation der beschriebenen Objekte der realen fachlichen Welt.

Aktueller Stand in INSPIRE und der GDI-DE

Bei der Entwicklung der INSPIRE-Datenspezifikationen wurden Themen-übergreifend diejenigen Standards festgelegt, die zur Beschreibung der Geodaten verwendet werden sollen und wie sie konkret anzuwenden sind. Da Geoinformationsstandards in der Regel einen sehr breiten Anwendungsbereich haben sowie 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 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. [MS2] 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 Model s ein Referenzmodell für die GDI-DE zu erstellen.

Derzeit macht das Architekturkonzept jedoch noch keine Vorgaben für die Erstellung eines Referenzmodells. Im Technikdokument wird lediglich empfohlen, bei der Entwicklung neuer Geodatenspezifikationen innerhalb der GDI-DE grundsätzlich auf der Normenserie ISO 19100 aufzusetzen. Was konkret zu beachten ist und welche Standards (ggf. Profile) einzusetzen sind, wird nicht   näher beschrieben. Ohne eine solche Konkretisierung wird aber ein einheitliches Vorgehen bei der Spezifizierung von Geodaten nicht erreicht, was bedeutet, dass jede Community ihre eigenen Vorgaben macht, was zu unkalkulierbaren Aufwänden bei der Zusammenführung von Daten aus unterschiedlichen Quellen führen kann. Um interoperable Geodaten in der GDI-D E 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.

Bewertung und Handlungsbedarf

Für die beiden definierten Anwendungsfälle des Interoperabilitätsrahmens (siehe Kap. 1) sind werden dringend abgestimmte Vorgaben (durch Fachgremien) für die Modellierung eine benötigt wichtige Grundlage . Optimal wäre 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 w ird erden könnte . Mit einem derartigen Referenzmodell wird könnte   festgelegt werden , 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 sollten Methoden und Vorgaben zu den Inhalten der Modelldokumentation und zur Ableitung von Objektartenkatalogen aus dem UML-Modell festgelegt werden werden .

Maßnahmen:

  • Festlegung von ISO 19101 als G rundlage für die standardisiert e n Beschreibung d er 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.2     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.2.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 fest ge legen. 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 vo n m Geodaten zur Repräsentation von Realweltobjekten gebildet und beschrieben (Inhalt und Struktur, Modellkonstrukte) werden bzw. wie existierende Anwendungsschemata erweitert werden (z. B. INSPIRE Schemata).

3.2.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 und verpflichtenden Attributen:

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

  • Gibt Wenn es 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:
    • w enn 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 bindende n 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 explizit kein UML-Profil für die GDI-DE, allenfalls implizit in verschiedenen Anwendungen in Fachmodellen (z. B. AAA-Datenmodell der AdV).

3.2.3     Bewertung und Handlungsbedarf

 

Entwicklung eines GDI-DE- Referenzmodells

Für die beiden definierten Anwendungsfälle des Interoperabilitätsrahmens (s iehe . in Kap. 1) werden dringend abgestimmte Vorgaben (durch Fachgremien) für die Modellierung benötigt. Optimal wäre in diesem Zusammenhang   ein fachneutraler   Modellierungsrahmen , d er als Basis für alle Fachdaten in UML nach ISO 19109 zusammen mit einem GDI-DE-UML-Profil angewendet werden könnte. Mit einem derartigen Referen z modell könnte festgelegt werden , welche ISO/TC 211   Standards erfüllt werden müssen bzw. sollten und Hilfestellungen bzgl. der Nutzung von Standards gegeben . Darüber hinaus sollten Methoden und Vorgaben zu den Inhalten der Modelldokumentation und zur Ableitung von Objektar tenkatalogen aus dem UML-Modell festgelegt werden .

Best Practices für die Entwicklung von Anwendungsschemata für die GDI-DE

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 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 muss sollte n   unter anderem sollten i nhaltlich Folgendes inhaltlich geklärt werden:

  • Allgemeine Fragen zur Modellierung :  
    • Welche Vorteile hat ein auf internationalen Standards basierendes Datenmodell?
    • Welche Alternativen gibt es und haben welche diese Vorteile/Nachteile haben diese ?
    • Welche Software wird genutzt bzw. eingesetzt (UML Modellierung, Ableitung des XML Schema ta s , 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 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 Verpflichtung en der INSPIRE-Vorgaben umzusetzen?
    • 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:

  • Erstellung von abgestimmten Modellierungsvorgaben für Datenmodelle der GDI-DE
  • Entwicklung eines Referenzmodells für die Datenmodellierung für die GDI-DE
  • Einbringen der Ergebnisse Einrichtung eines Wikis für Best Practices Beispielen   für die Modellierung von Anwendungsschemata für die GDI-DE in   bestehende   eGovernment -Prozesse    

 

3.3     Identifikatormanagement

3.3.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. D a rü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   unterstützen ;       (eindeutige) Objektidentifikatoren erlauben bzw. ermöglichten den Zugriff auf die Geoobjekte, z. B. zum Verlinken von externen Daten auf die Geoobjekte.

3.3.2     Aktueller Stand in INSPIRE und der GDI-DE

 

INSPIRE-Vorgaben

-           INSPIRE hat hier Grundlagenarbeit geleistet (insb. INSPIRE D2.5 V 3.4 [ 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 . enannte „spatial objects“, im Folgenden Geoobjekte genannt [1] . Ein Objektidentifikator (OI) bezieht sich nicht auf ein real-weltliches Phänomen (z. B. einen bestimmten Baum oder ein en   bestimmte n   See), sondern auf dessen Abstraktion (= ein Geoobjekt). Unterschiedliche Abstraktionen des gleichen real-weltlichen Phänomens erhalten       unterschiedliche Objektidentifikatoren.

Üblichweise wird D d ie Art der Abstraktion wird üblicherweise 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 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.3.3     Bewertung und Handlungsbedarf

3.3.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 ( nun 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:

4         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 kann .
  • 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 K k lare Benennung der verantwortlichen Stellen für die Pflege der Objektidentifikatoren ist zwingend erforderlich . Ihnen obliegt die Durchsetzung bzw. Einhaltung dieser Anforderungen.

4.1.1.1 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 unkonkret 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 sich 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:

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

4.1.1.2 Rückverfolgbarkeit

INSPIRE fordert einen Mechanismus zur Auffindbarkeit von Geoobjekten, basierend auf dem jeweils dazugehörigen       Objektidentifikator. Ein Objektidentifikator muss daher ausreichend 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 eine s m Digitalen Objektbezeichner s (DOI). Über den Namensraum des Objektidentifikators lässt sich der Datenprovider identifizieren und in dessen Bestand (Katalog) das Geoobjekt finden.

Maßnahmen:

  • Verbindung 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 bereit ge stellt 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.

4.1.1.3 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:

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 nur noch umzusetzen.

Nutzung zentraler Komponenten der GDI-DE

 

Noch behandeln (?):

Beschreibung, wie die Zusammenarbeit bzw. die Prozesse zwischen den Komponenten erfolgen. Relevante Fragestellungen sind u.a.

  • Welchen Stellenwert hat die Testsuite? Evtl. eigenes Kapitel
  • Was fehlt aus unserer Sicht?
  • 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?

 

Beschreibung

Eine zentrale Komponente der GDI-DE ist ein Werkzeug, da s alle Akteure der GDI-DE benötigen. Durch die zentrale Bereitstellung und Pflege entfällt der mehrfache Implem e ntierungs- und Pflegeaufwand bei den jewei ligen Datenanbietern. Wenn Geodaten in der GDI-DE interoperabe l bereitgestellt werden sollen, dann müssen sie über die anderen Komponenten einer GDI (Met adaten, 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. Metadate n-I n f ormatio n ssysteme werden über Webdienste vernetzt, die Aktualisierung erfo l gt automatisch. Das Bereitstellen dieser Basisinformationen erfolgt in vielen nationalen Geodateninfrastrukturen derzeit typischerweise über Catalogue Services (Katalogdienste) nach dem ISO 19115/19119 Application Profile .

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 von klassischen Metadatenbegriff nicht erfasst werden. Auch b ei diesen Ressourcen ist eine Pflege nach wohldefinierten Prozeduren erforderlich. Auch müssen geänderte oder historisierte Ressourcen weiterhin zur Verfügung stehen, da diese natürlich weiterhin für in der Vergangenheit erfasste Datenbestände gültig sind und entsprechend zugänglich sein müssen. Jede Ressource muss außerdem mit einem eindeutigen und permanenten Identifikator assoziiert werden.   ISO 19135 verwendet hierfür den Begriff Re gistry . Die Inhalte eines Re gistry werden über das Internet online verfügbar gemacht ( Näheres siehe im Abschnitt Registry). Spezielle Registry -Dienste werden aus heutiger Sicht nicht benötigt, es reicht der als allgemeines Dateiübertragungsprotokoll sehr verbreitet e HTTP -Aufruf. In Registern verwaltete Ressourcen sind häufig Ressourcen, die eng mit der Spezifikationen 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, dass ein klares, nachhaltiges Organisationsmodell hierfür als zentraler Bestandteil des Aufbaus einer Geodateninfrastruktur entwickelt und festgeschrieben werden muss.  

Für eine interoperable Bereitstellung ist auch eine Komponente zum Test der Konformität der Daten zu den jeweiligen Datenspezif i kationen sinnvoll , da oft schon sehr geringe Abweichungen von den Vorgaben die gemeinsame Verwendung von Daten unmöglich macht. Die Kommunika tion mit eine r solchen Testsuit e 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 anwenderspezif isch erweitert werden können .

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 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 , die Anwendern einfache Möglichkeiten bietet, Geodaten zu recherchieren, zu verknüpfen und in Karten anzeigen zu lassen
  • Das Auskunftssystem GDI-DE Registry zur Verwaltung und technischen Unterstützung übergreifender Konzepte.

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

Auch bei INSPIRE wurden, bzw. werden zentrale Komponenten aufgebaut. Die INSPIRE-Regi s try dient jedoch ausschließlich zur Bereitstellung der eigenen Ressourcen. Eine Erweiterbarkeit durch die Mitgliedsstaaten ist nicht vorgesehen. Das gleiche 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. Der Test von nationalen und anwenderspezifischen Profilen muss daher auch künftig von der GDI-DE-Testsuite durchgeführt werden.

In Geo d ateninfrastrukturen werden Geodaten mit Hilfe von Diensten über das Internet bezogen , die unterschiedliche Funktionen haben können . Die Spezifikation en 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 s w ein , die in zentralen Registern in vorgegebenen Formaten abgelegt und zugänglich gemacht werden müssen .

Bewertung und Handlungsbedarf

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


 

M aßnahmen:  

  • Als Konsequenz ergibt sich, dass e Es muss e in klares, nachhaltiges Organisationsmodell für alle zentralen Komponenten als zentraler Bestandteil des Aufbaus einer Geodateninfrastruktur entwickelt und festgeschrieben werden muss .
  •  

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 Noch behandeln (?):

  • Beschreibung, wie die Zusammenarbeit bzw. die Prozesse zwischen den Komponenten erfolgen. Relevante Fragestellungen sind u.a.
  • Welchen Stellenwert hat die Testsuite? Evtl. eigenes Kapitel
  • Was fehlt aus unserer Sicht?
  • 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 mit andere n e Open- Government - Komponenten Dienste und -Standards?
  •  

 

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

4.2.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 w e i rd en . 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 [AL3] 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:

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

Ohne die verbindliche Festlegung dieser Rollen wird eine Registry auf Dauer nicht funktionieren. Eine Registry kann unterschiedliche Ressourcen enthalten. Ohne die verbindliche Festlegung dieser Rollen wird eine Registry auf Dauer nicht funktionieren. Der Begriff einer Codelisten-Registry wird verwendet, wenn die Ressourcen die Codelisten eines Datenmodells sind.  

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.

4.2.2      

4.2.2.1 Codelisten-Registry

Häufig verwendete oder nach einem vorgegebenen Konzept zu beschr e i e ben d e 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 D d er Einsatz eines Registers für Codelisten unterstützt :

  • die zuständigen Stellen , bei der Pflege der Codelisten und der enthaltenen Codes,
  • die Datenerfasser , bei der Auswahl eines geeignete n r 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 von zwischen den Datenanbieter n zu Datenanbieter 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:

  • 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 von 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).

 

4.2.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 en in ein einheitliches CRS gebracht werden.

Die Verknüpfung der Geometrien eines       Datensatzes zu 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. aus zu werten 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 [AL4] ) 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 andere r geodätische r 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:

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:

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 vorhanden geführt   sind werden .    

4.2.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:

Tab elle . 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

 

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.

4.3     Verwaltung und Bereitstellung von Schemadateien

4.3.1     Beschreibung

Dieses Interoperabilitätselement enthält Festlegungen, wie Datenmodelle und Schemata in Registries verwaltet und 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 sind dadurch in der Lage, diese XSD-Datei direkt online zu verwenden bzw. abzurufen oder zur lokalen Speicherung herunterzuladen.

4.3.2     Aktueller Stand in INSPIRE und der GDI-DE

XML-Schemata werden bei OGC und INSPIRE in einfachen dateibasierten Repositories über WebServer bereitgestellt. Diese Bereitstellung Zurverfügung stellung 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 A a ufgrund der unterschiedlichen Ansätze und Lösungen bei den Datenanbietern wird i m Gegensatz zu den XML-Schemadateien 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.

4.3.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:

Zentrale Bereitstellung aller erforderlichen Schemadateien durch die jeweiligen Datenanbieter, welche die 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. [AL5]


5         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 mit anhand von konkreten Elementen begonnen, das 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 vorgeschlagen , 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 vorgeschlagenen 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. Kst . 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 für der   die notwendigen weiteren Arbeiten für die Spezifizierung der Interoperabilitätselemente.       Aus diesem Grund müssen D d ie Arbeiten daran müssen daher fortgesetzt werden. Zudem ist die Umsetzung und Begleitung der vorgeschlagenen Maßnahmen zu organisieren. Hierzu sind insbesondere auch die Fachgremien einzubeziehen.

Ebenso besteht B b ei der weiteren Entwicklung des Interoperabilitätskonzeptes besteht auch ein dringender Bedarf an einer engen Abstimmung mit den XÖV-Standards, um ggf. vorhandene Interoperabilitätskomponenten gemeinsam zu nutzen und die ggf. unterschiedlichen Methoden und Konzepte einander an zu gleichen 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 künftig 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

 

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

  [ KBSt 2006 ] : Bundesministerium des Inneren, SAGA3 2006 BMI-KBSt: Standards und Architekturen für E-Government-Anwendungen Version 3.0, Berlin, 2006

[O OG 2003]: Open Geospatial Consortium, 2003. The OGC Reference Model.   [Online] http://www.opengeospatial.org/  

  • [PORTELE 2012]: Portele,C . (2012) Präsentation : Spatial Data Interoperability in INSPIRE, https://www.paikkatietoikkuna.fi/documents/108478/45ee0d1c-7285-4ae5-9170-7f8ea75411ab
  • [TÓTH ET AL. 2012]: Tóth, K., Portele, C., Illert, A., Lutz, M., Nunes de Lima, V. (2012): JRC Reference Report s : 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
  •  
  •   [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
  • [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“. http://inspire.ec.europa.eu/reports/ImplementingRules/DataSpecifications/D2.6_v3.0.pdf
  • 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  
  •   [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
  •   [PORTELE 2012]: Portele,C. (2012) Präsentation: Spatial Data Interoperability in INSPIRE, https://www.paikkatietoikkuna.fi/documents/108478/45ee0d1c-7285-4ae5-9170-7f8ea75411ab
  • [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


Anhang 1: Weitere noch zu spezifizierende Interoperabilitätselemente

 

Element

Kurzbeschreibung

Abschätzung der derzeitigen Situation in der GDI-DE

Kategorisierung der AG Geodaten

A=vorrangig zu entwickeln

B=nachrangig zu entwickeln

Modellierungs-grundsätze

Zusammenstellung der grundlegenden Modellierungsprinzipien 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)

A

Referenzmodell

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

In GDI-DE bisher nicht als Referenzmodell vorhanden

A

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.

A

Terminologie

Festlegungen von wesentlichen Begriffen und deren Definition

In GDI-DE derzeit nicht vorhanden

B

Innerhalb eines Fachnetzwerkes jedoch: A

Mehrsprachigkeit

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

In GDI-DE derzeit nicht vorhanden

GDI-DE-intern: B

Für INSPIRE: A

 

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

B

 

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.

B

Verwendung fachübergreifender Modellelemente

 

Festlegungen, wie mit übergreifend genutzten Modellelementen umgegangen wird

In GDI-DE derzeit nicht vorhanden

Derzeit B

Mit zunehmenden Fachmodellen: A

Umgang mit Maßstäben

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

In GDI-DE derzeit nicht vorhanden

 

 

A

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

A

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

 

A

 

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.

B

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.

B

Konformität

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

In GDI-DE derzeit für Geodaten nicht vorhanden

A

 

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.

B

 

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

A

 

Präsentation

Festlegungen zur Darstellung von Geodaten in Karten

In GDI-DE derzeit nicht vorhanden

B

Ontologien

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

Derzeit keine Nutzung.

B

 


 


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


[MS1] Bild noch anpassen, wenn klar ist, welche Komponenten alle beschrieben sind.

[MS2] Auch als Best Practice für GDI-DE vorschlagen oder etwas eigenen erstellen?

[AL3] Ggf. in „Gegebenheiten“ umformulieren.

[AL4] Ist dies die einizige CRS-Datenbank oder gibt es noch Weitere? Ansonsten ggf. ein „z.B.“ einfügen.

[AL5] Könnte dies auch ggf. als Maßnahme formuliert werden?