Bug report #18882: Attempting to add layer using site-wide WFS get capabilities URL in QGIS 3 errors out - QGIS Application - QGIS Issue Tracking

Bug report #18882

Attempting to add layer using site-wide WFS get capabilities URL in QGIS 3 errors out

Added by Ian Harrison over 6 years ago. Updated over 6 years ago.

Status:	Closed
Priority:	Normal
Assignee:	Even Rouault
Category:	Web Services clients/WFS
Affected QGIS version:	3.1(master)	Regression?:	No
Operating System:	Windows 7	Easy fix?:	No
Pull Request or Patch supplied:	No	Resolution:	fixed/implemented
Crashes QGIS or corrupts data:	No	Copied to github as #:	26714

Description

Attempted to add a WFS layer using a site-wide get capabilites: https://data.linz.govt.nz/services;key=API_KEY/wfs?service=WFS&request=GetCapabilities
The layer listing is returned successfully but highlighting a layer and clicking Add gives the error:
"Layer is not valid : The layer srsname='EPSG:4326' typename='data.linz.govt.nz:layer-50842' url='https://data.linz.govt.nz/services;key=API_KEY/wfs' version='auto' table="" sql= is not a valid layer and can not be added to the map. Reason: "
Adding the same layer using the layer specific get capabilities url works.
(Note: I have removed my API KEY from the urls above.)

Associated revisions

Revision 7511d1ff
Added by Even Rouault over 6 years ago

Revert "[bugfix][wfs] Expand support for 2.0.0 TYPENAMES" (fixes #18882)

This reverts partially commit ccb4c80f8a6d2bb179258f1ffec0dc9a447ca465.

The plural form of TYPENAMES is non conformant for the DescribeFeatureType
request of WFS 2.0
The logic of ccb4c80f8a6d2bb179258f1ffec0dc9a447ca465 breaks conformant
servers because they ignore the TYPENAMES parameter and thus return a
DescribeFeatureType response covering all layers of the service, which can
be extremely time consuming.

Changes related to better geometry handling have been kept.

Revision 2330b7fc
Added by Even Rouault over 6 years ago

[WFS provider] Handle buggy servers that require plural form TYPENAMES for DescribeFeatureType (fixes #18882, refs #17872)

Some servers like http://geoportal.samregion.ru/wfs12 return an
error when issuing a REQUEST=DescribeFeatureType&VERSION=2.0.0&TYPENAME=...
query, which is the conformant way
They expect the plural form TYPENAMES to be passed
As they return an exception when being provided with the singular form,
we can automate the retry with TYPENAMES.

Revision 839de2e2
Added by Even Rouault over 6 years ago

Merge pull request #7057 from rouault/fix_18882_alternate

[WFS provider] Revert to using singular TYPENAME keyword for WFS 2.0 DescribeFeatureType (fixes #18882, refs #17872)

History

#1 Updated by Nyall Dawson over 6 years ago

Status changed from Open to Feedback

Seems to get stuck on requesting

https://data.linz.govt.nz/services;key=KEY/wfs?SERVICE=WFS&REQUEST=DescribeFeatureType&VERSION=2.0.0&TYPENAMES=data.linz.govt.nz:layer-50764

Trying to retrieve this url outside of QGIS also times out.

Maybe an issue on the server?

#2 Updated by Jeremy Palmer over 6 years ago

When you change TYPENAMES to TYPENAME it return straight away.

I think the commit is the reason why it works in 2.18 and not 3.0: ccb4c80f8a6d2bb179258f1ffec0dc9a447ca465

#3 Updated by Jeremy Palmer over 6 years ago

Not this server is using geoserver in the backend as they implement TYPENAME. So I assume TYPENAMES is getting ignored, and it's trying to fetch the schemas for all types in the services, which is why it is timing out. This thread seems to discuss the issue further: http://osgeo-org.1560.x6.nabble.com/WFS-2-0-DescribeType-opertation-typeName-or-typeNames-td5323127.html and it might be that QGIS needs to go back to TYPENAME, or makes some guesses if it's a geoserver instance or not.

However, this services doesn't state that it's Geoserver, in headers or in the GetCapabilities document. The HTTP header does however say "Server: Koordinates"