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 Interoperabilitätskonzept für Geodaten in der GDI-DE [MLR1]

GDI-DE Interoperabilitätskonzept

 

 

ENTWURF

 

 

Arbeitsgruppe Geodaten

01.04.2016 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

 

29.03.2016

Kommentierung, Ergänzungs-/Änderungsvorschläge

Nicole Saravanja

 

 

 

 

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

3.2.3 Bewertung und Handlungsbedarf

3.3 Identifikatormanagement

3.3.1 Beschreibung

3.3.2 Aktueller Stand in INSPIRE und der 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 der GDI-DE

3.5.3 Bewertung und Handlungsbedarf

4 Ausblick

Referenzen

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

Anhang 2: Anforderungen an die Codelistenregistry

Anhang 2: CRS der Marine Dateninfrastruktur Deutschland (MDI-DE)

Dokumenteninformation ................................................................................................. 2

Änderungsverzeichnis ..................................................................................................... 2

1 Ziele des Interoperabilitätskonzepts ..................................................................... 4

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

3 Interoperabilitätskomponenten .............................................................................. 7

3.1 Organisatorische Handlungsempfehlungen für Datenmodellierung ......... 7

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

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

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

3.2 Regeln für die Erstellung von Anwendungsschemata ................................ 11 10

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

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

3.2.3 Bewertung und Handlungsbedarf .......................................................... 13 11

3.3 Identifikatoren Management ......................................................................... 14 13

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

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

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

3.4 Registry ............................................................................................................. 18 16

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

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

3.5 Bereitstellung von Schemadateien ............................................................... 22 20

3.5.1 Beschreibung ............................................................................................. 22 20

3.5.2 Aktueller Stand in INSPIRE und GDI-DE .............................................. 22 20

3.5.3 Bewertung und Handlungsbedarf .......................................................... 22 20

Referenzen ...................................................................................................................... 23 21

Anhang 1: Anforderungen an die Codelistenregistry ............................................... 24 22

Anhang 2: CRS der Marine Dateninfrastruktur Deutschland ................................. 28 26


1         Ziele des Interoperabilitätskonzepts

Die zentrale Aufgabe der GDI-DE ist es, Geodaten verschiedener Herkunft interoperabel verfügbar zu machen. Unter dem Begriff "Interoperabilität" wird nach § 3 Abs. 4 GeoZG [SK(2]   die Kombinierbarkeit von Daten bzw. die Kombinierbarkeit und Interaktionsfähigkeit verschiedener Systeme unter Einhaltung gemeinsamer Standards verstanden. D ieses   Das vorliegende   Dokument verfolgt zwei Ziele:

  1. Die Spezifizierung [SN3] von Komponenten , Ident i fikation en von Elementen , deren einheitliche Festlegung die für eine interoperable Bereitstellung von Geodaten in der GDI-DE erforderlich sind . (Interoperabilitätselemente) . [MLR4]

Die Festlegung Erarbeitung   [SN5] einer Methodik , die für eine schrittweise Harmonisierung vorhandener Datenbestände und Datenmodelle innerhalb der GDI-DE erforderlich sind .

  1.  

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

GDI- Kontakt- und Koordinierungsstellen des Bundes und 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 k omm u nale Geodatenanbieter ebenfalls die interoperable Bereitstellung und Nutzung von Geodaten in der GDI-DE anstreben.

? [MLR6]

Die Harmonisierung der Datenmodell e harmonisierung mit dem Ziel bundesweit einheitlicher Datenbestände zur Unterstützung nationaler und internationaler Fragestellungen soll jedoch nur bei konkreten Anwendungsfällen angegangen werden, indem zunächst die betroffenen Fachnetzwerke identifiziert (gemäß Meldeliste INSPIRE), [s7] 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. z. B. innerhalb von Fachnetzwerken, Arbeitskreisen) übernommen werden . ,

Auf nicht jedoch solche auf regionaler oder lokaler Ebene sind Ergänzungen oder andere Ansätze möglich , solange die Kompatibilität sichergestellt ist . [SN8]

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 . [MLR9] 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 heraus sollte die Entwicklung eines „Leitbilds“ für das vor der Anwendung des Interoperabilitätskonzept es [SN10] [MLR11] hervorgehen der erforderliche Harmonisierungsbedarf festgelegt werden , das 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 der Erkenntnisse dieses Leitbilds dieser Anforderungen sollten entsprechende benötigte zentrale Komponenten [s12] Aspekte identifiziert werden, und festgelegt werden , sowie in wessen Verantwortungsbereich die Bereitstellung und Laufendhaltung dieser Komponenten liegt Definition und Umsetzung dieser Aspekte fällt . . Ein Einbeziehen und Koordinieren in den INSPIRE-Fachnetzwerken wäre dazu sinnvoll.

Keinesfalls sollen mit dem Interoperabilitätskonzept verpflichtend umzusetzende Datenspezifikationen analog zu INSPIRE vorbereitet, erstellt und beschlossen werden. Dieses Dokument macht lediglich Vorschläge [s13] , 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. [SN14]

Dieses Dokument enthält Vorschläge für Interoperabilitäts komponenten [s15] ,   die einzeln oder in Gruppen in soll als eigenständiges Modul das Architekturkonzept der GDI-DE [s16] übernommen werden können ergänzen und entsprechend bedarfsweise fortgeschrieben werden .

Um die Zur Anwendbarkeit Priorisierung der dieses in diesem   Konzept s vorrangig beschriebenen Interoperabilitätselemente wurden zu demonstrieren , wird vorgeschlagen, zwei Anwendungsfälle exemplarisch durchgespielt durch zuspielen :

  • Für eine Fachdomäne existiert bereits ein formalisiert beschriebenes Datenmodell [SK(17] und dieses soll durch vorhandene oder noch zu entwickelnde Interoperabilitätskomponenten Interoperabilitäts elemente n der GDI-DE ( z.B. z. B. Registry) angepasst oder ergänzt werden. Hierfür wurde das AAA-An w endungsschema der AdV   herangezogen.
  • Für eine Fachdomäne existiert noch kein formalisiert beschriebenes Datenmodell und es soll ein neues Datenmodell erstellt , z.B. bzw. 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 [SN18]

Die INSPIRE-Richtlinie macht beinhaltet   bereits detaillierte Vorgaben zur Interoperabilität interoperablen Bereitstellung   von Geodaten. Um diese INSPIRE-relevanten 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]   ( JRC Reference Report 2012 ) veröffentlicht. 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 Empfehlungen fest.

Diese Aspekte gelten im Wesentlichen auch für andere Rahmenbedingungen und werden mit in   diesem Dokument auf die interoperable Bereitstellung von Geodaten in der GDI-DE übertragen. Die in diesem im vorliegenden 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   (orange)   wurden sind von der AG Geodaten priorisiert und für die oben beschriebenen Anwendungsfälle als unbedingt notwendig betrachtet worden . Weiterhin sind Ein Bezug zu den Kapiteln in diesem Dokument ist ebenfalls enthalten, in denen die einzelnen priorisierten Elemente in den nachfolgenden Kapiteln detailliert beschr e i e ben beschreiben werden . Durch weitere mögliche Anwendungsfälle können auch weitere oder andere Interoperabilitätselemente hoch priorisiert werden.

Die umfassende   Beschreibung der übrigen Interoperabilitätselemente soll schrittweise erfolgen. Zunächst wurden sie im Anhang 1 nur überblicksartig beschrieben und für die weitere Spezifizierung kategorisiert.

 

Abbildung 1 : Übersicht über die Interoperabilitäts komponente elemente n der GDI-DE [s19] [MLR20]

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

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

Grundsätzlich sollte die GDI-DE für die Bereitstellung von nicht-INSPIRE-Daten gemäß bereits gebräuchlicher Datenspezifikationen offen sein, sowohl was in Bezug auf   die Semantik als auch was auf   die Datenformate ang eht . Die vorgeschlagenen Interoperabilitätselemente legen somit nur einen grundlegenden Rahmen fest, der für eine interoperable Modellierung und Bereitstellung von Geodaten aller Fachdisziplinen in nerhalb 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. z. B. weil die Komponente ergänzt wurde) , werden deutsche Begriffe verwendet. [SN23] [SK(24]

Für die GDI-DE wird im Folgenden festgelegt [SN25] definiert , welche Festlegungen für Geodaten gelten soll t en sollen . Es ist davon auszugehen Es wurde grundsätzlich darauf geachtet , dass die Vorgaben in Bezug auf die Bereitstellung von interoperablen Datensätzen in der Regel deutlich weniger detailliert als in INSPIRE sind ausfallen   (wo durch die Vorgaben der Richtlinie bereits recht strikte Vorgaben bestehen, die für nicht-INSPIRE-Daten in der GDI-DE derzeit so vermutlich nicht sinnvoll sind). Detailliertere Vorgaben Präzise Anforderungen werden nur dort bei solchen Interoperabilitätselementen   formuliert gemacht , An anderer Stelle werden hingegen wesentlich detaillierter Vorgaben gemacht, nämlich an Stellen, bei denen wo bei denen die GDI-DE schon konkrete Lösungen ( z.B. z. B. zentrale Betriebskomponenten) hat oder verfolgt, die auf die speziellen Rahmenbedingungen in der GDI-DE zugeschnitten sind . [MLR26]

Grundsätzlich beziehen sich die I nteroperabilitätselemente auf D atenmodelle , 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.

3         Interoperabilitäts komponente elemente n [MLR27]

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

O rgani satorische   Anforderungen

3.1     O rgani satorische O rgani satorische s Vorgehen bei der Handlungsempfehlungen für Datenmodellierung [SN29]

3.1.1     Beschreibung

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

Dies bezieht sich ins besonder e s 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 muss geklärt werden ,

wer die Datenmodelle für die Datenbereitstellung nutzt und

wer die Nutzer der bereitgestellten Daten bzw. Dienste sind,

wer den Prozess [SN30] wie moderiert (z.B. die Kst.GDI -DE, die AG Geodaten , der AK Architektur) 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 ü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 wird das Vorgehen durch die jeweiligen Organisationsmodelle beschrieben. Einen guten Überblick über den Prozess [SN31] und seine die   Anforderungen wird im JRC Reference Report 2012 zum Conceptual Model gegeben. Weitere Zusätzliche   Details können aus den definierten Methoden des INSPIRE Drafting Teams Data Specification [INSPIRE D2.6 2008] ( deliverable D2.6 : ) entnommen werden. In letzterem Dokument werden insbesondere 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) und sowie   eine Interoperabilitätscheckliste für Datenmodelle beschrieben .

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

3.1.3     Bewertung, Handlungsbedarf und Empfehlungen

Liegt Sofern   bei allen Akteuren das eingangs erwähnte ein gemeinsame s Verständnis der „Interoperabilität“ für Datenmodelle vor liegt und ist der hat de n [SN32]   erforderliche n Grad der Harmonisierung zwischen einerseits einer möglichst vollständig harmonisierten Datenmodellierung und andererseits einer möglichst geringen Formalisierung festgelegt wurde , lassen sich folgende n Empfehlungen ableiten. Eine Unterscheidung erfolgt in

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 Datenmodellh H armonsierungsprozess von D atenmodellen

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

Daten bereitst e ller provider sind für die modellkonforme Daten bereitstellung erhebung und die Abbildung fachlich-inhaltlicher Informationen zuständig.

Beispiel: Die Umweltfachämter der Kommunen, die verantwortlich für die Daten bereitstellung erhebung zu von   Landschaftsschutzgebieten verantwortlich sind.

  • Datennutzer

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

Beispiel 1:   Datennutzer sind zum Beispiel von fachfremde n Behörden oder Behörden anderer Kommunen und Länder n ,

Beispiel 2 :   Nutzer auf der Bundes- und Europaebene und oder  

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

  • Koordinatoren/Moderatoren  

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

Beispiel: GDI-Koordinierungsstellen des Bundes und der Bundesländer   [SK(35] oder auch die Fachnetzwerke einer Domäne . 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. z. B. aus INSPIRE) und sind dafür verantwortlich, dass qualitativ hochwertige Datenmodelle erzeugt werden.

Beispiel: Datenmodellierungsexperten M odellierungsexperten aus der Geoinformatikwissenschaft.

  • Technische Datenmodellierungsexperten

Die technischen Datenmodellierungsexperten begleiten die Entwicklung der harmonisierten Datenmodelle mit der Entwicklung von entsprechenden Softwarewerkzeugen zur Modellierung und Schematransformation, z.   B. 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 [SN36] . Die INSPIRE-Fachnetzwerke sollen in die Vorbereitung mit einbezogen werden.

  1. Identifizierung eines Anwendungsfalls [MLR37]

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

  1. Liste der verantwortlichen Datenprovider und Nutzer Datenn utzer
     

  2. Um sicherzustellen dass alle relevanten Akteure am beim in den Modellierungsprozess involviert mit einbezogen   sind , sollte n eine Liste der die verantwortlichen Datenprovider und Datennutzer der Fachdomäne unter Berücksichtigung der föderalen Strukturen erstellt involviert   werden. Bei der Erstellung der Liste sollten   vorhandene Strukturen, wie z.B. 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.
  3. Liste möglicher Koordinatoren/Moderatoren fachlicher Ansprechpartner für die Harmonisierung der Datenmodelle [SK(42]

Es sollte eine Liste   möglicher ein Netzwerk Koordinatoren und Moderatoren fachlicher An s prechpartner für die Harmonisierung der Datenmodelle erstellt werden, aus der einerseits für die weitergehenden Ist- als auch Lückenanalysen Defizitan alysen fachlich kompetente Experten ausgesucht werden k önnen ann , 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
     
  2. Anhand von ausgewählten Beispieldatensätzen soll te evaluiert werden, zu welchen Aspekten es aufgrund der Unterschiedlichkeit der zurzeit verwendeten Datensätze Harmonisierungsbedarf gibt existiert   und ob es bereits eine einheitliche Datenspezifikationen bzw. Anforderungen im Sinne von bundesweiten Vorgaben bzw. Vereinbarungen gibt vorliegt   ( z.B. z. B. die Verwaltungsvereinbarung zum Austausch von Umweltdaten oder abgestimmte Datenmodelle für das Reporting und elektronische Berichterstattung). Hierzu sollen [SK(43] Datensätze von vergleichbaren Landesbehörden unterschiedlicher Bundesländer, als auch Bezirksregierungen und Kommunen untersucht werden, um später eine harmonisierte Datenbereitstellung für eine Erhöhung der wechselseitigen Nachnutzbarkeit zu gewährleisten. Hierbei soll te auch 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 inhaltliche r inhaltliche und technische r technische 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 ab zu leiten zu können .

  1. Entwicklung eines Anwendungsfalls [MLR44]

Anhand   von   den de r   Ergebnissen aus den Schritte n 1 bis 3   der vorstehenden Empfehlungen soll en ein oder mehrere Anwendungsfälle entwickelt werden, die auf der Bestands analyse [SN45] basieren . Die zu entwickelnden Anwendungsfälle sollen auch die   und bis zur eigentlichen Implementierung inklusive des entsprechenden Testens und Validierung Validier ens   reichen umfassen ,   reichen,   und Schritte für das weitere Fortschreiben des Datenmodells geben sollen vorgeben . Für die letzteren Schritte [SN46] sollen die Koordinatoren/Moderatoren verantwortlich sein. Die Schritte [SN47] sollen sich am bestehenden Prozess für die Erstellung der INSPIRE-Datenspezifikation en orientieren und Analysen bezüglich allgemeiner Nutzera nforderungen enthalten. [s48]

Empfehlungen für den Datenspezifikationsprozess

Es wird empfohlen sich bei der Spezifikation des Harmonisierten   h armonisierten   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) . [SN49] Anhand der Best Practice -Vorgaben (Kapitel 3.2.3 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. 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 ( D IN CEN/TR 15449-3 2014)

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

Für den Prozess ist ein i I n Abstimmung mit allen Akteuren ist ein realistischer Zeitplan   für den Prozess aufzustellen , welcher sowie d d ie Umsetzung zu begleite n t und zu überwach t en .

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

Regeln für die Erstellung von Anwendungsschemata Regeln für das Anwendungsschema [SN50]

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

 

3.1.4     Beschreibung

Diese Interoperabilitätskomponente ist nur dann anzuwenden, wenn ein Datenmodel l unter Verwendung der gleichen Modellierungsgrundsätze und Methodik wie 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.

Anwendungsschema ta s 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 Encodingschema ta   (z. B. in XSD) zu ermöglichen. Eigenschafts- bzw. Feature-Kataloge sind eine äquivalente Präsentation der Informationen aus den Anwendungsschemata [SN51] . 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 vom   Geodaten zur Repräsentation von Realweltobjekten gebildet und beschrieben (Inhalt und Struktur, Modellkonstrukte) werden bzw. wie existierende Anwendungsschemas erweitert werden ( z.B. z. B. INSPIRE Schemata).

3.1.5     Aktueller Stand in INSPIRE und der GDI-DE

In INSPIRE erfolgt die Modellierung der Anwendungsschemata in UML nach ISO 19109 unter Verwendung mit einem eine   INSPIRE-UML-Profil s . Die Objektartenkataloge sind aus dem UML-Modell abgeleitet. In den referenzierten Dokumenten (s. Referenzen) findet sich eine Reihe von weiteren detaillierteren Vorgaben von denen hier nur einige beispielhaft aufgeführt werden:

INSPIRE Generic Conceptual Model ( INSPIRE GCM 2014 document D2. 5 )

  • Definition des Spezifiziert den allgemeinen Rahmen s zur E ntwicklung von , in dem die harmonisierten Datenspezifikationen entwickelt werden :
    • Relationen zu den ISO 19xxx Standards
    • Raum-zeitliche Repräsentationen räumlicher Objekte über verschiedene Auflösungsstufen
    • Raum-zeitliche Beziehungen zwischen räumlichen Objekten
    • Identifikatoren ,
    • Mehrsprachigkeit
    • Verwendung von gemeinsamen Vokabularen

Drafting Team "Data Specifications" – deliverable D2.6, insb. Kapitel 6:

  • Festlegung von optionalen und verpflichtenden Attributen:
  • V v erpflichtende Attribute sind als solche festzulegen, wenn die Features ohne sie sonst bedeutungslos sind.
  • Bei verschiedenen Modellierungs O o ptionen sind jeweils Nutzungsempfehlungen zu geben.
  • Vermeidung von Enumerationen (nicht erweiterbare Aufzählungen) mit vordefinierten quantitativen Intervallen .
  • Benutzung Empfehlung zur Nutzung   von hierarchischen Klassifikationen , sofern wird empfohlen - wenn geeignet, die Unterklassen sollten immer nur durch ein Unterscheidungsmerkmal festgelegt sein sind , nicht durch mehrere .

JRC Reference Report 2012:

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

 

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

3.1.6     Bewertung und Handlungsbedarf

 

Entwicklung eines GDI-DE-Referenzmodells

Für die beiden definierten Anwendungsfälle des Interoperabilitäts konzepts (s. in Kap. 1) werden dringend Vorgaben für die Modellierung werden für beide in Kap. 1 definierten Anwendungsfälle des Interoperabilitäts konzepts rahmens dringend benötigt. Optimal wäre hier 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. [s52] Mit einem derartigen Referenzmodell wäre 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 eigentlich grundsätzlich   eine die   Aufgabe für Modellierungsexperten mit entsprechendem INSPIRE-Hintergrundwissen. In der Praxis verfügen die Modellierer jedoch nicht immer über dieses Wissen . und e E in e ein e Vorgehensleitlinie Leitlinie zum Vorgehen   für die Erstellung von Modellerstellung Modellen wäre hier demnach an dieser Stelle   hilfreich , . Ziel könnte b eispielsweise ein   z. B. in Form eines   frei zugängliches zugängliche n   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 anderem beispielweise   folgende Fragen geklärt werden:

  • Allgemeine Fragen zur Modellierung
    • Welche Vorteile hat ein auf internationalen Standards basierendes Datenmodell?
    • Welche Alternativen gibt es und welche haben diese Vorteile/Nachteil e haben dies e dies ?
    • Welche Software wird genutzt bzw. eingesetzt benutzt man dafür (UML Modellierung, Ableitung des XML Schemas, etc.)?
    • Welche Modellkonstrukte sind zu vermeiden ( z.B. z. B. Assoziation Classes)?
    • Wie sind die könnte eine Dokumentation der Modelle überhaupt zu dokumentieren aussehen ?
    • Wie muss [SK(53]   kann   die GDI-DE Registry bei der Modellierung eingebunden werden ( z.B. z. B. Registrierung der Codelisten)?
    • Wie sind Integritätsregeln zu definieren ( z.B. z. B. OCL)?
    • Vorgaben zur Modellierung der Maßstabsabhängigkeit :
    • welche Maßstäbe sind überhaupt relevant? Interlinked multiple representations ( siehe Punkt multiple Representation [SN54] )
  • Notwendiges Hintergrundwissen zu INSPIRE
    • Entscheidungshilfe /-fragen : Wer ist verpflichtet auf den INSPIRE Schemata aufsetzen? Wer ist nicht verpflichtet, sollte sich aber trotzdem daran orientieren? Für wen sind die INSPIRE Vorgaben bzw. die Vorgaben aus dem GDI-DE Interoperabilitätskonzept nicht relevant?
    • Welche INSPIRE Packages sind relevant? Wie sind diese einzubinden / zu erweitern?
    • Welche der von INSPIRE vorgegebenen INSPIRE-   Klassen sind wann und wie zu übernehmen?
    • Besonderheiten der INSPIRE Modellierung:
      • N ULL illable 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.2     Identifikatoren Identifikator m en Identifikatoren M anagement [SN55]

3.2.1     Beschreibung

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

Ziele:

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

3.2.2     Aktueller Stand in INSPIRE und der GDI-DE

INSPIRE- Vorschriften Vo rgaben

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

-           Nationale Regelungen greifen beruhen   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 In der INSPIRE Richtlinie sind identifizierbare Objekte 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. z. B. einen bestimmten Baum oder ein en ein bestimmter bestimmte n   See), sondern auf dessen Abstraktion (= ein Geoobjekt). Unterschiedliche Abstraktionen des gleichen realweltlichen Phänomens bekommen damit erhalten somit unterschiedliche Identifikatoren.

Die Art der Abstraktion wird üblicherweise in einer Vorschrift zur Objektbildung [s56] bzw. über eine Erfassungsvorschrift bei der Objektaufnahme im Freiland 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 Instrument zur normativen Objektbildung. Grundsätzlich bestimmen auch Ebenso legen Qualitätsvorgaben bei der Erfassung (Straßen als Linien oder Flächen, Lagegenauigkeit etc.) über grundsätzlich   die Art der Abstraktion fest . Unterschiedliche Abstraktionsniveaus können jedoch leicht in der Erfassung, Vorverarbeitung und Weitergabe der Daten ( z.B. z. B. durch zwischengeschaltete Generalisierungsstufen) entstehen. Solche Einflüsse werden im INSPIRE Generic Conceptual Model ( IGCM INSPIRE GCM 2014 ) jedoch nicht im Detail diskutiert.

Anforderungen an Objektidentifikatoren

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

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

3.2.3     Bewertung und Handlungsbedarf

3.2.3.1 Eindeutigkeit

Die Eindeutigkeit von Identifikatoren wird im IGCM wie folgt spezifiziert definiert :

(1)   Ein Identifikator bezeichnet genau ein Geoobjekt.

(2)   Die Eindeutigkeit dieses Identifikators muss innerhalb des Geltungsbereiches muss garantiert sein ( z.B. 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) haben 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. z. B. nachträgliche Korrekturen oder Änderungen an Attributfeldern transparent er zu kennzeichnen. Obwohl Versionen nicht Bestandteil des [externen] Identifikators eines Geoobjekts sind, wird im I NSPIRE GCM 2014 ein versionierter Datentyp für Identifikatoren vorgeschlagen (siehe Tabelle 1 Tab. Tab. XX ). Die Eigenschaften Ein Namespace und eine LocalId bilden den [externen] Identifikator, das Versionsfeld kann eine fortlaufende Nummer sein oder einen Zeitstempel enthalten. Zudem kann D d ieser Identifikator-Datentyp kann damit auch für die interne Datenhaltung genutzt werden.

Tabelle 1 : Auszug aus dem Generic   Conceptual Model von INSPIRE

Class:<<datatype>> Base Types.Identifier ( INSPIRE I 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:

Version ID

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

 

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 blei b en, damit diese nicht irrtümlich erneut vergeben werden.

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

3.2.3.2 Persistenz

Die Persistenz von Identifikatoren wird im INSPIRE GCM 2014 wie folgt beschrieben Unter dem Begriff Persistenz werden im Generic Conceptual Model von INSPIRE Aussagen zum Lebenszyklus von Geoobjekten und deren Identifikatoren getroffen :

(1)   Für den gesamten Lebenszyklus eines Geoobjektes bliebt D d er Identifikator eines Geoobjektes bleibt für dessen gesamten Lebenszyklus unverändert.

(2)   Die Regeln zum Lebenszyklus von Geoobjekten variieren zwischen verschiedenen Datenprovidern. Daher werden in den Die I NSPIRE-Datenspezifikationen machen daher keine definitiven Vorschriften zum Lifecycle 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 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 I NSPIRE 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 Versionierun g für Identifikatoren .

 

 

Konkrete Handlungsvorschriften : [MLR57]

-           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 Versionierun gsvorschrift für Identifikatoren.

3.2.3.3 Rückverfolgbarkeit

INSPIRE fordert einen Mechanismus zur Auffindung zu r m Auffind barkeit en 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 das Geoobjekt finden.

Maßnahmen:

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 en Mechanismus ( 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 Provider 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.

 

 

Konkrete Handlungsvorschriften:

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

-           Zusätzlich muss der Provider ein Mechanismus (z.B. 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. z. B. Bund, Land) ein solcher Dienst bereitgestellt werden, der stellvertretend für mehrere Provider Geoobjekte auffindbar macht.

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

3.2.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 [s58] . 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 der gesamte n r Behörde)

(bei nicht einheitlichen lokalen IDs innerhalb der gesamte n r Behörde)

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

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

Maßnahmen:   Zu diesen Fragen der Vergabe von Objekt i dentifikatoren   sind Entscheidungen zu treffen, zu erproben und ggf. weiterzuentwickeln. Die Vorarbeiten zum syntaktischen Aufbau von Namensräumen und Registries sind im Wesentlichen nur noch umzusetzen.

3.3     Registry

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

3.3.1     Beschreibung

Registries nehmen in Geodateninfrastrukturen eine zentrale Rolle ein, da sie das Verwalten, Auffinden und Nutzen von vorhandenen Geoinformationsressourcen den in innerhalb 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 [s59] geführt wird. Ein Register wiederum ist eine Zuordnung von sog. Identifikatoren zu Ressourcen und deren Beschreibungen. Eine Ressource ist in diesem Sinn e ein Sachverhalt, der in Abgrenzung zu anderen Sachverhalten eindeutig beschrieben werden kann. Ein Identifier ermöglicht es, Ressourcen der Registry eindeutig zu referenzieren.

Abbildung 3 : Organisationsmodell einer Registry nach ISO 19135

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 . z. B. (vgl. Abbildung 3 ) : . :

 

Maßnahmen:   Festlegung der Rollen gemäß ISO 10135 und der entsprechende n 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 unterschiedlichsten Ressourcen enthalten. Der Begriff einer Codelisten-Registry wird verwendet, wenn Sind die Ressourcen die Codelisten eines Datenmodells sind , . wird der Begriff einer Codelistenr egistry verwendet.

3.3.2     Aktueller Stand in GDI-DE und Handlungsbedarf [SN61]

3.3.2.1 Codelisten -   Regist e r y registry Codelistenregistry

Häufig verwendete oder nach einem vorgegebenen Konzept zu beschreibende Eigenschaften von Geoobjekten werden in Datenmodellen häufig durch Codes abgebildet. Die Menge der möglichen Werte ist in der Regel in einer Codeliste aufgeführt. Die Codeliste wird meist gemeinsam mit dem Datenmodell veröffentlicht. Datenerfassern muss diese Codeliste, die Bedeutung der einzelnen Codes 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 verhindern 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.

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

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

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

Maßnahmen: Anforderungsanalyse verschiedener Datenanbieter an die Codelisten -R r egistry [s62] und anschließende Weiterentwicklung der Codeliste n-R nr egistry. Es sind ferner Ferner sind die Prozesse zu definieren, wie ein Nutzersystem mit einer Registry kommuniziert ( z.B. z. B. wie Registryinhalte recherchiert und ausgewertet werden können).

3.3.2.2 CRS -   Regist e r y -Registry

Geodaten können in verschiedenen Koordinatenreferenzsystemen (CRS) erfasst und gespeichert werden. Für eine gemeinsame Verwendung, z.B. 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 erforderlichen Parameter 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. Derzeit 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 die Entwicklung und den 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 den gleichen Transformationsresultaten 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 besipielhaft   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 sind

3.3.2.3 Registry für Maßeinheiten [s63]

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 ( 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. 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.4     Verwaltung und Bereitstellung von Schemadateien [SN64]

3.4.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 in der Lage, die se XSD-Datei direkt online zu verwenden oder zur lokalen Speicherung herunterzuladen.

3.4.2     Aktueller Stand in INSPIRE und der GDI-DE

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

3.4.3     Bewertung und Handlungsbedarf

Das Schema -R r epository 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 nachhaltig langfristig zur Verfügung steht.

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

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

 


Weitere Schritte / weiteres Ausblick Vorgehen

Mit dem vorgelegten   Konzept   werden schrittweise Interoperabilitätsanforderungen an Geodaten der GDI-DE definiert , deren Umsetzung in einzelnen Fachdisziplinen oftmals auf Freiwilligkeit basiert und nur angega n gen werden soll, wenn es konkrete Anforderungen und ein gemeinsames Verständnis   der erforderlichen Interoperabilität gibt .

Aus diesen Überlegungen heraus wurde die Entwicklung des Interoperabilitätskonzept s   begonnen , das einen Lösungsweg vorschlägt, wie Geodaten unterschiedlicher Themen und innerhalb der GDI-DE harmonisiert werden könnten . Zur Um setzung dieser Empfehlungen wurden die benötigte n zentrale n Aspekte identifiziert und festge legt, in wessen Verantwortungsbereich die Definition und Umse t zung 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.)

Ausarbeitung der weiteren vorrangig zu behandelnden Interoperabilitätselemente (siehe Anhang 1)

Schrittweise Beschluss und Umsetzung der vorgeschlagenen Maßnahmen mit Festlegung der Akteure, die diese Umsetzung koordinieren sollen (z. B. Kst GDI-DE, AK Architektur etc.)

Geodaten   sind die zentrale Ressource 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.


Handlunsgempfehlung?

Referenzen

 

  • DIN CEN/TR 15449 (2014): Geoinformation – Geodateninfrastrukturen – Teil 3: Datenzentrierte Sicht. Beuth, Berlin , S. 27
  • JRC Reference Report 2012: A Conceptual Model for Developing Interoperability Specifications in Spatial Data Infrastructures, Editoren: Tóth, K., Portele, C. u.a. http://inspire.jrc.ec.europa.eu/documents/Data_Specifications/IES_Spatial_Data_Infrastructures_(online).pdf
  • INSPIRE D2.5: Generic Conceptual Model, Version 3.4, http://inspire.ec.europa.eu/documents/Data_Specifications/D2.5_v3.4.pdf
  • INSPIRE. (2008). Drafting Team „Data Specifications“ - deliverable D2.6: Methodology for the development of data specifications (Text No. D2.6_v3.0.pdf). INSPIRE Drafting Team „Data Specifications“. http://inspire.ec.europa.eu/reports/ImplementingRules/DataSpecifications/D2.6_v3.0.pdf
  • INSPIRE Guidelines for the encoding of spatial data, Version 3.3rc2, http://inspire.jrc.ec.europa.eu/documents/Data_Specifications/D2.7_v3.3rc2.pdf  
  • Dokumentation zur Modellierung der Geoinformationen des amtlichen Vermessungswesens (GeoInfoDok), Version 6.0.1, http://www.adv-online.de/icc/extdeu/broker.jsp?uMen=4b370024-769d-8801-e1f3-351ec0023010
  • Portele,C. (2012) Präsentation: Spatial Data Interoperability in INSPIRE, https://www.paikkatietoikkuna.fi/documents/108478/45ee0d1c-7285-4ae5-9170-7f8ea75411ab
  • Kröger, R., Klisch, M., Patzsch, S., Gros, D., Ulbricht, T., Weiß, U., … Zerbe, U. (2012). Geodaten in Kommunen - Leitfaden zur Betroffenheit und Pflichten der Kommunen im Rahmen der europäischen Geodateninfrastruktur. Schriftenreihe des Städte- und Gemeindetages Mecklenburg-Vorpommern e.V., Band 35. Abgerufen von http://www.ego-mv.de/fileadmin/Daten_Infos/Dokumente/GEODATEN_PDF_VERSION.pdf


Anhang 1: Weitere Anforderungen an die Codelistenregistry [s65] Interoperabilitätselemente [MLR66] (noch genauer zu spezifizieren)

 

Element

Kurzbeschreibung

Abschätzung der derzeitigen Situation in der GDI-DE

Kategorisierung der AG Geodaten

A=vorrangig zu entwickeln

B= nachrangig zu entwickeln

Modellierungsgrund - sätze

Zusammenstellung der grundlegenden Modellierungsp rinzipien 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änz t werden.

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

A

Terminolog ie

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 Geokodier ungs dienst 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 detaillierte n 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 Leb enszeitintervallen 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 vo r handene 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 k eine 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

Metadat en (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 k eine Nutzung.

B

 


Anhang 2: Anforderungen an die Codelistenregistry [s67] [MLR68]

 

 

Aufgrund der Verpflichtung zur Bereitstellung von INSPIRE-konforme n r 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 auch Aussagen zu den Akteuren getroffen, die für den späteren Betrieb erforderlich sind. Zur strukturierten Erfassung der Anforderungen wird ein Template vorgeschlagen.

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

Bezogen auf die Bezugnehmend auf die GDI-DE-Registry ging es dabei war vor allem um die Frage 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 registriert erfasst   werden. [SK(69]

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 [s70] der Marine Dateninfrastruktur Deutschland [MLR71] (MDI-DE)

 

Fehler! Verweisquelle konnte nicht gefunden werden. EPSG -Code

Koordinatenreferenzsystem

Bezeichnung im                         MDI-DE Portal

INSPIRE

GDI-DE

MDI-DE

2397

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

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

 

 

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

Zone

2398

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

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

 

 

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

Zone

2399

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

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

 

 

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

Zone

4230

Fehler! Verweisquelle konnte nicht gefunden werden. DMZ   ED50

ED50

 

 

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

Zone

4258

Fehler! Verweisquelle konnte nicht gefunden werden. ETRS89 , geographische Koordinaten

ETRS89 in geografischen Koordinaten

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

bindend

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

bindend

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

Zone

4326

World Geodetic System 1984 ( Fehler! Verweisquelle konnte nicht gefunden werden. WGS 84)

WGS84 in geografischen Koordinaten

 

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

bindend

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

bindend

4647

Fehler! Verweisquelle konnte nicht gefunden werden. ETRS89 / Fehler! Verweisquelle konnte nicht gefunden werden. UTM Zone 32N (zE-N)

ETRS89 / UTM Zone 32E

 

 

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

Zone

5650

ETRS89 / UTM Zone 33N (zE-N)

Geplant für Portal 2.0

 

 

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

Zone

7408

RD/NAP

RD/NAP

 

 

 

25832

Fehler! Verweisquelle konnte nicht gefunden werden. ETRS89 / Fehler! Verweisquelle konnte nicht gefunden werden. UTM Zone 32N

ETRS89 / UTM Zone 32N

 

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

sinnvoll

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

Zone

25833

Fehler! Verweisquelle konnte nicht gefunden werden. ETRS89 / Fehler! Verweisquelle konnte nicht gefunden werden. UTM Zone 33N

ETRS89 / UTM Zone 33N

 

 

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

Zone

31466

Fehler! Verweisquelle konnte nicht gefunden werden. DHDN / 3-Grad Gauß-Krüger Zone 2

Gauß-Krüger, 2. Streifen

 

 

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

Zone

31467

Fehler! Verweisquelle konnte nicht gefunden werden. DHDN / 3-Grad Gauß-Krüger Zone 3

Gauß-Krüger, 3. Streifen

 

 

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

Zone

31468

Fehler! Verweisquelle konnte nicht gefunden werden. DHDN / 3-Grad Gauß-Krüger Zone 4

Gauß-Krüger, 4. Streifen

 

 

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

Zone

31469

Fehler! Verweisquelle konnte nicht gefunden werden. DHDN / 3-Grad Gauß-Krüger Zone 5

Gauß-Krüger, 5. Streifen

 

 

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

Zone

32632

Fehler! Verweisquelle konnte nicht gefunden werden. WGS 84 / Fehler! Verweisquelle konnte nicht gefunden werden. UTM Zone 32N

WGS84 / UTM Zone 32N

 

 

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

Zone

35832

Fehler! Verweisquelle konnte nicht gefunden werden. ETRS89 , Fehler! Verweisquelle konnte nicht gefunden werden. UTM Zone 32 mit führender 32 im Rechtswert

Siehe EPSG:4647

 

 

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

Zone

35833

Fehler! Verweisquelle konnte nicht gefunden werden. ETRS89 , Fehler! Verweisquelle konnte nicht gefunden werden. UTM Zone 33 mit führender 33 im Rechtswert

Siehe EPSG:5650

 

 

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

Zone

3035

Europe Albers Equal Area Conic

ETRS89 / ETRS-LAEA

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

Zone

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

sinnvoll

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

Zone

3034

Europe Lambert Conformal Conic

ETRS89 / ETRS-LCC

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

Zone

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

sinnvoll

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

Zone

900913

Google-Projektion, Spherical Mercator

Google Maps Global Mercator

 

 

 

3857

Google-Projektion, Spherical Mercator

Google Maps Global Mercator

 

 

 

3038

ETRS89 / ETRS-TM26

Geplant für Portal 2.0

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

Zone

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

sinnvoll

 

3039

ETRS89 / ETRS-TM27

Geplant für Portal 2.0

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

Zone

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

sinnvoll

 

3040

ETRS89 / ETRS-TM28

Geplant für Portal 2.0

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

Zone

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

sinnvoll

 

3041

ETRS89 / ETRS-TM29

Geplant für Portal 2.0

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

Zone

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

sinnvoll

 

3042

ETRS89 / ETRS-TM30

Geplant für Portal 2.0

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

Zone

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

sinnvoll

 

3043

ETRS89 / ETRS-TM31

Geplant für Portal 2.0

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

Zone

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

sinnvoll

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

Zone

3044

ETRS89 / ETRS-TM32

Geplant für Portal 2.0

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

Zone

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

sinnvoll

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

Zone

3045

ETRS89 / ETRS-TM33

Geplant für Portal 2.0

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

Zone

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

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

Zone

3046

ETRS89 / ETRS-TM34

Geplant für Portal 2.0

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

Zone

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

 

3047

ETRS89 / ETRS-TM35

Geplant für Portal 2.0

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

Zone

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

 

3048

ETRS89 / ETRS-TM35

Geplant für Portal 2.0

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

Zone

 

 

3049

ETRS89 / ETRS-TM37

Geplant für Portal 2.0

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

Zone

 

 

3050

ETRS89 / ETRS-TM38

Geplant für Portal 2.0

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

Zone

 

 

3051

ETRS89 / ETRS-TM39

Geplant für Portal 2.0

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

Zone

 

 

5730

EVRF2000 height

Geplant für Portal 2.0

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

 

 

 

 


[1] “Spatial object: abstract representation of a real-world phenomenon related to a specific location or geographical area [INSPIRE Directive]. […] It is also synonymous with "(geographic) feature" as used in the ISO 19100 series. (Quelle: INSPIRE D2.5 V 3.4 )


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

[SK(2] Ggf. sollten wir hier auf die INSPIRE-RL verweisen, da das GeoZG eher für den Bund relevant ist.

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

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

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

[MLR6] Adressaten dieses Dokus sind … (momentan mir noch unklar, ob eher GDI-Kontaktstellen, geodatenhaltende Stellen, Fach-Communities, … die Hauptadressaten sein sollen)

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

[SN8] Formulierung unklar, nicht eindeutig

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

[SN10] Leitbild oder Interoperabilitätskonzept - Verwirrung

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

[s12] Das sind eher Interoperabilitätsaspekte als Komponenten

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

[SN14] Hier wird es deutlich

[s15] Aspekte der Interoperabilität

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

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

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

[s19] 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?

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

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

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

Elemente anscheinend nicht?

[SN23] Englische Titel ergänzen oder diesen Absatz streichen

[SK(24] Anm: in Abbdildung 1 werden die deutschen Begriffe verwendet.

[SN25] vorgeschlagen?

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

[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] Sollte genauso benannt werden, wie in Abb. 1

[SN30] der Datenmodellierung?

[SN31] der Datenmodellierung?

[SN32] Wer?

[s33] Vielleicht doch besser auf Deutsch „Datenanbieter“

[SN34] Warum nicht Datenanbieter?

[SK(35] Aus meiner Sicht ist es diskussionswürdig, ob sich die GDI-Koordinierungsstellen als Koordinatoren für die Entwicklung von Fachdatenmodellen sehen.

[SN36] Wie ist das zu verstehen?

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

[SN38] Welche Bestandsanalyse?

[SN39] Welche Schritte sind gemeint?

[SN40] Die letzteren? Besser Schritte konkret benennen.

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

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

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

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

[SN45] Welche Bestandsanalyse?

[SN46] Welche Schritte sind gemeint?

[SN47] Die letzteren? Besser Schritte konkret benennen.

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

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

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

[SN51] Schemata oder Schemas? Vereinheitlichen

[s52] 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, …)

[SK(53] Ggf. kann

[SN54] Verweis

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

        [s56] Interoperabilitätsaspekt „Erfassungsregeln“

[MLR57] 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?

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

[s59] Oder mehrere

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

[SN61] Einheitlich als gesonderten Abschnitt einführen?

[s62] Zur Info -> siehe Anforderungsmgmt.: 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.

[s63] 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

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

[s65] 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.

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

[s67] 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.

[MLR68] 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(69] Anmerkung: Kurzbeschreibung ist identisch mit der Beschreibung zum Denkmalschutz

[s70] Warum wird das hier aufgeführt?

[MLR71] 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.