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:
-
Die
Spezifizierung von Komponenten
Identfikationen
von Elementen
,
deren
einheitliche
Festlegung
die
für eine interoperable Bereitstellung von Geodaten der GDI-DE erforderlich sind
(Interoperabilitätselemente)
.
[MLR2]
-
Die Festlegung einer Methodik für eine schrittweise Harmonisierung vorhandener Datenbestände und Datenmodelle innerhalb der GDI-DE.
?
[MLR3]
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.
Mit dem vorliegenden Dokument
Im Rahmen der GDI-DE sollte
wird
ein gemeinsames Verständnis der „Interoperabilität“ für Datenmodelle
i
m Rahmen der GDI-DE
hergestellt
und geklärt werden
.
[MLR4]
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
[MLR5]
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.
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.
[MLR6]
Abb.1: Übersicht über die Interoperabilitätskomponenten der GDI-DE
[MLR7]
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
.
[MLR8]
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.
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.
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.
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 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 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.
-
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.
-
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.
-
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.
-
Entwicklung eines Anwendungsfalls
[MLR10]
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.
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).
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).
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, …)
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
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.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:
[MLR11]
-
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.
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.
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.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.
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.
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.
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.
