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 <[email protected]> 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 GarnettOn 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] <mailto:[email protected]>> wrote:On Thu, May 12, 2011 at 6:25 AM, Niels <[email protected] <mailto:[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 DeoliveiraOpenGeo - 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] <mailto:[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] <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
