Troubleshooting WFS Errors

Introduction

When you have a problem reading WFS, the problem often seems to be on the WFS Server side. In FME, the error is often “XML Module Halted on Error”.

To determine if the problem is on the server side, try reading the WFS dataset with the FME Data Inspector or FME Workbench. A number of URL’s will be logged in the log file. Each of these URLs can be double-clicked or copied and pasted into a web browser to see if valid XML is returned. If not, or an error is returned in the browser, the problem is likely on the WFS server end.

Steps-by-step Instructions

1. Check the Get Capabilities document. In the log file, this is described by the line starting with "<WFS> Capabilities URL".

e.g. Capabilities URL: ' http://webservices.ionicsoft.com:80/unData/wfs/UN?SERVICE=WFS&REQUEST=GetCapabilities&VERSION=1.1.0' 

2. Check the Describe Feature URL. In the log file this is described by the line starting with "<WFS> DescribeFeatureType URL".

e.g. <WFS> DescribeFeatureType URL:
'http://webservices.ionicsoft.com:80/unData/wfs/UN?SERVICE=WFS&VERSION=1%2E0%2E0&REQUEST=DescribeFeatureType&TYPENAME=wfs%3AAIR%5FPOINT'

3. Check the Get Feature URL. In the log file this is described by the line starting with "<WFS> GetFeature URL".

e.g. GetFeature URL: ' http://webservices.ionicsoft.com:80/unData/wfs/UN?SERVICE=WFS&VERSION=1%2E0%2E0&REQUEST=GetFeature&TYPENAME=wfs%3AAIR%5FPOINT&MAXFEATURES=30000' 

4. If there is an obvious problem in the application schema (xsd), then you can try locating or creating a static (correct) xsd and select it for the "Application Schema" parameter on the WFS reader. You should also try the 'Ignore Application Schema' option. This will eliminate problems related to app schema, such as bad DescribeFeatureType responses from the server or mismatched namespaces. This causes our reader to behave like more tolerant clients, such as QGIS, which tend to ignore the schema by default. For more on this see this old community post: FME desktop won't load data from wfs service.

5. Save the WFS DescribeFeatureType application schema and GetFeature GML responses locally. Use XMLValidator to validate the WFS GetFeature GML response against the DescribeFeatureType application schema response. Many WFS servers generate data that doesn't actually conform to their own application schemas, which often reveals errors. Often, errors reveal which element types are not correctly defined or problems with certain geometry types.

6. Once you have the GetFeature GML, you can try reading it locally with the GML reader.

Other Considerations

• Depending on the WFS server, sometimes single layers can be read when multiple layers cannot. Also, make sure you read a variety of layers when testing - some may have bad data, while others might be OK. Things to try here are to read different geometry types and to read layers with or without special characters or spaces in their names. Occasionally, individual features might be bad, so you could try reading a few features at a time using Max Features = 100, for example. You can also try using 'Prefer POST' instead of the default GET mode.
• Something that is not necessarily a problem but worth watching out for. An OGC service can appear to be working, but if its hard coded for a particular client/server combo (QQIS to QGIS, or ESRI to ESRI), then its not necessarily obeying the standard but could be using some proprietary profile of the standard, even if, as is the case with QGIS, it's an open source tool. To test this, try different client/server combinations - access to more than one WFS client can be useful. Also, look for custom namespace paths in the server responses (QGIS, etc.). See the XMLValidator tests above (5).
• Some Servers require a bounding box for them to return a valid result. Sometimes there is a default extent that doesn't really make sense for the selected data layer. Using a bounding box can sometimes reset the extents or cause the spatial reference to be updated correctly. This can be an issue for WMS as well.

• A little-known feature of FME's WFS reader can help with potential workarounds. If you add a WFS parameter to your WFS dataset URL, that parameter typically overrides the parameter values of the same name in following requests normally generated by FME from defaults or from the GUI. For example, by adding TYPENAMES to the dataset URL, it effectively overrides the TYPENAMES value that would normally be generated. FME generates a GetFeature request with the namespace prefixes from the GetCapabilities, such as ns1:Roads, ns2:Highways, etc.

  One common problem can be namespace mismatches between the GetCapabilities, DescribeFeatureType, and GetFeature responses. Another problem is how multiple-layer selections are defined. The spec dictates parenthesis notation, but many servers still look for comma-delimited data, even though that is not @FS 2.0-compliant. You can address both problems by including TYPENAMES in the dataset URL.

  So you might get an error such as:

  "ns1:ExceptionText The specified TypeNames does not exist:{(ns1}Roads)(ns2:Highways)</ns2:ExceptionText>"

  To get around this, simply add the TYPENAMES syntax you want to your WFS dataset URL:

  wfs_server_url?SERVICE=WFS&TYPENAMES=Roads,Highways

  What this does is just request the layer names without the namespace qualifier, and I suspect it works because the server uses the default namespace when none is provided. If you needed a different namespace, you could hard-code it here instead.

  The other problem this helps work around is that FME encloses layer names in parentheses, as the WFS 2.0 standard dictates. WFS1.1 and earlier used commas, but this is no longer supported within 2.0 unless there is a join query provided. So the default for a layer list should be with parentheses - see the Open Geospatial Consortium documentation.

  So, by defining the TYPENAMES list on the dataset URL, we can include commas that may be required by your particular WFS and avoid the standard 2.0 parenthesis syntax. Just don't forget to make sure your layer selection parameter matches what you put in the URL.

If you still have problems, please contact FME Support