[postgis-devel] EMPTY
Martin Davis
mbdavis at refractions.net
Wed Oct 7 08:44:49 PDT 2009
It would be easy to allow ST_Relate to accept both dotted and undotted
notation. It can just strip the dots out, since they are syntactic only.
Paragon Corporation wrote:
> 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
>
>
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
More information about the postgis-devel
mailing list