Interesting.
Could you add some kind of scoping? Something like ${feature.bounds} for the
bounds of the current feature?
Jody
On 25/05/2010, at 7:57 PM, Andrea Aime wrote:
> Hi,
> I'm looking for a way to make EnvFunction used in filters
> play nice with databases and stores in general.
>
> What happens now is that the function is not recognized and
> thus forces that part of the filter to be evaluated in memory.
>
> It would be nice to perform the param value expansion into
> a literal so that the store can use it for optimized filtering.
> A good place to perform the substitution is the
> SimplifyingFilterVisitor, which is already in use in a number
> of places.
>
> What we need to be sure about, though, is that the param
> value is not going to change on a feature by feature basis,
> which is not something we might not be able to take for granted...
>
> How do we deal with this? Add a "static" flag to the function
> where the use can declare if the function values are going to
> change during a data access?
>
> Or maybe add some global flag, some system variable, to declare
> the same?
>
> Imho the case of param values not changing feature by feature is
> the most common and having an optimization for it would be good,
> yet the dynamic case could be of interest as well
>
> Opinions?
>
> Cheers
> Andrea
>
> --
> Andrea Aime
> OpenGeo - http://opengeo.org
> Expert service straight from the developers.
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Geotools-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
------------------------------------------------------------------------------
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
