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

[Jose Carlos Martinez]

On 10/02/2012 13:15, Sandro Santilli wrote:
> On Fri, Feb 10, 2012 at 12:59:54PM +0100, Jose Carlos Martinez wrote:
>> 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.
> I guess the same reasoning should take us returning NULL
> for ST_Equals(empty,empty) ? or is that unspecified ?
>
> I personally don't value unapplied standards that much.
>
> --strk;
>
>    ,------o-.
>    |   __/  |    Delivering high quality PostGIS 2.0 !
>    |  / 2.0 |    http://strk.keybit.net
>    `-o------'
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
ok, one example, lets imagine one PostGIS  user who does not know deeply 
about standards, and the user want to check if several lines from one 
layer overlap polygons from another layer.

The user writes the query:

select count(*) from line, polygon where st_overlaps (line.geom, 
polygon.geom) and...
and PostGIS is going to return always false. Dont you think this is 
confusing for a normal PostGIS user? If st_overlaps return null then the 
user at least can think that something weird is happening. (in the docs 
you just have to write that null means unknown)

If these functions dont return null then you guys are assuming that all 
the postgis users know the standards a lot. I propose 2 solutions:
- write in the docs all the cases in which false does not mean anything 
and trust the users are going to study them.
- return null as the standard says.

Jose