[geos-devel] Bug in GEOSEquals predicate ?
Pascal Leroux
pa.leroux at gmail.com
Tue Mar 17 01:43:25 EDT 2009
Hi martin,
I had got no particular example.
But, if I have to find intersections and get a geometry collection, I'll
keep your approach in mind and only look at the right (0, 1 or 2D)
components of a geometry collection. In my case, I was only interested in 2D
parts (wrong intersections between buildings/polygons I have to fix).
Thanks
2009/3/16 Martin Davis <mbdavis at refractions.net>
> Yep, that's what you'd have to do.
> Probably a better way to think of this is that you need to decide what
> dimension of geometry you are interested in out of the intersection
> operation. Then you retain only those components of the result. In this
> case, since you are checking whether the intersection is equal to one of the
> input polygons, you should retain only the 2D components of the intersection
> result.
>
> I realize that it would be nice to have it a bit simpler to get the desired
> dimension components from an intersection result. One idea is to ensure
> that a result GEOMETRYCOLLECTION contains at most 3 (possible multi)
> geometry components, one each for the 0-D, 1-D, and 2-D components.
> In general if you are testing spatial relationships you should try and use
> just predicates. This will be faster and more accurate. What are the other
> cases which you think will not be as simple?
>
> Pascal Leroux wrote:
>
>> Does it mean that, when I get a geometry collection, the very first thing
>> I have to do is to split it into simple/multiple but homogeneous geometries
>> to go on ?
>>
>> In the script I've posted, I could have use "contains" or "within" with
>> the two polygons instead of "equals" with the intersection, but in others
>> cases, I'm afraid it is not so easy/simple !
>>
>> Can you give me an advice ?
>>
>> Pascal
>>
>> 2009/3/16 Sean Gillies <sgillies at frii.com <mailto:sgillies at frii.com>>
>>
>>
>> The GEOS C API returns a integer value of 2 to indicate an error.
>> It's good to learn that geometry collection predicates aren't
>> supported.
>>
>>
>> On Mar 16, 2009, at 9:46 AM, Martin Davis wrote:
>>
>> GEOS does not support evaluating predicates on
>> GEOMETRYCOLLECTIONS (due to the potential complexity and lack
>> of obvious semantics of heterogeneous collections).
>>
>> In JTS trying to do this throws an exception. I'm not sure
>> how GEOS reacts - or possibly shapely is not handling this
>> gracefully?
>>
>> Pascal Leroux wrote:
>>
>> Hi all
>>
>> while searching for intersections between polygons
>> (buildings), I have found shapes that make "equals"
>> predicate crash. With simpler shapes, it occurs too :
>>
>> >>> from shapely.geometry import Polygon
>> >>> p1 =
>> Polygon(((0,0),(0,10),(10,10),(10,0),(8,0),(8,8),(2,8),(2,0)))
>> >>> p2 = Polygon(((2,0),(2,8),(8,8),(7,4),(8,0)))
>> >>> inter = p1.intersection(p2)
>> >>> inter.is_valid and p1.is_valid and p2.is_valid
>> True
>> >>> inter.wkt
>> 'GEOMETRYCOLLECTION (POINT (8.0000000000000000
>> 0.0000000000000000), LINESTRING (8.0000000000000000
>> 8.0000000000000000, 2.0000000000000000
>> 8.0000000000000000), LINESTRING (2.0000000000000000
>> 8.0000000000000000, 2.0000000000000000 0.0000000000000000))'
>> >>> inter.equals(p1)
>> False
>> >>> inter.equals(p2)
>> Traceback (most recent call last):
>> File "<stdin>", line 1, in <module>
>> File
>>
>> "/usr/lib/python2.5/site-packages/Shapely-1.0.11-py2.5.egg/shapely/predicates.py",
>> line 34, in __call__
>> return bool(self.fn(self.context._geom, other._geom))
>> File
>>
>> "/usr/lib/python2.5/site-packages/Shapely-1.0.11-py2.5.egg/shapely/predicates.py",
>> line 21, in errcheck
>> raise PredicateError, "Failed to evaluate %s" %
>> repr(self.fn)
>> shapely.geos.PredicateError: Failed to evaluate <_FuncPtr
>> object at 0x96a3bf4>
>>
>> I have got a Bus Error on MacOSX (libgeos version 3.0.0)
>> and a Segmentation Fault on Ubuntu (libgeos version 3.0.3)
>> with an equivalent code written in C (so I think Shapely
>> is not involved).
>>
>> Any idea ? Did I miss something ?
>>
>> Pascal
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> geos-devel mailing list
>> geos-devel at lists.osgeo.org <mailto:geos-devel at lists.osgeo.org>
>> http://lists.osgeo.org/mailman/listinfo/geos-devel
>>
>>
>> -- Martin Davis
>> Senior Technical Architect
>> Refractions Research, Inc.
>> (250) 383-3022
>>
>> _______________________________________________
>> geos-devel mailing list
>> geos-devel at lists.osgeo.org <mailto:geos-devel at lists.osgeo.org>
>> http://lists.osgeo.org/mailman/listinfo/geos-devel
>>
>>
>> _______________________________________________
>> geos-devel mailing list
>> geos-devel at lists.osgeo.org <mailto:geos-devel at lists.osgeo.org>
>> http://lists.osgeo.org/mailman/listinfo/geos-devel
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> geos-devel mailing list
>> geos-devel at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/geos-devel
>>
>
> --
> Martin Davis
> Senior Technical Architect
> Refractions Research, Inc.
> (250) 383-3022
>
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geos-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/geos-devel/attachments/20090317/5033209b/attachment-0001.html
More information about the geos-devel
mailing list