Ihre Favoritenliste enthält derzeit keine Seiten. Sie fügen dieser Liste Seiten hinzu, indem Sie im Menü Extras der angezeigten Seite Favorit selektieren.
Wie sind externe Nutzer der WFS-Dienste in die Umstellung eingebunden und welche Unterstützung bei der Umstellung erhalten diese?
Bsp. Geologische Dienste: es erfolgt eine enge Abstimmung zur Ablösung der komplexen WFS-Dienste.
Welche Erfahrungen konnten Sie schon mit OGC API Styles machen?
Geobasis.NRW hat OGC API Styles getestet, bitte für weiteren Austausch an Geobasis.NRW wenden.
Könnten diese Styles über die GDI-DE Registry angeboten werden?
Wird in der PG Registry am behandelt.
Ersetzt die persistente ID die INSPIRE-ID in den Datensätzen? ID-Resolver zeigt auf WFS.
INSPIRE-ID bleibt erhalten. Bei der Ablösung von WFS müsste das umgestellt werden.
Warum sind die Codelisten nicht in der GDI-DE Registry abgelegt?
Im Rahmen der Bereitstellung von InVeKoS war es zum damaligen Zeitpunkt einfacher umsetzbar. Damals gab es noch keine Codeliste in der GDI-DE Registry.
Gibt es Erfahrungen mit mehreren Datenquellen, welche kaskadierend in OGC API Features ausgegeben werden sollen?
Daten werden eingesammelt und zentral bereitgestellt. Daher aktuell keine Erfahrungen. Im Client verschiedene Datenquellen integrierbar.
Wie stark werden die OGC API Schnittstellen im Vergleich zu den "alten" Standards (WFS, WMS) genutzt?
Braucht Zeit, Bereitstellung von API Features erst am Anfang, Weg ist aber gut und wird weiter verfolgt.
Bitte einen Link zu den Fehlercodes (Erläuterungen) hier teilen.
Eine Übersicht über die fehlerhaften Metadaten kannhierheruntergeladen werden. Über die "md_id" (= FID des Metadatensatzes) kann die "file_id" (Fehlerbericht aus dem Validator) ermittelt werden. Der Fehlerbericht kann hier heruntergeladen werden:Fehlerberichte zu Datensatz-MetadatenundFehlerberichte zu Dienst-Metadaten. In den Fehlerberichten finden sich detaillierte Erläuterungen zu den Fehlern und Beschreibungen zu den Fehlercodes.
Anzahl Datensätze im Vergleich zu anderen Mitgliedstaaten sehr hoch. Woran liegt das?
Grundsätzlich lässt sich dies durch unterschiedliche Bereitstellungsstrategien der geodatenhaltenden Stellen begründen. Die Anzahl der Datensätze wird auf EU-Ebene nicht mehr diskutiert. Das Augenmerk liegt eher auf der Verbesserung der Zugänglichkeit, Verfügbarkeit und Qualität.
Die Verwendung von Metadatenserien wird schon länger empfohlen, eine Gemeinde - eine Serie; das dürfte die Anzahl schon ein wenig reduzieren; zentrale (nationale) Sammlung und Bereitstellung und dann auch Identifizierung? Bsp: Prioritäre Datensätze für die Umweltberichterstattung sollten eigentlich immer nationale Datensätze sein, so wie sie auch an die EUA gehen, in DE melden aber Bundesbehörden und Länder.
Vergleich der durch das JRC ermittelten Zahlen mit den Zahlen aus dem GDI-DE Monitor? Wie geht es mit dem GDI-DE Monitor weiter?
Die Zahlen weichen an einigen Stellen ab, da die Berechnung durch das JRC teilweise nicht transparent genug ist. Fehler in der Berechnung der Datensatz-Konformität wurde an JRC übermittelt,Ticketist noch offen. Zugang zumGDI-DE Monitorist für alle möglich. Der GDI-DE Monitor soll weiterhin für die Vorbereitung des INSPIRE-Monitoring und die allgemeine Qualitätssicherung in der GDI-DE genutzt werden.
Wie kann die Kontaktstelle das INSPIRE-Monitoring sinnvoll begleiten? Prozess durchgängig machen? Aktuell nicht nachvollziehbar, ob alles angekommen ist.
Im GDI-DE Monitor kann zumindest nachvollzogen werden, ob alle Metadaten im Geodatenkatalog.de angekommen sind.
Fehlerberichte: Was wird von den Kontaktstellen erwartet?
Die Kontaktstellen sollten die Fehlerberichte nutzen, um Fehler zu prüfen und die geodatenhaltenden Stellen aufzufordern, diese zu korrigieren. Für die Fehleranalyse und -behebung können die GDI-DE Testsuite und/oder der INSPIRE Validator genutzt werden.
NRW nutzt zum Qualitätsmanagement den GDI-DE Monitor und ist damit äußerst zufrieden. Unsere Datenbereitsteller in NRW haben nur wenige dokumentierte Mängel und werden von der Kontaktstelle zur Behebung aufgefordert.
Das JRC hat für HB fehlerhafte Datensätze im Monitoring aufgeführt, die weder in der GDI-DE Testsuite noch im GDI-DE Monitor nachvollzogen werden können.
Die EU-Datenräume dienen vor allem zur Nutzung solcher Datensätze, die nicht als Open Data klassifiziert und gewissen Schutzbedarfen unterliegen. Genau dafür wird ja die komplexe Infrastruktur benötigt. Wieso sollen dann HVD - die ja per definitionem open data sind - die Grundlage der EU Datenräume sein?
Aus Sicht der EU-KOM sollen die Datenräume Zugang zu allen Datensätzen ermöglichen und nicht nur zu Datensätzen mit Schutzbedarf. Zumindest wurde das auf diversen Veranstaltungen von der EU-KOM so vertreten.
Gibt es Bsp. für nicht-inspire-relvenate HVDs?
Beispiele für nicht-Inspire-relevante Datensätze: aus der Statistik u.a. Industrieproduktion, Tourismusströme in Europa; aus der Meteorologie u.a. Klimadaten.
Ein wichtiger neuer Punkt für den Umweltbereich wäre noch: "Die Datensätze werden in einer vollständigen und öffentlich zugänglichen Online-Dokumentation beschrieben, aus der zumindest die Datenstruktur und -semantik hervorgeht."
Sind nur die harmonisierten/interoperablen Daten bereitzustellen, oder auch die originären? Die VO bezieht sich ja sehr stark auf die INSPIRE-RL, referenziert zwar die VO 1205/2008 (Metadaten) aber nicht die VO 1089/2010 (Interoperabilität).
Da die HVD-Verordnung nur sehr geringe bis keine Vorgaben hinsichtlich der Harmonisierung der Datensätze macht (es werden lediglich "Schlüsselattribute" festgelegt), sind die Datensätze unabhängig von ihrem Interoperabilitätsgrad bereitzustellen.
Wie könnte die Abstimmung mit der Open-Data-Community erfolgen?
Die Abstimmung könnte über GovData/FITKO angestoßen werden (Ansprechperson ist Peter Kochmann).
Es ging doch auch um Daten von Unternehmen. Wie sind hier die Informationsflüsse?
Die Einbindung der Unternehmen liegt in der Verantwortung des BMWK.
Wie gehen wir mit dem Schlüsselattribut Postalischer Deskriptor im Datensatz Adressen um, der nicht überall in DE open data ist? Wie gehen wir mit dem Schlüsselattribut Zahl der Stockwerke in Gebäude um, da diese Zahl zurzeit nicht Grunddatenbestand im AAA-Modell ist?
Fragestellungen wie diese sollten wir imGDI-DE Wikisammeln, um sie dann in den AKs (bzw. in den Fachgremien wie in diesem Fall in der AdV) zu diskutieren.
Ist das Netzwerk der GDI-DE federführend im Mitgliedstaat für die Umsetzung der HVD-Richtlinie zuständig? Oder gibt es ein Bundesministerium, das die Federführung für Open Data, Weiterverwendung usw. innehat?
Das BMWK vertritt Deutschland im Open Data Committee und ist somit für die Koordinierung der Umsetzung der Open-Data-Richtlinie in Deutschland zuständig.
Wie können wir die Umsetzung der HVD-Verordnung (für raumbezogene Daten) möglichst effizient abstimmen und diesbezügliche Fragestellungen möglichst schnell klären?
@Alle sammeln Fragestellungen im Zusammenhang mit der Umsetzung der HVD-Verordnung im GDI-DE Wiki
@AK-Leitungen sichten die Fragestellungen amim Rahmen des nächsten AK-Leitungstreffens mit Vorsitz LG GDI-DE und stimmen sich bezüglich der Bearbeitung ab
@AKs erarbeiten Vorschläge zur Lösung der offenen Fragen zur Umsetzung der HVD-Verordnung und dokumentieren diese im GDI-DE Wiki bzw. in einer GDI-DE Handlungsempfehlung
Bitte nicht immer behaupten, Deutschland würde die INSPIRE-Richtlinie (nur) für die EU umsetzen, unsere jeweilige Regierung hat der Verabschiedung dieser RL zugestimmt und diese in nationales Recht umgesetzt. Die Behauptung führt nämlich dazu, dass RL so umgesetzt werden, wie sie umgesetzt werden - nicht mit Blick auf den eigenen Nutzen.
Könnt ihr unter Punkt 3 "INSPIRE-Monitoring 2022" auch auf die ermittelten Kennwerte aus Sicht des JRC im Vergleich zur Sicht der GDI-DE eingehen? Eine Übersicht wie hier: Monitoring 2022 - Verlauf würde sehr helfen.
Vielen Dank für die Anregung, Holger Thunig. Wir prüfen, inwieweit wir eine Gegenüberstellung der ermittelten Indikatorwerte vom JRC und dem GDI-DE Monitor in der Präsentation mit berücksichtigen können. Die Seite "Monitoring 2022 - Verlauf" ist eine interne Arbeitsversion für Koordinierungsstelle und Betrieb GDI-DE. D. h. die dortigen Übersichten sind lediglich für die Kommunikation mit dem JRC notwendig und enthalten keine ergänzenden Informationen für die geodatenhaltenden Stellen oder Katalogbetreibenden.
zur Aussage: "Die Anforderungen von INSPIRE können sowohl über WFS als auch über OGC API Features umsetzt werden".
Für die Quell-Datensätze (as is) scheint das richtig zu sein. So wie ich Armin Retterathin seinem Vortrag https://pretalx.com/fossgis2022/talk/T3CNGS/ verstanden habe, können die komplexen INSPIRE-Datenmodelle nicht über OGC API-Features bereitgestellt werden. Vielleicht können wir das abschließend klären.
Beachtet werden sollte aber, dass die Validierung der Daten bis auf Weiteres lediglich in GML möglich ist. Wichtig außerdem (vgl. GeoJSON encoding of INSPIRE Datasets | INSPIRE (europa.eu), Abschnitt Technical limitations): "The GeoJSON format cannot deal with 3D geometries and coverage/raster data, therefore this GP cannot be used for those types of data."
Hierzu gab es im MIG-T Meeting am folgende Informationen:
Für die Verabschiedung des Good Practice Candidate "GeoJSON encoding for INSPIRE Datasets" als Good-Practice-Dokument werden noch weitere Umsetzungsbeispiele benötigt. Bisher liegen lediglich Umsetzungsbeispiele aus Finnland vor, siehe https://github.com/INSPIRE-MIF/gp-geojson-encodings/issues. Also, wenn es Umsetzungsbeispiele aus DE gibt, bitte auf Github dokumentieren!
Beispiele für die Bereitstellung von INSPIRE-Datensätzen im GeoJSON-Format über OGC API Features: https://geo.stat.fi/inspire
Zur Validierung von alternativen Encodings (GeoPackage, GeoJSON): "GeoJSON cannot be validated in the INSPIRE Reference Validator. However, please note that no tests for GeoJSON will be added, in the same way as no tests for GPKG were added. To validate data encoded in an additional encoding, the idea is that you should provide a transformation to/from GML, and then use the Validator to validate the GML encoding of that dataset."
Ich habe mir erlaubt, den Sachverhalt mit Herrn Portele von der Firma interactive instruments zu besprechen. Hier seine Antwort:
OGC API Features hat weder Einschränkungen zur Komplexität der Feature-Schemas noch zu den verwendeten Encodings. Dasselbe gilt für die OGC API Features Good Practice. Es könnte auch das INSPIRE-GML abgeben werden, wenn es denn tatsächlich jemand in der Form haben wollte. Bei den Gebäudemodellen wird ja z.B. auch CityGML abgegeben.
OGC API Features als auch die Good Practice haben Vorgaben bzw. Empfehlungen, wenn GeoJSON verwendet wird, aber keine davon bezieht sich auf die Komplexität des Feature-Schemas.
Bei der Entwicklung der initialen INSPIRE-APIs in NRW in 2020 wurde damals beschlossen, die Abgabe in abgeflachter Form durchzuführen, weil GIS-Clients wie QGIS oder ArcGIS (besser) damit klar kommen.
Da in den Kommentaren auf "INSPIRE-Konformität" Bezug genommen wird: Aus rechtlicher Sicht können die Daten in jeder Form und in jedem Encoding abgegeben werden - solange die Encoding Rule dokumentiert ist. Siehe Artikel 7 der Verordnung. Zum Nachweis der Konformität müssten die in NRW verwendeten Encoding Rules noch formal dokumentiert werden, auch wenn die Abbildung auf die INSPIRE-Anwendungsschemas weitgehend offenkundig sein sollte. Bei den Arbeiten in 2020 hatten wir uns an den Arbeiten an GeoJSON in INSPIRE aus 2017/2018 orientiert (https://github.com/INSPIRE-MIF/2017.2).
Die MIG-T / JRC haben die 2018 eingeschlafene Aktivität für eine GeoJSON-Good-Practice vor ein paar Monaten wieder aktiviert. Siehe https://github.com/INSPIRE-MIF/gp-geojson-encodings. Das wäre für NRW in jedem Fall relevant, vor allem wenn dort Schemas für Themen oder eine Encoding Rule festgelegt werden, die dann implizit auch für NRW relevant würden. Oder wenn NRW sicherstellen will, dass ihre Encodings auch in die GP-Entwicklung eingebracht werden.
Die INSPIRE MIG-T ist bei der Good Practice für GeoPackage den Weg gegangen, dass man zwischen INSPIRE-GeoPackage und INSPIRE-GML konvertieren kann. Rechtlich ist eine Abbildung aus dem in der Verordnung beschriebenen Anwendungsschema in das Zielencoding erforderlich, das GML-Encoding spielt hier keine Rolle. Es geht vermutlich dabei vor allem darum, die Daten auf diese Weise mit dem bestehenden INSPIRE Validator validieren zu können. Diese Vorgehensweise für die Datenbereitsteller wird übertrieben komplex / aufwändig angesehen. Es wäre sicher gut, wenn das bei GeoJSON nicht erforderlich wäre, aber aktuell ist es wohl so geplant. Es wurde bisher von interactive instruments nicht aktiv verfolgt.
Die niederländischen Kollegen von Geonovum haben im Zuge der Umsetzung der Bereitstellung von HVDs über OGC API Features unter Berücksichtigung der Anforderungen des INSPIRE Good-Practice die Weiterentwicklung von Geoserver, Deegree und Pygeoapi beauftragt. Erste Ergebnisse wurden nun in der MIG-T vorgestellt (siehe Präsentation). Eine Aufzeichnung einer weiteren öffentlichen Präsentation der Ergebnisse vom (in englischer Sprache) ist hier abrufbar: https://www.youtube.com/watch?v=xR66SUPh_9I.
Bitte nicht immer behaupten, Deutschland würde die INSPIRE-Richtlinie (nur) für die EU umsetzen, unsere jeweilige Regierung hat der Verabschiedung dieser RL zugestimmt und diese in nationales Recht umgesetzt. Die Behauptung führt nämlich dazu, dass RL so umgesetzt werden, wie sie umgesetzt werden - nicht mit Blick auf den eigenen Nutzen.
und Antworten 
8 Kommentare
Holger Thunig sagt:
Könnt ihr unter Punkt 3 "INSPIRE-Monitoring 2022" auch auf die ermittelten Kennwerte aus Sicht des JRC im Vergleich zur Sicht der GDI-DE eingehen? Eine Übersicht wie hier: Monitoring 2022 - Verlauf würde sehr helfen.
Danke und Grüße
Daniela Witter sagt:
Vielen Dank für die Anregung, Holger Thunig. Wir prüfen, inwieweit wir eine Gegenüberstellung der ermittelten Indikatorwerte vom JRC und dem GDI-DE Monitor in der Präsentation mit berücksichtigen können. Die Seite "Monitoring 2022 - Verlauf" ist eine interne Arbeitsversion für Koordinierungsstelle und Betrieb GDI-DE. D. h. die dortigen Übersichten sind lediglich für die Kommunikation mit dem JRC notwendig und enthalten keine ergänzenden Informationen für die geodatenhaltenden Stellen oder Katalogbetreibenden.
Renate Zweer sagt:
zur Aussage: "Die Anforderungen von INSPIRE können sowohl über WFS als auch über OGC API Features umsetzt werden".
Für die Quell-Datensätze (as is) scheint das richtig zu sein. So wie ich Armin Retterathin seinem Vortrag https://pretalx.com/fossgis2022/talk/T3CNGS/ verstanden habe, können die komplexen INSPIRE-Datenmodelle nicht über OGC API-Features bereitgestellt werden. Vielleicht können wir das abschließend klären.
Dr. Guido Schwichtenberg sagt:
Bei den Best Practices für die OGC API (OGC API – Features as an INSPIRE download service | INSPIRE (europa.eu)) geht es tatsächlich nur um die INSPIRE-Konformität des Dienstes. Damit das ganze Konstrukt (Daten + Dienste) für OGC API INSPIRE-konform ist, muss auch noch der Best Practice Kandidat "GeoJSON encoding for INSPIRE Datasets" (GeoJSON encoding of INSPIRE Datasets | INSPIRE (europa.eu)) als genehmigtes Best-Practice-Verfahren angenommen werden. Hierfür muss es dann für jedes INSPIRE-Schema ein Mapping von INSPIRE-GML zu GeoJSON geben (vgl. GitHub - INSPIRE-MIF/gp-geojson-encodings: Good practice for GeoJSON encodings of INSPIRE datasets).
Beachtet werden sollte aber, dass die Validierung der Daten bis auf Weiteres lediglich in GML möglich ist. Wichtig außerdem (vgl. GeoJSON encoding of INSPIRE Datasets | INSPIRE (europa.eu), Abschnitt Technical limitations): "The GeoJSON format cannot deal with 3D geometries and coverage/raster data, therefore this GP cannot be used for those types of data."
Daniela Witter sagt:
Hierzu gab es im MIG-T Meeting am folgende Informationen:
Renate Zweer sagt:
Ich verstehe. Vielen Dank für die Hinweise an Daniela Hogrebe und Guido Schwichtenberg.
Burkhard Schlegel sagt:
Ich habe mir erlaubt, den Sachverhalt mit Herrn Portele von der Firma interactive instruments zu besprechen. Hier seine Antwort:
Daniela Witter sagt:
Weiterer Nachtrag zum Thema "OGC API Features":
Die niederländischen Kollegen von Geonovum haben im Zuge der Umsetzung der Bereitstellung von HVDs über OGC API Features unter Berücksichtigung der Anforderungen des INSPIRE Good-Practice die Weiterentwicklung von Geoserver, Deegree und Pygeoapi beauftragt. Erste Ergebnisse wurden nun in der MIG-T vorgestellt (siehe Präsentation). Eine Aufzeichnung einer weiteren öffentlichen Präsentation der Ergebnisse vom (in englischer Sprache) ist hier abrufbar: https://www.youtube.com/watch?v=xR66SUPh_9I.