Inconsistent WFS Filter results between OGR vs. shapelib

[tbonfort]

with 6.4, in msautotest/wxs using

mapserv QUERY_STRING="map=wfs_ogr.map
&SERVICE=WFS
&VERSION=1.0.0
&REQUEST=GetFeature
&TYPENAME=road
&OUTPUTFORMAT=MultiMIDMIF
&FILTER=
<Filter>
 <BBOX>
  <PropertyName>POINT</PropertyName>
  <Box+srsName=%22EPSG:4326%22>
   <coordinates>-65.86,44.56+-65.76,44.68</coordinates>
  </Box>
 </BBOX>
</Filter>"

• using native shapefile access (which is what is used by default in wfs_ogr.map), the query returns 3 features.
• using OGR access (replacing DATA roads by CONNECTIONTYPE OGR CONNECTION "data/roads.shp", the query returns 5 features, which seems to be the correct result given the requested bbox

with master after RFC91 (#4974), the OGR driver returns 0 features, and the native shapefile driver returns 5 features

cc @sdlime

[tbonfort]

using test wfs_200_cite_filter_bbox_world.xml from wfs_200_cite.map, we are also getting inconsistent results, before and after RFC91 merge.

pre-rfc91 (529e26e):

• ogr: 21 features
• shapelib: 0 features

post rfc91:

• ogr: 0 features
• shapelib: 21 features

cc @rouault

[tbonfort]

patch 9f50847 fixes this issue for master post rfc91, both drivers now consistently return 5 features. We cannot call msEvalExpression from inside the OGR nextshape() function as the shapeObj has not yet been created from the OGR geometry. The proposed patch removes the call to msEvalExpression from inside the OGR driver, and lets it get handled by msLayerNextShape(). @sdlime given this fix, I imagine that the call to msEvalExpression inside msLayerNextShape is redundant for drivers that implement native filtering; for performance reasons shouldn't we try to avoid calling it in that case?

[sdlime]

Patch seems ok. You’re correct that avoiding calls to msEvalExpression would be good. There’s a test at the top of that function that could be moved outside I guess (type=MS_STRING, no item).

From: Thomas Bonfort [mailto:notifications@github.com]
Sent: Friday, September 19, 2014 9:45 AM
To: mapserver/mapserver
Cc: Lime, Steve D (MNIT)
Subject: Re: [mapserver] Inconsistent WFS Filter results between OGR vs. shapelib (#4995)

patch 9f508479f50847 fixes this issue for master post rfc91, both drivers now consistently return 5 features. We cannot call msEvalExpression from inside the OGR nextshape() function as the shapeObj has not yet been created from the OGR geometry. The proposed patch removes the call to msEvalExpression from inside the OGR driver, and lets it get handled by msLayerNextShape(). @sdlimehttps://github.com/sdlime given this fix, I imagine that the call to msEvalExpression inside msLayerNextShape is redundant for drivers that implement native filtering; for performance reasons shouldn't we try to avoid calling it in that case?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4995#issuecomment-56186589.

[rouault]

I've merged 9f50847 as well as other fixes, mainly in mapogr.cpp and in mapogcfiltercommon.c as well, that make now all WFS tests pass. See #4999

[sdlime]

Thanks for taking the time Even, I appreciate the help... Steve

---

From: Even Rouault [notifications@github.com]
Sent: Saturday, September 20, 2014 7:04 AM
To: mapserver/mapserver
Cc: Lime, Steve D (MNIT)
Subject: Re: [mapserver] Inconsistent WFS Filter results between OGR vs. shapelib (#4995)

I've merge 9f508479f50847 as well as other fixes, mainly in mapogr.cpp and in mapogcfiltercommon.c as well, that make now all WFS tests pass. See #4999#4999

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4995#issuecomment-56266029.

[sdlime]

These changes are in master, correct? --Steve

[sdlime]

I think this can be safely closed now. --Steve