I´m using Geoserver to query features through WFS in an Web Application with Openlayers as client. The queried layer is using SQL Server as backend storage.

When applying a spatial index to the queried layer in SQL Server, the response of an identify is very inaccurate and lots of features that are not even nearby the identify click are returned. When removing the spatial index in the backend, the identify in the client is accurate and only the clicked feature is returned.

The issue is that Geoserver uses the "Filter()" method of SQL Server when querying the bounds calculated by Openlayers for the area to identify. The "Filter()" method is using the spatial index to determine what features has to be returned. The documentation (http://msdn.microsoft.com/en-us/library/cc645883%28v=sql.105%29.aspx) states, that the "Filter" method is fast, but inaccurate when a spatial index is applied and potentially returns features outside the queried bounds.

Is there a possibilty to maintain a spatial index in the SQL Server table (is necessary for other functions operating on the table) and using STIntersects() instead of "Filter()" to filter the queried features when running an identify through WFS on Geoserver and get accurate results ?

Geoserver is version 2.5.1 and SQL Server is 2008 R2.

  • Could you check the request that the OpenLayers application is sending? Perhaps it is using a BBOX filter. By changing it to Intersects it might lead to slower but accurate search.
    – user30184
    Oct 1, 2014 at 7:31
  • Yes you are correct, Openlayers is sending a BBOX. It is using a clickTolerance when clicking, so that u can click near the feature for an identify (dev.openlayers.org/apidocs/files/OpenLayers/Control/…), but that would be the intended behaviour. The problem is that geoserver returns features that are relatively far away (+/- 250m) instead of the click tolerance of +/- 5 meter.
    – georam
    Oct 1, 2014 at 7:42
  • BBOX means theoretically the same as Intersects but in practice BBOX is doing a quick search from index. Thats fine for viewing a screen full of features because a few extra do not make any harm and generally the faster the better. Intersects should take an accurate path. Capture the OpenLayers query with BBOX and convert it to use Intersects. If the result is what you would like to have you know what to do: modify the application.
    – user30184
    Oct 1, 2014 at 7:52
  • 1
    can you open a JIRA report (jira.codehaus.org/browse/GEOT) on GeoTools (where the issue actually is) - I'm working on SQLServer currently and I'll try to roll this fix in.
    – Ian Turton
    Oct 1, 2014 at 7:53
  • I am not sure if it is a bug. There are clients like uDig which send new GetFeatures with BBOX every time when map is zoomed or panned. But if GeoTools makes BBOX query to SQL Server and filters our extra features with java it might lead to quite fast but still accurate result.
    – user30184
    Oct 1, 2014 at 8:00

1 Answer 1


The fix is defining a filterType parameter in the OpenLayers.Control.GetFeature constructor:

new OpenLayers.Control.GetFeature({
        filterType: OpenLayers.Filter.Spatial.INTERSECTS,

The default filterType is OpenLayers.Filter.Spatial.BBOX that results correctly in an uncertain Filter() query in SQL Server, when a spatial index is set. If no spatial index is set it uses the slower but accurate STIntersects().

By defining the INTERSECTS filterType in Openlayers in the GetFeature constructor, the query in the backend uses STIntersects() in every case (with and without a spatial index) and returns acurate results.

The parameter is not documented in the HTML docs (at least I couldn´t find it), but can be found in the source https://github.com/openlayers/openlayers/blob/release-2.13.1/lib/OpenLayers/Control/GetFeature.js (line 169)

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.