Bug report #18267
QGIS 3.0 WFS 2.0 not working
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Normal | ||
| Assignee: |  Even Rouault | ||
| 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 |
Description
Trying to attach WFS 2.0 service with endpoint http://services.cuzk.cz/wfs/inspire-CP-wfs.asp? to QGIS 3.0.
Output:
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.
Associated revisions
[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
History
#1
Updated by Giovanni Manghi over 6 years ago
- Status changed from Open to Feedback
- Easy fix? changed from Yes to No
What about 2.18 selecting the proper WFS version?
#2
Updated by Michal Med over 6 years ago
Never tried 2.18, I was using 2.14, the installed 3.0. I thought that WFS 2.0.0 support was added in QGIS 3.0.
#3
Updated by Giovanni Manghi over 6 years ago
Michal Med wrote:
Never tried 2.18, I was using 2.14, the installed 3.0. I thought that WFS 2.0.0 support was added in QGIS 3.0.
then please test also 2.18, as is the new LTR.
#4
Updated by Michal Med over 6 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 6 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
#6
Updated by Even Rouault over 6 years ago
- Assignee set to Even Rouault
Two main issues here:
- buggy server that expects TYPENAMES plural as DescribeFeatureType parameter
- once corrected, the schema returned consists of a single <include schemaLocation="..."/> that we didn't follow yet
#7
Updated by Even Rouault over 6 years ago
- Status changed from Feedback to Closed
- % Done changed from 0 to 100
Applied in changeset qgis|1d2686d0dcaca20f00392ee3dd8dc4bc404fd8d0.
#8
Updated by Michal Med over 6 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 over 6 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 "9.3.4.1 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 "9.3.4.1 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
#10
Updated by Michal Med over 6 years ago
I'll upgrade the server to accept both singular and plural. The single <include schemaCollection="..."/> is going to be supported in a near future?