Opened 17 years ago

Last modified 14 years ago

#2306 reopened defect

WFS filter contains with a BBOX in lat/long returned null

Reported by: nsavard Owned by: assefa
Priority: high Milestone: 6.0 release
Component: WFS Server Version: unspecified
Severity: normal Keywords:
Cc: jkemp101

Description

When I issue a GetFeature with a bbox in lat/long the server returns null. I tested with 5.0-rc2 on Linux. The feature returned should be "Quebec, Iles de la Madeleine". See msautotest.

QUERY_STRING="map=[MAPFILE]&SERVICE=WFS&VERSION=1.0.0& REQUEST=GetFeature&TYPENAME=province&FILTER=<Filter> <Contains><PropertyName>Geometry</PropertyName> <gml:Polygon><gml:outerBoundaryIs><gml:LinearRing> <gml:coordinates>-61.99,47.35 -61.95,47.35 -61.95,47.38 -61.99,47.38</gml:coordinates></gml:LinearRing> </gml:outerBoundaryIs></gml:Polygon></Contains></Filter>"

Change History (19)

comment:1 by assefa, 16 years ago

Milestone: 5.2 release
Owner: changed from mapserverbugs to assefa
Status: newassigned

updated files in msautotest in r7709. Works locally on windows.

Norm if you got a minute, can you run the msautotest

comment:2 by nsavard, 16 years ago

Assefa: Is it possible that you forgot to commit your changes in the map file for this request? I cannot see it in r7709.

comment:3 by tomkralidis, 16 years ago

FYI I'm still getting msautotest errors on this one too.

comment:4 by assefa, 16 years ago

I added a new wfs_filter_contains.xml. For some reason the original one was using EPSG:4269 and coordinates values were in meter.

I did not check/modify the coordinates used for querying in the test.

What is the error: empty result or diffrent feature found? weird It seems to pass on my test

comment:5 by tomkralidis, 16 years ago

Result is:

<?xml version='1.0' encoding="ISO-8859-1" ?>
<wfs:FeatureCollection
   xmlns:ms="http://mapserver.gis.umn.edu/mapserver"
   xmlns:wfs="http://www.opengis.net/wfs"
   xmlns:gml="http://www.opengis.net/gml"
   xmlns:ogc="http://www.opengis.net/ogc"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.opengis.net/wfs http://ogc.dmsolutions.ca/wfs/1.0.0/WFS-basic.xsd 
                       http://mapserver.gis.umn.edu/mapserver http://localhost/path/to/wfs_simple?SERVICE=WFS&amp;VERSION=1.0.0&amp;REQUEST=DescribeFeatureType&amp;TYPENAME
=province&amp;OUTPUTFORMAT=XMLSCHEMA">
   <gml:boundedBy>
      <gml:null>missing</gml:null>
   </gml:boundedBy>
</wfs:FeatureCollection>

comment:6 by tomkralidis, 16 years ago

Any update on this one?

comment:7 by assefa, 16 years ago

committed fix in r7737.

msautotest updated.

please test and we will close.

comment:8 by tomkralidis, 16 years ago

Works. You can close.

comment:9 by assefa, 16 years ago

Resolution: fixed
Status: assignedclosed

Thx. closing.

comment:10 by jkemp101, 15 years ago

Cc: jkemp101 added
Milestone: 5.2 release5.2.1 release
Resolution: fixed
Status: closedreopened

I believe this change has broken the behavior of a Contains filter. Based on JTS documentation Contains and Within should be the converse of each other. However, as now coded these two operations function the same in Mapserver's WFS implementation. There is no way to search for features that contain the specified geometry in the filter. I am not sure exactly which one this should be (I vote for Contains) but I know it should be either Contains or Within.

comment:11 by jkemp101, 15 years ago

Priority: normalhigh

I also just confirmed with GeoServer. In GeoServer a Contains filter will return features that contain the specified geometry in the filter statement.

comment:12 by assefa, 15 years ago

Tom,

Is it possible to verify the meaning on the wfs list before I revert the change?

If that is confirmed:

  • I will revert the change
  • do a new test case in the msautotest.

comment:13 by tomkralidis, 15 years ago

An initial response from wfs-dev:

Hi Tom,

You're right. There is no real difference (other than which object is containing versus being within)

i.e. if "A contains B" is true, then "B within A" is true.

The iso 19125 standard (that this comes from) states that 'Contains' is just defined for user convenience.

Regards
Dominic


On Thursday 11 December 2008 12:26:52 Kralidis,Tom [Ontario] wrote:
> Hi: can anyone elaborate on the difference between Contains and Within 
> functions.  In looking at 05-134, section 7.2.19.1, it appears that 
> they both return TRUE if one feature is completely contained in another.
>
> Thanks
>
> ..Tom

comment:14 by assefa, 15 years ago

mmm confused :) from the wfs filter perspective, when we use the CONTAIN filter, does this mean find all features that are contained in this shape OR find all features that contain this shape ?

in reply to:  14 comment:15 by tomkralidis, 15 years ago

Replying to assefa:

mmm confused :) from the wfs filter perspective, when we use the CONTAIN filter, does this mean find all features that are contained in this shape OR find all features that contain this shape ?

From http://portal.opengeospatial.org/files/?artifact_id=13228 :

Contains(g1 Geometry, g2 Geometry) : Integer

The return type is Integer, with a return value of 1 for TRUE, 0 for FALSE, and –1 for UNKNOWN corresponding to a function invocation on NULL arguments; convenience predicate: TRUE if g2 is completely contained in g1

comment:16 by assefa, 15 years ago

I am still not sure that I get your answer. I understand the function Contains (and it is also the way it is defined in Mapserver msGEOSContains.

jkemp101 made the point that we interpret it wrongly in MapServer (at least based on what Geoserver is doing)

I am leaning toward reverting the change back and assuming that the test case that prompted this bug was initially wrong. Do you see any problem changing the code back?

comment:17 by nsavard, 15 years ago

I am also interested by this clarification.

in reply to:  16 comment:18 by tomkralidis, 15 years ago

Replying to assefa:

I am still not sure that I get your answer. I understand the function Contains (and it is also the way it is defined in Mapserver msGEOSContains.

jkemp101 made the point that we interpret it wrongly in MapServer (at least based on what Geoserver is doing)

I am leaning toward reverting the change back and assuming that the test case that prompted this bug was initially wrong. Do you see any problem changing the code back?

OK

comment:19 by assefa, 14 years ago

Milestone: 5.6 release6.0 release
Note: See TracTickets for help on using tickets.