Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Reference-Resolving verhindert das Laden der Daten #25

Open
JuergenWeichand opened this issue Feb 1, 2022 · 3 comments
Open

Reference-Resolving verhindert das Laden der Daten #25

JuergenWeichand opened this issue Feb 1, 2022 · 3 comments
Labels
bug

Comments

@JuergenWeichand
Copy link
Collaborator

@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 3e9662f 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
@JuergenWeichand JuergenWeichand mentioned this issue Feb 1, 2022
Closed
@ejn
Copy link
Contributor

ejn commented Feb 2, 2022

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
Copy link
Collaborator Author

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 added a commit to ejn/qgis-wfs20-client-plugin that referenced this issue Aug 3, 2022
@ejn
feature: Enable user-side configuration of xlink:href resolving
d332291 
 * Due to qgisinspiretools#19 the GDAL-configuration GML_SKIP_RESOLVE_ELEMS was set to HUGE
   when the user requests resolving of xlink:href (previously NONE).
 * This change is presumably the reason for problems reported resolving in qgisinspiretools#25.
 * Since probably not everyone will be satisified with one or other of the
   options then the user should be able to choose which to use once
   resolving of xlink:href is activated, thus removing the need for the devloper
   to decide which option to use and passing this decision to the user.
 * The default GML_SKIP_RESOLVE_ELEMS is maintained as HUGE.
@ejn ejn mentioned this issue Aug 3, 2022
Open
@ejn
Copy link
Contributor

ejn commented Aug 3, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@ejn @JuergenWeichand