Niels I know you don't have a mandate to do all that work; do you want to break
the tasks section up to show what is needed short term for your deliverable; in
addition to these wider changes to api / parser / docs.
--
Jody Garnett
On Friday, 13 May 2011 at 12:06 AM, 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]>
> 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
>
------------------------------------------------------------------------------
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
