Bug report #18267
QGIS 3.0 WFS 2.0 not working
|Category:||Web Services clients/WFS|
|Affected QGIS version:||3.0.0||Regression?:||No|
|Operating System:||Easy fix?:||No|
|Pull Request or Patch supplied:||No||Resolution:|
|Crashes QGIS or corrupts data:||No||Copied to github as #:||26158|
Trying to attach WFS 2.0 service with endpoint http://services.cuzk.cz/wfs/inspire-CP-wfs.asp? to QGIS 3.0.
2018-02-28T12:35:03 WARNING Analysis of DescribeFeatureType response failed for url restrictToRequestBBOX='1' srsname='EPSG:5514' typename='cp:CadastralParcel' url='http://services.cuzk.cz/wfs/inspire-CP-wfs.asp?' version='2.0.0' table="" sql=: Cannot find schema root element
Service does not return data. It works properly in 2.14 using WFS 2.0 plugin.
[WFS provider] Handle DescribeFeatureType responses that consist of a single <include> (fixes #18267)
Also handle another occurence of a buggy server only accepting TYPENAMES plural
as parameter of DescribeFeatureType
#4 Updated by Michal Med over 2 years ago
2.18 returns the same:
2018-03-01T14:39:49 1 Analysis of DescribeFeatureType response failed for url restrictToRequestBBOX='1' srsname='EPSG:5514' typename='cp:CadastralBoundary' url='http://services.cuzk.cz/wfs/inspire-cp-wfs.asp?' version='2.0.0' table="" sql=: Cannot find schema root element
#5 Updated by Jeremy Palmer over 2 years ago
Is this provider generating storedQueries or using complex features? If so then it won't work, the QGIS WFS 2.0 provider doesn't support that at the moment, only Simple Feature level 0 schema (e.g relational style table). I understand the WFS 2.0 plugin does support storedQueries
#8 Updated by Michal Med about 2 years ago
Parameter typenames (plural) is required by the OGC service (http://cite.opengeospatial.org/pub/cite/files/edu/wfs/text/operations.html). The rest is correct.
#9 Updated by Even Rouault about 2 years ago
Hum, this is a complete mess...
http://docs.opengeospatial.org/is/09-025r2/09-025r2.html#147 "9.2.3 KVP Encoding" mentions TYPENAME, but "184.108.40.206 typeNames parameter" mention TYPENAMES (and with a remaining occurence of typeName). The XML encoding use TypeName ( in "9.2.2 XML Encoding" and http://schemas.opengis.net/wfs/2.0/wfs.xsd ), but they refer to "typeNames" in "220.127.116.11 typeNames parameter".
The "B.8.2 DescribeFeatureType examples" do mention TYPENAMES, but this is an informative annex.
So it seems that the intent was to switch to plural form but a lot of inconsistency exist everywhere in the spec. It would be wise for server implementations to support both TYPENAME and TYPENAMES given this mess.
The issue has been reported to OGC per http://ogc.standardstracker.org/show_bug.cgi?id=530