WFS getFeature works incorrectly when using combinations of DWithin and maxFeature
----------------------------------------------------------------------------------
Key: GEOS-3674
URL: http://jira.codehaus.org/browse/GEOS-3674
Project: GeoServer
Issue Type: Bug
Components: WFS
Affects Versions: 1.7.6
Environment: Observed on Tomcat 6, Sun JDK6 and Ubuntu 9.10 with PostGIS on PostgreSQL 8.3.
Reporter: Peter Becker
Assignee: Andrea Aime
We are using the following type of request:
<wfs:GetFeature service="WFS" version="1.1.0"
maxFeatures="1" xmlns:ehmp="http://health-e-waterways.org"
xmlns:wfs="http://www.opengis.net/wfs" xmlns:ogc="http://www.opengis.net/ogc"
xmlns:gml="http://www.opengis.net/gml" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opengis.net/wfs http://schemas.opengis.net/wfs/1.1.0/wfs.xsd">
<wfs:Query typeName="ehmp:estuaries_in_time">
<wfs:PropertyName>ehmp:name</wfs:PropertyName>
<ogc:Filter>
<ogc:And>
<ogc:DWithin>
<ogc:PropertyName>the_geom</ogc:PropertyName>
<gml:Point srsName="http://www.opengis.net/gml/srs/epsg.xml#4326">
<gml:coordinates>153,-27</gml:coordinates>
</gml:Point>
<ogc:Distance units="deg">0.01</ogc:Distance>
</ogc:DWithin>
<ogc:PropertyIsEqualTo>
<ogc:PropertyName>year</ogc:PropertyName>
<ogc:Literal>2009</ogc:Literal>
</ogc:PropertyIsEqualTo>
</ogc:And>
</ogc:Filter>
</wfs:Query>
</wfs:GetFeature>
The problem we observe is that there is exactly one result that can be returned -- if the query matches this result, then it will be returned, otherwise the result set will be empty despite possible matches.
The relevant log output on VERBOSE_LOGGING looks like this:
2009-11-27 13:44:57,766 INFO [geoserver.wfs] -
Request: getFeature
handle = null
service = WFS
version = 1.1.0
baseUrl = http://localhost:8080/geoserver/
providedVersion = 1.1.0
query = [net.opengis.wfs.impl.QueryTypeImpl@anonymised.com (group: null, propertyName: [name], function: null, filter: [[ the_geom dwithin POINT (153 -27), distance: 1.0 ] AND [ year = 2009 ]], sortBy: null, featureVersion: null, handle: null, srsName: null, typeName: [{http://health-e-waterways.org}estuaries_in_time])]
maxFeatures = 1
outputFormat = text/xml; subtype=gml/3.1.1
resultType = results
traverseXlinkDepth = null
traverseXlinkExpiry = null
formatOptions = {}
2009-11-27 13:44:57,770 DEBUG [geotools.xml] - [ class org.geotools.data.jdbc.JDBCFeatureCollection ] is not of type class [Lorg.opengis.feature.simple.SimpleFeature;
2009-11-27 13:44:57,770 WARN [geotools.xml] - org.geotools.data.jdbc.JDBCFeatureCollection@anonymised.com (org.geotools.data.jdbc.JDBCFeatureCollection) is not of type [Lorg.opengis.feature.simple.SimpleFeature;
2009-11-27 13:44:57,770 DEBUG [geotools.xml] - Could not convert org.geotools.data.jdbc.JDBCFeatureCollection@anonymised.com to [Lorg.opengis.feature.simple.SimpleFeature;
2009-11-27 13:44:57,771 DEBUG [data.jdbc] - calling sql builder with filter [ year = 2009 ]
2009-11-27 13:44:57,771 TRACE [geotools.core] - ENTRY 14
2009-11-27 13:44:57,771 DEBUG [geotools.filter] - exporting SQL ComparisonFilter
2009-11-27 13:44:57,771 DEBUG [geotools.filter] - Filter type id is 14
2009-11-27 13:44:57,771 DEBUG [geotools.filter] - Filter type text is =
2009-11-27 13:44:57,771 DEBUG [geotools.filter] - exporting ExpressionAttribute
2009-11-27 13:44:57,771 DEBUG [geotools.filter] - exporting LiteralExpression
2009-11-27 13:44:57,771 DEBUG [geotools.filter] - exporting LiteralExpression
2009-11-27 13:44:57,771 DEBUG [data.jdbc] - sql is SELECT "id", "name", encode(asEWKB("the_geom",'XDR'),'base64') FROM "public"."estuaries_in_time" WHERE "year" = 2009 LIMIT 1
2009-11-27 13:44:57,771 DEBUG [data.jdbc] - SELECT "id", "name", encode(asEWKB("the_geom",'XDR'),'base64') FROM "public"."estuaries_in_time" WHERE "year" = 2009 LIMIT 1
2009-11-27 13:44:57,771 DEBUG [data.jdbc] - About to execute query: SELECT "id", "name", encode(asEWKB("the_geom",'XDR'),'base64') FROM "public"."estuaries_in_time" WHERE "year" = 2009 LIMIT 1
2009-11-27 13:44:57,779 DEBUG [geotools.xml] - _Feature is abstract
If I read this correctly Geoserver queries the database only with the filter on the property, not the geospatial filter. I assume there is additional filtering on the Java side since no wrong results are returned, but the fact the LIMIT is used on the SQL query means that only the first feature that matches the property filter is checked. This causes many false negatives.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira