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?
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. 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)?)
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?
This would have the advantage that overlay ops would then always return
a value which could be used in further overlay ops.
Any comments?
Rolf A. de By wrote:
Greetings all,
My st_intersection() of two multipolygons returns an empty geometry:
no problems, as it should. When I ask for its st_geometrytype() I am
told it is "ST_Geometry", and I can live with that. When I ask for
its st_astext() I get "GEOMETRYCOLLECTION EMPTY," and that by itself I
can also live with. However, in combination I find those answers
inconsistent and potentially confusing for writing geometry
manipulation code. And also, isn't the OGC standard SF99 demanding
that geometry collections always have at least one member geometry?
Or am I missing something here?
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
