Regeln für Teilnehmer:
Ich bin mit den Regeln einverstanden

Übersicht:

Favoritenliste:

Favourite Pages

There are currently no pages on your favourites list. You can add pages to this list by selecting Favourite from the Tools menu on the page you're viewing.
Child pages
  • Interoperabilitätskonzept

gdi-de_logo_300dpi.tif

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

GDI-DE Interoperabilitätskonzept

 

 

ENTWURF

 

 

Arbeitsgruppe Geodaten

01.04.2016  

 

Dieses Dokument enthält ein Konzept zu den Anforderungen für die interoperable Bereitstellung von Geodaten in der Geodateninfrastruktur Deutschland (GDI-DE).


Dokumenteninformation

Bezeichnung

GDI-DE Interoperabilitätskonzept

Autor

AG Geodaten

Erstellt am

01.02.2016

Zuletzt geändert

01.04.2016

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

 

Stephan Mäs

0.4

01.04.2016

Überarbeitung nach Review in der AG Geodaten und AK Architektur

AG Geodaten

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


Inhalt

Dokumenteninformation

Änderungsverzeichnis

1 Ziele des Interoperabilitätskonzepts

2 Einführung

3 Interoperabilitätselemente

3.1 Organisatorische Anforderungen

3.1.1 Beschreibung

3.1.2 Aktueller Stand in INSPIRE und GDI-DE

3.1.3 Bewertung, Handlungsbedarf und Empfehlungen

3.2 Regeln für das Anwendungsschema

3.2.1 Beschreibung

3.2.2 Aktueller Stand in INSPIRE und GDI-DE

3.2.3 Bewertung und Handlungsbedarf

3.3 Identifikatormanagement

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 Verwaltung und Bereitstellung von Schemadateien

3.5.1 Beschreibung

3.5.2 Aktueller Stand in INSPIRE und GDI-DE

3.5.3 Bewertung und Handlungsbedarf

Weitere Schritte / weiteres Vorgehen

Referenzen

Anhang 1: Weitere Interoperabilitätselemente (noch genauer zu spezifizieren)

Anhang 2: 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 die Kombinierbarkeit von Daten bzw. die Kombinierbarkeit und Interaktionsfähigkeit verschiedener Systeme unter Einhaltung gemeinsamer Standards verstanden. Das vorliegende Dokument verfolgt zwei Ziele:

  1. Die [SN2] Identifikation von Elementen, deren einheitliche Festlegung für eine interoperable Bereitstellung von Geodaten in der GDI-DE erforderlich sind (Interoperabilitätselemente). [MLR3]
  2. Die Erarbeitung [SN4] einer Methodik, die für eine schrittweise Harmonisierung vorhandener Datenbestände und Datenmodelle innerhalb der GDI-DE erforderlich sind.

Dieses Dokument mit seinen Empfehlungen richtet sich mit seinen Empfehlungen in erster Linie an:

  • GDI-Kontakt- und Koordinierungsstellen des Bundes und sowie   der Länder
  • Fachgremien der Arbeitsgemeinschaften der Fachministerkonferenzen, die mit der Formalisierung von Geodaten betraut wurden
  • Gemeinde- und Städtetag, die im Rahmen ihrer Aufgaben als kommunale Geodatenanbieter ebenfalls die interoperable Bereitstellung und Nutzung von Geodaten in der GDI-DE anstreben.

Mit dem Ziel der   Die Harmonisierung der Datenmodelle mit dem Ziel einen bundesweit einheitliche n r Datenbest a ä nd e zur Unterstützung nationaler und internationaler Fragestellungen zu schaffen, soll nur bei anhand von konkreten Anwendungsfällen angegangen werden, indem zunächst die betroffenen Fachnetzwerke identifiziert (gemäß Meldeliste INSPIRE), [s5] 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.

Auf Eine Ergänzung oder Erweiterung der harmonisierten Datenmodelle auf regionaler oder lokaler Ebene sind Ergänzungen oder andere Ansätze ist möglich, solange die Kompatibilität sichergestellt ist [AL6] . [SN7]

Mit dem vorliegenden Dokument wird ein gemeinsames Verständnis der von   „Interoperabilität“ für Datenmodelle im Rahmen der GDI-DE hergestellt. [MLR8]   Das daraus resultierende Dieses gemeinsame Verständnis ergibt sich aus dem Spannungsfeld zwischen ergibt sich einerseits einer möglichst vollständig harmonisierten Datenmodellierung und andererseits aus einer möglichst geringen Formalisierung, die nur wenig Anforderungen an eine Koordination zwischen den beteiligten Fachgebieten (Basisdaten, Umwelt, Statistik, Verkehr, etc.) stellt, aber unterschiedliche Modellierungsansätze für ähnliche Inhalte zulässt. Aus diesen Überlegungen heraus sollte vor der Anwendung des Interoperabilitätskonzeptes [SN9] [MLR10] der erforderliche Harmonisierungsbedarf festgelegt werden [AL11] , der sich mit der Frage beschäftigt, was wie stark zwischen einzelnen Themen und Fachdaten innerhalb der GDI-DE harmonisiert werden soll, um damit den Anforderungen an die angestrebten fachlichen Produkte zu genügen. Dies können Produkte auf nationaler, regionaler oder lokaler Ebene sein oder auch Produkte im Rahmen der Berichtspflichten an die EU.

Zur Umsetzung dieser Anforderungen sollten entsprechend e benötigte zentrale [s12] Aspekte identifiziert und festgelegt werden, sowie die Klärung und ggf. Festlegung in wessen Verantwortungsbereich die Definition und Umsetzung dieser Aspekte fällt. Ein Einbeziehen und Koordinieren in den der bestehenden INSPIRE-Fachnetzwerken wäre dazu sinnvoll [AL13] .

Keinesfalls sollen mit dem Interoperabilitätskonzept verpflichtend umzusetzende Datenspezifikationen analog zu INSPIRE vorbereitet, erstellt und beschlossen werden. Dieses Dokument macht lediglich Vorschläge [s14] [AL15] , wie Geodatenbestände formal beschrieben und ggf. harmonisiert bereitgestellt werden können, um eine interoperable Datenbereitstellung innerhalb der GDI-DE und die Nutzung der zentralen Komponenten der GDI-DE (z.B. Registry) zu fördern. [SN16]

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

Zur Priorisierung der in diesem Konzept vorrangig beschriebenen Interoperabilitätselemente wurden zwei Anwendungsfälle exemplarisch dargestellt   durchgespielt :

  • Für eine Fachdomäne existiert bereits ein formalisiert beschriebenes Datenmodell [SK(18] und dieses soll durch vorhandene oder noch zu entwickelnde Interoperabilitätselementen der GDI-DE (z. B. Registry) angepasst oder ergänzt werden. Hierfür wurde das AAA-Anwendungsschema der AdV herangezogen.
  • Für eine Fachdomäne existiert noch kein formalisiert beschriebenes Datenmodell und es soll ein neues Datenmodell erstellt, z.B. das entsprechende INSPIRE-Kerndatenmodell erweitert / verfeinert werden. Hierfür wurde das LAWA-Datenmodell verwendet.

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

2         Einführung [SN19]

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

Diese Aspekte gelten im Wesentlichen auch für andere Rahmenbedingungen und werden in diesem Dokument auf die interoperable Bereitstellung von Geodaten in der GDI-DE übertragen. Die im vorliegenden Dokument vorgeschlagenen Aspekte eines Interoperabilitätskonzepts basieren auf dem „INSPIRE Interoperability Framework“. Die Abbildung 1 enthält eine Übersicht über die für die interoperable Bereitstellung von Geodaten erforderlichen Elemente. Die farblich hervorgehobenen Elemente (orange) sind von der AG Geodaten priorisiert und für die oben beschriebenen Anwendungsfälle als unbedingt notwendig betrachtet   erachtet worden. Weiterhin sind die einzelnen priorisierten  Elemente in den nachfolgenden Kapiteln detailliert beschrieben. Durch weitere mögliche Anwendungsfälle können auch zusätzliche weitere oder abweichende andere Interoperabilitätselemente als hoch priorisiert werden.

Die umfassende Beschreibung der übrigen Interoperabilitätselemente soll schrittweise erfolgen. Im Anhang 1 wurden Z z unächst wurde n   sie im Anhang 1 nur überblicksartig die anderen/restlichen Interoperabilitätselemente beschrieben und für die weitere Spezifizierung kategorisiert.

 

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

[MLR22] Dieses Dokument ergänzt die von INSPIRE vorgeschlagenen Interoperabilitätselemente (siehe Abb. 1) um einige für die GDI-DE relevante n Aspekte, beschreibt kurz die ausgewählte, erforderlichen Interoperabilitätselemente und die daraus abgeleiteten konkreten Maßnahmen bzw. Handlungsempfehlungen. Die Ergebnisse sollten in die GDI-DE Architektur einfließen und schrittweise umgesetzt werden. [SN23]

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

Für die GDI-DE wird im Folgenden definiert, welche Festlegungen für Geodaten gelten sollten. Es wurde grundsätzlich darauf geachtet, dass die Vorgaben in Bezug auf die Bereitstellung von interoperablen Datensätzen deutlich weniger detailliert sind als in INSPIRE ausfallen   (wo durch die Vorgaben der Richtlinie bereits recht strikte Vorgaben bestehen, die für nicht-INSPIRE-Daten in der GDI-DE derzeit so nicht sinnvoll sind) [AL24] . Präzise Anforderungen werden nur bei solchen Interoperabilitätselementen gemacht, bei denen die GDI-DE schon bereits   konkrete Lösungen (z. B. zentrale Betriebskomponenten) hat oder verfolgt, die auf die speziellen Rahmenbedingungen in der GDI-DE zugeschnitten sind . [MLR25]

Grundsätzlich beziehen sich die Interoperabilitätselemente auf Datenmodelle, die für eine übergreifende Geodatennutzung vorgesehen sind (sog. Bereitstellungsmodell). Auch die INSPIRE-Datenmodelle gelten als derartige Bereitstellungsmodelle. Völlig anders und unabhängig von den Interoperabilitätselementen der GDI-DE können Datenmodelle spezifiziert werden, die innerhalb eines Fachbereichs für die Datenführung implementiert werden, solange die Kompatibilität zu den jeweiligen Bereitstellungsmodellen sichergestellt ist. [AL26]

3         Interoperabilitätselemente [MLR27]

Nachfolgend werden die für die GDI-DE priorisierten Interoperabilitätselemente beschrieben (vgl. Abbildung 1 ) sowie der aktuelle Stand bewertet und mögliche Maßnahmen formuliert. [s28]

3.1     Organisatorische Anforderungen

3.1.1     Beschreibung

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

Dies bezieht sich insbesondere auf die Rollenverteilung bei der Modellerstellung bzw. der Erweiterung/Verfeinerung der INSPIRE-Kerndatenmodelle, die Identifikation und Bestimmung der jeweils in den Datenthemen und Anwendungsdomänen hauptverantwortlichen Datenprovider und die Sicherstellung, dass diese auch in den Prozess eingebunden werden. Zusätzlich muss geklärt werden,

  • wer die Nutzer der Datenmodelle für die Datenbereitstellung sind, nutzt und
  • wer die Nutzer der bereitgestellten Daten bzw. Dienste sind,
  • wer der Moderator der den Prozess [SN29] [AL30] wie moderiert (z.B. die Kst.GDI-DE, die AG Geodaten, der AK Architektur) ist und in welcher Form dies erfolgt und
  • wie die Erfüllung der Nutzeranforderungen überprüft werden. Dies ist in erster Linie nur für solche Datenmodelle relevant, die aufgrund konkreter Anwendungsfälle länder - und/oder d atenanbieter übergreifend und/oder Datenanbieter übergreifend abgestimmt werden sollen.

3.1.2     Aktueller Stand in INSPIRE und der GDI-DE

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

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

3.1.3     Bewertung, Handlungsbedarf und Empfehlungen

Sofern bei allen Akteuren ein gemeinsames Verständnis der zur   „Interoperabilität“ für Datenmodelle vorliegt und der [SN33] erforderliche Grad der Harmonisierung zwischen einerseits einer möglichst vollständig harmonisierten Datenmodellierung und andererseits einer möglichst geringen Formalisierung festgelegt wurde, lassen sich folgende Empfehlungen ableiten. Eine Unterscheidung erfolgt 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 Harmon i sierungsprozess von Datenmodellen

Die folgenden Rollen und deren Motivation lassen sich identifizieren und sind in den Harmonisierungsprozess von Datenmodellen mit einzubinden:

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

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

  • Datennutzer

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

Beispiel 1: Datennutzer von fachfremden Behörden oder Behörden anderer Kommunen und Länder

Beispiel 2: Nutzer auf der Bundes- und Europaebene oder  

Beispiel 3: Nutzer aus der Wirtschaft, Wissenschaft und dem Privatbürgertum.

  • Koordinatoren/Moderatoren

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

Beispiel: Fachnetzwerke, Arbeitsgruppen der GDI-DE oder Einzelpersonen

  • Generelle Datenmodellierungsexperten

Die generellen Datenmodellierungsexperten haben weitreichende Erfahrung in der Modellierung von (Geo-)Daten, kennen die spezifischen Anforderungen (z. B. aus INSPIRE) und sind dafür verantwortlich, dass qualitativ hochwertige Datenmodelle erzeugt werden.

Beispiel: Modellierungsexperten aus der Geoinformatikwissenschaft.

  • Technische Datenmodellierungsexperten

Die technischen Datenmodellierungsexperten begleiten die Entwicklung der harmonisierten Datenmodelle mit der Entwicklung [AL38] von entsprechenden Softwarewerkzeugen zur Modellierung und Schematransformation, z. B. mit der FME.

Beispiel: Geoinformatikexperten aus Wissenschaft und Forschung.

Empfehlungen für die Vorbereitung des Harmonisierungsprozesses

Hinweis: Die folgenden Schritte dienen der Vorbereitung und der Entwicklung des eigentlichen Harmonisierungsworkflows. Die INSPIRE-Fachnetzwerke sollen in die Vorbereitung mit einbezogen werden.

  1. Identifizierung eines Anwendungsfalls [MLR39]

Vor den folgenden Schritten sollen ein oder mehrere Anwendungsfälle beschrieben werden, die auf einer Ist-Analyse [SN40] basieren. Die zu entwickelnden Anwendungsfälle sollen auch die eigentliche Implementierung inklusive des entsprechenden Testens und Validierens umfassen und sowie   Schritte für das Fortschreiben des Datenmodells vorgeben. Für die letzteren Schritte [SN41] sollen die Koordinatoren/Moderatoren verantwortlich sein. Die Aktivitäten [SN42] sollen sich am bestehenden Prozess für die Erstellung der INSPIRE-Datenspezifikationen orientieren und Analysen bezüglich allgemeiner Nutzeranforderungen enthalten. [s43]

  1. Liste der verantwortlichen Datenprovider und Datennutzer

Um sicherzustellen , dass alle relevanten Akteure in den Modellierungsprozess mit einbezogen sind, sollten die verantwortlichen Datenprovider und Datennutzer der Fachdomäne unter Berücksichtigung der föderalen Strukturen involviert 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.

  1. Liste möglicher fachlicher Ansprechpartner [SK(44] [AL45]

Es sollte ein Netzwerk fachlicher Ansprechpartner für die Harmonisierung der Datenmodelle erstellt werden, aus der fachlich kompetente Experten einerseits zum einen   für die weitergehenden Ist- als auch Defizitanalysen fachlich kompetente Experten ausgesucht werden können, als auch für die spätere eigentliche Datenmodellharmonisierung. Für die Kommunikation innerhalb dieser Ansprechpartner wird eine zentral organisierte Kooperationsplattform (Wiki) vorgeschlagen.

  1. Analyse bestehender Datensätze/-spezifikationen (unterschiedlicher) Behörden

Anhand von ausgewählten Beispieldatensätzen sollte evaluiert werden, zu welchen Aspekten es aufgrund der Unterschiedlichkeit   der zurzeit unterschiedlich verwendeten Datensätze Harmonisierungsbedarf existiert und ob bereits eine einheitliche Datenspezifikationen bzw. Anforderungen im Sinne von bundesweiten Vorgaben bzw. Vereinbarungen vorliegt (z. B. die Verwaltungsvereinbarung zum Austausch von Umweltdaten oder abgestimmte Datenmodelle für das Reporting und elektronische Berichterstattung). Hierzu sollen [SK(46] Datensätze von vergleichbaren Landesbehörden unterschiedlicher Bundesländer, als auch Bezirksregierungen und Kommunen untersucht werden, um später eine harmonisierte Datenbereitstellung für eine Erhöhung der wechselseitigen Nachnutzbarkeit zu gewährleisten. Hierbei sollte ebenfalls geklärt werden, auf welchen Ebenen die Zuständigkeiten für die Koordination und Moderation der Harmonisierung liegen sollen.

Als Ergebnis sollte eine Liste von Standards und Spezifikationen, die für das jeweilige Thema bereits Verwendung finden und bestehender inhaltlicher und technischer Anforderungen an das harmonisierte Datenmodell , erstellt werden. Weiterhin sollen Datensätze für die weitere Untersuchung gesammelt werden, um daraus einen oder mehrere Anwendungsfälle (-beispiele) für den Harmonisierungsprozess ableiten zu können.

Empfehlungen für den Datenspezifikationsprozess

Es wird empfohlen sich bei der Spezifikation des harmonisierten Datenmodelles an den aus INSPIRE bekannten Schritten für den Datenspezifikationsprozess zu orientieren (siehe Abb. 2; INSPIRE, 2008; Tóth u. a., 2012) . [SN47] Anhand der Best Practice -Vorgaben (Kapitel 3.2.3 ) und den Ergebnissen und sowie den   Anforderungen aus den vorhergehenden Empfehlungen zur Vorbereitung sollen bestehende Datenmodelle fortgeführt und erweitert bzw. neue Datenmodelle entwickelt werden. Die Modellierung sollte sich immer an konkreten Anwendungsfällen orientieren. Zur Ergebnisvalidierung sollten i n Zusammenarbeit gemeinsam   mit den Datenprovidern, Datenmodellierungsexperten und den für die Softwareumsetzung geschulten Experten (z. B. FME) die Anwendungsfälle beispielhaft durchgespielt werden.

 

  C:\Users\Markus.NB2914\Pictures\Bild1wewewe.png

Abbildung 2 : Mögliche Schritte bei der Erstellung von Datenspezifikationen (DIN CEN/TR 15449-3 2014)

In Abstimmung mit allen Akteuren ist ein realistischer Zeitplan für den Prozess aufzustellen, welcher die Umsetzung begleitet und überwacht.

*************************bis hier in der AG Geodaten besprochen**********************

3.2     Regeln für das Anwendungsschema [SN48]

Dieses , im Folgenden beschriebene Interoperabilitätselement ist nur dann anzuwenden, wenn ein Datenmodell unter Verwendung der gleichen Modellierungsgrundsätze und Methodik wie bei INSPIRE gewollt ist. Ferner ist dieses Element Voraussetzung für den Andendungfall An w endung s fall „Erweiterung von INSPIRE“, da eine fachliche Erweiterung der INSPIRE-Datenmodelle nur unter Berücksichtigung derselben Modellierungsmethodik möglich ist.

 

3.2.1     Beschreibung

wie Anwendungsschemata sind konzeptionelle Datenmodelle, die für eine bestimmte Anwendung Applikation   oder ein Datenthema entwickelt wurden. Darin Es   werden Objektklassen definiert, die die (räumlichen) Objekttypen, Attribute, Relationen und Integritätsregeln zwischen den Objekten festgeleg en t . Zur Repräsentation von konzeptionellen Datenmodellen werden in der Regel maschinenlesbare Notationen wie UML verwendet, um die automatische Ableitung von Encodingschemata (z. B. in XSD) zu ermöglichen. Eigenschafts- bzw. Feature-Kataloge sind eine äquivalente Präsentation der Informationen aus den Anwendungs schemata [SN49] [AL50] . Sie unterstützen die textuelle Dokumentation, die Mehrsprachigkeit, sowie die Suche und den Zugriff auf einzelne Elemente der Anwendungsschemata.

Die Regeln für Anwendungsschemata liefern Festlegungen, wie Datenmodelle vom 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 der GDI-DE

In INSPIRE erfolgt die Modellierung der Anwendungsschemata in UML nach ISO 19109 unter Verwendung eine s INSPIRE-UML-Profils. Die Objektartenkataloge sind aus dem UML-Modell abgeleitet. In den referenzierten Dokumenten ( s. Referenzen [AL51] ) findet sich eine Reihe von weiteren detaillierteren Vorgaben , von denen hier nur e E inige beispielhaft aufgeführt werden:

INSPIRE Generic Conceptual Model (INSPIRE GCM 2014)

  • Definition des allgemeinen Rahmens zur Entwicklung von harmonisierten Datenspezifikationen:
    • Relationen zu den ISO 19xxx Standards
    • Raum-zeitliche Repräsentationen räumlicher Objekte über verschiedene Auflösungsstufen
    • Raum-zeitliche Beziehungen zwischen räumlichen Objekten
    • Identifikatoren
    • Mehrsprachigkeit
    • Verwendung von gemeinsamen Vokabularen

Drafting Team "Data Specifications" – deliverable D2.6, insb. Kapitel 6   [INSPIRE D2.6 2008] [AL52] :

  • Festlegung von optionalen und verpflichtenden Attributen:

Verpflichtende Attribute sind als solche festzulegen, wenn die Features ohne sie  bedeutungslos [AL53] sind.

  • Bei verschiedenen Modellierungsoptionen sind jeweils Nutzungsempfehlungen [AL54] zu geben.
  • Vermeidung von Enumerationen (nicht erweiterbare Aufzählungen) mit vordefinierten quantitativen Intervallen.
  • Empfehlung zur Nutzung von hierarchischen Klassifikationen, sofern die Unterklassen immer nur durch ein Unterscheidungsmerkmal festgelegt sind, nicht durch mehrere.

JRC Reference Report 2012   ( TÓTH ET AL. 2012) [AL55] :

  • Bedingungen zur Entwicklung von mehreren Anwendungsschemata für ein Datenthema:
    • sehr umfangreiches Thema sehr umfangreich oder eine logische Aufteilung nach unterschiedlichen Sichten nicht möglich ist , wie z. B. beim INSPIRE Thema „Transport Netze“ mit der Unterteilung nach Straßen-, Schienen- und Wasserverkehr etc.
    • bei rechtlich bindende Kernkomponenten des Modells, während Erweiterungen nur einen empfehlenden Charakter haben
    • bei explizite r Modellierung verschiedener Auflösungs- oder Skalierungsstufen.

d D erzeit gibt es innerhalb der GDI-DE keine mit den INSPIRE Daten Spezifikationen vergleichbaren, konkreten Vorgaben und es sind bisher im Rahmen der NGDB auch keine geplant. Das GDI-DE-Architekturkonze [AL56] pt empfiehlt bislang nur sehr allgemein die Beachtung der INSPIRE-Grundsätze. Des Weiteren existiert derzeit explizit kein UML-Profil für die GDI-DE, allenfalls implizit in verschiedenen Anwendungen in Fachmodellen (z. B. AAA-Datenmodell der AdV).

3.2.3     Bewertung und Handlungsbedarf

 

Entwicklung eines GDI-DE-Referenzmodells

Für die beiden definierten Anwendungsfälle des Interoperabilitätsrahmens (s. in Kap. 1) werden dringend Vorgaben für die Modellierung werden für beide in Kap. 1   definierten Anwendungsfälle des Interoperabilitätsrahmens dringend benötigt. Optimal wäre in diesem Zusammenhang ein fachneutraler Modellierungsrahmen, der als Basis für alle Fachdaten in UML nach ISO 19109 zusammen mit einem GDI-DE-UML-Profil angewendet werden könnte. [s57] Mit einem derartigen Referenzmodell könnte festgelegt werden, welche ISO/TC 211   Standards erfüllt werden müssen bzw. sollten und Hilfestellungen bzgl. der Nutzung von Standards gegeben. Darüber hinaus sollten Methoden und Vorgaben zu den Inhalten der Modelldokumentation und zur Ableitung von 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 grundsätzlich die Aufgabe für von   Modellierungsexperten mit entsprechendem INSPIRE-Hintergrundwissen. In der Praxis verfügen die Modellierer jedoch nicht immer über dieses Wissen. Eine Leitlinie zum Vorgehen für die Erstellung von Modellen wäre an dieser Stelle hilfreich, z. B. in Form eines frei zugänglichen Wiki mit Beispielen, Leitfäden, einer Sammlung weiterführender Links, Diskussionsforum etc., ähnlich wie:

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

U nter anderem sollten I i nhaltlich sollten unter anderem F f olgende s Fragen   geklärt werden:

  • Allgemeine Fragen zur Modellierung
    • Welche Vorteile hat ein auf internationalen Standards basierendes Datenmodell?
    • Welche Alternativen gibt es und haben diese Vorteile/Nachteile?
    • Welche Software wird genutzt bzw. eingesetzt (UML Modellierung, Ableitung des XML Schemas, etc.)?
    • Welche Modellkonstrukte sind zu vermeiden (z. B. Assoziation Classes)?
    • Wie könnte eine Dokumentation der Modelle aussehen?
    • Wie kann die GDI-DE Registry bei der Modellierung eingebunden werden (z. B. Registrierung der Codelisten)?
    • Wie sind Integritätsregeln zu definieren (z. B. OCL)?
  • Vorgaben zur Modellierung der Maßstabsabhängigkeit
  • Notwendiges Hintergrundwissen zu INSPIRE ( Entscheidungshilfe /-fragen):
    • Entscheidungshilfe /-fragen : Wer ist verpflichtet auf den INSPIRE Schemata aufsetzen [AL59] ?
    • Wer ist nicht verpflichtet ist , sollte sich aber trotzdem daran orientieren?
    • Für wen sind die Vorgaben von INSPIRE Vorgaben bzw. die Vorgaben aus dem GDI-DE Interoperabilitätskonzept nicht relevant?
    • Welche INSPIRE Packages sind relevant? Wie sind diese einzubinden bzw, / zu erweitern?
    • Welche vorgegebenen INSPIRE-Klassen sind wann und wie zu übernehmen?
    • Besonderheiten der INSPIRE Modellierung:
      • NULL -   Attribute
      • Unterscheidung von featuretype (geographisch referenziert) und datatype: Wo ist eine geographische Referenz notwendig?
      • Unterscheidung von Codelisten und Enumerationen
      • Beschreibung der Prozesse zur Erweiterung der INSPIRE-Datenmodelle (Objektarten, Codelisten, …)

Maßnahmen:

  • Entwicklung eines Referenzmodells für die Datenmodellierung für die GDI-DE
  • Best Practices für die Entwicklung von Anwendungsschemata für die GDI-DE

 

3.3     Identifikatormanagement [SN60]

3.3.1     Beschreibung

Festlegungen, ob und wie Dinge Geoo bjekte   in der realen Welt und Objekte abgebildet und dauerhaft identifiziert werden können. Dies beinhaltet 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 (eindeutige) Identifikatoren auch erlaubt bzw. ermöglicht   den Zugriff auf die Geoo O bjekte erlauben , z. B. zum Verlinken von externen Daten auf die Geoobjekte

3.3.2     Aktueller Stand in INSPIRE und der GDI-DE

INSPIRE-Vorgaben

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

-           Nationale Regelungen beruhen oft auf INSPIRE-Vorgaben

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

Geltungsbereich für Objekt [AL61] identifikatoren

In der INSPIRE Richtlinie sind identifizierbare Objekte sogenannte „spatial objects“, im Folgenden Geoobjekte genannt [1] . Ein Objektidentifikator (OI) bezieht sich damit nicht auf ein real - weltliches Phänomen (z. B. einen bestimmten Baum oder einen bestimmten See), sondern auf dessen Abstraktion (= ein Geoobjekt). Unterschiedliche Abstraktionen des gleichen real - weltlichen Phänomens erhalten [AL62] somit unterschiedliche Identifikatoren [AL63] .

Die Art der Abstraktion wird üblicherweise in einer Vorschrift zur Objektbildung [s64] bzw. über eine Erfassungsvorschrift bei der Objektaufnahme im Feld oder über fernerkundliche Hilfsmittel festgelegt. Die Anwendung sog. „spatial object types“ mit verpflichtenden und optionalen thematischen, geometrischen, topologischen und temporalen Attributen sind ein übliches gängiges   Instrument zur normativen Objektbildung. Ebenso legen Qualitätsvorgaben bei der Erfassung (Straßen als Linien oder Flächen, Lagegenauigkeit etc.) grundsätzlich die Art der Abstraktion fest. Unterschiedliche Abstraktionsniveaus können jedoch leicht in der Erfassung, Vorverarbeitung und Weitergabe der Daten (z. B. durch zwischengeschaltete Generalisierungsstufen) entstehen. Solche Einflüsse werden im INSPIRE Generic Conceptual Model ( INSPIRE GCM 2014 ) jedoch nicht im Detail diskutiert.

Anforderungen an Objektidentifikatoren

Das INSPIRE Generic Conceptual Model ( INSPIRE GCM 2014 ) (IGCM) stellt 4 vier   Anforderungen an Objektidentifikatoren:

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

3.3.3     Bewertung und Handlungsbedarf

3.3.3.1 Eindeutigkeit

Die Eindeutigkeit von Objekt I i dentifikatoren wird im INSPIRE GCM 2014   IGCM wie folgt definiert:

(1)   Ein Identifikator bezeichnet genau ein Geoobjekt.

(2)   Die Eindeutigkeit dieses Identifikators muss innerhalb des Geltungsbereiches garantiert sein (z. B. eindeutig innerhalb der Menge aller INSPIRE-Geoobjekte).

(3)   Unterschiedliche Versionen oder Kopien des gleichen Geoobjektes (d.h. gleiche Abstraktion des gleichen real - weltlichen Phänomens) haben den gleichen Identifikator.

(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 transparenter zu kennzeichnen. Obwohl Versionen nicht Bestandteil des [externen] [AL65] Identifikators eines Geoobjekts sind, wird im INSPIRE GCM 2014 ein versionierter Datentyp für Identifikatoren vorgeschlagen (siehe Tabelle 1 ). Ein Namespace und eine LocalId bilden den [externen] Identifikator, das Versionsfeld kann eine fortlaufende Nummer sein oder einen Zeitstempel enthalten. Zudem kann dieser Identifikator-Datentyp auch für die interne Datenhaltung genutzt werden.

Tabelle 1 : Auszug aus dem Generic Conceptual Model von INSPIRE

Class:<<datatype>> Base Types.Identifier (INSPIRE GCM 2014, Clause 9.8.2.3.1)

Attribute:

LocalId

Definition: A local identifier, assigned by the data provider. The local identifier is unique within the namespace, i.e. no other spatial object carries the same unique identifier.

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

Attribute:

Namespace

Definition: Namespace uniquely identifying the data source of the spatial object.

Description: The namespace value will be owned by the data provider of the spatial object and will be registered in the INSPIRE External Object Identifier Namespaces Register.

Attribute:

VersionID

Definition: The identifier of the particular version of the spatial object, with a maximum length of 25 characters. If the specification of a spatial object type with an external object identifier includes life-cycle information, the version identifier is used to distinguish between the different versions of a spatial object. Within the set of all versions of a spatial object, the version identifier is unique.

Description: The maximum length has been selected to allow for time stamps based on ISO 8601, for example, "2007-02-12T12:12:12+05:30" as the version identifier.

The property is void, if the spatial data set does not distinguish between different versions of the spatial object. It is missing, if the spatial object type does not support any life-cycle information.

 

Maßnahmen:

  • 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 [AL66] sein.
  • „Verfallene“ Identifikatoren müssen erfasst bleiben, damit diese nicht irrtümlich erneut vergeben werden.
  • Die verantwortlichen Stellen für die Pflege der Identifikatoren sollten klar benannt sein. Ihnen obliegt die Durchsetzung bzw. Einhaltung der obigen Punkte.

3.3.3.2 Persistenz

Die Persistenz von Identifikatoren wird im INSPIRE GCM 2014 wie folgt beschrieben:

(1)   Für den gesamten Lebenszyklus eines Geoobjektes bl i e i bt der Identifikator unverändert.

(2)   Die Regeln zum Lebenszyklus von Geoobjekten variieren zwischen verschiedenen Datenprovidern. Daher werden sind in den I NSPIRE-Datenspezifikationen keine definitiven Vorschriften zum Lebenszyklus-Management für Geoobjekte vorgenommen.

Im Bereich der INSPIRE-Datenthemen gibt es in den Mitgliedsstaaten keine flächendeckende Unterstützung für die Abbildung von Lebenszyklen oder Versionen. Daher bleiben das INSPIRE Generic Conceptual Model und die darauf aufbauenden Datenspezifikationen hier unkonkret. Folgende Aspekte sind jedoch in als   Regeln zum für   ein Life-Cycle [AL67] 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 i m n INSPIRE GCM 2014, Kapitel 9.7 zu finden.

Maßnahmen:

  • Werden Informationen zum Lebenszyklus des Geoobjekts generell nötig (ja/nein)?
  • Wenn ja:

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

-           Definition einer entsprechenden Vorschrift zur Versionierung für Identifikatoren.

3.3.3.3 Rückverfolgbarkeit

INSPIRE fordert einen Mechanismus zur Auffindbarkeit von Geoobjekten, basierend auf dem jeweilis dazugehörigen 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 (Katalog) das Geoobjekt finden.

Maßnahmen:

  • Voraussetzung für die Rückverfolgbarkeit setzt ist 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 einen Mechanismus [AL68] (z. B. einen Suchdienst) bereitstellen, der das Auffinden von Downloaddiensten für die von ihm bereitgestellten Geoobjekte ermöglicht.

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

-           Der Zugriff auf vorangegangene Versionen eines Geoobjektes ist optional. Der Suchende muss aber erkennen können, welche Version des Geoobjektes über den Datenzugriffsdienst bezogen werden kann.

3.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 [s69] . Sie definieren syntaktische Vorgaben für den Aufbau von Namensräumen auf verschiedenen föderalen Ebenen.

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

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

(bei nicht einheitlichen lokalen IDs innerhalb der gesamten Behörde)

Konzeptionelle Probleme ergeben sich typischerweise an administrativen Grenzen oder an überlappenden fachlichen Zuständigkeiten. Hierbei sind folgende Fragen zu klären:  

  • Was passiert mit Geoobjekten, welche die Ländergrenzen schneiden?
  • Hört die Objektbildung grundsätzlich an der Ländergrenze auf?
    • Das ist in großen Teilen zwar gängige Praxis (z. B. überregionale Flussläufe, grenzüberscheitende Schutzgebiete), aber aus Anwendersicht oft verwirrend und schwer nachvollziehbar.
  • In wessen Zuständigkeit fällt die Bildung ( bestimmter ) grenznaher oder -überschrei tender Geoobjekte (z. B. Flussläufe) für welchen Anwendungsfall?

Maßnahmen: Zu d D iese n Fragen zur der Vergabe von Objektidentifikatoren sind zunächst 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 -bereitstellung an eine Registry beschrieben. Andere funktionale Aspekte, wie z. B. das INSPIRE-Monitoring, werden in diesem Zusammenhang nicht behandelt.

3.4.1     Beschreibung

Registries nehmen in Geodateninfrastrukturen eine zentrale Rolle ein, da sie das Verwalten, Auffinden und Nutzen von vorhandenen Geoinformationsressourcen innerhalb der Infrastruktur ermöglichen. Dazu gehören beispielsweise Datenprodukte, Dienste, Anwendungsschemata (in UML/XML), Koordinatenreferenzsysteme, Maßeinheiten, Codelisten, Daten- und Objektarten, Dienstetypen oder auch Zeichenvorschriften und Symbole sowie die Schemadateien. 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. [AL71]

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

Abbildung 3 : Organisationsmodell einer Registry nach ISO 19135

Entscheidend für einen geordneten Betrieb einer Registry ist die Festlegung der verschiedenen Rollen, unabhängig von der technischen Realisierung einer Registry, wie z. B. (vgl. Abbildung 3 ):

Maßnahmen: Festlegung der Rollen gemäß ISO 1 9 0 135 und der entsprechenden verantwortlichen Akteure für jedes Register der GDI-DE.

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

3.4.2     Aktueller Stand in GDI-DE und Handlungsbedarf [SN75]

3.4.2.1 Codelisten-Registry

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 [AL76] in einer Codeliste aufgeführt. Die Codeliste wird meist gemeinsam mit dem Datenmodell veröffentlicht. Dem Datenerfassern Datener heber   muss diese Codeliste, die Bedeutung der einzelnen Codes sowie der Pflege- und Qualitätszustand bekannt sein, um für die Erfassung den passenden Wert auswählen zu können.

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 vermeiden, 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. [AL77]

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 zur   Erstellung von harmonisierten Geodatensätzen sowie
  • die Anwender bei der Interpretation der Codes in einem Datensatz.

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

Maßnahmen: Analyse der Anforderung sanalyse der verschiedene n r Datenanbieter an die Codelisten -R egistry   [s78] und anschließende Weiterentwicklung der Codelisten-Registry. Ferner sind die Prozesse zu definieren, wie ein Nutzersystem [AL79] 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 die Einzeldaten   durch eine entsprechende Transformationen in ein einheitliches CRS gebracht werden.

Die Kopplung Verknüpfung   der Geometrien eines der Datens atzes ätze zu einem CRS erfolgt jeweils über einen CRS-Identifikator. Um die erforderlichen Parameter für eine Transformation zu erhalten, müssen Anwendungen in der Lage sein, die dem Identifikator zugeordneten Parameter des CRS zu erhalten zu interpretieren bzw. auszuwerten . Um die CRS-Parameter verlässlich nutzen zu können, müssen sie diese   durch eine autorisierte Stelle bereitgestellt und gepflegt werden. Derzeit werden CRS ü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 und keine 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 erfolgt die Entwicklung und de r n Betrieb eines , von allen Datenanbietern , nutzbare s n CRS-Registers für die GDI-DE, über das alle Anwendungen zu über   eine n m CRS-Identifikator exakt die gleichen CRS-Parameter erhalten. Durch die Nutzung und Pflege dieses Registers soll gewährleistet werden, dass Transformationen, die über Transformationsdienste externe D ienste bereitgestellt werden, oder Anwendungen, die selbst transformieren oder für andere Zwecke CRS- konforme Informationen benötigen, im Ergebnis zu den gleichen Transformationsresultaten R esultaten kommen.

Steht die CRS-Registry der GDI-DE zur Verfügung, sind sämtliche von der GDI-DE den Datenanbietern zum Zwecke der interoperablen Bereitstellung verwendete Koordinatenreferenzsysteme zu erfassen und einzutragen. Im Anhang 2 sind be i s i pielhaft die von den Datenanbietern der Marine Dateninfrastruktur Deutschland (MDI-DE) 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 noch nicht in der EPSG-Datenbank   vorkommen/ vorhanden sind [AL80]

3.4.2.3 Registry für Maßeinheiten [s81]

In einem Datenmodell muss für jeden quantitativen Wert dessen Maßeinheit angegeben sein. In diesem Abschnitt werden die dafür zu verwendenden Kurzbezeichnungen definiert, die auch in den jeweiligen XML-Schemadateien Verwendung finden. Zur Interpretation dieser Kurzbezeichnungen wird die exakte Definition der verwendeten Maßeinheit in einer zentralen Registry benötigt. Die Angabe der Maßeinheit (UoM - Unit of Measure) in einer XML-Datei (GML) hat den Datentypen "anyURI". Damit sind sowohl URL- als auch URN-Angaben erlaubt. Die URL-Variante setzt eine explizite XML-Beschreibung der verwendeten Maßeinheit in einem GML-Dictionary voraus.

Die folgende Tabelle (Tab. 2) enthält exemplarisch einige gebräuchliche Maßeinheiten:

Tab. 2 : gebräuchliche Maßeinheiten

Maßeinheit

Kurzbezeichnung

Meter

m

Millimeter

mm

Kilometer

km

Quadratmeter

m2

Kubikmeter

m3

Grad, dezimal (Altgrad)

grad

Gon, dezimal

gon

Radians

rad

m/s 2

ms-2

m 2 /s 2

m2s-2

 

Maßnahmen: Erfassung und Beschreibung der verwendeten Maßeinheiten in einer Registry (UoM-Registry) durch die jeweiligen Fachnetzwerke [AL82] . 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     Verwaltung und Bereitstellung von Schemadateien [SN83]

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

3.5.2     Aktueller Stand in INSPIRE und der GDI-DE

XML-Schemata werden bei OGC und INSPIRE in einfachen dateibasierten Repositories über WebServer bereitgestellt. Diese Bereitstellung ist für die Zwecke der GDI-DE ausreichend. Hier wird kein e nach ISO-19135 aufgebautes Register benötigt . , sondern eine einfache Lösung ist aus reichend . Da die GDI-DE bereits ein entsprechendes Register aufgebaut hat, werden die einschlägigen Schemadateien der Datenanbieter dort eingestellt.

Siehe http://repository.gdi-de.org/schemas/

 

Aufgrund der unterschiedlichen Ansätze und Lösungen bei den Datenanbietern wird im Gegensatz zu den XML-Schemadateien eine zentrale Bereitstellung der Datenmodelle in einem von GDI-DE geführten Register als nicht notwendig erachtet. Es ist jedoch sicherzustellen, dass diese Datenspezifikationen an geeigneter Stelle online zur Verfügung stehen.

3.5.3     Bewertung und Handlungsbedarf

Das Schema-Repository für XML-Dokumente wird bereits betrieben. Die GDI-DE sollte darauf hinwirken, dass dieses Repository von allen Datenanbietern innerhalb der GDI-DE verwendet wird und langfristig zur Verfügung steht.

Maßnahmen: Bereitstellung aller erforderlichen Schemadateien, welche die interoperable Daten in der GDI-DE spezifizieren nach einheitlichen Regeln   spezifizieren .

Damit das Einstellen der Schemadateien und deren Strukturierung in den Verzeichnissen der Registry nach einheitlichen Regeln passiert   erfolgt , ist die Festlegung entsprechender Regelungen für den Namensraum -Regelungen für von Schemata durch den AK Architektur erforderlich.

 


4         Ausblick

Mit dem vorgelegten Das vorliegende Konzept werden definiert   schrittweise   d i e     Interoperabilitätsanforderungen an Geodaten innerhalb der GDI-DE definiert , deren Umsetzung in einzelnen Fachdisziplinen oftmals auf Freiwilligkeit basiert und nur angegangen werden soll müssen , wenn es konkrete Anforderungen Regelungen   und ein gemeinsames Verständnis der erforderlichen Interoperabilität gibt.

Aus diesen Überlegungen heraus wurde die Entwicklung des Interoperabilitätskonzepts begonnen, das einen Lösungsweg [AL84] vorschlägt, wie Geodaten aus unterschiedliche n r Themen komplexen und innerhalb der GDI-DE harmonisiert werden könnten. Zur Umsetzung dieser Empfehlungen wurden die benötigten zentralen Aspekte identifiziert und festgelegt, sowie in wessen Verantwortungsbereich die Definition und Umsetzung dieser Aspekte fällt.

Folgende weitere Schritte werden vorgeschlagen:

  • Evaluierung des vorgeschlagenen Ansatzes und der vorgeschlagenen Maßnahmen durch die Akteure der GDI-DE (Arbeitskreise, Kontaktstellen, Fachnetzwerke etc.)
  • Fortschreibung und Ergänzung des Konzeptes ,   Ausarbeitung um die der weiteren , vorrangig zu behandelnden Interoperabilitätselemente (siehe Anhang 1)
  • Schrittweise Beschluss und schrittweise Umsetzung der vorgeschlagenen Maßnahmen mit Festlegung der Akteure, die diese n Umsetzung Prozess   koordinieren bzw. mit begleiten sollen (z.B. Kst GDI-DE, AK Architektur etc.)

Geodaten sind die zentrale Ressource n einer Geodateninfrastruktur. Mit diesem Entwurf für ein GDI-DE Interoperabilitätskonzept entsteht ein wichtiger Leitfaden für eine standardkonforme Beschreibung und Bereitstellung von Geodaten in der GDI-DE. Daher sollten die Arbeiten daran fortgesetzt werden.


Referenzen

 


Anhang 1: Weitere Interoperabilitätselemente [MLR85] ( noch genauer zu spezifizieren [AL86] )

 

Element

Kurzbeschreibung

Abschätzung der derzeitigen Situation in der GDI-DE

Kategorisierung der AG Geodaten

A=vorrangig zu entwickeln

B=nachrangig zu entwickeln

Modellierungs - grund - sätze

Zusammenstellung der grundlegenden Modellierungsprinzipien und –methodiken für Geodaten in der GDI

 

Bisher nur grobe und allgemeingültige Vorgaben im Architekturkonzept

INSPIRE-Erwägungsgründe gelten unmittelbar auch für GDI-DE

Allerdings fehlen bisher Ansätze zur Modellierung und Sicherstellung von Nutzeranforderungen (vgl. Element Organisatorische Anforderungen)

A

Referenzmodell

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

In GDI-DE bisher nicht als Referenzmodell vorhanden

A

Nutzung zentraler Komponenten der GDI-DE

Festlegungen, wie Geodaten mit anderen Komponenten der GDI zusammenhängen.

Bezug zum Organisationsmodell: Was sind global genutzte Komponenten im Interoperabilitäts-rahmen? Welche müssen dezentral vorhanden sein, damit die Architektur später auch funktioniert?

Welche Rolle spielen hier andere Open-Government-Dienste und -Standards?

Bisherige Festlegungen des Architekturkonzepts müssen entsprechend ergänzt werden.

Für Dienste werden derzeit von der GDI-DE verschiedene Profile (Handlungsempfehlungen) erarbeitet, die auch das Zusammenwirken mit den Geodaten behandeln.

A

Terminologie

Festlegungen von wesentlichen Begriffen und deren Definition

In GDI-DE derzeit nicht vorhanden

B

Innerhalb eines Fachnetzwerkes jedoch: A

Mehrsprachigkeit

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

In GDI-DE derzeit nicht vorhanden

GDI-DE-intern: B

Für INSPIRE: A

 

Objekt-referenzierung

Festlegungen, wie indirekte Georeferenzierung von Objekten unterstützt wird

Derzeit keine konkreten Vorgaben. Allerdings besteht ein technisches Konzept für einen Geokodierungsdienst der AdV, der eine indirekte Georeferenzierung von Objekten unterstützt

B

 

Räumliche und zeitliche Modellierung

Festlegungen, wie räumliche und zeitliche Sachverhalte in Objekten beschrieben werden; dies umfasst auch Festlegungen zu den verschiedenen Repräsentierungen als Vektordaten, Coverages (z.B. Rasterdaten) oder Beobachtungen/Messungen.

Im Technikdokument der GDI-DE-Architektur sind derzeit keine detaillierten Regelungen vorhanden, wie räumliche und zeitliche Aspekte zu berücksichtigen sind. Vorgaben sind nur indirekt gemacht, .z.B. über Austauschformate (z.B. GML), die geometrische Repräsentierungen vorschreiben.

Beispiele für zeitliche Aspekte gibt es in INSPIRE mit der Möglichkeit zur  Führung von Lebenszeitintervallen bei Objekten, was auch die Führung historischer Daten ermöglicht.

B

Verwendung fachübergreifender Modellelemente

 

Festlegungen, wie mit übergreifend genutzten Modellelementen umgegangen wird

In GDI-DE derzeit nicht vorhanden

Derzeit B

Mit zunehmenden Fachmodellen: A

Umgang mit Maßstäben

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

In GDI-DE derzeit nicht vorhanden

 

 

A

Modell-erweiterungen

(Leitfäden)

Festlegungen, wie vorhandene Datenspezifikationen (z.B. von INSPIRE) erweitert werden können, ohne die Interoperabilität zu verlieren

In GDI-DE derzeit nicht vorhanden

A

Datenkonsistenz (auch an Ländergrenzen)

Festlegungen zu Anforderungen an die Konsistenz von Daten – auch datensatzübergreifend und länderübergreifend

In GDI-DE derzeit keine Vorgaben oder Empfehlungen, aber von INSPIRE gefordert.

Grenzübergreifende Harmonisierung offen (Aufgabe der Datenanbieter)

Datensatzübergreifende Konsistenz ebenfalls offen

 

A

 

Datenqualität (auch Aktualität)

Festlegungen, welche Anforderungen an die Datenqualität gestellt werden und wie die Qualität der Daten kommuniziert und sichergestellt wird.

Es gibt derzeit keine expliziten Qualitätsvorgaben. Die Datenqualität könnte in den Metadaten angegeben werden, soweit bekannt.

B

Metadaten (auch fachspezifisch)

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

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

B

Konformität

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

In GDI-DE derzeit for Geodaten nicht vorhanden

A

 

Erfassungskriterien

Festlegungen zu den Erfassungsregeln von Geodaten

In GDI-DE derzeit nicht vorhanden. Muss in erster Linie von den Datenanbietern gemacht werden. Regelungen zur Dokumentation müsste von GDI-DE vorgeben werden.

B

 

Modelltrans-formationen (auch die Ableitung von Produkten)

Festlegungen, wie Daten aus der Datenhaltung in die festgelegten Austauschformate (z.B. von INSPIRE) transformiert werden

In GDI-DE derzeit nicht vorhanden

A

 

Präsentation

Festlegungen zur Darstellung von Geodaten in Karten

In GDI-DE derzeit nicht vorhanden

B

Ontologien

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

Derzeit keine Nutzung.

B

 


Anhang 2: Anforderungen an die Codelistenregistry [s87] [MLR88]

 

Aufgrund der Verpflichtung zur Bereitstellung von INSPIRE-konformen 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 Bundesanstalt für Geowissenschaften und Rohstoffe (BGR) und der Denkmalschutzverwaltung aufgelistet. Darüber hinaus werden 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)

Bezugnehmend auf die GDI-DE-Registry war vor allem zu klären, 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 Änderungen wurden in den zuständigen Bund-Länder-Fachgremien abgestimmt und müssen nun in der Registry GDI-DE erfasst werden. [SK(89]

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

 

Die folgende Abbildung zeigt das um weitere Eigenschaften erweiterte INSPIRE-Datenmodell für Schutzgebiete.

 

 

 


Anhang 2: CRS [s90] der Marine Dateninfrastruktur Deutschland [MLR91] (MDI-DE)

 

Fehler! Verweisquelle konnte nicht gefunden werden. -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

Fehler! Verweisquelle konnte nicht gefunden werden.

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

Fehler! Verweisquelle konnte nicht gefunden werden. , 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 ( Fehler! Verweisquelle konnte nicht gefunden werden. 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

Fehler! Verweisquelle konnte nicht gefunden werden. / Fehler! Verweisquelle konnte nicht gefunden werden. 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

Fehler! Verweisquelle konnte nicht gefunden werden. / Fehler! Verweisquelle konnte nicht gefunden werden. 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

Fehler! Verweisquelle konnte nicht gefunden werden. / Fehler! Verweisquelle konnte nicht gefunden werden. 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

Fehler! Verweisquelle konnte nicht gefunden werden. / 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

Fehler! Verweisquelle konnte nicht gefunden werden. / 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

Fehler! Verweisquelle konnte nicht gefunden werden. / 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

Fehler! Verweisquelle konnte nicht gefunden werden. / 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

Fehler! Verweisquelle konnte nicht gefunden werden. 84 / Fehler! Verweisquelle konnte nicht gefunden werden. 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

Fehler! Verweisquelle konnte nicht gefunden werden. , Fehler! Verweisquelle konnte nicht gefunden werden. 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

Fehler! Verweisquelle konnte nicht gefunden werden. , Fehler! Verweisquelle konnte nicht gefunden werden. 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 )


[MLR1] „…für Geodaten IN der GDI-DE“ ist besser!

[SN2] Begriff? Besser: Beschreibung? Erläuterung?

[MLR3] 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“!

[SN4] Besser: Empfehlung? Mögliche schrittweise Harmonisierung? Hört sich sonst so verpflichtend an

[s5] Siehe Kapitel 3.1
Sind keine thematischen Fachnetzwerke vorhanden, so müssen welche etabliert werden.

[AL6] … „sichergestellt bleibt“

[SN7] Formulierung unklar, nicht eindeutig

[MLR8] Bitte klare (!) Aussagen, alternativ: Das vorliegende Dokument ist die Grundlage (~im Sinne einer Checkliste), um diese Interoperabilität herzustellen.

[SN9] Leitbild oder Interoperabilitätskonzept - Verwirrung

[MLR10] Hm. Was heißt das?!

[AL11] Unklar, was mit dieser Aussage gemeint ist. Grundsätzlich muss die Frage des erforderlichen Harmonisierungsbedarfes/ -grades beantwortet werden.

[s12] Das sind eher Interoperabilitätsaspekte als Komponenten

[AL13] Und ratsam oder anzustreben.

[s14] Wenn die beteiligten Akteure (und nur dann)  Vorgaben zu Datenharmonisierungen als sinnvoll erachten, sollten die Vorschläge in diesem Dokument umgesetzt werden.

[AL15] Umformulierung in: … Dokument zeigt (Handlungs-)Empfehlungen auf, wie ….

[SN16] Hier wird es deutlich

[s17] Es wäre besser, das resultierende Dokument als Teil der GDI-DE Architektur zu sehen.

[SK(18] Mein Verständnis war, dass mit dem ersten Anwendungsfall die Erweiterung eines INSPIRE-Themas behandelt werden soll.

[SN19] Ziele des Interoperabilitätskonzepts in Einführung einordnen?

[s20] Die Aspekte der Harmonisierung sind in vielen Arbeiten (z.B. Orchestra Humboldt, GIGAS, INSPIRE, …) beschrieben.
Ich finde es gut, nur die GDI-DE relevanten Aspekte genauer zu bearbeiten. Vielleicht lassen sich noch konkretere Regeln ableiten?

[MLR21] Sollte nicht auch das Element „Konformität“ näher beleuchtet werden? - Wenn man Datenmodellierung vorschreibt, muss man auch das Testing / QS-Prozess beschreiben!

 

Anmerkung: Wenn wir diese „Diskussion“ beginnen, stellt sich auch grundlegende die Frage, welche Elemente in welcher Reihenfolge „abgearbeitet“ werden sollen, um einen harmonisierten Datenbestand zu erhalten. Geht man schematisch oder inhaltlich bei den Interoperabilitätselementen vor?

[MLR22] Bitte Erläuterungen ergänzen zu den einzelnen InteroperabilitätsELEMENTEN , was man jeweils darunter versteht (ggf. in sinngemäßer Übersetzung des INSPIRE-Interoperability-Frameworks)

[SN23] Elemente, Komponenten, Maßnahmen – finden sich diese Begrifflichkeiten im Dok wieder?

Elemente anscheinend nicht?

[AL24] Unklare Formulierung.

[MLR25] 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!

[AL26] Inwiefern ist dieser Hinweis relevant für den Leser? Welche ggf. weiteren Schritte folgen daraus?

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

[s28] Es sollten aber ebenfalls die anderen Interoperabilitätsaspekte ganz kurz beschrieben werden um eine Abgrenzung zu ermöglichen.

Besonders kritisch sind Abgrenzungen bei: Modellierungsgrundsätze, Referenzmodell, Regeln für Anwendungsschemas, räumliche und zeitliche Modellierung, Modelltransformationen.

[SN29] der Datenmodellierung?

[AL30] In dem Kapitel geht es um die organisatorischen Anforderungen für den gesamten Prozess der Harmonisierung von Daten für die Interoperabilität.

[SN31] der Datenmodellierung?

[AL32] siehe dazu Kommentar AL30

[SN33] Wer?

[s34] Vielleicht doch besser auf Deutsch „Datenanbieter“

[AL35] Grundsätzlich ist dies ein semantisches Problem. Außerdem ist die datenhaltende Stelle nicht zwangsläufig die datenbereitstellende Stelle. Ggf. könnte hier die (semantische) Unterscheidung zwischen der Person „Datenanbieter“ und dem Produkt „Datenbereitstellung“ erfolgen.

[SN36] Warum nicht Datenanbieter?

[AL37] Ist an dieser Stelle der Harmonisierungs- oder der Modellierungsprozess gemeint?

[AL38] Programmierung?

[MLR39] Wäre eine Erhebung potenzieller Anwendungsfälle nicht besser, als deren Entwicklung?

[SN40] Welche Bestandsanalyse?

[SN41] Welche Schritte sind gemeint?

[SN42] Die letzteren? Besser Schritte konkret benennen.

[s43] Speziell die Anwendungsfälle und die unscharfen Themen sind bei INSPIRE problematisch. Es sollten daher nur bestehende, konkrete Anwendungsfälle herangezogen werden!

[SK(44] Ich halte den Aufbau einer solchen Liste für sehr schwierig. Wer soll hier die Federführung übernehmen?

[AL45] Das Interoperabilitätskonzept ist eine Empfehlung für den Gesamtprozess, daher muss diese Frage nicht (abschließend) geklärt sein. Es wäre wünschenswert, wenn solch eine Liste existieren würde.

[SK(46] Ggf. „können“

[SN47] Evtl. mit dt. Übersetzung aus DIN CEN/TR 15449-3 ersetzen (s. u.)?

[SN48] Sollte genauso benannt werden, wie in Abb. 1

[SN49] Schemata oder Schemas? Vereinheitlichen

[AL50] Laut Duden ist Beides möglich > Plural: die Schemas und Schemata, auch: Schemen < aber eine Vereinheitlich im Dokument ist anzustreben.

[AL51] Eine konkrete Benennung der relevanten Dokumente wäre an dieser Stelle sinnvoll.

[AL52] Verweis/ Referenz auf das Dokument.

[AL53] Umformulierung in „nichts sagend“ bzw. „… wenn die Features ohne sie keine Aussagekraft hätten“

[AL54] Sind hier ggf. Anwendungsempfehlungen (für die verschiedenen Modellierungsoptionen) gemeint?

[AL55] Verweis/ Referenz auf das Dokument.

[AL56] Ggf. die Referenz zum Dokument angeben.

[s57] Mit allen Aufwänden und Problemen, die sich in den INSPIRE Vorgaben zeigen, erscheint es mir nicht sinnvoll eigene Modellierungsvorgaben für die GDI-DE zu erarbeiten.
Wenn überhaupt müssten starke Vereinfachungen der INSPIRE Vorgaben angestrebt werden (z.T. Einschränkungen in Datentypen, resultierenden Kodierungen, …)

[SN58] Verweis

[AL59] Bedeutet das in diesem Zusammenhang, wer das INSPIRE Schemata anwenden soll?

[SN60] Sollte genauso benannt werden, wie in Abb. 1

[AL61] Einheitliche Bezeichnung Objekt oder Geoobjekt?

[AL62] Ggf. Umformulierung in „besitzen“

[AL63] Ggf. Umformulierung in „nicht den gleichen Objektidentifikator“.

        [s64] Interoperabilitätsaspekt „Erfassungsregeln“

[AL65] An dieser Stelle wird nicht ganz deutlich, was der Unterschied zwischen [extern] und [internen] Identifikator ist. Ist hier [intern] die LocalID gemeint und die Kombination aus Namespace + LocalID ist dann der [externe] Identifikator, wie im darauffolgenden Satz geschrieben? Falls ja, sollte die []-Klammer entfernt werden.

[AL66] Unklare Formulierung.

[AL67] Einheitlichkeit der Begriffe beachtet, entweder (überall) Lebenszyklus oder Life-Cycle verwenden.

[AL68] Ist hiermit das Publish-Bind.Find-Prinzip gemeint?

[s69] Mit der GDI-DE Registry haben wir auch ein entspr. Instrument!
https://registry.gdi-de.org/register/namespace/

[AL70] GGf. wäre es an dieser Stelle sinnvoll, wenn die GDI-DE Registry-Vorgaben ebenfalls als Beispeil mit aufgeführt werden.

[AL71] Doppelung zum ersten Satz in diesem Abschnitt.

[s72] Oder mehrere

[AL73] Einheitliche Bezeichnung im gesamten Dokument: Identifier oder Identifikator.

[s74] Innerhalb eines Registers. Somit sind in einem Registry System verschiedene Control Bodies für verschiedenen Register und Subregister möglich.

[SN75] Einheitlich als gesonderten Abschnitt einführen?

[AL76] Ggf. Umformulierung in „… mögliche Werte sind idealerweise in einer Codeliste …

[AL77] Doppelung zum vorherigen Satz, kann ggf. gestrichen werden.

[s78] Zur Info -> siehe Anforderungsmanagment.: http://redmine.gdi-de.org/projects/gdi-de-registry

Und die Wiki Seite:
http://redmine.gdi-de.org/projects/gdi-de-registry/wiki/Anforderungen_Codelisten-Register

Vor einer Beauftragung werden aber noch einmal die Anforderungssteller kontaktiert.

[AL79] Ggf. Umformulierung in „… wie ein Nutzer mit einer Registry kommuniziert…“

[AL80] Ggf. könnte dies auch als eine Maßnahme formuliert werden.

[s81] Hinweis: Bislang ist in der Architektur der GDI-DE kein Register für Masseinheiten vorgesehen.

Ziel sollte es sein, die originären Quellen von Definitionen zu verwenden und nur im Zweifel eigene Definitionen zu pflegen.

        Abklärung erforderlich über Zuständigkeiten und Lenkungsgremiumszustimmung

[AL82] Ggf. Umformulierung in „… jeweils zuständigen Fachnetzwerke …“

[SN83] Sollte genauso benannt werden, wie in Abb. 1

[AL84] Ggf. Umformulierung in „… das (Handlungs-)Empfehlungen vorschlägt, wie …“

[MLR85] Macht das hier im Interoperabilitätskonzept wirklich Sinn? – Die nachfolgenden Anforderungen sind doch eher als CR einzubringen, ggf. ist hierfür ein Template vorzugeben …?!

[AL86] Grundlegend muss geklärt werden, ob nicht alle Interoperabilitselemente im Konzept aufgegriffen werden und die gekennzeichnet werden, welche  vorerst (aber zukünftig) nicht näher beschrieben werden.

[s87] Falsche Stelle.

Anforderungen siehe Anforderungsmanagement GDI-DE ( http://redmine.gdi-de.org/projects/gdi-de-registry ) ! Führt nur zu doppelter Pflege, Aufwände und Diskrepanzen.

[MLR88] Macht das hier im Interoperabilitätskonzept wirklich Sinn? – Die nachfolgenden Anforderungen sind doch eher als CR einzubringen, ggf. ist hierfür ein Template vorzugeben …?!

[SK(89] Anmerkung: Kurzbeschreibung ist identisch mit der Beschreibung zum Denkmalschutz

[s90] Warum wird das hier aufgeführt?

[MLR91] Macht das Sinn im vorliegenden Interoperabilitätskonzept der GDI-DE??? Sollte nicht vielmehr auf das künftige CRS-Register verwiesen werden, dass nur die dort registrierten CRS (ggf. Vorauswahl!) in GDI-DE verwendet werden dürfen / sollen.