Cool; if you can indicate which tasks need volunteers it will help sort things
out. Perhaps when you remove the KVP example.
It also occurs to me that CQL / ECQL added some support for matchCase; I did
not pay attention to the details but hopefully they can follow a similar
solution to work with matchAction.
+1
--
Jody Garnett
On Friday, 13 May 2011 at 1:02 PM, Niels wrote:
> Hi Jody,
>
> Yes I would love it if others were able step in and help with this. The only
> thing I currently need for the short term is step (1). Currently in
> app-schema everyone is used to the 'any' behaviour as that is what has
> previously been supported, and that is in the short run the only thing I need
> at the moment. i have the code basically ready for this, apart from the
> change suggested by Andrea. All the other steps are open for anyone ;) I
> won't have time for those other steps immediately, as I will be working more
> on what I am working on, but it would be great if I could commit step (1)
> asap.
>
> Regards
> Niels
>
> On 13/05/11 07:35, Jody Garnett wrote:
> > 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
> > >
> >
>
> --
> 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
>
------------------------------------------------------------------------------
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
