Thanks for the proposal,
I have one non intuitive result - in reviewing:
> (x, y, z) = (a, b)
> the result will be true if x=a OR x=b OR y=a OR y=b OR z=a OR z=b.
I am wondering about these kind of tests for spatial filters:
example 1)
If we were checking disjoint( (x,y,z), (a,b) )
I would expect false if any of the combinations overlap overlap. This is the
same result I would get if I made a GeometryCollection from (x,y,z) and a
GeometryCollection for (a,b) and called disjoint.
This is not an idle question as that was one of the ways I considered handling
multiple returned geometries for the rendering system (in order to have a
minimal impact on the existing code). The existing code calls evulate( expr,
Geometry.class ) - indicating that it expects a single geometry back; as such
we could convert using the Converters class a List<Geometry> into a
GeometryCollection and proceed?
example 2)
Another spatial one here; if we are doing *within* I would expect within(
(x,y,z), (a,b) ) to only return true if all of the items x,y,z are fully
contained (no edge touching) the items a,b. Once again this would be in
alignment with the behaviour of a geometry collection.
I am not saying the proposal us wrong; just that it is not intuitive if the
results do not match treating each side of the test as a collection?
For most of the most part the spatial relationships will work out fine (ie
touches etc...). It is these ones where we are trying to ask a blanket question
- ie disjoint the questions is "do these two have anything to do with each
other at all?" we may get in trouble.
Does the GML, FIlter or WFS 2.0 specification have any guidance for us in these
matters?
--
Jody Garnett
On Wednesday, 11 May 2011 at 1:25 PM, Niels wrote:
> Oops I forgot the link:
>
> http://docs.codehaus.org/display/GEOTOOLS/Support+Multi-Valued+Attributes+in+Filter+Comparison+Operators
>
> On 11/05/11 11:19, Niels wrote:
> > The proposal is to modify the following filters:
> > - comparison filters: equals, not equals, gt, gte, lt, lte, between, like
> > - all geometry filters
> > to allow collections of values as input, besides single values. if an
> > expression returns a collection of values rather than just a single value,
> > the filters will be able to handle it. The way these collection of values
> > is interpreted by the filter should be according to the X-path standard,
> > i.e. the result will be the OR-ed aggregation of all possible combinations.
> > For example, if we compare the following values
> > (x, y, z) = (a, b)
> > the result will be true if x=a OR x=b OR y=a OR y=b OR z=a OR z=b.
> > --
> > 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
> >
>
> --
> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
