Use Case 1: Bildung von INSPIRE-Objekt-IDs (Objektidentifikator - OID)

Gemäß EG Nr. 1089/2010 sind sämtliche (INSPIRE-)Geoobjekte mit einer eindeutigen INSPIRE-ID zu versehen. Hintergrund ist, dass jedes Geoobjekt in der GDI eindeutig referenziert (und verlinkt) werden soll. Somit können einzelne Geoobjekte direkt über Downloaddienste bezogen werden.
Der in Anhang I Abschnitt 2.1 (Seite 5) definierte Datentyp „Identifier“ ist als Typ für den externen Objektidentifikator eines Geo- Objekts zu verwenden. (Art. 9). Der externe Objektidentifikator zur eindeutigen Identifizierung von Geo-Objekten darf während des Lebenszyklus eines Geo-Objekts nicht geändert werden. INSPIRE-Objekt-IDs können mit Hilfe des Namespace-Registers verwaltet und dereferenziert werden.

Geplante Umsetzung von INSPIRE-Objektidentifikatoren (BY)

Attribut inspireID vom Typ Identifier, bestehend mindestens aus namespace und localId:

In der GDI-BY ist geplant, den vollständigen Unique Ressource Identifier (bestehend aus in dem in der Registry geführtem GDI-BY-Namensraum + UUID, s. Use Case 2) als namespace für die INSPIRE-Objektidentifkatoren zu verwenden.

Bsp.: https://registry.gdi-de.org/id/de.by/125cce16-7ae1-3cf0-96e2-05a4453f3cb1/{localId}       

Diese URI sollte anschließend durch die GDI-Registry in eine entsprechende WFS-Query aufgelöst werden können. Eine Ergänzung für die Version des Objekts ist optional möglich.

Fiktives Beispiel:
https://registry.gdi-de.org/id/de.by/125cce16-7ae1-3cf0-96e2-05a4453f3cb1/cf83e135

wird aufgelöst zu:
https://www.geodaten.bayern.de/wfs/does-not-exit?service=WFS&version=2.0.0&request=GetFeature&storedquery_id=GetFeatureById&id=cf83e135

Hierbei sollten u.a. folgende Aspekte untersucht werden:

  • Verhalten bei internen und externen Objektreferenzen
  • Potentiell erhebliche Auswirkungen auf die Dienst-Performance
     

Umsetzung von INSPIRE-Objektidentifikatoren (NW)

In der GDI-NW wurden bereits INSPIRE-Umsetzungen begonnen, insbesondere für Themen aus ATKIS und ALKIS, die von Geobasis NRW verantwortet werden.

Für die gesamte GDI-NW wurde dazu unter dem NRW-eigenen Namensarum "de.nw" der Namensraum "inspire" eingerichtet: https://registry.gdi-de.org/id/de.nw.inspire

Je umzusetzendem Thema und Quelldatenbestand wird dieser weiter untergliedert wird, z.B. für Flurstücke aus ALKIS: https://registry.gdi-de.org/id/de.nw.inspire.cp.alkis     

Dabei werden für das INSPIRE Thema einheitlich die aus zwei Buchstaben bestehenden Kürzel (TN, HY, AU, CP etc.) verwendet. Die weitere Untergliederung bzgl. des Quelldatenbestands ist notwendig, da es z.B. für Verwaltungseinheiten (AU) eine Umsetzung sowohl aus dem ATKIS Basis-DLM als auch als ALKIS geben wird, die in verschiedene Datenbanken münden und auch über verschiedene Download-Dienste angesprochen werden.

Anmerkung: Momentan existieren noch NRW-Datenbestände, die im Namensraum zwischen "de.nw" und "inspire" die Ebene "geobasis" enthalten. Diese wird jedoch zur Vereinfachung aufgegeben.


 

Geplante Umsetzung von INSPIRE-Objektidentifikatoren durch die BfG (Bund) für zentrale Datensätze der Wasserwirtschaftsverwaltungen im Berichtsportal WasserBLIcK

Analog zur oben beschriebenen Vorgehensweise im Land Bayern, wird die Bundesanstalt für Gewässerkunde die INSPIRE-Objekt-ID für zentrale Datensätze der Wasserwirtschaftsverwaltungen im Berichtsportal WasserBLIcK im Namensraum der BfG in der GDI-Registry generieren. Die entstehende URI wird durch die GDI-Registry in eine entsprechende WFS-Query aufgelöst, so dass die Geoobjekte mit Kenntnis der INSPIRE-ID unmittelbar im Internet bezogen werden können. Der namespace wird genutzt, um die domainspezifischen Objektarten zu gruppieren. Die localId entspricht der im nationalen Berichtsportal von den zuständigen Behörden der Länder unabhängig von INSPIRE gepflegten wasserwirtschaftlichen, internationalen Objekt-ID (EU_CD_Code).

Ein Beispiel aus der Domaine "Wasserschutzgebiete": http://registry.gdi-de.org/id/de.bund.bfg.wsg/DE_PD_DENW_510603


Use Case 2: Bildung von eindeutigen Ressourcenbezeichnern (unique resource identifier) zur Umsetzung der Daten-Dienste-Kopplung

Die Daten-Dienste-Kopplung ist in den Konventionen zu Metadaten, Abschnitt 4.1 und 4.2 beschrieben.

Umsetzung Daten-Dienste-Kopplung - UC2 (NRW)

Entsprechend der Vereinbarung vom AP-Workshop im Juni 2015 hat NRW begonnen, den vorgesehenen Namensraum (zunächst nur für Ressourcenidentifikatoren in den Metadaten, nicht für Objekte) zu nutzen, d.h. neben dem Erstellen der URL-Vorlage mit dem CSW-Aufruf für den GEOkatalog NRW wurden erste Metadatensätze zu Daten und Diensten entsprechend verändert und publiziert.

Die Auflösung eines solchen Ressourcenidentifikators entsprechend der URL-Vorlage hin zu einem qualifizierten CSW-Aufruf, um den Metadatensatz aufzurufen, funktioniert grundsätzlich, jedoch ist momentan die Ausführbarkeit des CSW-Aufrufs u.U. (abhängig von der eingesetzten Katalog-Software) nicht gegeben.

NRW setzt im Landesknoten die Software terraCatalog ein. Dort wird ein CSW-Aufruf, wie dieser in der URL-Vorlage gem. Konventionendokument Metadaten abgebildet wurde (GetRecords mit KVP (KeyValuePair) zwecks Anfrageparameter für resourceIdentifier), nicht unterstützt, da die Unterstützung von KVP nicht zum verpflichtenden CSW-Standard gehört, sondern eine Option darstellt.

Das BKG (Betriebsstelle) sieht in der Nutzung von POST-Requests (anstatt GET) seitens der Registry eine mögliche Alternative. Die Realisierbarkeit muss aber zunächst in Erfahrung gebracht werden.

Umsetzung Daten-Dienste-Kopplung - UC2 (BY)

Namensraum: https://registry.gdi-de.org/id/de.by

Unique Ressource Identifier: https://registry.gdi-de.org/id/de.by/125cce16-7ae1-3cf0-96e2-05a4453f3cb1 

Dieser eindeutige Ressourcenbezeichnern wird über die Registry aufgelöst. Diese löst einen Redirect aus, auf:

http://geoportal.bayern.de/csw/bvv?service=CSW&version=2.0.2&request=GetRecords&namespace=xmlns%28csw=http://www.opengis.net/cat/csw/2.0.2%29,xmlns%28gmd=http://www.isotc211.org/2005/gmd%29&resultType=results&outputFormat=application/xml&outputSchema=http://www.isotc211.org/2005/gmd&startPosition=1&maxRecords=1&typeNames=csw:Record&elementSetName=full&constraintLanguage=CQL_TEXT&constraint_language_version=1.1.0&constraint=csw:ResourceIdentifier=%27*125cce16-7ae1-3cf0-96e2-05a4453f3cb1*%27

Die dazugehörige Namensraum-Konfiguration kann unter dem entsprechenden Regitry-Item nachvollzogen werden: https://registry.gdi-de.org/item/d6d8eef0-be6b-4e8b-9b02-944c41f73798

Beispiel für Umsetzung der Daten-Dienste-Kopplung unter Verwendung des Namensraumes (Handlungsempfehlung AK Geodienste): https://github.com/gdi-de/ak-geodienste/blob/master/handlungsempfehlung-downloaddienste/wfs20/inspire-metadata-service.xml


Welche Länderkonzepte zur Namensraum-Vergabe gibt es?



  • Keine Stichwörter

9 Kommentare

  1. Benutzer-c18c5 sagt:

    > ... jedoch ist momentan die Ausführbarkeit des CSW-Aufrufs u.U. (abhängig von der eingesetzten Katalog-Software) nicht gegeben.

    Dies ist bei der gegenwärtigen Architektur der Portale jedoch kein Hindernis, da die Auflösung der Daten-Dienste-Kopplung auch über mehrere CSW-requests funktioniert.

    1. Peter Kochmann sagt:

      Was bedeutet das genau? Ist damit die Auflösung in POST-Requests gemeint?

  2. Anja Loddenkemper sagt:

    Was ist unter "Geo-Objekt" technisch genau zu verstehen?

    Beispiel: Ich habe Geodaten, bei denen es sich um ein Punkte-Shape handelt. Ist dann das Punkte-Shape selbst das "Geo-Objekt" oder ist der einzelne "Punkt" das (bzw. bei mulitpart-Features die Punkte-Gruppe) das "Geo-Objekt"?

    1. Michael Räder sagt:

      Bei der INSPIRE Modellierung wäre der einzelne Punkt das Geoojekt, dass mit jeweils einer anderen INSPIRE ID gekennzeichnet sein muss.

      INSPIREID = Namespace+ID(individuell)+Version

      1. Anja Loddenkemper sagt:

        Danke, das hatte ich schon befürchtet. Das wird dazu führen, dass wir Namensräume für die Ressourcenidentifikatoren benötigen und auch welche für die INSPIREIDs. Dabei kann es natürlich Überlappungen geben.

        1. Michael Räder sagt:

          Das ist die Frage. Man kann das ganze auch mit nur einem Namespace zu den Daten modellieren, wenn man immer den "Besitzer" als Namespacedefiniert.

          Die ID kann dann ja nach speziellen Regeln für jedes INSPIRE Thema gebildet werden.

           

          Ich halte es an dieser Stelle für erforderlich, dass man sich national auf eine Vorgehensweise einigt oder festsetzt, da sonst wieder sehr viel Wildwuchs produziert wird.

          1. Peter Kochmann sagt:

            Ich denke, dass man an mehreren Namensräumen nicht vorbei kommt:

            • Einer für die Ressourcen-Identifier in den Metadaten, um daraus in einen CSW-GetRecords-Command aufzulösen.
            • Weitere für die Objekt-Identifier in den Daten, um daraus auf einen bestimmten WFS-GetFeature-Command aufzulösen. Ich denke nicht, dass man das allein über ein Muster im Identifier hinbekommt. Oder es würde zumindest sehr unübersichtlich. Wir denken bereits daran, pro INSPIRE-Thema einen Namensraum anzulegen.

  3. Anja Loddenkemper sagt:

    Frage zu Use Case 1: Wie muss ich mir die tatsächliche fachliche Fragestellung vorstellen, die mit der Referenzierbarkeit von Geo-Objekten beantwortet werden soll?

    Ich habe das folgende Szenario vor Augen:

    Ein EU-Sachbearbeiter sitzt vor einem umfangreichen Datenpool, den er mit Hilfe komplexer Analyseverfahren aus INSPIRE Daten gewonnen hat. Nun soll dieser Datenpool aktualisiert werden.

    Geprüft werden muss daher, welches Geo-Objekt welche Aktualität besitzt (aktuell oder schon veraltet und damit aktualisierungswürdig). Die Versionierung des Geo-Objektes gibt Auskunft zur Aktualität. Um das Geo-Objekt aktualisieren zu können, muss der Download-Dienst ausfindig gemacht werden, der dieses Geo-Objekt verantwortlich bereit stellt. Der Namensraum gibt Auskunft zu der URL des Download-Dienstes. Aus dem Dienst selbst kann auf die Daten-Metadatensätze geschlossen werden. Spätestens von hier aus ist auch der Service-Metadatensatz bekannt und es kann  auf den Betreiber des Dienstes geschlossen werden. Ebenso kann durch die Daten-Service Kopplung bzw. den Dienst direkt auf die Daten und den Verantwortlichen für die Daten geschlossen werden, da der Daten-Metadatensatz über den Dienst zugänglich ist. Dies ist wichtig, da fachliche Fragen zu einem Geo-Objekt auftauchen könnten, die nur ein Fachverantwortlicher beantworten kann.

    Einer Geo-Objekt basierten automatischen Aktualisierung (ggf. mit Hilfe durch einen verantwortlichen Fachverantwortlichen für Daten oder Dienst) durch den EU-Sachbearbeiter steht nichts mehr im Wege. Es funktioniert selbst dann, wenn seine Daten aus sämtlichen Verwaltungsebenen und aus beliebigen Ländern der EU stammen.

    -------------------------------

    Ist das das Szenario, welches mit der VO abgedeckt werden soll???

    Wenn wir das Szenario (oder die Szenarien) gut durchdenken und strukturieren, sollten wir eine Lösung für die bestmögliche Bildung von Namensräumen finden können - verbindlich für die GDI-DE insgesamt.

  4. Anja Loddenkemper sagt:

    Überlegung zu UseCase 1: Unterschiedliche Datenbestände erfordern unterschiedliche Behandlung von  Identifikatoren für Geo-Objekte

    Grundsätzlich gibt es zwei unterschiedliche Arten von Geodaten:

    Wildwuchs Geodaten: Auf der einen Seite haben wir die, wo eine vom GIS automatisch generierter Identifkator für die Geo-Objekte vorliegt. Vielleicht hat der ein oder andere Datenhalter noch einen eigenen Identifikator pro Geo-Objekt hinzugefügt, um die Leistungsfähigkeit seiner räumlichen Datenbank per Indexbildung zu verbessern. Die Identifikatoren für die Geo-Objekte sind jedoch alles in allem fachlich nicht von Belang, sondern es gibt sie nur, weil die technisch eben benötigt werden, um Geometrien mit Attributen zu verknüpfen oder eine Datenbank ein wenig schneller zu machen.

    Organisierte Geodaten: Auf der anderen Seite haben wir recht komplex angelegte Geodaten. Bei diesen hat ein Geo-Objekt in jedem Falle einen fachlich bedeutsamen Identifikator. Kann sein, dass dieser aus einer technischen Notwendigkeit entstand, jedoch wird er tatsächlich gehegt und gepflegt. Jedes Geo-Objekt hat wirklich seinen verlässlichen Identifikator. Dies mag der Fall sein, weil ein vereinbartes lokales Datenmodell es erfordert und entweder innerhalb der Institution oder innerhalb einer Gruppe von Institutionen vereinbart wurde.

    ------------------------------------

    Ich denke, dass die Umsetzung der Namensräume für die Wildwuchs Geodaten und für die Organisierten Geodaten per Registry unterschiedlich sein muss. Es ist nicht so einfach möglich zu sagen: Ich nehme mal für jede Institution einen eigenen Namensraum; ich nehme mal für jeden Dienst einen Namensraum; ich nehme mal für jedes INSPIRE Thema einen Namensraum... Damit würden wir die Organisierten Geodaten regelrecht degradieren und sie zurück in den "Wildwuchs" schicken, obwohl wir fachlich abstimmungstechnisch eigentlich bei denen schon viel weiter waren.

    ------------------------------------

    Beispiele von Wildwuchs-Geodaten kann sich jeder auf seinem eigenen Rechner erzeugen. So sind wohl die meisten Geodaten einmal entstanden. Und das ist das, was mit INSPIRE (endlich und zum Nutzen aller!) sein Ende finden soll.

    Beispiele für Organisierte Geodaten sind auf unterschiedlichen Verwaltungs- oder Fachebenen zu finden. Ein schönes und übersichtliches Beispiel sind die InVeKoS-Feldblöcke. Hier existiert ein FLIK und FLEK als Identifikator, der deutschlandweit zwischen den Bundesländern verbindlich vereinbar wurde. Der Feldblock als solcher dient EU-weit zur Auszahlung der Flächenprämien in der Landwirtschaft, sofern "Feld ungleich Flurstück" ist. Nachlesen wie FLIK und FLEK verwendet werden kann man gut bei der LWK NRW: https://www.landwirtschaftskammer.de/foerderung/feldblock/flik/index.htm

    Erläuterung Flächenidentifikator:

    http://profilglossar.data-experts.de/index.php/Fl%C3%A4chenidentifikator (vom 25.11.2015)

    ---------------------------------------------

    Die INSPIRE Namensräume dürfen aus meiner Sicht diese bestehenden und hochgradig durchorganisierten Identifikatoren nicht mutwillig "zerstören", sondern wir sollten versuchen, die benötigen Namensräume so zu bilden, dass derlei Datenbestände mit geringstmöglichen Aufwand auch weiterhin als Einheit betrachtet werden können. Sofern Datensätze bereits heute für die EU-Ebene relevant sind, müsste aus meiner Sicht auch die EU die zugehörigen Namensräume vorgeben. Möglicherweise müssten wir dann durch die GDI-DE Registry diese Gesamtnamensräume durch den lokalen Identifikator (hier also FLIK) auflösen, um daraus auf die Dienste bei unterschiedlichen Anbietern in den Bundesländern zu schließen.

    ---------------------------------------------

    Unsere neusten Erkenntnisse zu den Identifikatoren für Geo-Objekte:

    Die Attribute des Datentyps Identifier richten sich nach VO(EU) 1089/2010 Anhang I 2.1 geändert durch VO(EU) 1253/2013. Ich kann daraus keine Verpflichtung zur Verwendung von Namensräumen ableiten, wenn es sich bei den Identifkatoren der Geo-Objekte sowieso schon um UUIDs handelt. - Sehe ich das so richtig?

    Wenn Geo-Objekte sowieso eine UUID haben, dann braucht man keinen Namensraum, um sie zu identifizieren. Da aber eine EU-weite Suche nach dem passenden Dienst durch alle Registries sehr langwierig wäre, könnten wir uns für solche Geo-Objekte auf einen Namensraum für "Deutschland" einigen. Die GDI-DE Registry müsste dann alle Geo-Objekte, die mit UUIDs gekennzeichnet sind, beinhalten, um so auf die damit in Verbindung stehenden Download-Dienste zu schließen. (Da bin ich gespannt auf die Performanzanalyse!)

    Wenn Geo-Objekte lokale Identifkatoren besitzen, benötigen diese zwingend einen Namensraum.

    Kann mir jemand sagen, wo ich etwas zur Versionierung finde? Ist das ein date/timestamp, oder wie muss ich mir das vorstellen?