Inconsistent WFS Filter results between OGR vs. shapelib #4995

Closed
tbonfort opened this Issue Sep 17, 2014 · 7 comments

Comments

Projects
None yet
3 participants
@tbonfort
Member

tbonfort commented Sep 17, 2014

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

This comment has been minimized.

Show comment
Hide comment
@tbonfort

tbonfort Sep 18, 2014

Member

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

Member

tbonfort commented Sep 18, 2014

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

This comment has been minimized.

Show comment
Hide comment
@tbonfort

tbonfort Sep 19, 2014

Member

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?

Member

tbonfort commented Sep 19, 2014

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

This comment has been minimized.

Show comment
Hide comment
@sdlime

sdlime Sep 19, 2014

Member

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/mapserver/mapserver/issues/4995#issuecomment-56186589.

Member

sdlime commented Sep 19, 2014

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/mapserver/mapserver/issues/4995#issuecomment-56186589.

@rouault

This comment has been minimized.

Show comment
Hide comment
@rouault

rouault Sep 20, 2014

Contributor

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

Contributor

rouault commented Sep 20, 2014

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

This comment has been minimized.

Show comment
Hide comment
@sdlime

sdlime Sep 20, 2014

Member

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/mapserver/mapserver/issues/4995#issuecomment-56266029.

Member

sdlime commented Sep 20, 2014

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/mapserver/mapserver/issues/4995#issuecomment-56266029.

@sdlime

This comment has been minimized.

Show comment
Hide comment
@sdlime

sdlime Feb 4, 2015

Member

These changes are in master, correct? --Steve

Member

sdlime commented Feb 4, 2015

These changes are in master, correct? --Steve

@sdlime

This comment has been minimized.

Show comment
Hide comment
@sdlime

sdlime Feb 12, 2015

Member

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

Member

sdlime commented Feb 12, 2015

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

@sdlime sdlime closed this Feb 12, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment