We currently experiment with the gdal java bindings to receive data from a WFS service.

Regarding the WFS specification a FeatureType must define its default coordinate system (Tag DefaultCRS).

We have the requirement that the WFS features of a FeatureType must be requested in different coordinate systems according to the WFS capabilities.

We have figured out the following things:

  • the GetSpatialRef() method of the Layer class always only returns the default crs of a FeatureType from the capabilities
  • the request that is generated for a GetFeature request with a bounding box filter is missing the srsName attribute in the envelope tag. According to the WFS specification it is then assumed that the coordinates are defined in the default crs.
  • we have tried to set the spatial filter using an instance of the Geometry class with a specific spatial reference system, but it is not considered in the request

This leads to the assumption that the WFS vector driver only considers the default crs of WFS services. Is that correct?

1 Answer 1


The short answer is that it is possible by adding a supported srsName to the WFS server URL that GDAL is using ...srsName=EPSG:3857or srsName=urn:ogc:def:crs:EPSG::3857 if that is what the WFS server prefers.

This seems to be undocumented in https://gdal.org/drivers/vector/wfs.html, but by reading the source code https://github.com/OSGeo/gdal/tree/master/ogr/ogrsf_frmts/wfs and making some experiments it looks like both the nativeCRS and any CRS listed as otherCRS can be used.

Steps for making the test:

Read getCapabilities for seeing what srsNames are supported. Then make a request with the default one

ogrinfo WFS:"http://localhost:8080/geoserver/wfs?service=WFS&version=2.0.0" topp:states --debug on

and then with some other srsName

ogrinfo WFS:"http://localhost:8080/geoserver/wfs?service=WFS&version=2.0.0&srsname=EPSG:3857" topp:states --debug on

In the latter case the debug info shows that the defined srsName is really used in the request:

GDAL: GDALOpen(/vsicurl_streaming/http://localhost:8080/geoserver/wfs?SERVICE=WFS&VERSION=2.0.0&srsname=EPSG:3857&REQUEST=GetFeature&TYPENAMES=topp:states&COUNT=1000000, this=000002E6CD1F0A60) succeeds as GML.

By the documentation there is some coordinate system support for filters https://gdal.org/drivers/vector/wfs.html#filtering.

  • This applies to the implementation in C++. According to the Javadoc for the Layer-Class methods SetSpatialFilter & SetSpatialFilterRect, the coordinates or geometry must be defined in the coordinate system as returned by the Layer-Class method GetSpatialRef layer. According to our analyses, this is always the default CRS from the capabilities. This means that the Java bindings are only able to request features in the default coordinate system defined in the capabilities. can anyone confirm this? Commented May 23 at 8:04
  • If you use WFS URL that includes "srsName" with different supported CRSs, does it affect what you get from GetSpatialRef?
    – user30184
    Commented May 23 at 8:20
  • which specific URL is meant? Commented May 24 at 6:46
  • I guess that you are doing something similar than in this (skipped) test github.com/OSGeo/gdal/blob/master/autotest/ogr/ogr_wfs.py#L88. I mean the URL that you use in ogr.Open. The test is skipped because the test service has disappeared. There are also examples about how to use XML filters, including srsName for the filter geometry.
    – user30184
    Commented May 24 at 7:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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