I found your bug report on the topic:
- http://jira.codehaus.org/browse/GEOT-1941
Thanks for working on a visitor to perform simplifications; it is
exactly what I had in mind for this issue.
Andrea Aime wrote:
> The class is SimplyfingFilterVisitor, I've added tests,
> used it in the two sql encoders (FilterToSQL and SQLEncoder)
> to simplify the filter before encoding, and made sure postgis,
> oracle and mysql tests are still passing.
> Yet, I haven't committed, for a couple of issues I hope
> to solve with the help of the community:
> * I cannot test DB2 and ArcSDE. If I commit is there anyone able to run the
> tests? The encoded filter does not change, but I've made so that if the
> simplification returns Filter.INCLUDE, no where clause is created at all
> ('Select ... from ... where true' is just silly).
>
ArcSDE is now mostly doing its own thing; I will let you know tomorrow
if I can run tests (I need to confirm that my ArcSDE instance still works).
As for DB2 I do not have it installed locally; we will need to ask
around for another developer to help out.
> * Are the filter encoders the right place to perform the simplification
> logic? For sure it's the minimal modification giving the best overall usage
> of the algorithm, but I'm wondering if the simplification is the duty of the
> encoder, or of the class calling it.
>
I would ask each DataStore developer to apply any simplifications they
know of prior to encoding; the fact that you have
SimplyfingFilterVisitor for them to start from is just great. I imagine
some datastores would like to rename functions or fold in some
optimizations prior to encoding.
The case where a filter has just been split is special; I would expect
each side of the split could be simplified prior to use.
> I've checked, doing the simplification outside of the encoders would result
> in a much larger patch and would require me to touch code I'm not familiar
> with, yet I would like to hear your opinion.
Can you tell me more about what this patch would involve? Or an area
where you are concerned?
> If the other devs prefer to see the simplification called in the caller class
> I can just move the simplification calls into JDBC1DataStore to cover the the
> jdbc classic case, that would leave out ArcSDE and H2 thought.
>
I would personally prefer this; and would encourage ArcSDE and H2
datastores to pick this simplification up. I imagine this may also be
called from ShapefileDataStore and other locations if needed?
Jody
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
