[postgis-users] Help with spatial query (bug??)

[Carl Anderson]

Brent Wood wrote:

>--- Carl Anderson <carl.anderson at vadose.org> wrote:
>  
>
>>
>>To my understanding the Boundary test is being carried out and the 
>>Interior test is not
>>
>>I think that this case should not return TRUE or FALSE but should return 
>>NULL
>>    
>>
>
>I beg to differ (but do appreciate your comments):
>
>Surely a line comprising one coordinate (or multiple vertices at the same
>point) should return the same result from these queries as a point at the same
>location?
>
>  
>
As I see It the spatial operators in SF-SQL are predicated on 
relationships between the
Interior,Boundary, and Exterior of geometries.  I get the "feeling" that 
Intersects, Overlaps and the
rest are shortcuts for the DE-9IM.  Which is a relationship matrix of 
the Interior, Boundar, and Exterior of geometric objects.

You are assuming that If you present a deficient geometry of a given 
dimension, lacking some relationship  component (boundary or interior or 
exterior), the engine should automatically downcast your request to the 
next lower geometry dimension.

If you agree that OGC 99-049 is the controlling specification for these 
operations, then the definitions
of Interior and Boundary for a closed Curve and the definition of the 
Disjoint operator leave you with

an empty boundary
an empty interior (or an undefined interior)
an operator that compares interiors and boundaries.

and no defined automatic downcast.

There are LOTS of things in SF-SQL that I don't like and think could be 
defined in a more user friendly way.
Those wished for additons to the spec are not debatable, the spec is 
well known and well distributed. The issue is, does the Postgis/GEOS 
engine act in a way that is conformant with the spec? 

Dave Blasby asserts that a 0 length LINESTRING is invalid, and as such 
outside of the scope of the SF-SQL spec.  The acceptance of which into 
a  PostGIS geometry then would be accidental and not intentional.

strk has been improving the support for geometry collections which could 
be a proper wrapper for your dataset.  Your dataset is a mixture of 
POINTs and LINESTRINGs, which a geometry collection could hold.

OTOH PostGIS 0.8 has not so good geometry collection support for some 
operators.

perhaps strk can clarify what was working back then.


C.


>If the line had a null geometry the the null result is appropriate. A zero
>length line geometry is not the same as null. Since the locations of all the
>line's vertices are specified, as they are for the polygons, a valid spatial
>overlay is possible, and the result of an overlay should therefore be t/f. 
>
>Unfortunately, the wrong t/f is returned in some cases at present.
>
>
>Brent
>_______________________________________________
>postgis-users mailing list
>postgis-users at postgis.refractions.net
>http://postgis.refractions.net/mailman/listinfo/postgis-users
>  
>