On Tuesday, 10 May 2011 at 1:30 PM, Niels wrote:
With Complex Features, there is the possibility of properties evaluating to
multiple values (collections of values) rather than a single value.
> It should be possible to apply comparison operators (like "=", "<") and
> geometry operators (like overlaps/touches/etc) to multi-valued properties.
>
> 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.
> 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...
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.
Note that both of the above two solutions only talk about what "filter" should
do; we really need to ground out this discussion with consideration of
rendering engine. That is how to upgrade it so it does not die when "some of
the content" is returned as a List?
Could I ask you to look at the rendering code (spend a day with it?) and
approach this from a solid requirement rather than trying to lean on the
specifications which are a bit vague in this area?
The alternative would be to always perform the xml queries by hand as a
reference point; and then make the rendering code and our filter behaviour
match. As the reason the standards are vague is because they assume an W3C
based technology and did not feel the need to be specific.
> Any comments?
Really glad you guys made it here :-) I first had this conversation when I
visited the team and was horrified at the above workaround/assumption.
Jody
------------------------------------------------------------------------------
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
