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  

Teil 2: Vorgaben und Empfehlungen

 

 

ENTWURF

 

 

Arbeitsgruppe Geodaten

20.09.2016  

 

Dieses Dokument enthält Vorgaben und Empfehlungen für die interoperable Bereitstellung von Geodaten in der Geodateninfrastruktur Deutschland (GDI-DE).


Dokumenteninformation

Bezeichnung

Teil 2: Vorgaben und Empfehlungen Teil 2: Vorgaben und Empfehlungen

Autor

AG Geodaten

Erstellt am

20.09.2016

Zuletzt geändert

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

Markus Seifert

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 



1         Einführung

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

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

Diese Vorgaben und Empfehlungen sollen Datenanbieter bei der interoperablen Beschreibung und Bereitstellung von Geodaten in der GDI-DE unterstützen

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

2         Interoperabilitätselemente

Nachfolgend werden die Vorgaben und Empfehlungen für die GDI-DE für eine interoperable Bereitstellung von Geodaten erforderlichen Interoperabilitätselemente beschrieben.

2.1     Organisatorische Anforderungen

2.1.1     Empfehlungen für die Rollenverteilung im Harmonisierungsprozess von Datenmodellen

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

  • Datenbereitsteller

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

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

  • Datennutzer

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

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

Beispiel 2: Nutzer auf der Bundes- und Europaebene

Beispiel 3: Nutzer aus der Wirtschaft, Wissenschaft und der Öffentlichkeit bzw. Privatpersonen.

  • Koordinatoren/Moderatoren

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

Beispiel: Fachnetzwerke, Arbeitsgruppen der GDI-DE oder Einzelpersonen

  • Generelle Datenmodellierungsexperten

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

Beispiel: Modellierungsexperten aus der Geoinformatikwissenschaft.

  • Technische Datenmodellierungsexperten

Die technischen Datenmodellierungsexperten begleiten die Entwicklung der harmonisierten Datenmodelle mit der Konzeption, Programmierung und Implementierung von entsprechenden Softwarewerkzeugen zur Modellierung und Schematransformation, z. B. mit der FME.

Beispiel: Geoinformatikexperten aus Wissenschaft und Forschung.

2.1.2     Empfehlungen für die Vorbereitung des Harmonisierungsprozesses

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

  1. Identifizierung eines Anwendungsfalls

Vor den nachfolgenden Schritten sollten ein oder mehrere Anwendungsfälle beschrieben werden, die auf einer Ist-Analyse basieren. Die darauf aufbauend zu entwickelnden Anwendungsfälle sollten  die Implementierung inklusive des entsprechenden Testens und Validierens umfassen sowie Schritte für das Fortschreiben des Datenmodells vorgeben. Für die letztgenannten Schritte sollten die Koordinatoren/Moderatoren verantwortlich sein. Die Aktivitäten sollten sich am bestehenden Prozess für die Erstellung der INSPIRE-Datenspezifikationen orientieren und Analysen bezüglich allgemeiner Nutzeranforderungen enthalten.

  1. Liste der verantwortlichen Datenprovider und Datennutzer

Um sicherzustellen, dass alle relevanten Akteure in den Modellierungsprozess mit einbezogen sind, sollten unter Berücksichtigung der föderalen Strukturen die verantwortlichen Datenprovider und Datennutzer der Fachdomäne mit involviert werden. Bei der Zusammenstellung sollten   vorhandene Strukturen, wie z. B. die Fachnetzwerke für die Erweiterung von INSPIRE-Datenmodellen oder vorhandene Listen mit den geodatenhaltenden Stellen für die INSPIRE-Annexthemen, genutzt werden. Die Fachnetzwerke könnten bei der Erstellung Koordinierungsaufgaben übernehmen.

  1. Liste möglicher fachlicher Ansprechpartner

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

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

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

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

2.1.3     Empfehlungen für den Datenspezifikationsprozess

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

 

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

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

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

2.2     Referenzmodell

Für die beiden definierten Anwendungsfälle des Interoperabilitätsrahmens werden dringend abgestimmte Vorgaben (durch Fachgremien) für die Modellierung benötigt. Optimal wäre in diesem Zusammenhang ein fachneutraler Modellierungsrahmen, der als Basis für alle Fachdaten in UML nach ISO 19109 zusammen mit einem GDI-DE-UML-Profil angewendet werden könnte. Mit einem derartigen Referenzmodell könnte festgelegt werden, welche ISO/TC 211 Standards erfüllt werden müssen bzw. sollten und Hilfestellungen bzgl. der Nutzung von Standards geben. Darüber hinaus sollten Methoden und Vorgaben zu den Inhalten der Modelldokumentation und zur Ableitung von Objektartenkatalogen aus dem UML-Modell festgelegt werden.

Maßnahmen:

  • Festlegung von ISO 19101 als Grundlage für die standardisierten Beschreibung der Geodaten im Technikdokument der GDI-DE
  • Entwicklung eines Referenzmodells für die Datenmodellierung für die GDI-DE auf Basis des INSPIRE Generic Conceptual Model [INSPIRE GCM 2014]

 

2.3     Regeln für das Anwendungsschema

Dieses Interoperabilitätselement ist nur dann anzuwenden, wenn ein Datenmodell unter Verwendung der gleichen Modellierungsgrundsätze und Methodik wie bei INSPIRE gewollt ist.

Die Erweiterung der INSPIRE-Modelle aus den Durchführungsbestimmungen ist grundsätzlich die Aufgabe von Modellierungsexperten mit entsprechendem INSPIRE-Hintergrundwissen. In der Praxis verfügen die Modellierer jedoch nicht immer über dieses Wissen. Eine Leitlinie zum Vorgehen für die Erstellung von Modellen wäre an dieser Stelle hilfreich, z. B. in Form eines frei zugänglichen Wiki mit Beispielen, Leitfäden, einer Sammlung weiterführender Links, Diskussionsforum etc., ähnlich wie:

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

Zum Erreichen einer interoperablen Bereitstellung von Geodaten in der GDI-DE sollten unter anderem Folgendes inhaltlich geklärt werden:

  • Allgemeine Fragen zur Modellierung:
    • Welche Vorteile hat ein auf internationalen Standards basierendes Datenmodell?
    • Welche Alternativen gibt es und welche  Vorteile/Nachteile haben diese?
    • Welche Software wird genutzt bzw. eingesetzt (UML Modellierung, Ableitung des XML Schemata, etc.)?
    • Welche Modellkonstrukte sind zu vermeiden (z. B. Assoziation Classes)?
    • Wie könnte eine Dokumentation der Modelle aussehen?
    • Wie kann die GDI-DE Registry bei der Modellierung mit eingebunden werden (z. B. Registrierung der Codelisten)?
    • Wie sind Integritätsregeln zu definieren (z. B. OCL)?
  • Vorgaben zur Modellierung der Maßstabsabhängigkeit:
    • Welche Maßstäbe und Repräsentationen sind in welchen Anwendungen relevant?
    • Ist die Repräsentation eines Objekts in verschiedenen Maßstäben erforderlich?
  • Notwendiges Hintergrundwissen zu INSPIRE (Entscheidungshilfe/-fragen):
    • Für wen sind die Vorgaben von INSPIRE bzw. aus dem GDI-DE Interoperabilitätskonzept (nicht) relevant?
    • Wie können weitere Datenanbieter von genereller Bedeutung gewonnen werden, auch ohne die Verpflichtungen der INSPIRE-Vorgaben umzusetzen?
    • Welche INSPIRE Packages sind relevant? Wie sind diese einzubinden bzw, zu erweitern?
    • Welche vorgegebenen INSPIRE-Klassen sind wann und wie zu übernehmen?
    • Besonderheiten der INSPIRE Modellierung wie z.B. :
      • NULL-Attribute
      • Unterscheidung von featuretype (geographisch referenziert) und datatype: Wo ist eine geographische Referenz notwendig?
      • Unterscheidung von Codelisten und Enumerationen
      • Beschreibung der Prozesse zur Erweiterung der INSPIRE-Datenmodelle (Objektarten, Codelisten, …)

 

Maßnahmen:

  • Einrichtung eines Wikis für Best Practices Beispielen für die Modellierung von Anwendungsschemata für die GDI-DE

 

2.4     Identifikatormanagement

2.4.1     Eindeutigkeit

Die Eindeutigkeit von Objektidentifikatoren wird im INSPIRE GCM 2014 wie folgt definiert:

(1)   Ein Objektidentifikator bezeichnet genau ein Geoobjekt.

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

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

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

Geoobjekte können versioniert werden, um z. B. nachträgliche Korrekturen oder Änderungen an Attributfeldern transparenter zu kennzeichnen. Obwohl Versionen nicht Bestandteil des Objektidentifikators eines Geoobjekts sind, wird im INSPIRE GCM 2014 ein versionierter Datentyp für Objektidentifikatoren vorgeschlagen (siehe Tabelle 1 ). Ein Namespace und eine LocalId bilden den eindeutigen Objektidentifikator, das Versionsfeld kann eine fortlaufende Nummer sein oder einen Zeitstempel enthalten. Zudem kann dieser Identifikator-Datentyp auch für die interne Datenhaltung genutzt werden.

Tabelle 1 : Auszug aus dem Generic Conceptual Model von INSPIRE

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

Attribute:

LocalId

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

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

Attribute:

Namespace

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

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

Attribute:

VersionID

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

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

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

 

Maßnahmen:

  • Realisierung eines Prozesses zur Vergabe und Registrierung von Objektidentifikatoren, der folgende Anforderungen erfüllt:

-          Ein Objektidentifikator für ein Geoobjekt darf bzw. kann nur einmal vergeben werden.

-          Die Verknüpfung zwischen Geoobjekt und dessen Objektidentifikator muss auflösbar (d.h. rückverfolgbar) sein.

-          „Verfallene“ Objektidentifikatoren müssen erfasst bleiben, damit diese nicht irrtümlich erneut vergeben werden können.

-           Eine klare Benennung der verantwortlichen Stellen für die Pflege der Objektidentifikatoren ist zwingend erforderlich. Ihnen obliegt die Durchsetzung bzw. Einhaltung dieser Anforderungen.

2.4.2     Persistenz

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

(1)   Für den gesamten Lebenszyklus eines Geoobjektes bleibt der Objektidentifikator unverändert.

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

Im Bereich der INSPIRE-Datenthemen gibt es in den Mitgliedsstaaten keine flächendeckende Unterstützung für die Abbildung von Lebenszyklen oder Versionen. Daher bleiben das INSPIRE Generic Conceptual Model und die darauf aufbauenden Datenspezifikationen hier unkonkret [AL1] . Folgende Aspekte sind jedoch als Regeln für einen Lebenszyklus eines Geoobjektes zu berücksichtigen:

(3)   Es muss geklärt sein, wie stark sich ein Geoobjekt verändert werden kann [AL2] , 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 im INSPIRE GCM 2014, Kapitel 9.7 zu finden bzw- nachzulesen.

Maßnahmen:

  • Klärung der Frage, ob Informationen zum Lebenszyklus des Geoobjekts generell nötig sind.
  • Wenn ja:

-           Definition von Regeln zum Lebenszyklus- Management auf fachlicher Ebene

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

2.4.3     Rückverfolgbarkeit

INSPIRE fordert einen Mechanismus zur Auffindbarkeit von Geoobjekten, basierend auf dem jeweils dazugehörigen Objektidentifikator. 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 eines Digitalen Objektbezeichners (DOI). Über den Namensraum des Objektidentifikators lässt sich der Datenprovider identifizieren und in dessen Bestand (Katalog) das Geoobjekt finden.

Maßnahmen:

  • Verbindung zwischen dem Datenprovider und dessen Namensraum muss definiert und diese Information in einer geeigneten Registry hinterlegt werden.
  • Zusätzlich muss ein interoperabler Dienst bereitstellt werden, der das Auffinden von Downloaddiensten für die von ihm bereitgestellten Geoobjekte ermöglicht.

-           Es kann auch auf höherer Ebene (z. B. Bund, Land) ein solcher Dienst bereitgestellt werden, der stellvertretend für mehrere Datenprovider 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.

2.4.4     Machbarkeit

INSPIRE-Objektidentifikatoren müssen so aufgebaut sein, dass sie auf existierende nationale Objektidentifikatoren abgebildet werden können. Hierfür existieren in Deutschland bereits zahlreiche, machbare Vorschläge aus der AdV und den Landesvermessungen. Sie definieren syntaktische Vorgaben für den Aufbau von Namensräumen auf verschiedenen föderalen Ebenen. Mit der GDI-DE Registry gibt es bereits ein entsprechendes Instrument (siehe
https://registry.gdi-de.org/register/namespace/ ), das dafür verwendet werden kann und ggf. angepasst werden muss.

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

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

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

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

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

Maßnahmen:

  • Klärung der oben genannten Fragen zur Vergabe und Führung von Objektidentifikatoren. Die Lösungsansätze sind zu erproben und ggf. weiterzuentwickeln. Die in der GDI-DE bereits geleisteten Vorarbeiten zum syntaktischen Aufbau von Namensräumen und Registries sind im Wesentlichen nur noch umzusetzen.

2.5     Nutzung zentraler Komponenten der GDI-DE

Die zentralen Komponenten stehen schon weitgehend bereit und sind zu nutzen. Dabei sind die jeweiligen Schnittstellen zu berücksichtigen.

Maßnahmen:

  • Als Konsequenz ergibt sich, dass ein klares, nachhaltiges Organisationsmodell für alle zentralen Komponenten als zentraler Bestandteil des Aufbaus einer Geodateninfrastruktur entwickelt und festgeschrieben werden muss.
  • Die GDI-DE Testsuite ist zu erweitern, damit künftig auch Datentests möglich sind. Die Erweiterbarkeit von anwenderspezifischen Testfällen ist zu berücksichtigen.

 

2.6     Registry

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

Maßnahmen:

  • Festlegung der Rollen gemäß ISO 19135 und der entsprechenden verantwortlichen Akteure für jedes Register der GDI-DE.

2.6.1     Codelisten-Registry

Die Anforderungen an eine Codelisten-Registry sind vielschichtig und oft von Datenanbieter zu Datenanbieter unterschiedlich. In der Regel verursachen spezielle Anforderungen eine Weiterentwicklung der GDI-DE-Codelisten-Registry. Ideen und Vorschläge werden derzeit in einem Wiki unter http://redmine.gdi-de.org/projects/gdi-de-registry/wiki/Anforderungen_Codelisten-Register gesammelt und im Rahmen eines Anforderungsmanagements bei der Weiterentwicklung der Registry berücksichtigt.

Maßnahmen:

  • Analyse der Anforderung der verschiedenen Datenanbieter und ggf. anschließende Weiterentwicklung der Codelisten-Registry. Ferner sind die Prozesse zu definieren, wie ein Nutzersystem mit einer Registry kommuniziert (z. B. wie Registryinhalte recherchiert und ausgewertet werden können).
  • Diskussion über die verschiedenen Aspekte bei der Erweiterung von Codelisten in den Fachgremien erforderlich.
  • Abstimmung bei Codelistenerweiterungen mit international festgelegten Codelisten.
  • Festlegung von Abstimmungsprozessen zwischen unterschiedlichen Registern, die ähnlich Inhalte verwalten (z.B. XÖV-Codelisten).

 

2.6.2     CRS-Registry

Geodaten können in verschiedenen Koordinatenreferenzsystemen (CRS) erfasst und gespeichert werden. Für eine gemeinsame Verwendung, z. B. die Darstellung mehrerer Geodatensätze auf einer Karte, müssen die Einzeldaten durch eine entsprechende Transformation in ein einheitliches CRS gebracht werden.

Maßnahmen:

  • Entwicklung und der Betrieb eines, von allen Datenanbietern nutzbares CRS-Registers für die GDI-DE, über das alle Anwendungen über einen CRS-Identifikator exakt die gleichen CRS-Parameter erhalten.
  • Durch die Nutzung und Pflege dieses Registers muss gewährleistet werden, dass Transformationen, die über externe Dienste bereitgestellt werden, oder Anwendungen, die selbst transformieren oder für andere Zwecke CRS-konforme Informationen benötigen, im Ergebnis zu den gleichen Resultaten 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.

Maßnahme:

  • 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 geführt werden.

2.6.3     Registry für Maßeinheiten

In einem Datenmodell muss für jeden quantitativen Wert dessen Maßeinheit angegeben sein. In diesem Abschnitt werden die dafür zu verwendenden Kurzbezeichnungen definiert, die 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:

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

2.7     Verwaltung und Bereitstellung von Schemadateien

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

Maßnahmen:

  • Zentrale Bereitstellung aller erforderlichen Schemadateien durch die jeweiligen Datenanbieter, welche interoperable Daten in der GDI-DE nach einheitlichen Regeln spezifizieren.

 

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

 

 


[AL1] Ggf. durch „eher abstrakt“ ersetzen.

[AL2] Umformulierung je nach Aussage: entweder in: „wie stark sich ein Geoobjekt verändern kann“ oder „wie stark ein Geoobjekt verändert werden kann“

[AL3] Könnte dies auch ggf. als Maßnahme formuliert werden?