[postgis-users] Re: Nitpicking empty geometries

[Martin Davis]

Rolf,

And *thank you* for pointing out a nuance of the SFS which I had 
overlooked.  I agree, sec 2.1.2 indicates that GCs cannot be empty.

Now, I don't know why this restriction should exist - all the other 
Geometry types can be empty, and there's no reason I can see that GCs 
should be different.  In fact, you might argue that it makes even more 
sense to allow empty GCs than the other types (if you think of GCs as 
being essentially an arbitary list of geometries.)

Be that as it may, I chose to allow empty GCs in JTS & GEOS (ahem - thus 
dramatically advancing the capabilties of the spec...  8^).  And I chose 
to use them as the "null value" in cases where it was needed - such as 
empty intersections.

I'm not sure why ST_geometrytype doesn't return GEOMETRY_COLLECTION - 
this sounds like a bug, or at least a limitation, in PostGIS.

And I would say that you were correct to tell your class that an empty 
geometry is very different to a "null" geometry in PostGIS.  Nulls have 
a very special treatment in relational DBs, and the distinction between 
"empty" and "null" is vital.  (When I refer to "null" in the context of 
spatial overlay operations, I'm using it in a very different sense - 
that of "empty set".  Confusing I know...)

I'm still liking the idea of returning an empty geometry of "least 
dimension", so that it can be used in further computation... I might end 
up changing JTS to conform to this (although when and whether this would 
make it into PostGIS I can't say)

Martin

Rolf A. de By wrote:
> Martin, big thanks for your elaboration.  You wrote:
>
>> I don't think that the SFS requires GeometryCollections to be 
>> non-empty.  If you think it does, can you provide a page & section 
>> number?
>
> In the hope that OGC 99-049 rev 1.1 is still considered a valid 
> reference on this,
> section 2.1.2, page 2-4 states "A GeometryCollection is a geometry 
> that is
> a collection of 1 or more geometries."
>
>> The reason that intersection() returns GC EMPTY as its null return 
>> value is that this is the standard value that JTS/GEOS uses to 
>> indicate null returns.
>
> And I was just telling my students today that a null geometry is very
> different from an empty geometry in a PostGIS database ;-)  The first
> being a "don't know geometry"; the second being empty, as in the 
> distribution
> of an extinct biological species.
>
>> It was thought that it was better to have a single "null" value, 
>> rather than trying to return an empty geometry of a different type.  
>> (For instance, what would be the null return value for 
>> intersection(POLYGON, LINESTRING)?)
>
> I totally agree that a single empty geometry only is what we want and 
> that
> it is in line with the apparent strive for uniqueness of geometric 
> objects
> in the standards.  (Well, that is how I rationalize some of the 
> correctness
> rules for polygons, at least.)
>
>> However, this is a somewhat arbitrary design decision, and it may be 
>> that it would better to always have intersection etc. return "the 
>> most correct type".  Or perhaps it should return the type of smallest 
>> dimension?
>
> I see the point you are making but I'd say that because the result of an
> intersection can at least always be viewed as a geocollection, then that
> is actually the most appropriate type for the empty result.
>
> My point was that I would expect to see st_geometrytype() then return
> "ST_GEOMETRYCOLLECTION" but it does not.
>
>> This would have the advantage that overlay ops would then always 
>> return a value which could be used in further overlay ops.
>
> Hmm, that remark makes me wonder whether you aren't giving the answer to
> my original question . . .
>
> Rolf
>
>
>
> International Institute for Geo-Information Science and Earth 
> Observation (ITC)
> Chamber of Commerce: 410 27 560
>
> E-mail disclaimer
> The information in this e-mail, including any attachments, is intended 
> for the addressee only. If you are not the intended recipient, you are 
> hereby notified that any disclosure, copying, distribution or action 
> in relation to the content of this information is strictly prohibited. 
> If you have received this e-mail by mistake, please delete the message 
> and any attachment and inform the sender by return e-mail. ITC accepts 
> no liability for any error or omission in the message content or for 
> damage of any kind that may arise as a result of e-mail transmission.
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022