Huh? What is going on? JDBC, which PostGIS inherits from, already does
pre and post filter processing based on capabilities, by way of
SQLUnpacker (yes somewhat poorly named). That was the whole reason
filter capabilities were invented, to do pre and post filter splitting
with SQLUnpacker.
I wrote the original code, and though I'm not really that attached to
it, it should at least be fully replaced in the right manner, not in a
half assed way in one of the jdbc sub-classes. SQLUnpacker (in main,
org.geotools.filter) is used in DefaultSQLBuilder (in main,
org.geotools.data.jdbc), so if you really want to use the
PostPreProcessFilterSplittingVisitor (ok, my name sucks, but that's not
much better), replace it there. And don't add nasty static capability
additions. The capabilities are already added in the PostGIS Filter
classes in org.geotools.filter in the postGIS package. Also your
implementation doesn't seem to take GEOS presence in to account at all?
The spatial filter capabilities should only be added if GEOS is present.
And I sorta would like to hear the justification as to why the new
filter splitter is better than the old? I'm totally willing to concede
that it is, but if it's better, it should really replace it all, instead
of breaking the decomposition we did before. Are the masks really that
much faster? Is this operation performed many times so that the
difference matters? If not then I find the masks less readable - it
feels more like programmer wanking. But I do agree that dueling
FilterCapabilities should be combined so nice work on that, David and I
talked about doing it. But if you're moving the new processing in to
PostGIS, put it in the right place in the SQLBuilder and don't litter it
with a bunch of new methods and static adding of filter capabilities.
But yeah, your new patch is _more_ likely to send unsupported filters to
PostGIS, since it will do so when there's no GEOS present, in addition
to adding unnecessary cruft to the already crowded PostGISDataStore when
we've already decomposed it nicely to different classes, including ones
in the parent class so others can use it.
Chris
Cory Horner (JIRA) wrote:
Unsupported filters should not be sent to Postgis
-------------------------------------------------
Key: GEOT-895
URL: http://jira.codehaus.org/browse/GEOT-895
Project: GeoTools
Type: Bug
Components: data postgis
Versions: 2.2.M0
Reporter: Cory Horner
Assigned to: Cory Horner
Fix For: 2.3.M0, 2.2-RC5
Postgis should make use of PostPreProcessFilterSplittingVisitor from GEOT-893
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;377 Broadway, 11th Floor;New York;NY;10013;USA
email;internet:[EMAIL PROTECTED]
title:VP, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
