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

[Martin Davis]

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!

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