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
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
