Thank you for your comments,
On 10/05/11 11:48, Jody Garnett wrote:
However, the current filter system in Geotools assumes a single value
for each property.
Actually it does not; You should also be able to use xpath to
reference a specific example if you want to do a < comparison?
We may be in need of creating additional functions that work on a list
of items? We have a similar set of functions allowing access to the
component parts of a Geometry.
What I mean is for example filtering on the following equation:
a/b/c = "foo"
where the property expression "a/b/c" evaluates to multiple values.
This is currently not supported in the filters. The filters will try to
extract one value from "a/b/c". If evaluation results in a collection
rather than a single value, the filters will not be able to handle it
and always return false.
Currently in app-schema, a work-around exists for making this work on
mapped feature collections. This work-around only works when the
filtering is applied to the mapping datastore, not when applying
filters on already built complex features. Therefore it does not work
in two situations
- in WMS styling files, it doesn't work
- I am currently creating a new post-filtering system for a
performance improved app-schema and I cannot use the old workaround
any more.
Better would be provide proper support for filtering on multiple
values in the actual filters.
I suspect the question is wrong Niels; I think you need to update the
renderer to work with multiple results; ie for a single feature; the
query may produce multiple geometries; each of which will need to be
handed to the renderer etc...
Actually , this doesn't really have anything to do with the renderer. In
fact, I am not working on WMS right now, I am working on a performance
improvement that applies to building features in app-schema, for both
wms and wfs, but I am actually mainly testing wfs at the moment. The WMS
point was just an example in which the current work-around doesn't
apply, because there too filters are applied on already built features.
The issue here is a more general issue of applying a filter on a complex
feature, irrespective of where or for what it is used.
So the problem is not in updating the expression / filter / style
system; the problem is in updating the rendering pipeline to work with
this more general data?
I could not find any information on multi-valued properties in the
OGC filter standard. But in XPath, the standard says that when
comparing nodes with multiple values, the result should be the OR-ed
aggregation of all possible combinations. My proposal is that the
same principle would be applied to geotools filters.
Interesting; I can see how that would work:
* for rendering you are saying "yes - some of the content here matches
the filter".
I also would of been content with (and I think I prefer the power of):
* a list of (true, true, false,false,false,true,...) being returned;
and then using that list to index out the appropriate entries.
That is an interesting approach, but the filter interface returns a
boolean value when evaluated, according to the current API.
Regards,
--
*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
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
