[Geoserver-users] Am I seeing a bug with BBOX processing? Or is my request syntax/coordinate order incorrect? 1.6.5 and 1.7.2

If anyone can enlighten me on a few issues that I’ve been having I would greatly appreciate it!

I have a problem with GetFeature and BBOX with both GeoServer 1.6.5 and 1.7.2.
I’m doing a GetFeature against a line dataset (SDE) with a bounding box filter.
There is no line in the box, but depending on how I ask the question, sometimes I get a nearby line returned.
I’ve tried these combos:

XML with BBOX
XML with Intersects
Both the above in 1.0.0 and 1.1.1

CQL with BBOX
CQL with INTERSECT
Both the above in 1.0.0 and 1.1.1

And adding srsName in there on the Query element sometimes too.

I’m slightly crazy now…:slight_smile:

Everything works except:

XML with BBOX (either 1.0.0 or 1.1.1)
XML with Intersects 1.1.1
CQL with BBOX (either 1.0.0 or 1.1.1)

And I forget exactly WHEN the coordinates need to be flipped (that axis order issue), can someone remind me? (Trying that didn’t help me though).

In all these tests I’m using the order of (east-west coordinate, north-south coordinate) - which is long/lat or the regular math X, Y

For example, against 1.7.2, the XML WFS with Intersects works fine:

Request:

<wfs:GetFeature xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance
xsi:schemaLocation=“http://www.opengis.net/wfs http://giswebservices.massgis.state.ma.us/geoserver/schemas/wfs/1.0.0/WFS-basic.xsd

xmlns:gml=“http://www.opengis.net/gml” xmlns:wfs=“http://www.opengis.net/wfs
xmlns:ogc=“http://www.opengis.net/ogc” service=“WFS” version=“1.0.0”>
<wfs:Query typeName=“massgis:DCR.ROADS_TRAILS_LINE”
xmlns:massgis=“http://massgis.state.ma.us/featuretype”>
ogc:Filter
ogc:Intersects
ogc:PropertyNameSHAPE</ogc:PropertyName>
<gml:Box srsName=“EPSG:26986”>
gml:coord
gml:X107852.29760060333</gml:X>
gml:Y891504.5038015026</gml:Y>
</gml:coord>
gml:coord
gml:X107857.89759757933</gml:X>
gml:Y891510.1037984787</gml:Y>
</gml:coord>
</gml:Box>
</ogc:Intersects>
</ogc:Filter>
</wfs:Query>
</wfs:GetFeature>

Response:

<?xml version="1.0" encoding="UTF-8"?>

<wfs:FeatureCollection xmlns=“http://www.opengis.net/wfs” xmlns:wfs=“http://www.opengis.net/wfs
xmlns:gml=“http://www.opengis.net/gml” xmlns:massgis=“http://massgis.state.ma.us/featuretype
xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance
xsi:schemaLocation=“http://massgis.state.ma.us/featuretype http://localhost:8080/geoserver-1.7.2/wfs?service=WFS&version=1.0.0&request=DescribeFeatureType&typeName=massgis:DCR.ROADS_TRAILS_LINE http://www.opengis.net/wfs http://localhost:8080/geoserver-1.7.2/schemas/wfs/1.0.0/WFS-basic.xsd”>

gml:boundedBy
gml:nullunknown</gml:null>
</gml:boundedBy>
</wfs:FeatureCollection>

No lines are returned, which is correct.

But, if I use WFS XML with BBOX instead of Intersects I get that nearby line returned:

Request:

<wfs:GetFeature xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance
xsi:schemaLocation=“http://www.opengis.net/wfs http://giswebservices.massgis.state.ma.us/geoserver/schemas/wfs/1.0.0/WFS-basic.xsd

xmlns:gml=“http://www.opengis.net/gml” xmlns:wfs=“http://www.opengis.net/wfs
xmlns:ogc=“http://www.opengis.net/ogc” service=“WFS” version=“1.0.0”>
<wfs:Query typeName=“massgis:DCR.ROADS_TRAILS_LINE”
xmlns:massgis=“http://massgis.state.ma.us/featuretype”>
ogc:Filter
ogc:BBOX
ogc:PropertyNameSHAPE</ogc:PropertyName>
gml:Box
gml:coordinates107852.29760060333,891504.5038015026
107857.89759757933,891510.1037984787</gml:coordinates>
</gml:Box>
</ogc:BBOX>
</ogc:Filter>
</wfs:Query>
</wfs:GetFeature>

Response:

<?xml version="1.0" encoding="UTF-8"?>

<wfs:FeatureCollection xmlns=“http://www.opengis.net/wfs” xmlns:wfs=“http://www.opengis.net/wfs
xmlns:gml=“http://www.opengis.net/gml” xmlns:massgis=“http://massgis.state.ma.us/featuretype
xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance
xsi:schemaLocation=“http://massgis.state.ma.us/featuretype http://localhost:8080/geoserver-1.7.2/wfs?service=WFS&version=1.0.0&request=DescribeFeatureType&typeName=massgis:DCR.ROADS_TRAILS_LINE http://www.opengis.net/wfs http://localhost:8080/geoserver-1.7.2/schemas/wfs/1.0.0/WFS-basic.xsd”>

gml:boundedBy
gml:nullunknown</gml:null>
</gml:boundedBy>
gml:featureMember
<massgis:DCR.ROADS_TRAILS_LINE fid=“DCR.ROADS_TRAILS_LINE.6668”>
massgis:TYPETrail</massgis:TYPE>
massgis:ILLEGALNo</massgis:ILLEGAL>
massgis:SURFACENatural</massgis:SURFACE>
massgis:WIDTH0’ - 3’</massgis:WIDTH>
massgis:CONDITIONGood</massgis:CONDITION>
massgis:VEHICACCESNone</massgis:VEHICACCES>
massgis:TRAIL_MARKNone</massgis:TRAIL_MARK>
massgis:COMMENTS </massgis:COMMENTS>
massgis:GPS_DATE6/13/2007</massgis:GPS_DATE>
massgis:GPS_TIME03:44:38pm</massgis:GPS_TIME>
massgis:MAX_PDOP11.1</massgis:MAX_PDOP>
massgis:MAX_HDOP4.6</massgis:MAX_HDOP>
massgis:CORR_TYPEPostprocessed Code</massgis:CORR_TYPE>
massgis:GPS_DATE_12007-06-13T00:00:00.298</massgis:GPS_DATE_1>
massgis:GPS_TIME_103:41:56pm</massgis:GPS_TIME_1>
massgis:AVG_HORZ_P2.1</massgis:AVG_HORZ_P>
massgis:LENGTH0.0</massgis:LENGTH>
massgis:NAME </massgis:NAME>
massgis:SHAPEFILENedit_mttom_line.shp</massgis:SHAPEFILEN>
massgis:OBJECTID0</massgis:OBJECTID>
massgis:GPS_3DLENG0.0</massgis:GPS_3DLENG>
massgis:SHAPE_LENG0.0</massgis:SHAPE_LENG>
massgis:FNODE_0</massgis:FNODE_>
massgis:TNODE_0</massgis:TNODE_>
massgis:LPOLY_0</massgis:LPOLY_>
massgis:RPOLY_0</massgis:RPOLY_>
massgis:PITTS_LINE0</massgis:PITTS_LINE>
massgis:PITTS_LI_10</massgis:PITTS_LI_1>
massgis:RCVR_TYPE </massgis:RCVR_TYPE>
massgis:DATAFILE </massgis:DATAFILE>
massgis:DATA_DICTI </massgis:DATA_DICTI>
massgis:GPS_LENGTH952.0450000000001</massgis:GPS_LENGTH>
massgis:SOURCE </massgis:SOURCE>
massgis:MILES0.0</massgis:MILES>
massgis:METERS0.0</massgis:METERS>
massgis:GIS_LENGTH234.21005434877</massgis:GIS_LENGTH>
massgis:SITE_NAME </massgis:SITE_NAME>
massgis:TEMP </massgis:TEMP>
massgis:UPDATE_STA </massgis:UPDATE_STA>
massgis:AVG_VERT_P0.0</massgis:AVG_VERT_P>
massgis:WORST_VERT0.0</massgis:WORST_VERT>
massgis:WORST_HORZ0.0</massgis:WORST_HORZ>
massgis:LINE_ID0</massgis:LINE_ID>
massgis:UNIQUE_ID6667</massgis:UNIQUE_ID>
massgis:SHAPE
<gml:MultiLineString srsName=“http://www.opengis.net/gml/srs/epsg.xml#26986”>
gml:lineStringMember
gml:LineString
<gml:coordinates xmlns:gml=“http://www.opengis.net/gml” decimal=“.”
cs=“,” ts=" ">107803.8251,891455.1017 107792.872,891461.4426
107780.1849,891477.706 107769.8661,891496.3591
107763.1192,891520.1717 107765.1036,891534.8561
107772.2473,891555.4936 107787.5601,891572.6394
107807.5693,891583.6718 107820.6662,891588.4343
107859.56,891589.2281 107878.9121,891586.6114</gml:coordinates>
</gml:LineString>
</gml:lineStringMember>
</gml:MultiLineString>
</massgis:SHAPE>
</massgis:DCR.ROADS_TRAILS_LINE>
</gml:featureMember>
</wfs:FeatureCollection>

On the CQL side of things - INTERSECT correct (doesn’t return the line)

http://localhost:8080/geoserver-1.7.2/wfs?request=GetFeature&version=1.0.0&service=wfs&typename=massgis:DCR.ROADS_TRAILS_LINE&CQL_FILTER=INTERSECT(SHAPE,POLYGON((107852%20891504,107852%20891510,%20107857%20891510,%20107857%20891504,%20107852%20891504)))

On the CQL side of things - BBOX wrong (does return the line)

http://localhost:8080/geoserver-1.7.2/wfs?request=getfeature&version=1.0.0&service=wfs&typename=massgis:DCR.ROADS_TRAILS_LINE&CQL_FILTER=BBOX(SHAPE,107852,891504,107857,891510)

And this is a separate issue I think - although my WFS XML Intersects above works for 1.0.0 I can’t get it to work for 1.1.0, do I have the syntax wrong?

<wfs:GetFeature xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance
xsi:schemaLocation=“http://www.opengis.net/wfs http://giswebservices.massgis.state.ma.us/geoserver/schemas/wfs/1.1.0/wfs.xsd

xmlns:gml=“http://www.opengis.net/gml” xmlns:wfs=“http://www.opengis.net/wfs
xmlns:ogc=“http://www.opengis.net/ogc” service=“WFS” version=“1.1.0”>
<wfs:Query typeName=“massgis:DCR.ROADS_TRAILS_LINE”
xmlns:massgis=“http://massgis.state.ma.us/featuretype”>
ogc:Filter
ogc:Intersects
ogc:PropertyNameSHAPE</ogc:PropertyName>
<gml:Box srsName=“EPSG:26986”>
gml:coord
gml:X107852.29760060333</gml:X>
gml:Y891504.5038015026</gml:Y>
</gml:coord>
gml:coord
gml:X107857.89759757933</gml:X>
gml:Y891510.1037984787</gml:Y>
</gml:coord>
</gml:Box>
</ogc:Intersects>
</ogc:Filter>
</wfs:Query>
</wfs:GetFeature>

I get a NullPointerExcpetion:

<?xml version="1.0" encoding="UTF-8"?>

<ows:ExceptionReport version=“1.0.0”
xsi:schemaLocation=“http://www.opengis.net/ows http://localhost:8080/geoserver-1.7.2/schemas/ows/1.0.0/owsExceptionReport.xsd

xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance
xmlns:ows=“http://www.opengis.net/ows” xmlns:xml=“http://www.w3.org/XML/1998/namespace”>
<ows:Exception exceptionCode=“NoApplicableCode”>
ows:ExceptionTextjava.lang.NullPointerException null</ows:ExceptionText>
</ows:Exception>
</ows:ExceptionReport>

In the geoserver.log:

2009-02-11 12:59:54,286 ERROR [geoserver.ows] -
java.lang.NullPointerException
at org.geoserver.feature.ReprojectingFilterVisitor.reproject(ReprojectingFilterVisitor.java:324)
at org.geoserver.feature.ReprojectingFilterVisitor$GeometryFilterTransformer.transform(ReprojectingFilterVisitor.java:353)

at org.geoserver.feature.ReprojectingFilterVisitor.visit(ReprojectingFilterVisitor.java:213)
at org.geotools.filter.spatial.IntersectsImpl.accept(IntersectsImpl.java:58)
at org.geoserver.wfs.WFSReprojectionUtil.reprojectFilter(WFSReprojectionUtil.java:93)
at org.geoserver.wfs.WFSReprojectionUtil.normalizeFilterCRS(WFSReprojectionUtil.java:108)
at org.geoserver.wfs.GetFeature.toDataQuery(GetFeature.java:505)
at org.geoserver.wfs.GetFeature.run(GetFeature.java:349)
at org.geoserver.wfs.DefaultWebFeatureService.getFeature(DefaultWebFeatureService.java:134)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:310)
at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)

at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
at org.geoserver.ows.util.EMFLogger.invoke(EMFLogger.java:51)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy15.getFeature(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.geoserver.security.OperationSecurityInterceptor.invoke(OperationSecurityInterceptor.java:41)
at org.geoserver.ows.Dispatcher.execute(Dispatcher.java:582)
at org.geoserver.ows.Dispatcher.handleRequestInternal(Dispatcher.java:211)
at org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:153)
at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)

at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:875)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:809)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571)
at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:511)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)
at org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107)
at org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:178)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229)

at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.geoserver.filters.LoggingFilter.doFilter(LoggingFilter.java:73)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.geoserver.filters.ReverseProxyFilter.doFilter(ReverseProxyFilter.java:163)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.geoserver.filters.GZIPFilter.doFilter(GZIPFilter.java:47)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:868)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:663)

at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Unknown Source)

Freeman, Aleda (EEA) ha scritto:

If anyone can enlighten me on a few issues that I've been having I would greatly appreciate it!

I have a problem with GetFeature and BBOX with both GeoServer 1.6.5 and 1.7.2.
I'm doing a GetFeature against a line dataset (SDE) with a bounding box filter.
There is no line in the box, but depending on how I ask the question, sometimes I get a nearby line returned.
I've tried these combos:

XML with BBOX
XML with Intersects
Both the above in 1.0.0 and 1.1.1

CQL with BBOX
CQL with INTERSECT
Both the above in 1.0.0 and 1.1.1

And adding srsName in there on the Query element sometimes too.

I'm slightly crazy now....:slight_smile:

Everything works except:

XML with BBOX (either 1.0.0 or 1.1.1)
XML with Intersects 1.1.1
CQL with BBOX (either 1.0.0 or 1.1.1)

And I forget exactly WHEN the coordinates need to be flipped (that axis order issue), can someone remind me? (Trying that didn't help me though).

In all these tests I'm using the order of (east-west coordinate, north-south coordinate) - which is long/lat or the regular math X, Y

WFS 1.1 always needs flipped coordinates in case your data is
geographic. But from what I see in your examples, your data is
projected, so there should not be any axis flipping going on.

For the intersects/bbox case above it might be that the filter is
translated in a different native SDE filter, which in turn leads
to different results. I have no SDE knowledge so I cannot help,
probably Gabriel might have some ideas.

As for the CQL ones, hum, curious. One thing I'm noticing is that
the SRS has been attached to the geometry only in the first request,
whilst in all of the others it's missing. Are you making your
request in the same SRS as your native data, or is the bbox expressed
in an srs other than the native one?

And this is a separate issue I think - although my WFS XML Intersects above works for 1.0.0 I can't get it to work for 1.1.0, do I have the syntax wrong?

If you post your request to http://host:port/geoserver/wfs?strict=true
GeoServer itself will tell you if the request has xml validation issues
or not. We don't have validation up by default because many clients
generate slightly broken requests.

I put your request into the validator and it showed a number of issues.
The first one is that "DCR.ROADS_TRAILS_LINE" is not a valid typename,
dots are not permitted by the WFS specification inside the type names.
GeoServer will work with it anyways, but it's not formally correct.

The other issue (the real one) is that gml:Box is not part of GML3,
and you have to make your requests in GML3 with WFS 1.1. If you look
in our sample requests for GeoServer 1.7 you'll see the syntax is
something like this: (taking it from a sample request verbatim, you'll
have to adapt it to your case).

<ogc:BBOX>
         <ogc:PropertyName>the_geom</ogc:PropertyName>
         <gml:Envelope srsName="EPSG:4326">
            <gml:lowerCorner>-75.102613 40.212597</gml:lowerCorner>
            <gml:upperCorner>-72.361859 41.512517</gml:upperCorner>
         </gml:Envelope>
       </ogc:BBOX>

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

I think I've digested the info from Andrea now...Let me see if I've got it straight....

All my data are in 26986. For a WFS GetFeature:
If I want the data back in something OTHER than 26986 then I should provide srsName attribute on the Query tag.
If I want to provide the BBOX in something OTHER than 26986 then I should provide srsName attribute on the Box tag.
Otherwise I can drop all srsName attributes.

Provided coordinates don't need to be flipped unless they're in geographic (4326).

With the correct syntax for 1.1.0 WFS you provided, my 1.1.0 BBOX now works (in the sense that it doesn't produce an error)

<wfs:GetFeature xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot;
   xsi:schemaLocation="http://www.opengis.net/wfs http://giswebservices.massgis.state.ma.us/geoserver/schemas/wfs/1.1.0/wfs.xsd&quot;
   xmlns:gml="http://www.opengis.net/gml&quot; xmlns:wfs="http://www.opengis.net/wfs&quot;
   xmlns:ogc="http://www.opengis.net/ogc&quot; service="WFS" version="1.1.0">
   <wfs:Query typeName="massgis:DCR.ROADS_TRAILS_LINE"
      xmlns:massgis="http://massgis.state.ma.us/featuretype&quot;&gt;
      <ogc:Filter>
         <ogc:BBOX>
            <ogc:PropertyName>SHAPE</ogc:PropertyName>
            <gml:Envelope>
               <gml:lowerCorner>107852.29760060333 891504.5038015026</gml:lowerCorner>
               <gml:upperCorner>107857.89759757933 891510.1037984787</gml:upperCorner>
            </gml:Envelope>
         </ogc:BBOX>
      </ogc:Filter>
   </wfs:Query>
</wfs:GetFeature>

(I realize we don't have valid typeNames. Unfortunately it's too late to change on spots now on that one.)

However, I'm still stuck on why some ways of asking "What's in this box" return features that are not in the box.

For example, the request above returns a (nearby) line feature, but the Intersects version doesn't:

<wfs:GetFeature xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot;
   xsi:schemaLocation="http://www.opengis.net/wfs http://giswebservices.massgis.state.ma.us/geoserver/schemas/wfs/1.1.0/wfs.xsd&quot;
   xmlns:gml="http://www.opengis.net/gml&quot; xmlns:wfs="http://www.opengis.net/wfs&quot;
   xmlns:ogc="http://www.opengis.net/ogc&quot; service="WFS" version="1.1.0">
   <wfs:Query typeName="massgis:DCR.ROADS_TRAILS_LINE"
      xmlns:massgis="http://massgis.state.ma.us/featuretype&quot;&gt;
      <ogc:Filter>
         <ogc:Intersects>
            <ogc:PropertyName>SHAPE</ogc:PropertyName>
            <gml:Envelope>
               <gml:lowerCorner>107852.29760060333 891504.5038015026</gml:lowerCorner>
               <gml:upperCorner>107857.89759757933 891510.1037984787</gml:upperCorner>
            </gml:Envelope>
         </ogc:Intersects>
      </ogc:Filter>
   </wfs:Query>
</wfs:GetFeature>

Whether XML or CQL it seems that BBOX is always the one returning the nearby feature.
Version of GeoServer doesn't matter (1.6.5 vs. 1.7.2)
Whether the data is SDE or SHP doesn't matter.
The dataset that I try doesn't matter.

What I seem to find is that I get back features whose envelopes intersect (overlap with) the box I'm supplying.
So with my tiny box, any features that curve around it (but aren't IN it) are returned.
Is this what should be happening? I thought that with Filter BBOX I was asking for features inside the box.
I went back to the OGC Filter specification but I can't figure out if I'm misunderstanding.
But this example: http://geoserver.org/display/GEOSDOC/5-+WFS seems to concur - select features within bbox.

I decided to try Within for variety.

<wfs:GetFeature xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot;
   xsi:schemaLocation="http://www.opengis.net/wfs http://giswebservices.massgis.state.ma.us/geoserver/schemas/wfs/1.1.0/wfs.xsd&quot;
   xmlns:gml="http://www.opengis.net/gml&quot; xmlns:wfs="http://www.opengis.net/wfs&quot;
   xmlns:ogc="http://www.opengis.net/ogc&quot; service="WFS" version="1.1.0">
   <wfs:Query typeName="massgis:DCR.ROADS_TRAILS_LINE"
      xmlns:massgis="http://massgis.state.ma.us/featuretype&quot;&gt;
      <ogc:Filter>
         <ogc:Within>
            <ogc:PropertyName>SHAPE</ogc:PropertyName>
            <gml:Envelope>
               <gml:lowerCorner>107852.29760060333 891504.5038015026</gml:lowerCorner>
               <gml:upperCorner>107857.89759757933 891510.1037984787</gml:upperCorner>
            </gml:Envelope>
         </ogc:Within>
      </ogc:Filter>
   </wfs:Query>
</wfs:GetFeature>

Within doesn't return features, which makes sense to me.

For now I just had my user use Intersects so he'll get what he expects.

Freeman, Aleda (EEA) wrote:

I think I've digested the info from Andrea now...Let me see if I've got it straight....

All my data are in 26986. For a WFS GetFeature: If I want the data back in something OTHER than 26986 then I should provide srsName attribute on the Query tag.
If I want to provide the BBOX in something OTHER than 26986 then I should provide srsName attribute on the Box tag. Otherwise I can drop all srsName attributes.

Provided coordinates don't need to be flipped unless they're in geographic (4326).

With the correct syntax for 1.1.0 WFS you provided, my 1.1.0 BBOX now works (in the sense that it doesn't produce an error)

<wfs:GetFeature xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot;
   xsi:schemaLocation="http://www.opengis.net/wfs http://giswebservices.massgis.state.ma.us/geoserver/schemas/wfs/1.1.0/wfs.xsd&quot;
   xmlns:gml="http://www.opengis.net/gml&quot; xmlns:wfs="http://www.opengis.net/wfs&quot;
   xmlns:ogc="http://www.opengis.net/ogc&quot; service="WFS" version="1.1.0">
   <wfs:Query typeName="massgis:DCR.ROADS_TRAILS_LINE"
      xmlns:massgis="http://massgis.state.ma.us/featuretype&quot;&gt;
      <ogc:Filter>
         <ogc:BBOX>
            <ogc:PropertyName>SHAPE</ogc:PropertyName>
            <gml:Envelope>
               <gml:lowerCorner>107852.29760060333 891504.5038015026</gml:lowerCorner>
               <gml:upperCorner>107857.89759757933 891510.1037984787</gml:upperCorner>
            </gml:Envelope>
         </ogc:BBOX>
      </ogc:Filter>
   </wfs:Query>
</wfs:GetFeature>

(I realize we don't have valid typeNames. Unfortunately it's too late to change on spots now on that one.)

However, I'm still stuck on why some ways of asking "What's in this box" return features that are not in the box.

For example, the request above returns a (nearby) line feature, but the Intersects version doesn't:

<wfs:GetFeature xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot;
   xsi:schemaLocation="http://www.opengis.net/wfs http://giswebservices.massgis.state.ma.us/geoserver/schemas/wfs/1.1.0/wfs.xsd&quot;
   xmlns:gml="http://www.opengis.net/gml&quot; xmlns:wfs="http://www.opengis.net/wfs&quot;
   xmlns:ogc="http://www.opengis.net/ogc&quot; service="WFS" version="1.1.0">
   <wfs:Query typeName="massgis:DCR.ROADS_TRAILS_LINE"
      xmlns:massgis="http://massgis.state.ma.us/featuretype&quot;&gt;
      <ogc:Filter>
         <ogc:Intersects>
            <ogc:PropertyName>SHAPE</ogc:PropertyName>
            <gml:Envelope>
               <gml:lowerCorner>107852.29760060333 891504.5038015026</gml:lowerCorner>
               <gml:upperCorner>107857.89759757933 891510.1037984787</gml:upperCorner>
            </gml:Envelope>
         </ogc:Intersects>
      </ogc:Filter>
   </wfs:Query>
</wfs:GetFeature>

Whether XML or CQL it seems that BBOX is always the one returning the nearby feature. Version of GeoServer doesn't matter (1.6.5 vs. 1.7.2)
Whether the data is SDE or SHP doesn't matter.
The dataset that I try doesn't matter.

What I seem to find is that I get back features whose envelopes intersect (overlap with) the box I'm supplying. So with my tiny box, any features that curve around it (but aren't IN it) are returned. Is this what should be happening? I thought that with Filter BBOX I was asking for features inside the box. I went back to the OGC Filter specification but I can't figure out if I'm misunderstanding. But this example: http://geoserver.org/display/GEOSDOC/5-+WFS seems to concur - select features within bbox.

Yeah, you're right, BBOX by spec should only be a shortcut syntax for intersects. For performance reasons, it's not :slight_smile:

Basically in WMS we use bbox filters to extract the features, and that
has to run very fast, so BBOX is implemented in most datastores as
a envelope vs envelope comparison as opposed to a real intersection.

Ideally, we'd have to add a hint into wms queries so that the datastore
use the "fast" version only in that case, but we don't have that much right now.
What we have in some datastores (postgis) is the "fast bbox" paramer
that allows the user to choose how the bbox is executed (loose and fast
vs slow and correct), but that is global, independent of how the request
is executed.

If you want it so that only WMS does the fast version please open
a jira issue, if we have enough demand or find someone interested
in sponsoring it, we'd be able to work on it.

Cheers
Andrea

If BBOX wants to do a fast envelope calculation that's fine with me.
I'll just make a note of it so I remember and let the users know.
I'm glad there was an easy explanation.