[postgis-users] ST_Intersects and NOT ST_Disjoint aren't equal?

Sufficool, Stanley ssufficool at rov.sbcounty.gov
Thu Mar 26 13:43:56 PDT 2009


> -----Original Message-----
> From: postgis-users-bounces at postgis.refractions.net 
> [mailto:postgis-users-bounces at postgis.refractions.net] On 
> Behalf Of Martin Davis
> Sent: Thursday, March 26, 2009 12:51 PM
> To: PostGIS Users Discussion
> Subject: Re: [postgis-users] ST_Intersects and NOT 
> ST_Disjoint aren't equal?
> 
> 
> Ah, I see the problem.  The polygon that you provide is not a valid 
> polygon (It only has 2 unique points, so really it's a line segment 
> masquerading as a polygon).  The spatial predicates are only 
> guaranteed 
> to work with valid geometries as input - they may give 
> incorrect answers 
> if the input is invalid.
> 
> The reason ST_intersects works for all cases is that 
> intersection can be 
> determined without requiring topological validity for most 
> simple cases 
> (which this certainly is).  I think PostGIS may contain optimizations 
> for ST_intersects which are not present for ST_disjoint 
> (although they 
> should be....), and these are determining the correct answer.
> 
> So use ST_intersects!

Would it be appropriate to make st_disjoint an SQL function just
wrapping _NOT_ st_intersects(...) ?

> 
> Gerrit Hoven wrote:
> > the query:
> > select ST_AsEWKT(geom) from tbl_surface where 
> > ST_Disjoint(ST_GeomFromText('Polygon((0 0, 9999999 0, 
> 9999999 9999999, 
> > 0 9999999, 0 0))'), geom) thinks that this polygon is 
> outside of this 
> > box: POLYGON((3512977.796 5404487.019 280.571,3512967.71 5404472.11
> > 280.571,3512967.71 5404472.11 243.831,3512977.796 5404487.019
> > 243.831,3512977.796 5404487.019 280.571))
> >
> >
> >
> > Martin Davis schrieb:
> >> Can you find a single geometry where NOT ST_Disjoint and
> >> ST_Intersects are different?  That will help in debugging this 
> >> behaviour.
> >>
> >> Gerrit Hoven wrote:
> >>> Hello Postgis Users
> >>>
> >>> I was wondering about the behavior of ST_Disjoint and 
> ST_Intersects.
> >>>
> >>> My data is a 3D citymodel which is stored in 
> "tbl_surface". There is
> >>> the geometry column "geom".
> >>> Normally I expect the same behavior of "WHERE ST_Intersects(...)" 
> >>> and "WHERE NOT ST_Disjoint(...)"
> >>>
> >>> But look what happens if I try to get everything inside a huge
> >>> boundingbox:
> >>>
> >>> Query A:
> >>> select geom from tbl_surface where
> >>> ST_Intersects(ST_GeomFromText('Polygon((0 0, 9999999 0, 9999999 
> >>> 9999999, 0 9999999, 0 0))'), geom)
> >>>
> >>> returns 98524 rows, which I expect because this is all my data and
> >>> the boundingbox covers them all
> >>>
> >>>
> >>> Query B:
> >>> select geom from tbl_surface where not
> >>> ST_Disjoint(ST_GeomFromText('Polygon((0 0, 9999999 0, 9999999 
> >>> 9999999, 0 9999999, 0 0))'), geom)
> >>>
> >>> returns: 61895 rows (should be 98524 ???)
> >>>
> >>>
> >>> Query C:
> >>> select geom from tbl_surface where
> >>> ST_Disjoint(ST_GeomFromText('Polygon((0 0, 9999999 0, 9999999 
> >>> 9999999, 0 9999999, 0 0))'), geom)
> >>>
> >>> returns: 36629 rows (should be 0 ???)
> >>>
> >>>
> >>> All my geometries are polygons which have z-coordinates. 
> There exist 
> >>> polygons (like walls), which when projecting them to the 
> x-y plane, 
> >>> are only lines. I think this is a hint for the strange 
> behavior of 
> >>> ST_Disjoint. Just look what the query results look like:
> >>>
> >>> This is all my data:
> >>> http://81.89.98.151/Picture/queryA.png
> >>>
> >>> This is everything inside the big box, using NOT ST_Disjoint. All
> >>> the polygons that are not a line in 2D
> >>> http://81.89.98.151/Picture/queryB.png
> >>>
> >>> This is everything "outside" the big box, using 
> ST_Disjoint. All the
> >>> polygons that are lines in 2D
> >>> http://81.89.98.151/Picture/queryC.png
> >>>
> >>>
> >>> Can anybody explain this to me? Or is it a bug.
> >>>
> >>>
> >>> Regards,
> >>> Gerrit
> >>>
> >>> _______________________________________________
> >>> postgis-users mailing list postgis-users at postgis.refractions.net
> >>> http://postgis.refractions.net/mailman/listinfo/postgis-users
> >>>
> >>
> >
> > _______________________________________________
> > postgis-users mailing list postgis-users at postgis.refractions.net
> > http://postgis.refractions.net/mailman/listinfo/postgis-users
> >
> 
> -- 
> Martin Davis
> Senior Technical Architect
> Refractions Research, Inc.
> (250) 383-3022
> 
> _______________________________________________
> postgis-users mailing list postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
> 



More information about the postgis-users mailing list