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 URL’s 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
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 schema by default. For more on this see: https://knowledge.safe.com/questions/23873/fme-desktop-wont-load-data-from-this-wfs-service.html
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, so this will often reveal errors. Often the errors will reveal which element types are not correctly defined or perhaps reveal 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 try to read a variety of layers when testing - some layers may have bad data and others might be OK. Things to try here are try reading different geometry types, or try to read layers with or without special characters or spaces in the 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 the case is with QGIS, its 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).
- 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 a lot of servers still look for comma delimited even though that is not @FS 2.0 compliant. You can get around both of these problems by including TYPENAMES on 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 requests the layer names without the namespace qualifier, and I suspect it works most likely because the server ends up using the default namespace when none is provided. If you needed a different namespace you could instead hard code it here.
The other problem this helps workaround is that FME encloses layer names in parens as this is what 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 parenthesis - see:
http://docs.opengeospatial.org/is/09-025r2/09-025r2.html#90
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 access FME technical support.
