Opened 17 years ago
Closed 17 years ago
#2105 closed enhancement (fixed)
Upgrade Filter encoding to use geos operators
Reported by: | assefa | Owned by: | assefa |
---|---|---|---|
Priority: | normal | Milestone: | 5.0 release |
Component: | WFS Server | Version: | 5.0 |
Severity: | normal | Keywords: | |
Cc: | bartvde@…, sdlime, tomkralidis, nsavard, jmckenna@… |
Description
Filter encoding can use geos to support spatial operators.
Change History (19)
comment:1 by , 17 years ago
Cc: | added |
---|---|
Status: | new → assigned |
Type: | defect → enhancement |
comment:2 by , 17 years ago
Cc: | added; removed |
---|
comment:3 by , 17 years ago
Cc: | added; removed |
---|---|
Version: | → 5.0 |
comment:4 by , 17 years ago
Cc: | added |
---|
comment:5 by , 17 years ago
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?
comment:6 by , 17 years ago
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."
follow-up: 16 comment:7 by , 17 years ago
- 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.
follow-up: 9 comment:8 by , 17 years ago
Cc: | added |
---|
comment:9 by , 17 years ago
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.
comment:10 by , 17 years ago
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.
comment:11 by , 17 years ago
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.
comment:12 by , 17 years ago
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.
comment:13 by , 17 years ago
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>
comment:14 by , 17 years ago
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.
comment:15 by , 17 years ago
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 ?
comment:16 by , 17 years ago
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.
comment:19 by , 17 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Added missing operators in doc. Closing.
The intention is to do the following :
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.