Ü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. |
|
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). |
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 |
Version |
Datum |
Änderung |
Ersteller |
0.1 |
01.02.2016 |
Initialfassung |
AG Geodaten |
0.2 |
01.02.2016 |
Ergänzungen Kapitel 3.1 Organisation; Kapitel 3.2 Anwendungsschemata und Kapitel 3.3 Identifikatoren |
Stephan Mäs, Matthias Müller, Johannes Brauner |
0.3 |
29.02.2016 |
Ergänzung der Kapitel 3.4 Registry und 3.5 Bereitstellung von Schemadateien und der Anhänge (Erweiterung von Codelisten und CRS); Bearbeitung von Anmerkungen aus der 3. Sitzung der AG Geodaten |
Markus Seifert
Stephan Mäs |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Inhalt
1 Ziele des Interoperabilitätskonzepts
3 Interoperabilitätskomponenten
3.1 Organisatorische Handlungsempfehlungen für Datenmodellierung
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.2 Aktueller Stand in INSPIRE und GDI-DE
3.2.3 Bewertung und Handlungsbedarf
3.3 Identifikatoren Management
3.3.2 Aktueller Stand in INSPIRE und GDI-DE
3.3.3 Bewertung und Handlungsbedarf
3.4.2 Aktueller Stand in GDI-DE und Handlungsbedarf
3.5 Bereitstellung von Schemadateien
3.5.2 Aktueller Stand in INSPIRE und GDI-DE
3.5.3 Bewertung und Handlungsbedarf
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 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:
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.
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.
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.
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.
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.
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.
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.
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)
Drafting Team "Data Specifications" – deliverable D2.6, insb. Kapitel 6:
JRC Reference Report 2012:
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:
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:
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:
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.
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.
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.
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.
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.:
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.
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 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).
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.
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.
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.
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):
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 |
Darüber hinaus wären folgende Punkte sinnvoll i.S. der Anwendbarkeit des Systems:
|
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 |
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):
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 |
über folgendes, “meschenlesbares” URL-Muster referenzierbar sein:
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
|
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 |
EPSG -Code |
Koordinatenreferenzsystem |
Bezeichnung im MDI-DE Portal |
INSPIRE |
GDI-DE |
MDI-DE |
Pulkovo 1942(83) / 3-Grad Gauß-Krüger Zone 3 |
Pulkovo 1942(83) / Gauß-Krüger Zone 3 |
|
|
Zone |
|
Pulkovo 1942(83) / 3-Grad Gauß-Krüger Zone 4 |
Pulkovo 1942(83) / Gauß-Krüger Zone 4 |
|
|
Zone |
|
Pulkovo 1942(83) / 3-Grad Gauß-Krüger Zone 5 |
Pulkovo 1942(83) / Gauß-Krüger Zone 5 |
|
|
Zone |
|
ED50 |
|
|
Zone |
||
ETRS89 , geographische Koordinaten |
ETRS89 in geografischen Koordinaten |
bindend |
bindend |
Zone |
|
World Geodetic System 1984 ( WGS 84) |
WGS84 in geografischen Koordinaten |
|
bindend |
bindend |
|
ETRS89 / UTM Zone 32E |
|
|
Zone |
||
ETRS89 / UTM Zone 33N (zE-N) |
Geplant für Portal 2.0 |
|
|
Zone |
|
RD/NAP |
RD/NAP |
|
|
|
|
ETRS89 / UTM Zone 32N |
|
sinnvoll |
Zone |
||
ETRS89 / UTM Zone 33N |
|
|
Zone |
||
DHDN / 3-Grad Gauß-Krüger Zone 2 |
Gauß-Krüger, 2. Streifen |
|
|
Zone |
|
DHDN / 3-Grad Gauß-Krüger Zone 3 |
Gauß-Krüger, 3. Streifen |
|
|
Zone |
|
DHDN / 3-Grad Gauß-Krüger Zone 4 |
Gauß-Krüger, 4. Streifen |
|
|
Zone |
|
DHDN / 3-Grad Gauß-Krüger Zone 5 |
Gauß-Krüger, 5. Streifen |
|
|
Zone |
|
WGS84 / UTM Zone 32N |
|
|
Zone |
||
Siehe EPSG:4647 |
|
|
Zone |
||
Siehe EPSG:5650 |
|
|
Zone |
||
Europe Albers Equal Area Conic |
ETRS89 / ETRS-LAEA |
Zone |
sinnvoll |
Zone |
|
Europe Lambert Conformal Conic |
ETRS89 / ETRS-LCC |
Zone |
sinnvoll |
Zone |
|
Google-Projektion, Spherical Mercator |
Google Maps Global Mercator |
|
|
|
|
Google-Projektion, Spherical Mercator |
Google Maps Global Mercator |
|
|
|
|
ETRS89 / ETRS-TM26 |
Geplant für Portal 2.0 |
Zone |
sinnvoll |
|
|
ETRS89 / ETRS-TM27 |
Geplant für Portal 2.0 |
Zone |
sinnvoll |
|
|
ETRS89 / ETRS-TM28 |
Geplant für Portal 2.0 |
Zone |
sinnvoll |
|
|
ETRS89 / ETRS-TM29 |
Geplant für Portal 2.0 |
Zone |
sinnvoll |
|
|
ETRS89 / ETRS-TM30 |
Geplant für Portal 2.0 |
Zone |
sinnvoll |
|
|
ETRS89 / ETRS-TM31 |
Geplant für Portal 2.0 |
Zone |
sinnvoll |
Zone |
|
ETRS89 / ETRS-TM32 |
Geplant für Portal 2.0 |
Zone |
sinnvoll |
Zone |
|
ETRS89 / ETRS-TM33 |
Geplant für Portal 2.0 |
Zone |
|
Zone |
|
ETRS89 / ETRS-TM34 |
Geplant für Portal 2.0 |
Zone |
|
|
|
ETRS89 / ETRS-TM35 |
Geplant für Portal 2.0 |
Zone |
|
|
|
ETRS89 / ETRS-TM35 |
Geplant für Portal 2.0 |
Zone |
|
|
|
ETRS89 / ETRS-TM37 |
Geplant für Portal 2.0 |
Zone |
|
|
|
ETRS89 / ETRS-TM38 |
Geplant für Portal 2.0 |
Zone |
|
|
|
ETRS89 / ETRS-TM39 |
Geplant für Portal 2.0 |
Zone |
|
|
|
EVRF2000 height |
Geplant für Portal 2.0 |
|
|
|
[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 )
[MLR1] „…für Geodaten IN der GDI-DE“ ist besser!
[MLR2]
generell noch verwirrender Sprachgebrauch, wenn es um „Komponenten“, „Elemente“, „Anforderungen“, „Interoperabilitätskomponenten“, „Interoperabilitätselemente“ geht, die alle die für die Interoperabilität relevanten Aspekte beschreiben und tlw. synonym gebraucht werden!
=> ggf. im gesamten Doku SUCHEN+ERSETZEN durch „Interoperabilitätselemente“ (in Abgrenzung zu Geoportal, Testsuite usw. als „Komponenten“!
[MLR3] Adressaten dieses Dokus sind … (momentan mir noch unklar, ob eher GDI-Kontaktstellen, geodatenhaltende Stellen, Fach-Communities, … die Hauptadressaten sein sollen)
[MLR4] Bitte klare (!) Aussagen, alternativ: Das vorliegende Dokument ist die Grundlage (~im Sinne einer Checkliste), um diese Interoperabilität herzustellen.
[MLR5] Hm. Was heißt das?!
[MLR6] Sollte nicht auch das Element „Konformität“ näher beleuchtet werden? - Wenn man Datenmodellierung vorschreibt, muss man auch das Testing / QS-Prozess beschreiben!
[MLR7] Bitte Erläuterungen ergänzen zu den einzelnen InteroperabilitätsELEMENTEN , was man jeweils darunter versteht (ggf. in sinngemäßer Übersetzung des INSPIRE-Interoperability-Frameworks)
[MLR8]
Irgendwo hier sollte unterschieden werden bzgl. des Zwecks der Anwendungsschemata von Geodaten:
1. Innerhalb eines Fachbereichs zur Erledigung spezifischer Aufgaben ausführliches und ggf. komplexes Datenmodell („Erhebungs-/Führungsmodell“)
2. Datenmodell für die Nachnutzung von Daten durch Externe, das sich aus obigem Datenmodell speist, aber nur die für die übergreifende Geodatennutzung relevanten Inhalte enthält („Bereitstellungsmodell“)
Die GDI-DE (und damit das vorliegende Doku) beschränkt sich auf Nr. 2!
[MLR9] Generell: Festlegungen und Empfehlungen klar benennen, z.B.
„In der GDI-DE ist das GDI-DE-UML-Profil anzuwenden“
„Datenmodelle für INSPIRE-betroffene Daten werden grundsätzlich auf Basis der INSPIRE-Kernmodelle nach dem vorgegebenen Mechanismus erweitert.“
usw.
Am besten deutlich kennzeichnen, z.B. in Kasten (Requirements vs. recommendations, vgl. INSPIRE)
[MLR10] Wäre eine Erhebung potenzieller Anwendungsfälle nicht besser, als deren Entwicklung?
[MLR11] Wie kann die Persistenz bei INSPIRE-Objekten gewährleistet werden, wenn ein INSPIRE-Objekt aus verschiedenen Objekten des Fachdatenbestands erst bei der Abgabe erzeugt wird? – Gleiche Frage stellt sich, wenn aus fachinternen komplexen Datenmodellen einfache Bereitstellungsmodelle abgeleitet werden und die Objekte keine unmittelbares 1:1-Äquivalent darstellen! – Handlungsbedarf für einheitliche Regel?
[MLR12] Macht das hier im Interoperabilitätskonzept wirklich Sinn? – Die nachfolgenden Anforderungen sind doch eher als CR einzubringen, ggf. ist hierfür ein Template vorzugeben …?!
[MLR13] Macht das Sinn im vorliegenden Interoperabilitätskonzept der GDI-DE??? Sollte nicht vielmehr auf das künfitge CRS-Register verwiesen werden, dass nur die dort registrierten CRS (ggf. Vorauswahl!) in GDI-DE verwendet werden dürfen / sollen.