The idea of the Map was in case other properties are added in the
future, that the filterfactory interface doesn't have to change anymore.
But by popular demand, I will change it.
The proposal is updated now with all your remarks..
On 12/05/11 22:06, Justin Deoliveira wrote:
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] <mailto:[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]
<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/geotools-devel
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
--
*Niels Charlier*
Software Engineer
CSIRO Earth Science and Resource Engineering
Phone: +61 8 6436 8914
Australian Resources Research Centre
26 Dick Perry Avenue, Kensington WA 6151
------------------------------------------------------------------------------
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
