From: Niels <nie...@cs...> - 2011-05-17 02:10:20
|
Thanks, Justin! On 14/05/11 01:45, Justin Deoliveira wrote: > Since I am already playing with filter for wfs 2.0 i am happy to do > the parsing work and update the filter bindings to include the > matchAction property. > > On Thu, May 12, 2011 at 9:02 PM, Niels <nie...@cs...> 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 >>> <and...@ge... >>> <mailto:and...@ge...>> wrote: >>>> On Thu, May 12, 2011 at 6:25 AM, Niels <nie...@cs... >>>> <mailto:nie...@cs...>> 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 >>>> Geo...@li... >>>> <mailto:Geo...@li...> >>>> 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 >>> Geo...@li... >>> <mailto:Geo...@li...> >>> 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 > Geo...@li... > <mailto:Geo...@li...> > 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 |