Jody,
I am not sure what you mean with option (b), but I do know what I need
for app-schema to work is option (c).
People want to compare an x-path with a value, and for various reasons
the x-path can return multiple values.
We are not interested in selecting a specific value from the collection
with a function before comparing, we want to do all possible
comparisons. For example when we compare "name = 'foo'" we don't care
whether name[1], name[2], name[3] or name [53688] is equal to 'foo'. All
we know is the feature needs to be have a name "foo". So it should be OR-ed.
The renderer and style system is irrelevant, because I am using this
currently for post-filtering on WFS requests, in which this behaviour is
already expected. But it would be nice if it worked for WMS too. I don't
think we need multiple values returned there, or need to do an extra
selection if the filter return true. If the filter returns true, the
feature should be styled according to the associated style, like it does
now.
So why not improve the filtering system to deal with these multiple
values? All existing behaviour will still work, it is only an extension
of functionality. I am working on a code proposal, will upload it and
then see what you think.
Regards,
Niels
On 10/05/11 12:56, 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.
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
--
*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
