[postgis-devel] Spatial relationships not defined should return null

[Jose Carlos Martinez]

On 10/02/2012 12:05, Mark Cave-Ayland wrote:
> On 10/02/12 04:53, Paul Ramsey wrote:
>
>> I'm not enthusiastic to change this behavior.
>> P.
>>
>> On Thu, Feb 9, 2012 at 2:39 PM, Jose Carlos Martinez Llario
>> <jomarlla at cgf.upv.es> wrote:
>>> Hi list,
>>> According to the standards the spatial predicates which are not 
>>> defined as
>>> st_touches (point , point) or st_overlaps (line, polygon) must 
>>> return null.
>>> PostGIS returns false in those cases (trunk and previous versions 
>>> too), so
>>> it is against SQL/MM.
>>>
>>> Should I open a ticket or this is the wanted behavior?
>>>
>>> Regards,
>>> Jose
>
> I agree with Paul, it does sound a little strange. Can you point us 
> towards the relevant page in SQL/MM? Also what do SQL Server/Oracle 
> Spatial do?
>
>
> ATB,
>
> Mark.
>
Hi, for me is not strange, in fact returning false is so confusing 
because the user can think the spatial relationship is defined. Im sure 
many users already have made this kind of mistake.
The SQL/MM is clear about that:

ISO 13249-3:2011 -> 4.2.2.3 Spatial Methods using ST_Geometry

one example (I copied the test from the standard maybe this is not ok 
because of the copyright, sorry):

"ST_Touches:

ST_Touches: tests if an ST_Geometry value spatially touches another 
ST_Geometry value.
ISO/IEC 13249-3:2011(E)
20 © ISO/IEC 2011 - All rights reserved
Given two geometries a and b, ST_Touches is defined as:
Case:
a) If a.ST_Dimension() = 0 (zero) and b.ST_Dimension() = 0 (zero), then 
the null value
b) Otherwise, a.ST_Touches(b) ⇔ (Interior(a) ∩ Interior(b) = ∅) ∧ (a ∩ 
b) ≠ ∅"


I think PostGIS is making an effort in the 2.0 release to follow 
standards in a more strict way, but Lately I dont understand the PostGIS 
policy about standards, sometimes PostGIS follows standards sometimes 
doesnt as I already discussed with the ST_StartPoint, ST_GeometryN, etc. 
in a previous email. and what is worse from my point o view sometimes 
without a logical reason.

Jose