Upgrade Filter encoding to use geos operators

The intention is to do the following :

• have a query function in mapquery.c : int msQueryByOperator(mapObj *map, int qlayer, shapeObj *selectshape,

int geos_operator)

• supported operators are : MS_GEOS_EQUALS, MS_GEOS_DISJOINT, MS_GEOS_TOUCHES, MS_GEOS_OVERLAPS, MS_GEOS_CROSSES, MS_GEOS_INTERSECTS, MS_GEOS_WITHIN, _GEOS_CONTAINS

• depending on the operator the appriate geos function is called. I am not sure if I need to validate the shape types (point, line, polygon) depending on the operator.

• Add support in the Filter encoding to parse the spatial filters and call the query function. Additional gilters that will be supported are Equals, Disjoint, Touches, Crosses, Within, Contains, Overlaps (plus what was alreasy there : DWithin and Intersect). "Beyond" is not supported (not sure what that is).

The intention right now that all types of geometries (point, line, polygon) can be given in the filter. Not sure if I need to validate geomatries per type of operator.

Any comments ?

To confirm: this would be for Filter 1.0.0 (and not Filter 1.1.0), correct?

Here are the supported spatial filters from Filter 1.0.0 (specification: http://portal.opengeospatial.org/files/?artifact_id=1171, schema: http://schemas.opengis.net/filter/1.0.0/filter.xsd):

Equals (from SFSQL) Disjoint (from SFSQL) Touches (from SFSQL) Within (from SFSQL) Overlaps (from SFSQL) Crosses (from SFSQL) Intersects (from SFSQL) Contains (from SFSQL) DWithin Beyond BBOX

Explanations can be seen in Section 8 of the specification. FYI, geos fully supports the SFSQL spatial predicate functions. I wonder if geos supports DWithin or Beyond. BBOX is easy enough.

Note that, for the specifications which publish GetCapabilities output (like WFS and SOS), these routines will also need to be looked over, and the correct FilterCapabilities will have to be output.

Question: if someone builds MapServer without geos, will any spatial filters be available, or are we moving all filters to geos?

Here's what Peter Vretanos (FES 1.0.0 spec editor) says about DWithin and Beyond:

"According to the BNF in the Cat 1.0 specification DWithin tests to see whether geometry A is completely within a certain distance of geometry B.

I interpret this to mean a "buffer" query. That is you create a buffer around A at the specified distance and then do a WITHIN (as defined in SFSQL) between this new buffer-expanded geometry (A') and the test geometry B. If B is completely within A' then the operator evaluates to true

BEYOND is the opposite of DWITHIN. If B is completely outside of A' then the operator evaluates to true."

• It is for filter 1.0.0. I have not checked the major diffrences between 1.0. and 1.1 but I think we should upgrade to 1.1.0. Same with WFS 1.1. Maybe we could open upgrade bugs for those 2 and do the discussion there.

• I think we wil migrate all spatial opeartors to geos. If Mapserver is not built with geos, the GetCapabilities? will accordingly display waht is available.

• I will do the Beyond as the opposite of DWITHIN : so create a buffered shape and use the operator WITHIN

• One of the major things for implemeting this is to create the tests data sets and integrate them in the msautotest. There is already some tests to filter encoding (Intersects and DWithin) and this should be expanded.

• docs to be updated.

Replying to nsavard:

As Assefa wrote there are two existing tests in msautotest and I'll work with him to add the tests to validate the other spatial filters.

For information / clarification:

- we will be using geos for spatial predicate functions, and will expose their definition and interface via OGC Filter. Are there any other parts of MapServer which use spatial predicate functions but are NOT accessed through OGC Filter (i.e. CGI, etc.)? - we'll have to make sure the mapscript classes (i.e. shapeObj) functions which use spatial predicate functions point to the geos routines. If geos is not compiled, we'll need to return an error in mapscript - For OGC specifications, we'll have to make sure Exceptions are thrown if geos is not built in and if a spatial predicate Filter is passed by the client

- we will want to add / include Filter by FeatureId, as per ticket #2102. As well, there is GML Object id support, i.e.:

GML 3:

<Filter>

<GmlObjectId? gml:id="TREESA_1M.1234"/>

</Filter>

GML 2:

<Filter> <FeatureId? fid="TREESA_1M.1234"/> </Filter>

- Filter 1.0.0 vs. 1.1.0. The main differences are:

• addition of SortBy, thereby allowing a Filter expression the opportunity to specify a sortation column, either ascending or descending (ASC or DESC). Example:

<ogc:SortBy>

<ogc:SortProperty>

<ogc:PropertyName>title</ogc:PropertyName> <ogc:SortOrder>DESC</ogc:SortOrder> </ogc:SortProperty>

</ogc:SortBy>

• GML object id as per above

Other notes:

- do we want to support functions (like sin, cos) and arithmetic operators (Sub, Add, etc.) ?

Note that most of the MapServer OGC codebase leverages Filter 1.0.0, with the exception of SOS (to which we've basically implemented Filter 1.1.0 without the new features (i.e. looks like Filter 1.0.0).

We should discuss WFS 1.1.0 upgrading in a new ticket.

Guys,

I would like to do a commit on this. I have not tested all the operators but would like to use the upgrade/use the existing tests in msautotest to integrate additional operators. It is my hope that Norm (or others) would help me on building the tests and It feel It would be easier to build/test test cases when the functionality is available in cvs. What do you think ?

Tom : Are you opening a ticket for upgrade to WFS 1.1.0 and Filter 1.1. Depending on the amount of work, I am willing to do it before the 5.0. We need though to define it before June 15th and submit an RFC.

I think WFS 1.1.0 and Filter 1.1.0 would be a big piece of work for 5.0 (which shows for July 2007 for a final?). We would have to ensure that folks have time to get this going and implemented.

I'll open Filter 1.1.0 and WFS 1.1.0 tickets.

As for this ticket, sounds good. We'll have to test them for sure via WFS/SOS, through SLD, as well as the mapscript functions.

P.S. let's make sure we advertise these in the OGC code FilterCapabilities. Currently, querying WFS or SOS GetCapabilities in trunk returns only:

<ogc:Filter_Capabilities>

<ogc:Spatial_Capabilities>

<ogc:Spatial_Operators>

<ogc:Intersect/> <ogc:DWithin/> <ogc:BBOX/>

</ogc:Spatial_Operators>

</ogc:Spatial_Capabilities> <ogc:Scalar_Capabilities>

<ogc:Logical_Operators /> <ogc:Comparison_Operators>

<ogc:Simple_Comparisons /> <ogc:Like /> <ogc:Between />

</ogc:Comparison_Operators>

</ogc:Scalar_Capabilities>

</ogc:Filter_Capabilities>

Commited first version (r6169) : tests done with Intersect and Dwithin using the msaoutotest tests/data. Capabilities updated Need to build tests for other operators. Need to upgrade docs.

Steve,

I need to call up msGEOSSetup and I realise that there is a call to it inside function msSetup. But msSetup is not called from anywhere except from mapscript. Does it make sense to call this function when mapserver starts ?

Replying to assefa:

- One of the major things for implemeting this is to create the tests data sets and integrate them in the msautotest. There is already some tests to filter encoding (Intersects and DWithin) and this should be expanded.

The tests for all spatial operators have been created and after their execution they produced the expected results.

Need to update mapserver docs.

Adding missing entry in HISTORY.txt r6502

Added missing operators in doc. Closing.