Hi Pascal, I wonder if there is a build problem or whether the algorithm is unstable. I'm going to be hacking on Shapely one evening this weekend and will try to see about adding a test for this scenario.
Sean On Mar 21, 2009, at 6:54 AM, Pascal Leroux wrote: > I couldn't reproduce the issue on a MacOSX system and on another > Ubuntu system !!! > > BUT, on the SAME Ubuntu system, > > - if I build libgeos with (g++ as a symbolic link to) g++4.2 : no > problem, no empty geometry collection > - if I build libgeos with (g++ as a symbolic link to) g++4.3 : the > issue occurs ! > > (it was one of the differences between my two Ubuntu systems) > > With libgeos built with g++4.3, the issue desn't occur with a C > program > > Is this problem known with g++4.3 on a linux system ? > > 2009/3/20 Pascal Leroux <[email protected]> > Sorry, I meant that, when you use Rtree, the "intersects" predicate > is always True for each polygon obtained with the "intersection" > method of Rtree. > > So if two polygons don't intersect each other, if their "minimum > bounding rectangle" intersects each other, the "intersects" > predicate is True. > > 2009/3/20 Pascal Leroux <[email protected]> > > Hi all, > > With the geos library version 3.1, it seems that the "intersects" > predicate (used with polygons) always returns True. For more than > 135,000 couples of polygons (got with the "intersection" method of > Rtree), I always got True but about 125,000 intersections were empty > geometry collections. > > When I use the version 3.0.3, it doesn't happen : each time > "intersects" returns True, the intersection is not empty. > > I couldn't reproduce this issue in C with version 3.1 : when > GEOSintersects return 1 (True), the intersection returned by > GEOSIntersection is not empty. > > All these tests have been done on Ubuntu with Shapely version 1.0.11 > > Here's a couple of polygons for which intersects return True with an > empty intersection > > POLYGON ((599801.1221290760440752 2546550.0634658345952630, > 599806.0258591863093898 2546538.0948937772773206, > 599780.3041890829335898 2546526.9730210378766060, > 599777.5322963981889188 2546499.6322209336794913, > 599807.2772084334865212 2546496.2815793519839644, > 599804.4406587256817147 2546476.6445081932470202, > 599760.1544660580111668 2546483.7799901803955436, > 599769.8198137159924954 2546536.2887050621211529, > 599801.1221290760440752 2546550.0634658345952630)) > > POLYGON ((599758.8006132490700111 2546478.1623347853310406, > 599772.7430304150329903 2546474.0790138356387615, > 599760.4723994010128081 2546410.1387482765130699, > 599767.0911384929204360 2546408.3941536685451865, > 599762.7293910720618442 2546391.5474267113022506, > 599740.1731945683714002 2546396.7629298437386751, > 599758.8006132490700111 2546478.1623347853310406)) > > Pascal > > > _______________________________________________ > Community mailing list > [email protected] > http://lists.gispython.org/mailman/listinfo/community _______________________________________________ Community mailing list [email protected] http://lists.gispython.org/mailman/listinfo/community
