0

A browser's (Chrome) DescribeFeatureType request to GeoServer version 2.12 returns an inline XML response in the browser's window.

Using that same browser to send a DescribeFeatureType request to a GeoServer version 2.14, the response is a document that is downloaded to the Windows' Downloads directory with the filename geoserver-describefeaturetype.application. This document contains the same XML content as the inline XML response when requesting from GeoServer version 2.12.

Coincidently, QGIS is not able to resolve the DescribeFeatureType request to the GeoServer version 2.14 but does resolve the DescribeFeatureType request from GeoServer 2.12.

We don't see any settings in GeoServer to modify how it responds to DescribeFeatureType requests.

Interestingly, a browser's GetCapabilities request to both versions of GeoServer yields an inline XML response from GeoServer.

The DescribeFeatureType request is in the form https://myserver.com/geoserver/mynamespace/wfs?request=DescribeFeatureType

and the GetCapabilities request is in the form

https://myserver.com/geoserver/mynamespace/wfs?request=GetCapabilities

Most importantly, we want to get the WFS connection from QGIS to GeoServer version 2.14 working. But we also want the inline response to a DescribeFeatureType request.

Any suggestions?

3
  • I have no problem in using GeoServer 2.16 with QGIS 3.11. Please clarify how it appears that your QGIS can't read DescribeFeatureType from your server. – user30184 Jan 15 '20 at 8:46
  • You might be thinking about this the wrong way around. It's unlikely that GeoServer is giving different responses to the same request from different sources (unless you've tied it down with some security, but you've not mentioned that), it's much more likely that actual requests are different somehow. – nmtoken Jan 18 '20 at 13:23
  • The other possibility is the response is the same, and Qgis can't parse it. This can happen with complex feature WFS – nmtoken Jan 19 '20 at 12:35
2

A GetCapabilities request must include the service type, so https://myserver.com/geoserver/mynamespace/wfs?request=GetCapabilities is not correct, it should be:

https://myserver.com/geoserver/mynamespace/wfs?request=GetCapabilities&service=WFS

This will give an XML result in your browser.

Similarly, a DescribeFeatureType request must include the service parameter and version, and ideally type to be described (otherwise you get all types), so should be something like:

https://myserver.com/geoserver/mynamespace/wfs?request=DescribeFeatureType&service=WFS&version=2.0.0&typename=your_type_name&

You can also add an output format depending on what's listed in the GetCapabilities response for your version of service.

For QGIS you just specify the service URL (without any WFS request parameters) so just:

https://myserver.com/geoserver/mynamespace/wfs?

QGIS will (should) add appropriate WFS request parameters.

If QGIS (or any other client) can read the GetCapabilities response, but then fails in other operations you should check whether URLs in the GetCapabilities response are as expected. There's no requirement for all advertised URLs to be the same, though it's common.


Note

typename vs. typenames in WFS requests

In a WFS 2.0.0 service the specification tells us to use typename for DescribeFeatureType request but typenames for GetFeature

11
  • Or you can use the global service from myserver.com/geoserver/wfs? – user30184 Jan 15 '20 at 8:48
  • Thanks, @nmtoken. I should have included the 'service=wfs` and version=2.0.0 in my post to avoid confusion. GeoServer fills in with default values if they are not present. The results are identical regardless if I explicitly include them in the URL or not - I still receive a document in my Downloads directory than inline within the browser window. Same with DescribeFeatureType. I agree with how the QGIS URL should be supplied - I already did that. I can see the layers, but when I double click on one of them to set a filter, I get the "DescribeFeatureType failed" message. – slalomchip Jan 16 '20 at 1:42
  • @user30184 - We have Global Services enabled in GeoServer. I'm not an admin of the server and I don't quite understand what you mean by "use the global service from ...". Can you clarify? – slalomchip Jan 16 '20 at 1:45
  • Global services are those which are not accessed by including the workspace part in the URL. localhost://geoserver/wfs is global while localhost://geoserver/topp/wfs, the URL model that was used in the answer, is pointing to a virtual service in the GeoServer vocubulary docs.geoserver.org/master/en/user/data/webadmin/workspaces.html. Versions 2.14 and 2.16 work for me with QGIS so the problem is not generally in the new version. Unfortunately I can't say why it fails for you. – user30184 Jan 16 '20 at 6:56
  • @slalomchip I've answered keeping the OGC specification in mind and the answer is applicable to any WFS not just one supplied by GeoServer, I know that GeoServer is lax in following the standards, but really as we're talking about basic operations of a WFS, let's keep to the standard. Note the standard tells us it must be service=WFS& and not per GeoServer documentation service=wfs&. If the response in the browser to the WFS DescribeFeatureType is a download, then you have the wrong mime type, try outputformat=text/xml;%20subtype=gml/2.1.2& assuming it's supported. – nmtoken Jan 16 '20 at 8:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.