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 der GDI-DE

GDI-DE Interoperabilitätskonzept

 

 

ENTWURF

 

 

Arbeitsgruppe Geodaten

29.02.2016

 

Dieses Dokument gibt eine Übersicht über die Anforderungen für die interoperable Bereitstellung von Geodaten innerhalb der Geodateninfrastruktur Deutschland (GDI-DE).


Dokumenteninformation

Bezeichnung

GDI-DE Interoperabilitätskonzept

Autor

AG Geodaten

Erstellt am

01.02.2016

Zuletzt geändert

 

Bearbeitungszustand

x

in Bearbeitung

 

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

 

Stepha n Mäs

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


Inhalt

Dokumenteninformation

Änderungsverzeichnis

1 Ziele des Interoperabilitätskonzepts

2 Einführung

3 Interoperabilitätskomponenten

3.1 Organisatorische Handlungsempfehlungen für Datenmodellierung

3.1.1 Beschreibung

3.1.2 Aktueller Stand in INSPIRE und GDI-DE

3.1.3 Bewertung, Handlungsbedarf und Empfehlungen

3.2 Regeln für die Erstellung von Anwendungsschemata

3.2.1 Beschreibung

3.2.2 Aktueller Stand in INSPIRE und GDI-DE

3.2.3 Bewertung und Handlungsbedarf

3.3 Identifikatoren Management

3.3.1 Beschreibung

3.3.2 Aktueller Stand in INSPIRE und GDI-DE

3.3.3 Bewertung und Handlungsbedarf

3.4 Registry

3.4.1 Beschreibung

3.4.2 Aktueller Stand in GDI-DE und Handlungsbedarf

3.5 Bereitstellung von Schemadateien

3.5.1 Beschreibung

3.5.2 Aktueller Stand in INSPIRE und GDI-DE

3.5.3 Bewertung und Handlungsbedarf

Referenzen

Anhang 1: Anforderungen an die Codelistenregistry

Anhang 2: CRS der Marine Dateninfrastruktur Deutschland


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 nach § 3 Abs. 4 GeoZG die Kombinierbarkeit von Daten bzw. die Kombinierbarkeit und Interaktionsfähigkeit verschiedener Systeme unter Einhaltung gemeinsamer Standards verstanden. Dieses Dokument verfolgt zwei Ziele:

  1. Die Spezifizierung von Komponenten, die für eine interoperable Bereitstellung von Geodaten der GDI-DE erforderlich sind.
  2. Die Festlegung einer Methodik für eine schrittweise Harmonisierung vorhandener Datenbestände und Datenmodelle innerhalb der GDI-DE.

Die Datenmodellharmonisierung soll jedoch nur bei konkreten Anwendungsfällen angegangen werden, indem zunächst die betroffenen Fachnetzwerke identifiziert (gemäß Meldeliste INSPIRE), 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, nicht jedoch solche auf regionaler oder lokaler Ebene.

Im Rahmen der GDI-DE sollte ein gemeinsames Verständnis der „Interoperabilität“ für Datenmodelle hergestellt und geklärt werden. Dieses gemeinsame Verständnis ergibt sich aus dem Spannungsfeld zwischen einerseits einer möglichst vollständig harmonisierten Datenmodellierung und andererseits 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 sollte die Entwicklung eines „Leitbilds“ für das Interoperabilitätskonzept hervorgehen, das sich mit der Frage beschäftigt, was wie stark zwischen einzelnen Themen und Fachdaten innerhalb der GDI-DE harmonisiert werden soll. Zur Umsetzung der Erkenntnisse dieses Leitbilds sollten entsprechende benötigte zentrale Komponenten identifiziert werden, und festgelegt werden in wessen Verantwortungsbereich die Bereitstellung und Laufendhaltung dieser Komponenten liegt. Ein Einbeziehen und Koordinieren in den INSPIRE-Fachnetzwerken wäre dazu sinnvoll.

Keinesfalls sollen verpflichtend umzusetzende Datenspezifikationen analog zu INSPIRE erstellt und beschlossen werden. Dieses Dokument macht lediglich Vorschläge, 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 zu fördern.

Dieses Dokument enthält Vorschläge für Interoperabilitätskomponenten, die einzeln oder in Gruppen in das Architekturkonzept der GDI-DE übernommen werden können.

Um die Anwendbarkeit dieses Konzepts zu demonstrieren, wird vorgeschlagen, zwei Anwendungsfälle exemplarisch durchzuspielen:

  • Für eine Fachdomäne existiert bereits ein formalisiert beschriebenes Datenmodell und dieses soll durch vorhandene oder noch zu entwickelnde Interoperabilitätskomponenten der GDI-DE (z.B. Registry) angepasst oder ergänzt werden.
  • Für eine Fachdomäne existiert noch kein formalisiert beschriebenes Datenmodell und es soll ein neues Datenmodell erstellt bzw. das entsprechende INSPIRE-Kerndatenmodell erweitert / verfeinert werden.

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

2         Einführung

Die INSPIRE-Richtlinie macht bereits detaillierte Vorgaben zur Interoperabilität von Geodaten. Um Geodaten in INSPIRE themen-, maßstabs- und länderübergreifend interoperabel verfügbar machen zu können, wurde in INSPIRE ein sog. Interoperabilitätsrahmen („Interoperability Framework“) entwickelt. Eine verallgemeinerte Dokumentation wurde in 2012 als JRC Reference Report "A Conceptual Model for Developing Interoperability Specifications in Spatial Data Infrastructures" [Referenz] veröffentlicht. Dieser identifiziert, welche Aspekte für die Interoperabilität und ggf. auch Harmonisierung der Geodaten betrachtet werden müssen und legt entsprechende Anforderungen und Empfehlungen fest.

Diese Aspekte gelten im Wesentlichen auch für andere Rahmenbedingungen und werden mit diesem Dokument auf die interoperable Bereitstellung von Geodaten in der GDI-DE übertragen. Die in diesem Dokument vorgeschlagenen Aspekte eines Interoperabilitätskonzepts basieren somit auf dem „INSPIRE Interoperability Framework“. Die Abbildung 1 enthält eine Übersicht über die für die interoperable Bereitstellung von Geodaten erforderlichen Elemente. Die farblich hervorgehobenen Elemente wurden von der AG Geodaten priorisiert und für die oben beschriebenen Anwendungsfälle als unbedingt notwendig betrachtet. Ein Bezug zu den Kapiteln in diesem Dokument ist ebenfalls enthalten, in denen die einzelnen Elemente detailliert beschreiben werden. Die Beschreibung der übrigen Interoperabilitätselemente soll schrittweise erfolgen.

 

Abb.1: Übersicht über die Interoperabilitätskomponenten der GDI-DE

Dieses Dokument ergänzt die von INSPIRE vorgeschlagenen Interoperabilitätselemente um einige für die GDI-DE relevante Aspekte, beschreibt kurz die dafür erforderlichen Interoperabilitätskomponenten und die daraus abgeleiteten konkreten Maßnahmen. Ergebnisse sollten in die GDI-DE Architektur einfließen und schrittweise umgesetzt werden.

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

Für jedes Element des Interoperabilitätskonzepts wird hier der englische Titel aus dem JRC Reference Report verwendet, um den Bezug zu Kapitel 4 des INSPIRE-Dokuments eindeutig zu halten. Wo dies nicht der Fall ist (z.B. weil die Komponente ergänzt wurde), werden deutsche Begriffe verwendet.

Für die GDI-DE wird im Folgenden festgelegt, welche Festlegungen für Geodaten gelten sollen. Es ist davon auszugehen, dass die Vorgaben in Bezug auf Bereitstellung von interoperablen Datensätzen in der Regel deutlich weniger detailliert als in INSPIRE sind (wo durch die Vorgaben der Richtlinie bereits recht strikte Vorgaben bestehen, die für nicht-INSPIRE-Daten in der GDI-DE so vermutlich nicht sinnvoll sind). An anderer Stelle werden hingegen wesentlich detaillierter Vorgaben gemacht, nämlich an Stellen, bei denen GDI-DE schon konkrete Lösungen (z.B. zentrale Betriebskomponenten) hat oder verfolgt, die auf die speziellen Rahmenbedingungen in der GDI-DE zugeschnitten sind.

 

3         Interoperabilitätskomponenten

In diesem Kapitel werden die für die GDI-DE priorisierten Interoperabilitätskomponenten beschrieben sowie der aktuelle Stand bewertet und mögliche Maßnahmen formuliert.

3.1     Organisatorische Handlungsempfehlungen für Datenmodellierung

3.1.1     Beschreibung

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

Dies bezieht sich besonders 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 gilt es zu klären, wer die Datenmodelle für die Datenbereitstellung nutzt und wer die Nutzer der bereitgestellten Daten bzw. Dienste sind, wer den Prozess wie moderiert und wie die Erfüllung der Nutzeranforderungen überprüft werden.

3.1.2     Aktueller Stand in INSPIRE und GDI-DE

Auf europäischer Ebene für INSPIRE wird das Vorgehen durch die jeweiligen Organisationsmodelle beschrieben. Einen guten Überblick über den Prozess und seine Anforderungen wird im JRC Reference Report 2012 zum Conceptual Model gegeben. Weitere Details können den definierten Methoden des INSPIRE Drafting Teams Data Specification (deliverable D2.6:) entnommen werden. In letzterem Dokument werden insbesondere die organisatorischen Aspekte (Abschnitt 5) inkl. des dazugehörigen Rollenmodells (Abschnitt 5.3), eine Schritt-für-Schritt-Anleitung (Abschnitt 6) und eine Interoperabilitätscheckliste für Datenmodelle beschrieben.

Ein vergleichbares Vorgehen ist im Rahmen der GDI-DE, der Länder-GDI und auf regionaler und kommunaler Ebene noch nicht beschrieben, insbesondere unter Berücksichtigung der föderalen Besonderheiten und Zuständigkeiten in Deutschland.

3.1.3     Bewertung, Handlungsbedarf und Empfehlungen

Liegt bei allen Akteuren das eingangs erwähnte gemeinsame Verständnis der „Interoperabilität“ für Datenmodelle vor und hat den erforderlichen Grad der Harmonisierung zwischen einerseits einer möglichst vollständig harmonisierten Datenmodellierung und andererseits einer möglichst geringen Formalisierung festgelegt, lassen sich folgenden Empfehlungen ableiten. Sie werden unterteilt in Empfehlungen zur Vorbereitung und Entwicklung genereller Best Practices bei der Modellerstellung und in die eigentliche Datenmodellharmonisierung.

Zuvor sind die wesentlichen Akteure und deren Rollenverteilung angegeben und entsprechende Beispiele angeführt.

Empfehlungen für die Rollenverteilung im Datenmodellharmonsierungsprozess

Die folgenden Rollen und deren Motivation lassen sich identifizieren und sind in den Datenmodellharmonisierungsprozess mit einzubinden:

  • Datenprovider

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

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

  • Datennutzer

Datennutzer arbeiten mit den bereitgestellten Daten und verwenden das Datenmodell bei Bedarf als Metainformation. Datennutzer sind zum Beispiel fachfremde Behörden oder Behörden anderer Kommunen und Ländern, Nutzer auf der Bundes- und Europaebene und Nutzer aus der Wirtschaft, Wissenschaft und dem Privatbürgertum.

  • Koordinatoren/Moderatoren

Die Koordinatoren/Moderatoren sind für den eigentlichen Prozess verantwortlich, steuern diesen, beziehen die notwenden Stakeholder ein, sammeln Erfahrungen und verwalten und pflegen die Ergebnisse.

Beispiel: GDI-Koordinierungsstellen des Bundes und der Bundesländer oder auch die Fachnetzwerke einer Domäne.

  • Generelle Datenmodellierungsexperten

Die generellen Datenmodellierungsexperten haben weitreichende 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: Datenmodellierungsexperten aus der Geoinformatikwissenschaft.

  • Technische Datenmodellierungsexperten

Die technischen Datenmodellierungsexperten begleiten die Entwicklung der harmonisierten Datenmodelle mit der Entwicklung 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 Empfehlungen sollten mindestens zweimal durchlaufen werden. Die INSPIRE-Fachnetzwerke sollen in die Vorbereitung mit einbezogen werden.

  1. Liste der verantwortlichen Datenprovider und Nutzer
    Um sicherzustellen dass alle relevanten Akteure am beim Modellierungsprozess involviert sind sollte eine Liste der verantwortlichen Datenprovider und Datennutzer der Fachdomäne unter Berücksichtigung der föderalen Strukturen erstellt werden. Bei der Erstellung der Liste sollten   vorhandene Strukturen, wie z.B. die Fachnetzwerke für die Erweiterung von INSPIRE-Datenmodellen oder vorhandene Listen geodatenhaltender Stellen für die INSPIRE-Annexthemen, genutzt werden. Die Fachnetzwerke können bei der Listenerstellung Koordinierungsaufgaben übernehmen.
  2. Liste möglicher Koordinatoren/Moderatoren für die Harmonisierung der Datenmodelle

Es sollte eine Liste möglicher Koordinatoren und Moderatoren für die Harmonisierung der Datenmodelle erstellt werden, aus der einerseits für die weitergehenden Ist- als auch Lückenanalysen ausgesucht werden kann, als auch für die spätere eigentliche Datenmodellharmonisierung.

  1. Analyse bestehender Datensätze/-spezifikationen (unterschiedlicher) Behörden
    Anhand von ausgewählten Beispieldatensätzen soll evaluiert werden, zu welchen Aspekten es aufgrund der Unterschiedlichkeit der zurzeit verwendeten Datensätze Harmonisierungsbedarf gibt und ob es bereits einheitliche Datenspezifikationen bzw. Anforderungen im Sinne von bundesweiten Vorgaben bzw. Vereinbarungen gibt (z.B. die Verwaltungsvereinbarung zum Austausch von Umweltdaten oder abgestimmte Datenmodelle für das Reporting und elektronische Berichterstattung). Hierzu sollen 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 soll auch geklärt werden, auf welchen Ebenen Zuständigkeiten für die Koordination und Moderation der Harmonisierung liegen sollen.

Ergebnis : Liste von Standards und Spezifikationen die für das jeweilige Thema bereits Verwendung finden und bestehender inhaltliche und technische Anforderungen an das harmonisierte Datenmodell. Weiterhin sollen Datensätze für die weitere Untersuchung gesammelt werden, um daraus einen oder mehrere Anwendungsfälle (-beispiele) für den Harmonisierungsprozess abzuleiten.

  1. Entwicklung eines Anwendungsfalls

Anhand den Ergebnissen der vorstehenden Empfehlungen sollen ein oder mehrere Anwendungsfälle entwickelt werden, die auf der Bestandsanalyse basieren und bis zur eigentlichen Implementierung inklusive des entsprechenden Testens und Validierung reichen, und Schritte für das weitere Fortschreiben des Datenmodells geben sollen. Für die letzteren Schritte sollen die Koordinatoren/Moderatoren verantwortlich sein. Die Schritte sollen sich am bestehenden Prozess für die Erstellung der INSPIRE-Datenspezifikationen orientieren und Analysen bezüglich allgemeiner Nutzeranforderungen enthalten.

Empfehlungen für den Datenspezifikationsprozess

Es wird empfohlen sich bei der Spezifikation des Harmonisierten Datenmodelles an den an den aus INSPIRE bekannten Schritten für den Datenspezifikationsprozess zu orientieren (siehe Abb. 2;  INSPIRE, 2008; Tóth u. a., 2012) . Anhand der Best Practice -Vorgaben (Kapitel 3.2.3.) und den Ergebnissen und 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 in Zusammenarbeit mit den Datenprovidern und Datenmodellierungsexperten und den für die Softwareumsetzung geschulten Experten (z.   B. FME) die Anwendungsfälle beispielhaft durchgespielt werden.

 

Abb. 2:  Schritte für den Datenspezifikationsprozess bei INSPIRE (aus Portele 2012)

Für den Prozess ist ein in Abstimmung mit allen Akteuren realistischer Zeitplan aufzustellen sowie die Umsetzung zu begleiten und zu überwachen.

 

3.2     Regeln für die Erstellung von Anwendungsschemata

3.2.1     Beschreibung

Diese Interoperabilitätskomponente ist nur dann anzuwenden, wenn ein Datenmodell unter Verwendung der gleichen Modellierungsgrundsätze und Methodik bei bei INSPIRE gewollt ist. Ferner ist diese Komponente Voraussetzung für den Andendungfall „Erweiterung von INSPIRE“, da eine fachliche Erweiterung der INSPIRE-Datenmodelle nur unter Berücksichtigung derselben Modellierungsmethodik möglich ist.

Anwendungsschemas sind konzeptionelle Datenmodelle, die für eine bestimmte Anwendung oder ein Datenthema entwickelt wurden. Darin werden die (räumlichen) Objekttypen, Attribute, Relationen und Integritätsregeln festgelegt. Zur Repräsentation von konzeptionellen Datenmodellen werden in der Regel maschinenlesbare Notationen wie UML verwendet, um die automatische Ableitung von Encodingschemas (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 der Anwendungsschemata, die Mehrsprachigkeit, sowie die Suche und den Zugriff auf einzelne Elemente der Anwendungsschemata.

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

3.2.2     Aktueller Stand in INSPIRE und GDI-DE

In INSPIRE erfolgt die Modellierung der Anwendungsschemata in UML nach ISO 19109 mit einem INSPIRE-UML-Profil. 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 (document D2.5)

  • Spezifiziert den allgemeinen Rahmen, in dem die harmonisierten Datenspezifikationen entwickelt werden:
    • 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, insb. Kapitel 6:

  • Festlegung von optionalen und verpflichtenden Attributen: verpflichtende Attribute sind als solche festzulegen, wenn die Features sonst bedeutungslos sind.
  • Bei verschiedenen Optionen sind jeweils Nutzungsempfehlungen zu geben.
  • Vermeidung von Enumerationen (nicht erweiterbare Aufzählungen) mit vordefinierten quantitativen Intervallen
  • Benutzung von hierarchischen Klassifikationen wird empfohlen - wenn geeignet, die Unterklassen sollten immer nur durch ein Unterscheidungsmerkmal festgelegt sein, nicht durch mehrere

JRC Reference Report 2012:

  • Bedingungen unter denen  für Datenthema mehr als ein Anwendungsschema entwickelt werden kann:
    • Wenn das Thema zu groß oder eine logische Aufteilung nach unterschiedlichen Sichten möglich ist wie z.B. beim INSPIRE Thema Transport Netze die Unterteilung nach Straßen-, Schienen- und Wasserverkehr etc.
    • Wenn Kernkomponenten des Modells rechtlich bindend sind, während Erweiterungen nur einen empfehlenden Charakter haben
    • Zur expliziten Modellierung verschiedener Auflösungs- oder Skalierungsstufen.

In der GDI-DE existieren derzeit keine mit den INSPIRE Daten Spezifikationen vergleichbaren, konkreten Vorgaben und es auch keine geplant. Das GDI-DE-Architekturkonzept empfiehlt bislang nur sehr allgemein die Verwendung der INSPIRE-Grundsätze. Explizit existiert derzeit kein UML-Profil für GDI-DE, allenfalls implizit anhand verschiedener Anwendungen in Fachmodellen (z.B. AAA-Datenmodell).

3.2.3     Bewertung und Handlungsbedarf

 

Entwicklung eines GDI-DE-Referenzmodells

Vorgaben für die Modellierung werden für beide in Kap. 1 definierten Anwendungsfälle des Interoperabilitätsrahmens dringend benötigt. Optimal wäre hier ein fachneutraler Modellierungsrahmen, der 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 Referenzmodell wäre festgelegt, welche ISO/TC 211Standards erfüllt werden müssen bzw. sollten und Hilfestellungen bzgl. der Nutzung von Standards gegeben. Darüber hinaus sollten Methoden und Vorgaben zu Inhalten der Modelldokumentation und zur Ableitung von Objektartenkatalogen 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 eigentlich eine Aufgabe für Modellierungsexperten mit entsprechendem INSPIRE-Hintergrundwissen. In der Praxis verfügen die Modellierer jedoch nicht immer über dieses Wissen und eine Vorgehensleitlinie für die Modellerstellung wäre hier hilfreich. Ziel könnte beispielsweise ein frei zugängliches Wiki mit Beispielen, Leitfäden, einer Sammlung weiterführender Links, Diskussionsforum etc. sein, ähnlich wie:

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

Inhaltlich sollten unter beispielweise folgende Fragen geklärt werden:

  • Allgemeine Fragen zur Modellierung
    • Welche Vorteile hat ein auf internationalen Standards basierendes Datenmodell?
    • Welche Alternativen gibt es und welche Vorteile/Nachteil haben dies?
    • Welche Software benutzt man dafür (UML Modellierung, Ableitung des XML Schemas, etc.)?
    • Welche Modellkonstrukte sind zu vermeiden (z.B. Assoziation Classes)?
    • Wie sind die Modelle überhaupt zu dokumentieren?
    • Wie muss die GDI-DE Registry bei der Modellierung 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 sind überhaupt relevant? Interlinked multiple representations (siehe Punkt multiple Representation)
  • Notwendiges Hintergrundwissen zu INSPIRE
    • Entscheidungshilfe: Wer ist verpflichtet auf den INSPIRE Schemata aufsetzen? Wer ist nicht verpflichtet, sollte sich aber trotzdem daran orientieren? Für wen sind die INSPIRE Vorgaben bzw. die Vorgaben aus dem GDI-DE Interoperabilitätskonzept nicht relevant?
    • Welche INSPIRE Packages sind relevant? Wie sind diese einzubinden / zu erweitern?
    • Welche der von INSPIRE vorgegebenen Klassen sind wann und wie zu übernehmen?
    • Besonderheiten der INSPIRE Modellierung:
      • Nillable Attribute
      • Unterscheidung featuretype (geographisch referenziert) und datatype: Wo ist eine geographische Referenz notwendig?
      • Unterscheidung Codelisten und Enumerationen
      • Beschreibung der Prozesse zur Erweiterung der INSPIRE-Datenmodelle (Objektarten, Codelisten, …)

3.3     Identifikatoren Management

3.3.1     Beschreibung

Festlegungen, ob und wie Dinge in der realen Welt und Objekte dauerhaft identifiziert werden können. Die beinhalte darüber hinaus auch die Definition von Namensräumen.

Ziele:

  • Eindeutige Identifikation und Auffindbarkeit von Geoobjekten
  • Lifecyclemanagement und Versionierung von Geoobjekten
  • Mehrfachverwendung unterstützen, da Identifikatoren auch den Zugriff auf die Objekte erlauben, z.B. zum Verlinken von externen Daten auf die Geoobjekte

3.3.2     Aktueller Stand in INSPIRE und GDI-DE

INSPIRE-Vorschriften

-           INSPIRE hat hier Grundlagenarbeit geleistet (insb. INSPIRE D2.5 V 3.4)

-           Nationale Regelungen greifen oft auf INSPIRE-Vorgaben zurück

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

Geltungsbereich für Objektidentifikatoren

Identifizierbare Objekte in der INSPIRE Richtlinie sind sogenannte „spatial objects“, im Folgenden Geoobjekte genannt [1] . Ein Objektidentifikator (OI) bezieht sich damit bezieht sich damit nicht auf ein realweltliches Phänomen (z.B. einen bestimmten Baum oder ein bestimmter See), sondern auf dessen Abstraktion (= ein Geoobjekt). Unterschiedliche Abstraktionen des gleichen realweltlichen Phänomens bekommen damit unterschiedliche Identifikatoren.

Die Art der Abstraktion wird üblicherweise in einer Vorschrift zur Objektbildung bzw. über eine Erfassungsvorschrift bei der Objektaufnahme im Freiland oder über fernerkundliche Hilfsmittel festgelegt. Die Anwendung sog. „spatial object types“ mit verpflichtenden und optionalen thematischen, geometrischen, topologischen und temporalen Attributen sind ein übliches Instrument zur normativen Objektbildung. Grundsätzlich bestimmen auch Qualitätsvorgaben bei der Erfassung (Straßen als Linien oder Flächen, Lagegenauigkeit etc.) über die Art der Abstraktion. 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 Generic Conceptual Model (IGCM) jedoch nicht im Detail diskutiert.

Anforderungen an Objektidentifikatoren

Das INSPIRE Generic Conceptual Model (INSPIRE D2.5 V 3.4) (IGCM) stellt 4 Anforderungen an Objektidentifikatoren:

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

3.3.3     Bewertung und Handlungsbedarf

3.3.3.1 Eindeutigkeit

Die Eindeutigkeit von Identifikatoren wird im IGCM wie folgt spezifiziert:

(1)   Ein Identifikator bezeichnet genau ein Geoobjekt.

(2)   Die Eindeutigkeit dieses Identifikators innerhalb des Geltungsbereiches muss 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 realweltlichen Phänomens) sollen den gleichen Identifikator haben.

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

 

Geoobjekte können optional versioniert werden, um z.B. nachträgliche Korrekturen oder Änderungen an Attributfeldern transparent zu kennzeichnen. Obwohl Versionen nicht Bestandteil des [externen] Identifikators eines Geoobjekts sind, wird im IGCM ein versionierter Datentyp für Identifikatoren vorgeschlagen (siehe Tab. XX). Die Eigenschaften Namespace und LocalId bilden den [externen] Identifikator, das Versionsfeld kann eine fortlaufende Nummer oder einen Zeitstempel enthalten. Dieser Identifikator-Datentyp kann damit auch für die interne Datenhaltung genutzt werden.

Base Types.Identifier (IGCM, Clause 9.8.2.3.1)

LocalId

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.

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

Namespace

Namespace uniquely identifying the data source of the spatial object.

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.

Version

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.

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.

 

Abb. 3:  Auszug aus dem Generic Conceptual Model von INSPIRE

 

Konkrete Handlungsvorschriften:

-           Es muss sichergestellt werden, dass ein Identifikator für ein Geoobjekt nur einmal vergeben werden kann.

-           Die Verknüpfung zwischen Geoobjekt und dessen Identifikator muss auflösbar sein.

-           „Verfallene“ Identifikatoren müssen erfasst bleiben, damit diese nicht irrtümlich erneut vergeben werden.

-           Die für die Pflege der Identifikatoren verantwortlichen Stellen sollten klar benannt sein. Ihnen obliegt die Durchsetzung der obigen Punkte.

3.3.3.2 Persistenz

Unter dem Begriff Persistenz werden im Generic Conceptual Model von INSPIRE Aussagen zum Lebenszyklus von Geoobjekten und deren Identifikatoren getroffen:

(1)   Der Identifikator eines Geoobjektes bleibt für dessen gesamten Lebenszyklus unverändert.

(2)   Regeln zum Lebenszyklus von Geoobjekten variieren zwischen verschiedenen Datenprovidern. Die INSPIRE-Datenspezifikationen machen daher keine definitiven Vorschriften zum Lifecycle-Management für Geoobjekte.

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 Generic Conceptual Model von INSPIRE und die darauf aufbauenden Datenspezifikationen hier unkonkret. Folgende Aspekte sind jedoch in Regeln zum Life-Cycle Management zu berücksichtigen:

(3)   Es muss 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 in IGCM, Kapitel 9.7 zu finden.

Konkrete Handlungsvorschriften:

-           Sind Informationen zum Lebenszyklus des Geoobjekts generell nötig (ja/nein)?

-           Wenn ja:

a)      Definition von Regeln zum Life-Cycle Management auf fachlicher Ebene

b)      Definition einer entsprechenden Versionierungsvorschrift für Identifikatoren.

3.3.3.3 Rückverfolgbarkeit

INSPIRE fordert einen Mechanismus zur Auffindung von Geoobjekten, basierend auf ihrem Identifikator. 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 einem Digitalen Objektbezeichner (DOI). Über den Namensraum des Objektidentifikators lässt sich der Datenprovider identifizieren und in dessen Bestand finden.

Konkrete Handlungsvorschriften:

-           Rückverfolgbarkeit setzt die Kenntnis der Verbindung zwischen dem Datenprovider und dessen Namensraum voraus. Die Information kann z.B. in Registries hinterlegt werden.

-           Zusätzlich muss der Provider ein Mechanismus (z.B. einen Suchdienst) bereitstellen, der das Auffinden von Downloaddiensten für die von ihm bereitgestellten Geoobjekte ermöglicht.

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

b)      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.3.3.4 Machbarkeit

INSPIRE-Objektidentifikatoren müssen so aufgebaut sein, dass sie auf existierende nationale Identifikatoren 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.

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

(bei eindeutigen lokalen IDs innerhalb gesamter Behörde)

(bei nicht einheitlichen lokalen IDs innerhalb gesamter Behörde)

Konzeptionelle Probleme ergeben sich typischerweise an administrativen Grenzen oder an überlappenden fachlichen Zuständigkeiten.

  • Was passiert mit Geoobjekten, welche die Ländergrenzen kreuzen? 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 Geoobjekte (z.B. Flussläufe) für welchen Anwendungsfall.

Zu diesen Fragen sind Entscheidungen zu treffen, zu erproben und ggf. weiterzuentwickeln. Die Vorarbeiten zum syntaktischen Aufbau von Namensräumen und Registries sind im Wesentlichen nur noch umzusetzen.

3.4     Registry

In diesem Kapitel werden die speziellen Anforderungen der Datenmodellierung und Datenbereitstellung an eine Registry beschrieben. Andere funktionale Aspekte, wie z.B. INSPIRE-Monitoring, spielen in diesem Zusammenhang keine Rolle.

3.4.1     Beschreibung

Registries nehmen in Geodateninfrastrukturen eine zentrale Rolle ein, da sie das Verwalten, Auffinden und Nutzen von den in der Infrastruktur vorhandenen Geoinformationsressourcen 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. Die Ressourcen selbst sowie wichtige kennzeichnende Eigenschaften, die für das Verwalten, Auffinden und Nutzen von besonderer Bedeutung sind, werden über eine Registry verfügbar gemacht.

Gemäß ISO 19135 ist eine Registry ein Informationssystem, in dem ein Register geführt wird. Ein Register wiederum ist eine Zuordnung von sog. Identifikatoren zu Ressourcen und deren Beschreibungen. Eine Ressource ist in diesem Sinn ein Sachverhalt, der in Abgrenzung zu anderen Sachverhalten eindeutig beschrieben werden kann. Ein Identifier ermöglicht es, Ressourcen der Registry eindeutig zu referenzieren.

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

  • Das Control Body entscheidet über die Eintragung einer neuen Ressource (Item) und die Gültigkeit vorhandener Einträge.
  • Der Registry Owner ist verantwortliche Stelle für den Betrieb der Registry (z.B. GDI-DE).
  • Die Submitting Organization ist die Stelle, die Änderungen sammelt und zur Eintragung weiterleiten darf.

Ohne die verbindliche Festlegung dieser Rollen wird eine Registry auf Dauer nicht funktionieren. Eine Registry kann die unterschiedlichsten Ressourcen enthalten. Sind die Ressourcen die Codelisten eines Datenmodells, wird der Begriff einer Codelistenregistry verwendet.

3.4.2     Aktueller Stand in GDI-DE und Handlungsbedarf

3.4.2.1 Codelistenregistry

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

Teilweise sind die in einer Codeliste verfügbaren Codes allerdings nicht ausreichend. In den INSPIRE-Datenmodellen wird mitunter nur die gemeinsame Sicht abgedeckt, aber nicht die länderspezifischen Bedürfnisse (Erweiterungen). 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 verhindern, ist es notwendig, die Pflege der länderspezifischen Codelisten zu organisieren. Eine Registry ist hierfür ein geeignetes Werkzeug, das es ermöglicht, die Pflege von nationalen und länderspezifischen Codelisten sowie auch anderen Codelisten zu organisieren.

Der Einsatz eines Registers für Codelisten unterstützt:

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

Die Anforderungen an eine Codelistenregistry sind vielschichtig und oft von Datenanbieter zu Datenanbieter unterschiedlich. In der Regel verursachen spezielle Anforderungen eine Weiterentwicklung der GDI-DE-Codelistenregistry.

Maßnahmen: Anforderungsanalyse verschiedener Datenanbieter an die Codelistenregistry und anschließende Weiterentwicklung der Codelistenregistry. Es sind ferner die Prozesse zu definieren, wie ein Nutzersystem mit einer Registry kommuniziert (z.B. wie Registryinhalte recherchiert und ausgewertet werden können).

3.4.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 sie durch entsprechende Transformationen in ein einheitliches CRS gebracht werden.

Die Kopplung der Geometrien der Datensätze zu einem CRS erfolgt jeweils über einen CRS-Identifikator. Um die für eine Transformation erforderlichen Parameter zu erhalten, müssen Anwendungen in der Lage sein, die dem Identifikator zugeordneten Parameter des CRS zu erhalten. Um die CRS-Parameter verlässlich nutzen zu können, müssen sie durch eine autorisierte Stelle bereitgestellt und gepflegt werden. CRS werden derzeit üblicherweise in einer Online-Datenbank (EPSG-Registry) erfasst und bereitgestellt. EPSG ( European Petroleum Survey Group Geodesy) ist eine Arbeitsgruppe der europäischen Öl- und Gaserkundungsunternehmen, mithin also keine neutrale und amtliche Institution. Der EPSG-Code ist ein System weltweit eindeutiger, 4- bis 5-stelliger Schlüsselnummern für Koordinatenreferenzsysteme und andere geodätische Datensätze, wie Referenzellipsoide oder Projektionen. Es wird unter gleichem Namen von der Nachfolgeorganisation OGP weitergeführt.

Maßnahmen: Durch eine autorisierte Stelle Entwicklung und Betrieb eines von allen Datenanbietern nutzbaren CRS-Registers für die GDI-DE, über das alle Anwendungen zu einem CRS-Identifikator exakt die gleichen CRS-Parameter erhalten. Durch Nutzung dieses Registers soll gewährleistet werden, dass Transformationen, die über Transformationsdienste bereitgestellt werden, oder Anwendungen, die selbst transformieren oder für andere Zwecke CRS-Informationen benötigen, im Ergebnis zu gleichen Transformationsresultaten kommen.

Steht die CRS-Registry zur Verfügung, sind sämtliche von der GDI-DE den Datenanbietern zum Zwecke der interoperablen Bereitstellung verwendete Koordinatenreferenzsysteme zu erfassen und einzutragen. Im Anhang 2 sind die von den Datenanbietern der Marine Dateninfrastruktur Deutschland verwendeten CRS aufgelistet.

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

3.4.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 dann 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 (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 enthält exemplarisch einige 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 Fachnetzwerke. 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.5     Bereitstellung von Schemadateien

3.5.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, d.h. im Internet über eine URL (Schema-Location) erreichbar sein. Anwendungen sind dann in der Lage, die XSD-Datei direkt online zu verwenden oder zur lokalen Speicherung herunterzuladen.

3.5.2     Aktueller Stand in INSPIRE und GDI-DE

XML-Schemata werden bei OGC und INSPIRE in einfachen dateibasierten Repositories über WebServer bereitgestellt. Diese einfache Bereitstellung ist für die Zwecke der GDI-DE ausreichend. Hier wird kein nach ISO-19135 ausgerichtetes Register benötigt, sondern es reicht hier eine einfache Lösung aus. Da 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 eine zentrale Bereitstellung der Datenmodelle in einem von GDI-DE geführten Register aufgrund der unterschiedlichen Ansätze und Lösungen bei den Datenanbietern als nicht notwendig erachtet. Es ist jedoch sicherzustellen, dass diese Datenspezifikationen an geeigneter Stelle online zur Verfügung stehen.

3.5.3     Bewertung und Handlungsbedarf

Das Schemarepository für XML-Dokumente wird bereits betrieben. Die GDI-DE sollte darauf hinwirken, dass dieses Repository von allen Datenanbietern der GDI-DE verwendet wird und nachhaltig zur Verfügung steht. Damit dies nach einheitlichen Regeln passiert, ist die Festlegung entsprechender Namensraum-Regelungen für Schemata durch den AK Architektur erforderlich.

 


Referenzen

 


Anhang 1: Anforderungen an die Codelistenregistry

 

Aufgrund der Verpflichtung zur Bereitstellung INSPIRE-konformer Daten ist die Erweiterbarkeit der INSPIRE-Codelisten zeitkritisch. Die Abstimmung der Anforderung und die Konzeption der Umsetzung in der GDI-DE-Registry sind daher umgehend zu beginnen. In diesem Anhang werden die Anforderungen der BGR und der Denkmalschutzverwaltung aufgelistet. Darüber hinaus werden auch Aussagen zu den Akteuren getroffen, die für den späteren Betrieb erforderlich sind. Zur strukturierten Erfassung der Anforderungen wird ein Template vorgeschlagen.

Anforderung Die Bundesanstalt für Geowissenschaften und Rohstoffe ( BGR)

Bezogen auf die GDI-DE-Registry ging es dabei vor allem um die Frage, ob die Erweiterung um bestimmte Funktionalitäten bis etwa August 2016 realisiert werden kann.

Anwendungsfall

Deutsche Erweiterung von INSPIRE-Codelisten für das BGR

Akteure

N.N. (Rolle: Submitter)

N.N. (Rolle: Control Body), Bundesanstalt für Geowissenschaften und Rohstoffe

Kurz-beschreibung

Im Rahmen der Transformation von Denkmaldaten aus Deutschland in das INSPIRE Schema für ProtectedSites wurden folgende Erweiterungen modelliert (s. Abbildung):

  • Erweiterung der INSPIRE-Codelist „DesignationSchemeValue“ um den Wert „germanMonumentsRecord“
  • Definition einer deutschen Codelist „GermanMonumentsRecordDesignationValue“ als Subtyp der abstrakten INSPIRE-Codelist „DesignationValue“

Diese wurden in den zuständigen Bund-Länder-Fachgremien abgestimmt und müssen nun in der Registry GDI-DE registriert werden.

Funktionale Anforderungen an Registry

  • Unterstützung hierarchischer Strukturen mit Eltern-Kind-Beziehungen zwischen den Einträgen
  • Zu einem Listeneintrag sollten weitere Attribute hinzufügt werden können (i.S. einer Spalte in einer Schlüssellisten-Tabelle).
  • Unterstützung von Sortierkriterien bzw. des Einfügens von Attributen, die als solche genutzt werden können - insbesondere für Anzeige und Export
  • Unterstützung mehrsprachiger Inhalte (obligatorisch) und einer mehrsprachigen Oberfläche (zumindest Englisch).
    Letzteres besitzt insbesondere in den Fällen Relevanz, wenn die für INSPIRE verwendeten Erweiterungen des INSPIRE-Vokabulars in der Registry registriert werden (müssen). Dies ist für die Umsetzung des Themas „Boden“ gegeben
  • Personen müssen mehreren Rollen bzw. Organisationen zugeordnet werden können, denn ein und dieselbe Person kann Aufgaben für die Bearbeitung unterschiedlicher Schlüssellisten bzw. fachlicher Inhalte wahrnehmen – auch als Mitglied unterschiedlicher Arbeitsgruppen.
  • Unterstützung der Download-Formate für Schlüssellisten,   welche auch von der Registry beim JRC unterstützt werden.
  • Die Zuordnung von Listen zu Organisationen bzw. die Rechteverwaltung sind zu verbessern (Konkretisierung folgt).

 

Darüber hinaus wären folgende Punkte sinnvoll i.S. der Anwendbarkeit des Systems:

  • Die Einladung von nicht registrierten Nutzern zur Diskussion um Schlüssellisteneinträge sollte möglich sein.
  • Die Funktionalität zum Import von Schlüssellisten sollte besser erläutert werden

 

Ansprech-partner

N.N.

Referenzen

[1] INSPIRE Drafting Team Data Specifications: INSPIRE Generic Conceptual Model (D2.5_v3.4). URL http:// inspire.jrc.ec.europa.eu/documents/Data_Specifications/D2.5_v3.4.pdf

[2] INSPIRE Drafting Team Data Specifications: INSPIRE Guidelines for the encoding of spatial data (D2.7_v3.3). URL http:// inspire.jrc.ec.europa.eu/documents/Data_Specifications/D2.7_v3.3.pdf

 


Anforderungen der Denkmalschutzverwaltung

 

Anwendungsfall

Deutsche Erweiterung von INSPIRE-Codelisten für Denkmalpflege

Akteure

Roland Wanninger, Bayerisches Landesamt für Denkmalpflege (Rolle: Submitter)

Vereinigung der Landesdenkmalpfleger, Geschäftsstelle c/o Landschaftsverband Westfalen-Lippe (LWL) (Rolle: Control Body)

Kurz-beschreibung

Im Rahmen der Transformation von Denkmaldaten aus Deutschland in das INSPIRE Schema für ProtectedSites wurden folgende Erweiterungen modelliert (s. Abbildung):

  • Erweiterung der INSPIRE-Codelist „DesignationSchemeValue“ um den Wert „germanMonumentsRecord“
  • Definition einer deutschen Codelist „GermanMonumentsRecordDesignationValue“ als Subtyp der abstrakten INSPIRE-Codelist „DesignationValue“

Diese wurden in den zuständigen Bund-Länder-Fachgremien abgestimmt und müssen nun in der Registry GDI-DE registriert werden.

Funktionale Anforderungen an Registry

  • Der Submitter muss Code-Items als Erweiterung einer in der INSPIRE Registry geführten Codeliste auf gleicher Ebene definieren können.
  • Der Submitter muss eigene Codelisten als Subtypen von INSPIRE-Codelisten anlegen können.
  • Als Control Body für die Codelisten muss der Submitter eine bestimmte Organisation angeben können.
  • Codes und Codelisten müssen die Vorgaben aus [1] und [2] erfüllen, u.a. müssen sie

        über folgendes, “meschenlesbares” URL-Muster referenzierbar sein:
http://<registry-host>/codelist/<codelist>/<code>:<version>
Bsp.: http://inspire.ec.europa.eu/codelist/DesignationSchemeValue/ germanMonumentsRecord:1

        versioniert werden können, wobei alte Versionen weiterhin über die Registry erreichbar bleiben müssen.

        internationalisert werden können

        in HTML, RDF/SKOS und GML 3.3 codiert werden

  • Bei einem Code sollten als zusätzliche Attribute eine Definition sowie ein „menschenlesbares“ Label abgelegt werden können (vgl. INSPIRE Registry).
  • Die „Codelist-Resolver“-Schnittstelle der GDI-DE Registry muss es Anwendungen (die dazu grundsätzlich technisch in der Lage sind) ermöglichen, über die URL den Code abzurufen und sollte es darüber hinaus ermöglichen, über die URL das „menschenlesbare“ Label und die Definition abzurufen.
  • Die GDI-DE Registry muss im Rahmen der „Registry Federation“ mit der INSPIRE-Registry verknüpft werden, sobald seitens INSPIRE die technischen Voraussetzungen hierfür geschaffen wurden.

Ansprech-partner

Astrid Feichtner, Geschäftsstelle Geodateninfrastruktur Bayern

astrid.feichtner@ldbv.bayern.de

Referenzen

[1] INSPIRE Drafting Team Data Specifications: INSPIRE Generic Conceptual Model (D2.5_v3.4). URL http:// inspire.jrc.ec.europa.eu/documents/Data_Specifications/D2.5_v3.4.pdf

[2] INSPIRE Drafting Team Data Specifications: INSPIRE Guidelines for the encoding of spatial data (D2.7_v3.3). URL http:// inspire.jrc.ec.europa.eu/documents/Data_Specifications/D2.7_v3.3.pdf

 

 

 

 


Anhang 2: CRS der Marine Dateninfrastruktur Deutschland

 

EPSG -Code

Koordinatenreferenzsystem

Bezeichnung im                         MDI-DE Portal

INSPIRE

GDI-DE

MDI-DE

2397

Pulkovo 1942(83) / 3-Grad Gauß-Krüger Zone 3

Pulkovo 1942(83) / Gauß-Krüger Zone 3

 

 

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\LOGO_END_kurz.jpg

Zone

2398

Pulkovo 1942(83) / 3-Grad Gauß-Krüger Zone 4

Pulkovo 1942(83) / Gauß-Krüger Zone 4

 

 

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\LOGO_END_kurz.jpg

Zone

2399

Pulkovo 1942(83) / 3-Grad Gauß-Krüger Zone 5

Pulkovo 1942(83) / Gauß-Krüger Zone 5

 

 

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\LOGO_END_kurz.jpg

Zone

4230

DMZ ED50

ED50

 

 

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\LOGO_END_kurz.jpg

Zone

4258

ETRS89 , geographische Koordinaten

ETRS89 in geografischen Koordinaten

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\inspire-logo.jpg

bindend

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\logo_GDI_DE.jpg

bindend

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\LOGO_END_kurz.jpg

Zone

4326

World Geodetic System 1984 ( WGS 84)

WGS84 in geografischen Koordinaten

 

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\logo_GDI_DE.jpg

bindend

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\LOGO_END_kurz.jpg

bindend

4647

ETRS89 / UTM Zone 32N (zE-N)

ETRS89 / UTM Zone 32E

 

 

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\LOGO_END_kurz.jpg

Zone

5650

ETRS89 / UTM Zone 33N (zE-N)

Geplant für Portal 2.0

 

 

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\LOGO_END_kurz.jpg

Zone

7408

RD/NAP

RD/NAP

 

 

 

25832

ETRS89 / UTM Zone 32N

ETRS89 / UTM Zone 32N

 

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\logo_GDI_DE.jpg

sinnvoll

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\LOGO_END_kurz.jpg

Zone

25833

ETRS89 / UTM Zone 33N

ETRS89 / UTM Zone 33N

 

 

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\LOGO_END_kurz.jpg

Zone

31466

DHDN / 3-Grad Gauß-Krüger Zone 2

Gauß-Krüger, 2. Streifen

 

 

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\LOGO_END_kurz.jpg

Zone

31467

DHDN / 3-Grad Gauß-Krüger Zone 3

Gauß-Krüger, 3. Streifen

 

 

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\LOGO_END_kurz.jpg

Zone

31468

DHDN / 3-Grad Gauß-Krüger Zone 4

Gauß-Krüger, 4. Streifen

 

 

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\LOGO_END_kurz.jpg

Zone

31469

DHDN / 3-Grad Gauß-Krüger Zone 5

Gauß-Krüger, 5. Streifen

 

 

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\LOGO_END_kurz.jpg

Zone

32632

WGS 84 / UTM Zone 32N

WGS84 / UTM Zone 32N

 

 

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\LOGO_END_kurz.jpg

Zone

35832

ETRS89 , UTM Zone 32 mit führender 32 im Rechtswert

Siehe EPSG:4647

 

 

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\LOGO_END_kurz.jpg

Zone

35833

ETRS89 , UTM Zone 33 mit führender 33 im Rechtswert

Siehe EPSG:5650

 

 

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\LOGO_END_kurz.jpg

Zone

3035

Europe Albers Equal Area Conic

ETRS89 / ETRS-LAEA

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\inspire-logo.jpg

Zone

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\logo_GDI_DE.jpg

sinnvoll

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\LOGO_END_kurz.jpg

Zone

3034

Europe Lambert Conformal Conic

ETRS89 / ETRS-LCC

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\inspire-logo.jpg

Zone

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\logo_GDI_DE.jpg

sinnvoll

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\LOGO_END_kurz.jpg

Zone

900913

Google-Projektion, Spherical Mercator

Google Maps Global Mercator

 

 

 

3857

Google-Projektion, Spherical Mercator

Google Maps Global Mercator

 

 

 

3038

ETRS89 / ETRS-TM26

Geplant für Portal 2.0

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\inspire-logo.jpg

Zone

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\logo_GDI_DE.jpg

sinnvoll

 

3039

ETRS89 / ETRS-TM27

Geplant für Portal 2.0

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\inspire-logo.jpg

Zone

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\logo_GDI_DE.jpg

sinnvoll

 

3040

ETRS89 / ETRS-TM28

Geplant für Portal 2.0

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\inspire-logo.jpg

Zone

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\logo_GDI_DE.jpg

sinnvoll

 

3041

ETRS89 / ETRS-TM29

Geplant für Portal 2.0

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\inspire-logo.jpg

Zone

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\logo_GDI_DE.jpg

sinnvoll

 

3042

ETRS89 / ETRS-TM30

Geplant für Portal 2.0

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\inspire-logo.jpg

Zone

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\logo_GDI_DE.jpg

sinnvoll

 

3043

ETRS89 / ETRS-TM31

Geplant für Portal 2.0

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\inspire-logo.jpg

Zone

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\logo_GDI_DE.jpg

sinnvoll

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\LOGO_END_kurz.jpg

Zone

3044

ETRS89 / ETRS-TM32

Geplant für Portal 2.0

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\inspire-logo.jpg

Zone

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\logo_GDI_DE.jpg

sinnvoll

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\LOGO_END_kurz.jpg

Zone

3045

ETRS89 / ETRS-TM33

Geplant für Portal 2.0

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\inspire-logo.jpg

Zone

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\logo_GDI_DE.jpg sinnvoll

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\LOGO_END_kurz.jpg

Zone

3046

ETRS89 / ETRS-TM34

Geplant für Portal 2.0

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\inspire-logo.jpg

Zone

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\logo_GDI_DE.jpg sinnvoll

 

3047

ETRS89 / ETRS-TM35

Geplant für Portal 2.0

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\inspire-logo.jpg

Zone

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\logo_GDI_DE.jpg sinnvoll

 

3048

ETRS89 / ETRS-TM35

Geplant für Portal 2.0

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\inspire-logo.jpg

Zone

 

 

3049

ETRS89 / ETRS-TM37

Geplant für Portal 2.0

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\inspire-logo.jpg

Zone

 

 

3050

ETRS89 / ETRS-TM38

Geplant für Portal 2.0

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\inspire-logo.jpg

Zone

 

 

3051

ETRS89 / ETRS-TM39

Geplant für Portal 2.0

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\inspire-logo.jpg

Zone

 

 

5730

EVRF2000 height

Geplant für Portal 2.0

C:\01_Repository_SVN\MDI-DE\900_AG_s\04_AG Infrastrukturknoten\02_Grafiken\xx - Grafiken zum Basteln\inspire-logo.jpg

 

 

 

 


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