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

Übersicht:

Favoritenliste:

Favoritenseiten

Ihre Favoritenliste enthält derzeit keine Seiten. Sie fügen dieser Liste Seiten hinzu, indem Sie im Menü Extras der angezeigten Seite Favorit selektieren.
Zum Ende der Metadaten springen
Zum Anfang der Metadaten

05.07.2018

Auf Basis der von den Mitgliedstaaten gesammelten „Problemfälle“ hat sich die für das Arbeitspaket 2016.1 eingerichtete Arbeitsgruppe entschieden, den Fokus der Aktivitäten auf die Anpassung der Interoperabilitätsanforderungen zu den Anhang III Themen zu legen (Abschlussbericht 2016.1).

Deutschland hat als weiteren Input für das Arbeitspaket 2016.1 eine Studie in Auftrag gegeben, die exemplarisch einige der Probleme bei der Umsetzung der Interoperabilitätsanforderungen aufgreift und Lösungswege zur Vereinfachung der INSPIRE-Umsetzung aufzeigt.

Das Arbeitspaket 2016.1 wurde auf der 6. Sitzung der MIG am 13./14.06.2017 abgeschlossen. Die Aktivitäten werden weiter geführt in den Arbeitspaketen 2017.1 Drafting of „Master Guidelines“ fort he INSPIRE directive, 2017.2 Alternative encodings for INSPIRE data und 2017.3 Improved client support for INSPIRE data.

Darüber hinaus wurden zusätzlich gemeldete Aspekte, die nicht unter die neuen Arbeitspakete fallen, gebündelt und weiter in der MIG bzw. MIG-T behandelt. Unter dem Gesichtspunkt von möglichen Änderungen an der Interoperabilitätsverordnung ist diese Sammlung nach wie vor in Diskussion und war Gegenstand der letzten Sitzung der MIG am 21./22.06.2018.

07.11.2016

Die auf dieser Seite zusammengestellten "Problemfälle" wurden am 07.11.2016 der EU-KOM als Input für das Arbeitspaket 2016.1 "Fitness for pupose - Analysis" übermittelt: 161104_Interoperability_problems_DE.xlsx

 

Auf dieser Seite werden konkrete Problemfälle bei der Umsetzung der Interoperabilitätsanforderungen von INSPIRE gesammelt.

Die Aktivität steht in Zusammenhang mit dem Arbeitspaket 2016.1 (INSPIRE fitness for purpose - Analysis) des INSPIRE Maintenance and Implementation Work Programme (MIWP) 2016-2020. Im Rahmen dieses Arbeitspaketes soll eine temporäre Arbeitsgruppe in einem ersten Schritt einen Fragebogen entwickeln, um die konkreten Probleme bei der Umsetzung der Anforderungen von INSPIRE in den Mitgliedstaaten zu ermitteln. Die Sammlung der konkreten Problemfälle bei der Umsetzung der Interoperabilitätsanforderungen von INSPIRE in Deutschland ist als Ergänzung zu der Umfrage bei den Kontaktstellen im Vorfeld des Ansprechpartner-Workshops im Juni 2016 zu verstehen und soll einer potenziellen deutschen Vertretung in der Arbeitsgruppe als Input dienen.    

Haben Sie Probleme bei der Umsetzung der Interoperabilitätsanforderungen? Z.B., weil ein bestimmtes Datenmodell zu komplex modelliert ist? Bitte tragen Sie Ihr Problem in die Tabelle ein und beschreiben Sie dieses so konkret wie möglich und in Bezug auf die jeweilige(n) Anforderung(en) aus der Verordnung (EG) Nr. 1089/2010 zur Umsetzung der INSPIRE-Richtlinie hinsichtlich der Interoperabilität von Geodatensätzen und -diensten bzw. den zugehörigen Technical Guidance Dokumenten. Bitte tragen Sie zu Kontaktzwecken auch Ihren Namen in die letzte Spalte ein. Ist das Problem bereits an anderer Stelle beschrieben (z.B. in den Thematic Clusters) ist auch ein Verweis darauf ausreichend.

Bei Fragen können Sie sich an Daniela Hogrebe oder Markus Seifert wenden. 

 

Anforderung, die nicht oder nur mit erheblichem Aufwand umsetzbar istReferenz (z.B. Verordnung (EG) Nr. 1089/2010, Artikel 9, Nr. 1 oder D2.8.I.9 Data Specification on Protected SitesProtected Sites – Technical Guidelines, 5.3.1.4)Konkrete ProblembeschreibungEingebracht von

Durch die Art der Modellierung des Themas Transport Networks kann nicht garantiert werden, dass die INSPIRE-Identifier bei Fortführungen identisch bleiben (wie von Artikel 9 VERORDNUNG (EG) Nr. 1089/2010 gefordert). Außerdem sind die so modellierten Daten in vielen Fällen für eine Nutzung ungeeignet.

D2.8.I.7_v3.2 - Data Specification on Transport Networks - Technical Guidelines, 5.3.2, 5.4.2, 5.6.2, 5.7.2

Im Thema Transport Networks erfolgt eine aus unserer Sicht unangemessene Nutzung des Generic Network Models dergestalt, dass viele eigenständige Features (ohne Geometrie) entstehen, die in vielen Ausgangsdatenbeständen als Attribute zu Objekten geführt werden (z.B. Straßenbreiten, Straßennamen, Spurbreiten von Eisenbahnen etc. etc.). Für diese neu entstehenden Features müssen Inspire-Identifikatoren gebildet werden, und diese müssen bei Fortführungen identisch bleiben. Dies gelingt nur so lange, wie die Attribute im Ausgangsdatenbestand nicht multipel belegt sind.

Nach unserer Auffassung handelt es sich bei diesen Features auch nicht um Geo-Objekte im Sinne der Inspire-Richtlinie.

Außerdem führt diese Form der Modellierung dazu, dass die Daten in gängigen GIS-Systemen nicht ohne Weiteres genutzt werden können, weil zusammengehörende Informationen auf viele Objekte verteilt sind, die nur über Relationen miteinander verbunden sind (z.B. bis zu 10 Objekte für einen Straßenabschnitt). Für die Nutzung müssen die Daten i.d.R. über teilweise themenspezifische Lösungen so verflacht werden, dass aus den Features wieder Attribute werden.

GDI-NW
(Düren)

Die Nutzung des (Meta-)Datentyps "CI_Citation" beim Attribut "legalFoundationDocument" der Objektart "ProtectedSite" bewirkt

  • eine Inkonsistenz zwischen Annex I und Annex III (da für dasselbe Konzept unterschiedliche Datentypen verwendet werden)
  • eine unnötige Aufblähung des Protected Sites Schemas
  • ein Implementierungsproblem, da INSPIRE-konforme Datensätze in der Praxis mit einigen am Markt befindlichen Datenmodelltransformations-Tools an dieser Stelle nicht korrekt generiert werden können
Verordnung (EG) Nr. 1089/2010, Anhang II, Nr. 9.1.1.; D2.8.I.9 Data Specification on Protected SitesProtected Sites – Technical Guidelines 5.3.1.2, 5.3.2s. https://themes.jrc.ec.europa.eu/discussion/view/11598/ps-data-model-regarding-designations#group-repliesGDI-BY (Feichtner)
Die empfohlene hierarchische Layerstruktur im Thema Protected Sites scheint nicht sinnvoll umsetzbar zu sein.

D2.8.I.9 Data Specification on Protected SitesProtected Sites – Technical Guidelines 11.1.1

s. https://themes.jrc.ec.europa.eu/discussion/view/75006/ps-compliant-view-service-layer-naming-styling-and-organisationGDI-BY (Feichtner)
 Eine neu zu erzeugende inspireID (Administrative Boundary) kann nur mit erheblichen Aufwand bei Aktualisierungen – wie gefordert - persistent gehalten werden. D2.8.I.4 Data Specification on Administrative Units – Technical GuidelinesEs ist zu klären, wie die Verwaltungsgrenzen (Administrative Boundary) und insbesondere die persistenten Identifier (inspireID) der Verwaltungsgrenzen erzeugt werden sollen. Das Problem ist, dass die Grenz-Geometrien aus kleineren Fragmenten zusammengesetzt und persistent gehalten werden müssen. GDI-LSA
 99% Verfügbarkeit der GeodatendiensteVerordnung (EG)Nr. 1088/2010, Anhang I 99 % Verfügbarkeit ist nur mit erheblichem finanziellen und personellen Aufwand zu leisten. GDI-LSA
Darstellungsvorgaben (SLDs)Verordnung (EG)Nr. 1088/2010Die Standarddarstellungen für die WMS-Dienste, die in den Datenspezifikationen per SLD definiert sind, sind in vielen Fällen für die praktische Anwendung ungeeignet. So werden z.B. alle Verwaltungseinheiten (Thema AU) oder alle Straßen (Thema TN) ohne Unterscheidungsmöglichkeit identisch dargestellt. Bei anderen Themen gilt Ähnliches. Für die praktische Verwendung der Viewing-Dienste müsste man weitere, zusätzliche Styles definieren. Hiermit kommen allerdings viele GIS-Systeme nicht  klar. Besser wäre es also, die Standard-Styles so zu verbessern, dass eine kartographisch sinnvolle Anzeige erzeugt wird.GDI-NW
(Düren)
Fehlen von Clientsystemen, die mit komplexen Modellen direkt umgehen könnenVerordnung (EG)Nr. 1088/2010Die INSPIRE-Datenmodelle haben einen hohen Komplexitätsgrad. Dies erfordert Erweiterungen für Serversysteme speziell für INSPIRE. Zudem  fehlen Clientsysteme, die mit den komplexen Modellen direkt umgehen können. Die INSPIRE-Implementierung ist mit einem hohem Aufwand bei der Konfigurierung der eigenen Serversysteme verbunden. Serversysteme, die von den Anbietern speziell für INSPIRE weiterentwickelt wurden, stellen meist keine Lösung dar, da häufig der letzte Stand von INSPIRE noch nicht implementiert wurde. Alle Serversysteme nutzen für die interne Datenhaltung eine Datenbankstruktur. Die zugrunde liegenden Mechanismen zur Abbildung der komplexen INSPIRE-Modellierungen sind nur schwer steuerbar; teilweise ist die Umsetzung einzelner Modellaspekte vom Softwareanbieter noch ungelöst. Dies behindert die Abgabe korrekter INSPIRE-GML-Daten durch die Dienste. Bund (BKG)
Komplette und sinnvolle Umsetzung der Ergebnisse der HWRM-RL über INSPIRE-Methoden. Gefordert werden zudem abgestimmte Produkte auf nationaler Ebene.  

D2.8.III.12 Data Specification on Natural Risk Zones – Technical Guidelines

Prinzipiell sollten die Begrifflichkeiten von zentraler Stelle (mindestens national) in die Codelists eingepflegt werden. Beispiel:

Der Fluttyp gemäß HWRM-RL ist ein erstes Klassifikationsmerkmal, dass für eine sinnvolle Interoperabilität wichtig ist: Fluvial, Pluvial, Groundwater, SeaWater, Artifical Water-Bearing Infrastructure, Other

Als Lösung könnte SpecificHazardTypeValue mit den Begriffen aus der HWRM-RL als Katalog (möglichst zentral) bereitgestellt werden.

Solche Maßnahmen erfordern aber eine bessere Abstimmung des INSPIRE-Modells mit der Fachrichtlinie/den ReportingSheets zur Berichtspflicht und erfordern dort eine genauere Definition, welche Objekte wie umzusetzen sind (Beispielfrage: Sind APSFR nach Art. 4 oder 5 oder erst nach Art.6 HazardAreas oder RiskZones, wann sind Punkte, Linien oder Flächen gefragt). Unklare Begrifflichkeiten führen zu vielen Auslegungsmöglichkeiten, die die nationale Abstimmung wieder erschweren.

Es werden Wassertiefenkarten überschwemmter Bereiche gefordert (Tiefenklassen). Eine geeignete Umsetzung über die Attribute magnitudeOrIntensity, levelOrIntensity scheitert technisch an den dann viel zu komplexen Geometrien. Eine Umsetzung als WMTS (bunte transparente Layer) ist sinnvoll möglich- ist aber wohl kein INSPIRE-Standard.

NLWKN

(D. Weber)

 

  • Keine Stichwörter

5 Kommentare

  1. Auch Niedersachsen kann bestätigen, dass die 99%ige Verfügbarkeit der Geodatendienste eine große Hürde ist. Für viele geodatenhaltende Stellen steht der Aufwand im Missverhältnis zum eigenen direkt greifbaren Nutzen.

  2. Das BKG unterstützt die von GDI-NW und GDI-LSA eingebrachten Kommentare bzgl. der inspireId. Dies kann verallgemeinert werden: bei den meisten INSPIRE-Themen gibt es 1:n-Beziehungen (oder auch m:n-Beziehungen) zwischen Objektarten (Feature Types) im Quell- und Zieldatenbestand. Dabei gibt es erhebliche Probleme, die inspireId im abgeleiteten INSPIRE-Datensatz persistent zu halten. Insbesondere da davon auszugehen ist, dass die INSPIRE-Datensätze keine neuen, von der Daten haltenden Stelle zu pflegenden Datensätze darstellen, sondern nur für die INSPIRE-Dienste erzeugt werden.

  3. Das BKG unterstützt den von GDI-LSA eingebrachten Kommentar bzgl. Verfügbarkeit der Geodatendienste. Beim derzeitigen Stand der Implementierung und insbesondere der Nutzung von INSPIRE-Diensten, ist die Anforderung von 99% Verfügbarkeit nicht gerechtfertigt. Diese Anforderung wird zukünftig nur dann Berechtigung erlangen, wenn sich insbesondere die Europäische Kommission zur konsequenten Nutzung von INSPIRE-Diensten verpflichtet.

  4. Das BKG ist am INSPIRE-Fortführungsprozess beteiligt. Frau Dr. Anja Hopfstock leitet das Thematic Cluster „Topographic and Cadastral Reference Data“ (https://themes.jrc.ec.europa.eu/groups/profile/209/topographic-and-cadastral-reference-data). Diese Gruppe hat bereits 2015 konkrete Vorschläge zur Fortführung der entsprechenden Datenspezifikationen gemacht. Dies betrifft offensichtliche Fehler, unzureichende Spezifizierungen sowie schwer implementierbare Anforderungen. Diese Vorschläge sowie die Änderungsvorschläge der anderen Thematic Cluster (https://ies-svn.jrc.ec.europa.eu/projects/thematic-clusters/issues) wurden bisher nicht umgesetzt; voraussichtlich soll dies Teil des Arbeitspakets 2016.1 (INSPIRE Fitness for purpose - Analysis) des INSPIRE Maintenance und Implementation Work Programme (MIWP) werden. Diese Verzögerung trägt nicht zur Stärkung des Vertrauens in den Fortführungsprozess bei. Die Festschreibung von Attributwerten und Codelisten in der Richtlinie erschwert den Fortführungsprozess und sollte daher überdacht werden.

  5. es ist von deutscher Seite bereits mehrfach eingebracht worden (u.a. im REFIT-Prozess), dass die für die elektronische Berichterstattung (Reporting) festgelegten Codelisten zu den Fluttypen bzw. Hochwassertypen (List of flood types) in die INSPIRE-Registry aufgenommen werden sollten, damit diese eu-weit abgestimmten Codes allen zur Verfügung stehen und dort gepflegt werden. Zukünftig sollen auf EU-Ebene die INSPIRE- und Reporting-Aktivitäten besser aufeinander abgestimmt bzw. koordiniert werden (Federführung: Joachim d'Eugenio). Die EUA hat dafür einen Konzeptentwurf und eine Liste mit "priority datasets" für das eReporting erstellt.

    Die MS hatten übrigens sehr stark dafür plädiert, dass die INSPIRE-IR die Umweltfachrichtlinien nicht übersteuern. In der INSPIRE Community kennen sich wenige Personen mit eReporting aus (in den TWG's  gab es kaum Beteiligung seitens "Reporting-Leuten") und in der eReporting-Community mangelt es nach wie vor an INSPIRE-Kenntnissen. Daher ist eine gemeinsame Weiterentwicklung der Grundlagen bzw. "Schnittmengen" immens wichtig. Da die Vorgaben für das Reporting zur HWRM-RL und die Datenspezifikation zu "Natural Risk Zones" zeitlich parallel entwickelt worden sind, wobei letztere für alle Naturgefahren anwendbar sein muss, gibt es aus Sicht der "Reporting Community" erwartungsgemäß einige "shortcomings". Dabei darf nicht vergessen werden, dass die Datenspezifikationen mit dem zu dem Zeitpunkt vorhandenen Wissen erstellt worden sind und noch gar keine Erkenntnisse aus dem Reporting zur HWRM-RL vorgelegen haben. Mittlerweile liegen entsprechende Erkenntnisse vor und es ist geplant, dass die ungelösten Fälle und technischen Fragen in Zusammenarbeit zwischen der INSPIRE-TWG und der WG F subgroup im Rahmen der anstehenden Überarbeitung der Reporting-Vorgaben aufgearbeitet werden.