Niels
The rendering system is relevant as we need to keep its performance in mind for
any change to the evaluation system. As this is a hurdle that any of your
proposals must pass I my advice to you is to look at the thing for a couple of
hours.
I promise I am not wasting your time; the goal here is to prevent you wasting
my time as the discussion quickly moves into rendering issues. Look I know that
you are just looking at post-filtering WFS requests; I did not forget.
If you make this change (returning true is good; I agree that *or* is the way
to go!) then for the *first* time filters will return true; throwing multiple
values at the rendering system. So what is the plan Niels?
The work in app-schema has opened up a number of design issues (handling of
multiple values is one that was left on the table when this project started;
ben turned up a need for FeatureCollection to have a descriptor for feature
members; need some feature builders created etc...) and I am worried that they
are not getting addressed and are going to be left for a rainy day / code
sprint.
I am not asking you to address all of these today; just the one you are
exposing the code base to.
--
Jody Garnett
On Tuesday, 10 May 2011 at 3:54 PM, Niels wrote:
> 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
