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.
Yes I understand; my feedback was that the filter model does allow multiple
values; it is up to you as the author of the filter to select a single value to
feed into the basic filter comparisons.
You can do that with:
- xpath
- function (as an example we have geometry functions to access different points
in a linestring)
> 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.
Understood; as indicated in my discussion of options.
> > 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.
I does depend how you think on it; you have three options:
a) what we have now; require user to select out a single value for the test
(yes I know that does not scale)
b) Allow the single value to perform a single test; and automatically return
multiple values (and update the calling code (example rendering technology) to
support multiple values being returned.
c) Define filter to work with multiple values and combine the answer using "or"
as you indicated
Out of (b) and (c) what is more closely aligned with XPath or GML? Thought: GML
did want us to render all the geometries present when the user references a
feature (not just the "default geometry"). This is an example where the
expected behaviour was that we could handle multiple values being returned.
> > > 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.
Depends how you think of it; I suspect when you look that true is taken as
evaluating the result and checking that it is not null, nill, false, empty list
(kind of like perl concept of truthiness ).
And all our java code (example rendering) expects a single value back. So if
you start with reviewing the rendering system; you can see what it expects the
style and the datastore to provide. And then you can explore what it will look
like when you start feeding multiple values back? I am correct in thinking that
if the filter returned "true" the very next thing we would need to do is
"select out" the items which it returned true for in order to render them?
So yeah; I reiterate; please look at the slightly larger picture of the
rendering engine and allow it to steer this very interesting bit of development
work.
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
