WFS getfeature request with diffent SRS

Question

I'm having problems with a WFS getFeature request. I'm using openlayers with an OSM map as baselayers which use the google projection. Overlaying the layer with WMS works perfect. When I do a request to return all features within the bounds of a polygon, no features are found.

My layer uses EPSG:28992. the base layer uses: EPSG:900913

My layer config in geoserver:

When I set the declared SRS to EPSG:900913 and set "SRS handling" to "Reproject native to declared" it works fine, but I need openlayers to repoject it, not geoserver.

Below is an example request I would do. I think the problem is that geoserver does not convert the spatial filter to the native SRS.

http://mydomain.com/wfs?request=GetFeature&version=1.1.0&
srsName=epsg:28992&
typeName=Namespace:Layer1&
propertyName=(*)&
CQL_FILTER=year = 2011 and INTERSECTS(geometry,POLYGON((565585.61613069 6816272.786200799,565585.61613069 6817032.3791692,564362.62367835 6817032.3791692,564362.62367835 6816272.786200799,565585.61613069 6816272.786200799)))&
outputFormat=GMl2

Update

I just tried re-projecting some points from openlayers (EPSG:900913) via proj4js to EPSG:28992 (POSTGRESQL & Geoserver). I took 3 points and compared them. They all showed an offset.

1. Converted: POINT(233492,24349424947 582191,0681508556)

   In Database: POINT(233530,852147064 582315,680920578)

   Difference x: 38,60865281453 Difference y: 124,6127697224

2. Converted: POINT(133459,1980658749 455770,7481867363)

   In Database: POINT(133486,356985081 455879,67223342)

   Difference x: 27,1589192061 Difference y: 108,9240466837

3. Converted: POINT(176920,43262818802 317930,36182729155)

   In Database: POINT(176954,154083767 318023,515324756)

   Difference x: 33,72145557898 Difference y: 93,15349746445

If the offset was constant I could correct it. Now I'm not sure if the offset is caused by geoserver or by proj4js. I'm guessing proj4js since the wms layer does not show any offset.

Answer 1

Check you have the correct projection parameters for Rijksdriehoeksstelsel. For long, proj4 has had some parameters missing, causing a slight shift. Full story can be found below:

http://oegeo.wordpress.com/2008/05/20/note-to-self-the-one-and-only-rd-projection-string/

Furthermore, you may have to overwrite the projection of your base layer to EPSG:3857 which is the official code for Spherical Mercator. EPSG:900913 has been deprecated some time ago. More info:

http://docs.openlayers.org/library/spherical_mercator.html#sphericalmercator-and-epsg-aliases

Answer 2

There are two possibilities here - to reproject on the server use WFS 1.1 and set the required SRS in the request to 900913 (i.e. ask GeoServer to do the reprojection on the fly) or tell the client how to do the reprojection by including the relevant projection information from proj4js in your openlayers code.

The first option will be quicker and easier.

UPDATE

Reading your question again more carefully the issue is probably one of a mismatch between your filter's polygon's projection and your database/geoserver. You will need to reproject the polygon to 28992 as I don't think that GeoServer will do that reprojection for you. It would be worth checking the docs as I think it may be supported for WFS 1.1 requests that use OGC filters instead of CQL filters.

Answer 3

I encountered the same problem for native SRS' before (similarly used some Dutch reference systems) but had not have time to figure out if its %100 geoserver's fault. Probably it is. It seems like it is not re-projecting to the declared SRS.

Now I looked for if the support is available and it looks like it is supported in Geotools version 2.4.1 (so I would look for a Geoserver that uses geotools 2.4.1+) : http://jira.codehaus.org/browse/GEOT-1511

And in this tutorial it says

Current versions of GeoServer have support for EPSG:900913 built in, so there is no need to add additional projection data. Simply add your GeoServer layer as a WMS and add it to the map.

Current versions is a bit vague term there and it is stated for WMS but should not be different for WFS I assume (though assumptions are dangerous).

However, I don't know your use case but I would opt for keep re-projecting with Openlayers because in theory you can not rely on the OGC service where you might have not control of it.