[postgis-devel] Spatial relationships not defined should return null
Jose Carlos Martinez
jomarlla at cgf.upv.es
Fri Feb 10 03:59:54 PST 2012
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.
>> 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?
> 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?
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 -> 220.127.116.11 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: tests if an ST_Geometry value spatially touches another
20 © ISO/IEC 2011 - All rights reserved
Given two geometries a and b, ST_Touches is defined as:
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.
More information about the postgis-devel