Add native spatial filtering to DB backends, starting with PostGIS

[ejn]

As ​posted on mapserver-dev, I have developed a patch against trunk which adds the capability for spatial DBs to natively process spatial queries rather than just pulling all the data into MapServer and deferring the spatial filter to GEOS.

The patch hooks into the existing function for preparing simple (non-spatial) SQL for the DB backends, based on the FilterEncodingNode representation. As such it fits into the current processing path rather than the planned one (databases consuming MapServer's common filter encoding representation).

In this version, each DB driver supporting native spatial filtering must implement an additional vtable function

char *(*LayerBuildSpatialSQLForFilterNode)(FilterEncodingNode *filterNode, layerObj *layer)

and the knowledge of this must be inserted at the branching point in FLTLayerApplyCondSQLFilterToLayer.

The attached patch impements the hooks and the required function for the PostGIS driver.

[ejn]

Patch to add native spatial filtering to PostGIS driver

[dmorissette]

I'd like to hear what Assefa thinks of this approach for Filter Encoding support, as an alternative to the current SQL generation in the filter encoding code.

[sdlime]

I think the common filtering can help here in many ways, including security. We should be able to implement prepared statement binding since I think it's clear in the filter token list which tokens need to be bound...

Steve

[assefa]

Daniel, I think the approach proposed in the patch is an extension of what we currently do, that is generating sql in the filter encoding.

My understanding is that we want to go away from that and have the filter encoding just produce the common expressions. These expressions would then be used at driver level to generate the appropriate sql. I am not how easy how easy it is to parse the common expressions at driver level but basically the patch, instead of paring the filter encoding node structure, would parse the expressions and needs to be moved inside mapostigis.c

I think that fact that we want to use the common expressions was mentioned when this patch was initially proposed.

[dmorissette]

Thank you Steve and Assefa for pointing me at the light. I guess that means this patch is not the ultimate solution and the common filter stuff is still the way to go for 6.2 then.