Investigate support issues for WFS from QGIS Server

[tchaddad]

Report on mailing list for problems connecting to a WFS service coming from QGIS Server:
https://lists.osgeo.org/pipermail/geomoose-users/2025-April/007177.html

Discussed at the May PSC meeting, with further tests / follow-up to come

[brentfraser]

Have a look at comments in pull #787

[klassenjs]

It looks like QGIS Server is using qgs as the namespace for field names (<qgs:geometry> and <qgs:ogc_fid>). Doesn't need a namespace on layer names (it is just the layer_name not something like ms:layer_name)

Supports WFS 1.0.0 and 1.1.0.
Supports GML v2.1.2 and 3.1.1.

And is representing EPSG:4269 and 4326 in lon,lat order (with WFS 1.1.0 and GML 3.1.1).

[klassenjs]

For type="wfs" this is throwing about getCode():

gm3/src/gm3/components/map/layers/wfs.js

Line 148 in 02e4566

srsName: queryProjection.getCode(),

It looks like queryProjection is a string "EPSG:3857", not a proj object in this case:

gm3/src/gm3/components/map/layers/wfs.js

Line 105 in 02e4566

let queryProjection = mapProjection;

[klassenjs]

Then it looks like it is also assuming that the typename always has a namespace, which is causing featureTypes to be null.

gm3/src/gm3/components/map/layers/wfs.js

Lines 144 to 150 in 02e4566

	const typename = getTypeName(mapSource);
	const typeParts = typename.split(":");
	const formatOptions = {
	srsName: queryProjection.getCode(),
	featurePrefix: typeParts[0],
	featureTypes: [typeParts[1]],

[klassenjs]

And QGIS WFS Server also appears to need wgs84Hack=true. Which makes me wonder if the non-EPSG:4326 call is formatted correctly.

[lfilak7]

In our case wgs84Hack should already be true.
We use map-source, type="mapserver-wfs" instead of type="wfs" to bypass the getCode() error.
QGIS Server responses include complaints for "RequestNotWellFormed" due to "TypeName 'ms:layer_name'" on the initial WFS Get request.
However, the later WFS Post requests are working and returning EPSG:4326 results with lon,lat coordinates.

[klassenjs]

That's because type="mapserver-wfs" is meant to be specific to MapServer. It is not expected to work with other WFS servers.

Ideally, mapserver-wfs and mapserver-wms would go away and just use the standard wfs and wms connection types. They mostly exist to ease migration from older GeoMoose versions which were more directly tied to MapServer and make the MapServer map= parameter easier to deal with. There are better, more secure, ways to do that now (especially with MapServer 8+). mapserver-wfs also was a place where some MapServer specific hacks landed.

[tchaddad]

And I think for @lfilak7, the point here is that we are not going to try to encourage use of, or fix a (QGIS-Server) hack of a (MapServer) hack for wfs.

Instead, the pull request referenced by @klassenjs above (#902) puts the QGIS-Server-related hacks in a <mapsource type='qgis-wfs'> type for now, which is still a hack, but at least it is specific to the QGIS-Server issues, and more recognizable for the users of that server.