[postgis-users] Nitpicking on empty geometries
mbdavis at refractions.net
Thu Jun 12 09:41:42 PDT 2008
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
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.
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?
> 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
Senior Technical Architect
Refractions Research, Inc.
More information about the postgis-users