MapServer as WFS 1.1.0 client: Not suitable

21.03.2012 – 12:17 am

Last weeks I was playing with MapServer and it’s support for WFS 1.1.0 client. MapServer is great peace of software, which does everything I ever needed. However, it looks like WFS 1.1.0 client implementation is at the edge of interest of the MapServer developers. Conclusion for MapServer, acting as WFS 1.1.0 client is: MapServer is not suitable, as WFS 1.1.0 client. The reasons follow:

1. MapServer generates poor URL in the GET request

MapServer, while making the GetFeature request, does not specify

  • SRSNAME parameter – name of SRS, in which the resulting data should be
  • BBOX parameter leaks on SRS specification – server can not be sure, in which SRS given coordinates are

Those are crucial parameters, when requesting data from WFS 1.1.0 in non-default coordinate reference system.

2. MapServer does not respect coordinates order in the GET request

For some SRSs, coordinates order should respect the order in the SRS, e.g. WGS84, declared as urn:ogc:epsg::4326 should be given in north, east order. This should be applied in the BBOX parameter of the GetFeature type of request.

3. MapServer is not aware of coordinates order of returned data

When formulating proper request (with proper coordinates order in the BBOX request and propper SRSNAME parameter), for some coordiante systems, data are returned from the server with north,east axis order. MapServer can not handle this, it does not recognize, that the data are “somewhere else”.

Those three problems, I have hopefully solved. However, it was not enough. Following two issues are not solvable for now, I have no idea how to approach:

4. MapServer is not able to respect SRS encoding in the request

According to WFS specification, there are three ways of SRS encoding specification:

  • EPSG: EPSG_code — coordinates are NOT “swaped”
  • — no idea, weather the coordinates should or should not be swapped
  • urn:EPSG:geographicCRC:epsg_code — coordinates should be swaped

MapServer uses the last form – always, but some servers are using the first form of SRS encoding. Currently, it is not possible to force MapServer, to give propper SRS encoding to the server and expect propper coordinate order. As said, I have no idea, how to make things working here – I know, where it should go, but dunno how to do that.

5. GDAL seems to be unable to handle some coordinate systems

Reading GML data, we can pass GML_INVERT_AXIS_ORDER_IF_LAT_LONG and GML_CONSIDER_EPSG_AS_URN configuration options, which will make GDAL (or OGR) know, that it should consider axis order of the data based on their SRS. This works well for EPSG:4326, but does not for other coordinate systems, such as EPSG:3035. Reason is EPSGTreatAsLatLong() function, which is not suitable for this purpose. There is already motion in GDAL about this issue, and patch available, but still, it is not at least in trunk.

Result is: propper data will come to MapServer. MapServer tries to read the data with help of OGR, but OGR does not recognize, that axis order is north, east and everything fails.


Do not try to use MapServer as WFS 1.1.0 client. Use mapscript and for configuration of mapserver, downloading the data and convering them to some suitable SRS.


I love MapServer and MapScript. It is powerful combination and till now, I have done everything with it, including displaying various strange types of input data. Last time, I was programming in C, it was, when I was working at GRASS, nevertheless, I have tried with my limited skills to fix those issues in MapServer, so it is able to work as propper WFS 1.1.0 client. But this went too far. I’m not able to do it and this blog post expresses all my frustration from last weeks. If anybody want’s to make WFS 1.1.0 work within MapServer with all it’s axis-order-issues for various servers, I’m ready to help with testing, having list of various WFS servers by hand. Till then, I have to imlement this “by hand” somehow.

Share Button

Post a Comment