I don't have really anything to add past Andreas feedback. The proposal
looks good but I echo Andreas statements to only apply the collection
wrappers in cases where one of the sides of the filter is already a
collection. As for the new method on filter factory I agree just be explicit
and add a new parameter for matchAction. This is also generally the pattern
already used by the interface so I would say continue on with that.
2c.
On Thu, May 12, 2011 at 6:15 AM, Andrea Aime
<[email protected]>wrote:
> On Thu, May 12, 2011 at 6:25 AM, Niels <[email protected]> wrote:
> >
> http://docs.codehaus.org/display/GEOTOOLS/Support+Multi-Valued+Attributes+in+Filter+Comparison+Operators
>
> I don't have the Filter 2.0 specification handy but afaik you'll also
> have to update the
> OGC interfaces for those filters to add the matchAction attribute and
> modify the
> XML encoders and parsers (both old and new generation, sorry) to handle the
> matchAction?
> The proposal does not show that part.
>
> A little detail, in the code example it should be matchAction, not
> matchCase?
>
> As for the performance perspective, it would be better to avoid
> creating the collectoin
> wrappers as filters are evaluated repeatedly for each feature in the
> rendering, it's not
> uncommon to render hundreds of thousands, up to millions features in a
> simple
> feature rendering situation.
>
> So the code should be preceded, imho, with a check like:
>
> if(!(object1 instanceof Collection) && !(object2 instanceof Collection)) {
> return evaluateInternal(value1, value2);
> }
>
> right after the collection wrapping step.
>
> The changes to the filter factory... you will be preserving backwards
> compatible
> methods right?
> I did not follow the whole discussion but an untyped kvp is painful to use,
> it's
> one of the reasons why working with JAI is painful (look ma, just one
> factory
> method for all operations! And then they realized it was hard to use and
> made
> statically typed *Descriptor classes to make it code complete and autodoc
> friendly).
>
> Cheers
> Andrea
>
> --
> -------------------------------------------------------
> Ing. Andrea Aime
> GeoSolutions S.A.S.
> Tech lead
>
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
>
> phone: +39 0584 962313
> fax: +39 0584 962313
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
>
> -------------------------------------------------------
>
>
> ------------------------------------------------------------------------------
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Geotools-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
