In der GDI-BE raten wir den datenhaltenden Stellen zur Nutzung von QGIS um den WFS der transformierten Datensätze zu überprüfen. Mit dieser QS (Qualitätssicherung) schließen wir die Transformation ab.

Je nachdem, welche Funktion genutzt wird („WFS / OGC API-Feature“ oder das Plugin sind die Ergebnisse verschieden. Beide wiederum sind anders als die GML-Datei.

Meine Kollegin hat das demonstriert am Beispiel des INSPIRE-Themas AU.

Diese Situation ist misslich und zieht zeitintensive Erläuterungen nach sich.

Unsere Fragen:

  • Ist bekannt, ob an einer Weiterentwicklung der WFS-Client-Funktionalität gearbeitet oder an diese gedacht wird?
  • Ist es ggf. sinnvoll, diese durch die Kst zu beauftragen?   
  • Wie erfolgt die QS durch die datenhaltenden Stellen in anderen GDIn?


4 Kommentare

  1. Dr. Guido Schwichtenberg sagt:

    Renate Zweer ,

    auch wir nutzen QGIS im Rahmen der Qualitätssicherung für die Überprüfung der nach INSPIRE transformierten GML-Dateien und der daraufhin eingerichteten WFS- und WMS-Dienste. In den von uns genutzten QGIS-Versionen funktioniert die QGIS-eigene WFS-Einbindung jedoch nicht für INSPIRE-Dienste; wir nutzen daher ausschließlich das Plugin "WFS 2.0 Client" zum Einbinden von INSPIRE-WFS-Diensten.

    Da die Nutzung von QGIS für die Arbeiten mit INSPIRE-Daten und -Diensten nicht trivial ist und um Personen zu unterstützen, die nicht so regelmäßig QGIS für diese Arbeiten nutzen, habe ich hier im GDI-Wiki die Seite Kurzanleitungen: QGIS für INSPIRE erstellt. Dort können Sie sehen, wie wir QGIS für Arbeiten im Zusammenhang mit INSPIRE nutzen. 

    Angeregt durch Ihre Fragen habe ich  einen weiteren Abschnitt hinzugefügt: Exkurs: Validierung der GML-Dateien von INSPIRE-WFS-2.0-Diensten (und den anzugebenden Ausdruck für das Kartenbezugssystem im Abschnitt davor korrigiert). Auf die dort beschriebene Weise können auch INSPIRE-GML-Dateien aus WFS-2.0-Diensten validiert werden. Komplett identisch sind die Original-GML-Datei und die GML-Datei aus dem WFS damit aber immer noch nicht. Zumindest kann aber gezeigt werden, dass auch die GML-Datei aus dem WFS (wie bereits die Original-GML-Datei) valide ist. Anzumerken ist in diesem Zusammenhang aber noch, dass das Validierungs-Problem von WFS-GML-Dateien vielleicht auch beim Validator liegt und nicht bei der WFS-GML-Datei selbst. Denn so wie ich den Fehlerbericht interpretierte, wurden innerhalb des Validierungsprozesses Links mit falschen namespaces/Namensräumen generiert. die so überhaupt nicht in der WFS-GML-Datei vorkommen.

    1. Renate Zweer sagt:

      Vielen Dank  Dr. Guido Schwichtenberg für Ihre Einschätzung und die ergänzte Anleitung. Es freut mich, im Wiki öfter von Ihnen zu hören.

      Ich bin selbst keine QGIS-Nutzerin, aber vielleicht folge ich mal Ihrer Anleitung, die sehr verständlich wirkt.

      Unsere datenhaltenden Stellen nutzen den Validator in der Regel nicht. (Das macht meine Kollegin, die auch die Transformation durchführt). Die dhS haben daher kein Validierungsproblem. Vielmehr schauen sie durch die QGIS-Anwendung auf ihre transformierten Daten.

      In dem Beispiel meiner Kollegin (INSPIRE AU) fehlte – bei Nutzung des QGIS Plugin - wohl ein Attribut. Ggf. wird sie hier ergänzen.

  2. Dr. Birgit Kieler sagt:

    Vielen Dank Dr. Guido Schwichtenberg für Ihre Hinweise und die Anleitung. Für unsere QS nutzen wir auch das Plugin "WFS 2.0 Client". Speziell der Hinweis auf die Konfiguration des Plugins war nochmal hilfreich. Wir haben bisher den Haken bei "Convert attributes to fields" nicht gesetzt. Durch diese Veränderungen sind nun alle Attribute für folgenden Dienst: https://gdi.berlin.de/services/wfs/au_alkis sichtbar. Der Hinweis zusätzlich "Resolvedepth (WFS) = * " zu setzen, löst bei uns leider eine Fehlermeldung (OWS-Exception) aus, so dass erst gar keine Objekte geladen werden. Vielleicht zur Hintergrundinformation: Wir nutzen Geoserver für die Abgabe unserer Dienste. Evtl. hängt das Problem mit dem Geoserver zusammen.

    Wir haben aber auch die Beobachtung gemacht, dass für WFS-Dienste (z.B. https://gdi.berlin.de/services/wfs/ps_denkmal), mit dem Plugin "WFS 2.0 Client" (unabhängig davon, ob in der Konfiguration Haken gesetzt sind oder nicht) gar keine Objekte zurückgeliefert werden, da es sich um MultiGeometrien handelt. Und das es "mal mit dem Plugin funktioniert" und "mal nicht" ist schwer einem Nutzer zu vermitteln.

  3. Dr. Guido Schwichtenberg sagt:

    Renate Zweer , Dr. Birgit Kieler und für alle anderen Interessierten,

    es gibt sehr gute Neuigkeiten, was die QGIS-Implementierung von WFS im Zusammenhang mit INSPIRE betrifft: Am 13. November 2023 hatte Even Rouault auf github genau solch ein QGIS-Enhancement-Proposal eingestellt: Support for Complex Features in WFS provider · Issue #277 · qgis/QGIS-Enhancement-Proposals · GitHub. Am 15. Januar 2024 hatte er dann bereits einen offiziellen Pull-Request an die QGIS-Entwicklungsversion auf github eingereicht ([WFS provider] Handle documents with Complex Feature schemas (using OGR GMLAS driver), and JSON'ify content of complex properties by rouault · Pull Request #55847 · qgis/QGIS · GitHub).

    Vor zwei Tagen ist die Nachricht eingestellt worden, dass die Testing-Phase erfolgreich beendet wurde. So wie es aussieht, werden wir also eine auch für komplexe Datenmodelle (wie INSPIRE) funktionsfähige WFS-Implementierung mit Version 3.36 von QGIS erhalten!