[Geoserver-devel] [JIRA] (GEOS-7075) JSON matched features count bug with spatial filter

GeoServer GeoServer Developer
1

Paul Biskup created an issue

GeoServer / BugGEOS-7075

JSON matched features count bug with spatial filter

Issue Type:

BugBug

Assignee:

Unassigned

Created:

17/Jun/15 10:30 AM

Priority:

LowLow

Reporter:

Paul Biskup

Original Estimate:

2 hours

Remaining Estimate:

2 hours

There is a bug for the GeoJSON-outputformat which turns up, when a spatial filter is applied to the request and the requested projection is different from the base projection of the layer. I have come across this problem when using the oracle datastore extension. The problem is that the requested geometry won’t be transformed to the base projection of the layer and as a result of this a wrong select statement will be executed towards the database.

This can also causes slow response times from the database.

Example:

  • I have a layer with a geometry in EPSG:31467 (using the oracle datastore and the ‚JSON‘- outputformat in the map).
  • The base projection of my map-application is EPSG:4326

When I move the map a WFSGetFeature request is made for the current BBOX requesting the features in EPSG:4326 and the JSON-outputformat. Example-request:

<wfs:GetFeature xmlns:wfs=“http://www.opengis.net/wfs” service=“WFS” version=“1.1.0” outputFormat=“JSON” maxFeatures=“1000” xsi:schemaLocation=“http://www.opengis.net/wfs http://schemas.opengis.net/wfs/1.1.0/wfs.xsd” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”>

<wfs:Query typeName=“feature:DEMOKUNDEN” srsName=“EPSG:4326” xmlns:feature=“http://demoworkspace.de”>

<ogc:Filter xmlns:ogc=“http://www.opengis.net/ogc”>

<ogc:Intersects>

<ogc:PropertyName></ogc:PropertyName>

<gml:Polygon xmlns:gml=“http://www.opengis.net/gml” srsName=“EPSG:4326”>

<gml:exterior>

<gml:LinearRing>

<gml:posList>9.167425632478405 48.68678218271719 9.354193210576744 48.68678218271719 9.354193210576744 48.76650087897634 9.167425632478405 48.76650087897634 9.167425632478405 48.68678218271719</gml:posList>

</gml:LinearRing>

</gml:exterior>

</gml:Polygon>

</ogc:Intersects>

</ogc:Filter>

</wfs:Query>

</wfs:GetFeature>

The „totalFeatures“-value of the response is „0“, but there are features which are present in the returned JSON-Object:

{“type”:“FeatureCollection”,“totalFeatures”:0,“features”:[{“type”:“Feature”,“id”:“DEMOKUNDEN.894677”,“geometry”:{“type”:“Point”,…

Taking a look at the logs, while debugging this request (GEOTOOLS_DEVELOPER_LOGGING.properties), shows that the requested geometry will not be transformed to the base projection of the layer:

2014-10-30 12:10:05,870 DEBUG [org.geotools.jdbc] - SELECT count FROM OSS_OWNER.DEMOKUNDEN WHERE SDO_RELATE(GEOM, ?, ‘mask=anyinteract querytype=WINDOW’) = ‘TRUE’

2014-10-30 12:10:05,870 DEBUG [org.geotools.data.oracle.sdo] - Using layer SRID: 31467

2014-10-30 12:10:05,870 DEBUG [org.geotools.jdbc] - Setting parameter 1 as MDSYS.SDO_GEOMETRY(2003,31467,NULL,MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,3),MDSYS.SDO_ORDINATE_ARRAY(9.167425632478405,48.68678218271719,9.354193210576744,48.76650087897634))

2014-10-30 12:10:05,870 DEBUG [org.geotools.jdbc] - 1 = POLYGON ((9.167425632478405 48.68678218271719, 9.354193210576744 48.68678218271719, 9.354193210576744 48.76650087897634, 9.167425632478405 48.76650087897634, 9.167425632478405 48.68678218271719))

This request is made in line 433 in the function „getFeatureCountFromWFS11Request“ (org.geoserver.wfs.json.GeoJSONGetFeatureResponse):

count = source.getCount(countQuery);

When getting the features for the result, the geometry is correctly transformed:

2014-10-30 12:10:05,886 DEBUG [org.geotools.jdbc] - SELECT * FROM (SELECT PK,POSTLEITZAHL,KUNDENBINDUNG,ORT,SUMMEANGEBOTSPOTENTIAL,VERTRIEBSMITARBEITER,KURZNAME,STRASSE,HAUSNUMMER,GESCHAEFTSBEZIEHUNG,SUMMEANGEBOTSWERTE,UMSATZSTAFFEL,CL_WIRTSCHAFTSZWEIG,GEOM as GEOM,DESKTOP_LINK FROM OSS_OWNER.DEMOKUNDEN WHERE SDO_RELATE(GEOM, ?, ‘mask=anyinteract querytype=WINDOW’) = ‘TRUE’ ) WHERE ROWNUM <= 1000

2014-10-30 12:10:05,886 TRACE [org.geotools.data.oracle.sdo] - ordinates D:2

2014-10-30 12:10:05,886 TRACE [org.geotools.data.oracle.sdo] - ordinates L:0

2014-10-30 12:10:05,901 DEBUG [org.geotools.data.oracle.sdo] - Using layer SRID: 31467

2014-10-30 12:10:05,901 DEBUG [org.geotools.jdbc] - Setting parameter 1 as MDSYS.SDO_GEOMETRY(2003,31467,NULL,MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,1),MDSYS.SDO_ORDINATE_ARRAY(3512403.4538142183,5394367.242787822,3526155.116889829,5394414.403470575,3526113.836093776,5403279.503751489,3512383.892407218,5403232.360018856,3512403.4538142183,5394367.242787822))

2014-10-30 12:10:05,901 DEBUG [org.geotools.jdbc] - 1 = POLYGON ((3512403.4538142183 5394367.242787822, 3526155.116889829 5394414.403470575, 3526113.836093776 5403279.503751489, 3512383.892407218 5403232.360018856, 3512403.4538142183 5394367.242787822))

We can fix it by uncommenting this part " count = source.getCount(countQuery);" and always go for the “Query gtQuery”:

//count = source.getCount(countQuery);
//if (count == -1)

{ // information was not available in the header! org.geotools.data.Query gtQuery = new org.geotools.data.Query(countQuery); FeatureCollection<? extends FeatureType, ? extends Feature> features = source .getFeatures(gtQuery); count = features.size(); }

totalCount +=count;
//}

Should I create a patch for this?

Best regards,
Paul

Add Comment

Add Comment

This message was sent by Atlassian JIRA (v6.5-OD-05-041#65001-sha1:e07c9f6)

Atlassian logo