That's a really interesting question, we have been discussing it here
too yesterday.
There is another result that is non intuitive, i.e. for != (not equals).
In fact, the XPath standard implies that there is a difference between
(a != b) and !(a == b)
In the first case he will look for any a that doesn't equal b (doesn't
seem very useful), in the second case he will make sure none of the a is
equal to any of the b (which seems more intuitive in this case).
Still, for reasons of consistency I suppose, this is what XPath standard
says.
With geometries, you can ask the same question of course. I would
suggest, again for reasons of consistency, that if the user desires
another result (even if it is more intuitive and useful), that a
function should be explicitely used to merge the geometries together.
On 11/05/11 11:55, Jody Garnett wrote:
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]
<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/geotools-devel
--
*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
