qgisinspiretools / qgis-wfs20-client-plugin

QGIS Plugin for OGC Web Feature Service 2.0.0
11 stars 8 forks source link

Reference-Resolving verhindert das Laden der Daten #25

Open JuergenWeichand opened 2 years ago

JuergenWeichand commented 2 years ago

@ejn

Folgende Beobachtung in meinem Fall. QGIS v3.14.16 in Verbindung mit WFS Client 2.0 v0.9.11 und GDAL/OGR 3.0.4.

Mit https://github.com/qgisinspiretools/qgis-wfs20-client-plugin/commit/3e9662f8ade13c8b5df904b9c2f7c155f4d822d4 wurde das Reference-Resolving auf den Modus GML_SKIP_RESOLVE_ELEMS=HUGE umgestellt.

Das führt in meinem Fall zu einem fehlerhaften Ergebnis. Hierzu die Beispieldateien.

Die Datei erzeugt mit GML_SKIP_RESOLVE_ELEMS=NONE kann geladen werden. Die Datei erzeugt mit GML_SKIP_RESOLVE_ELEMS=HUGE nicht.

Bei HUGE entsteht zudem ein vollig änderer GML-Container ResolvedTopoFeatureCollection mit ungültigem XML. Beispielsweise mit XML-Tags in dieser Form: <gemeindezugehoerigkeit|AX_Gemeindekennzeichen|land>05</gemeindezugehoerigkeit|AX_Gemeindekennzeichen|land>.

wfs-responses.zip

ejn commented 2 years ago

Vielleicht ist es notwendig, alle drei Optionen (ALL/HUGE/NONE) anzubieten - die Umstellung auf HUGE war als Ergebnis von #19 durchgeführt, und sollte angeblich keine Nachteile haben. Wenn es mit HUGE nicht klappt, aber mit NONE schon deutet das gefühlt auf einem Problem in GDAL. @JuergenWeichand: Hast Du die Möglichkeit, mit einer neueren GDAL-Version zu testen?

JuergenWeichand commented 2 years ago

QGIS 3.22.3 ; WFS Client 2.0 v0.9.11; GDAL/OGR 3.4.1

Grundsätzlich das gleiche verhalten wie oben beschrieben, außer dass die Ebene AX_Flurstueck aus dem GML-Container ResolvedTopoFeatureCollection geladen wird.

ejn commented 1 year ago

I've added the ability to choose the setting for GML_SKIP_RESOLVE_ELEMS via the settings UI. Please test #27 (try both settings HUGE and NONE). I can't think of any other easy solution at the minute, as I find the behaviour of GDAL/OGR with HUGE rather strange - from #19 there didn't appear to be any problems with using HUGE and so in at least some circumstances it would appear to be appropriate. Maybe internally something from the NAS reader is (wrongly) being used, as your examples are AAA-based?

I have the feeling that the OGR/GDAL-documentation for GML_SKIP_RESOLVE_ELEMS may be incomplete, as the "following further configuration option" is not described.