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] <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 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]
<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]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
