[postgis-devel] EMPTY
Paragon Corporation
lr at pcorp.us
Tue Oct 6 20:28:45 PDT 2009
Wow those Microsoft people are really smart.
FFFFFFFF2
SELECT Geometry::STGeomFromText('POLYGON
EMPTY',4326).STRelate(Geometry::STGeomFromText('POLYGON EMPTY',4326),
'FFFFFFFF2') => 1
Makes perfect sense because every geometry is exterior to an empty geometry
including an empty geometry, therefore the exterior of an empty geometry
must intersect with the exterior of every geometry. The dimension has to be
2 also because well infinite space has a dimension of 2.
-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paragon
Corporation
Sent: Tuesday, October 06, 2009 11:14 PM
To: 'PostGIS Development Discussion'
Subject: Re: [postgis-devel] EMPTY
Martin,
As much as I prefer FFF.FFF.FFF for presentation. I think it would be
confusing since the more OGC compliant ST_Relate expects FFFFFFFFF for
input. So having the input of one function not be the output of another to
me is even more confusing an annoying.
Also I tested this in SQL Server 2008 and it returns 0. So I take it SQL
Serve disagrees?
SELECT Geometry::STGeomFromText('POLYGON
EMPTY',4326).STRelate(Geometry::STGeomFromText('POLYGON EMPTY',4326),
'FFFFFFFFF') => 0
For PostGIS the operation is unsupported for geometry collections I guess
because GEOS doesn't support it so can't compare.
What is interesting is that this resolves to 1 and I would have expected 0?
SELECT Geometry::STGeomFromText('POLYGON
EMPTY',4326).STEquals(Geometry::STGeomFromText('POLYGON EMPTY',4326)) => 1
Which seems puzzling to me because I thought equality requires intersection
by OGC standards. If that's the case -- SQL Server has violated its model
because
SELECT Geometry::STGeomFromText('POLYGON
EMPTY',4326).STRelate(Geometry::STGeomFromText('POLYGON EMPTY',4326),
'T*F**FFF*') => 0 (the intersection matrix for equality)
Or they are defining STEquals in a way I am unfamiliar with. Maybe their
STEquals is binary equality.
Thanks,
Regina
-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Martin
Davis
Sent: Tuesday, October 06, 2009 5:31 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] EMPTY
Yes, I replied too soon - after I realized that ST_relate returns the
matrix,not a boolean result.
But yes, I think FFFFFFFFF is the most reasonable return value.
BTW, I'm thinking of changing JTS so that it returns a more readable format
for the pattern - eg FFF.FFF.FFF (recognized where I got that idea?)
BTW2, the PG doc for ST_relate looks a little confusing to me. It lists the
ST_relate methods in the order (2 args => text, 3 args ==> boolean), but
then goes on to say "Version 1 returns BOOLEAN....)
Paul Ramsey wrote:
> Meaning FFFFFFFFF ? :)
>
> On Tue, Oct 6, 2009 at 2:25 PM, Martin Davis <mbdavis at refractions.net>
wrote:
>
>> FALSE!!!!
>>
>> Paul Ramsey wrote:
>>
>>> OK, the uber question (Kevin can meditate over this one tonight):
>>>
>>> ST_Relate(geometry, empty)
>>> ST_Relate(empty, empty)
>>>
>>> :)
>>>
>>> On Tue, Oct 6, 2009 at 2:11 PM, Paragon Corporation <lr at pcorp.us> wrote:
>>>
>>>
>>>> Yap 0 on all counts. Wow those Microsoft people are really smart.
>>>>
>>>> --geometry contains empty
>>>> SELECT Geometry::STGeomFromText('POINT(1
>>>> 2)',4326).STContains(Geometry::STGeomFromText('POLYGON EMPTY',4326))
>>>> => 0
>>>>
>>>> --geometry within empty
>>>> SELECT Geometry::STGeomFromText('POINT(1
>>>> 2)',4326).STWithin(Geometry::STGeomFromText('POLYGON EMPTY',4326))
>>>> => 0
>>>>
>>>> --empty contains geometry
>>>> SELECT Geometry::STGeomFromText('POLYGON
>>>> EMPTY',4326).STContains(Geometry::STGeomFromText('POINT(1
>>>> 2)',4326)) => 0
>>>>
>>>> --empty within geometry
>>>> SELECT Geometry::STGeomFromText('POLYGON
>>>> EMPTY',4326).STWithin(Geometry::STGeomFromText('POINT(1 2)',4326))
>>>> => 0
>>>>
>>>> Thanks,
>>>> Regina
>>>>
>>>> -----Original Message-----
>>>> From: postgis-devel-bounces at postgis.refractions.net
>>>> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of
>>>> Chris Hodgson
>>>> Sent: Tuesday, October 06, 2009 5:03 PM
>>>> To: PostGIS Development Discussion
>>>> Subject: Re: [postgis-devel] EMPTY
>>>>
>>>> I agree with you Regina, and I bet SQL Server does too.
>>>>
>>>> Chris
>>>>
>>>> Paragon Corporation wrote:
>>>>
>>>>
>>>>> They should all be false.
>>>>>
>>>>> Isn't the first requirement of containment/contains be that the
>>>>> two geometries intersect -- so if we say empty can't intersect
>>>>> with anything including empty, how can anything possibly contain it?
>>>>>
>>>>> Though have to pull out my sql server 2008 to see if it is in
agreement.
>>>>>
>>>>> Thanks,
>>>>> Regina
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: postgis-devel-bounces at postgis.refractions.net
>>>>> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf
>>>>> Of Paul Ramsey
>>>>> Sent: Tuesday, October 06, 2009 4:39 PM
>>>>> To: PostGIS Development Discussion
>>>>> Subject: Re: [postgis-devel] EMPTY
>>>>>
>>>>> In the spirit of maintaining the geometry logical flow, what do
>>>>> you think of these ideas?
>>>>>
>>>>> * ST_Contains(geometry, empty) == TRUE
>>>>> * ST_Within(geometry, empty) == FALSE
>>>>> * ST_Contains(empty, geometry) == FALSE
>>>>> * ST_Within(empty, geometry) == TRUE
>>>>>
>>>>> What does SQL Server say?
>>>>>
>>>>> P
>>>>>
>>>>> On Tue, Oct 6, 2009 at 1:34 PM, Paul Ramsey
>>>>> <pramsey at cleverelephant.ca>
>>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> I'm going to change my intersection/disjoint answers to agree w/
>>>>>> SQL Server. They are not bad, and they maintain the symmetry
>>>>>> between where intersection => ! disjoint.
>>>>>>
>>>>>> P.
>>>>>>
>>>>>> On Tue, Oct 6, 2009 at 12:45 PM, Chris Hodgson
>>>>>> <chodgson at refractions.net>
>>>>>>
>>>>>>
>>>>>>
>>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>>> I moved these and summarized the interesting results from SQL
>>>>>>> Server
>>>>>>> 2008 next to your original lines Paul.
>>>>>>>
>>>>>>> Note that SQL Server says that everything is disjoint from
>>>>>>> empty, including empty itself - whereas your original guesses
>>>>>>> were to return
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> false.
>>>>>
>>>>>
>>>>>
>>>>>>> So far I think I like SQL Server's answers. Would be good to
>>>>>>> compare with oracle spatial too.
>>>>>>>
>>>>>>> Chris
>>>>>>>
>>>>>>> Paul Ramsey wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Regina, could you move your SQL Server examples down to a big
>>>>>>>> block at the end, so the main part of the document is more
>>>>>>>> readable? So far I agree with SQL Server in all the examples!
>>>>>>>> Those guys are smart! :)
>>>>>>>>
>>>>>>>> P
>>>>>>>>
>>>>>>>> On Tue, Oct 6, 2009 at 12:12 PM, Paul Ramsey
>>>>>>>> <pramsey at cleverelephant.ca>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Tue, Oct 6, 2009 at 12:03 PM, Chris Hodgson
>>>>>>>>> <chodgson at refractions.net>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> I would dare say that geometry empty is more like zero, than
null.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> Bingo, there's a useful mental model. Wikify that!
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> postgis-devel mailing list
>>>>>>>> postgis-devel at postgis.refractions.net
>>>>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> postgis-devel mailing list
>>>>>>> postgis-devel at postgis.refractions.net
>>>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> _______________________________________________
>>>>> postgis-devel mailing list
>>>>> postgis-devel at postgis.refractions.net
>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> postgis-devel mailing list
>>>>> postgis-devel at postgis.refractions.net
>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> postgis-devel mailing list
>>>> postgis-devel at postgis.refractions.net
>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> postgis-devel mailing list
>>>> postgis-devel at postgis.refractions.net
>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel at postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>
>>>
>>>
>> --
>> Martin Davis
>> Senior Technical Architect
>> Refractions Research, Inc.
>> (250) 383-3022
>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel
More information about the postgis-devel
mailing list