I just noticed some strange behavior in PostGIS, with respect to WKT parsing.

A GeometryCollection containing 1 or more empty geometries


is the same an empty GeometryCollection


This doesn't seem right. But here's the truly weird part. If you throw a non-empty geometry into the collection, the empty geometries are suddenly represented in the collection:


It seems strange that empty geometries are only recognized if the collection contains at least one non-empty.

Is this is a bug? Is this behavior documented somewhere?

  • Lowest common denominator makes sense to me (all the better to make comparisons) – Vince Jul 11 '14 at 14:08

It's not a bug, more like a strategic laziness. 1.X versions of PostGIS only supported GEOMETRYCOLLECTION EMPTY, not other forms of empty. For 2.X I (perhaps foolishly) embraced the full variety of nothings. The result is a not-entirely-complete support of varieties of nothing, made slightly ill-formed by the fact that support libraries like GEOS have their own concepts of what kinds of nothing are worth preserving, and that standards like WKB cannot even represent some forms of it (POINT EMPTY is not representable in WKB).

Anyhow, a bunch of nothing is still nothing. Do you you need to retain fidelity of your collections of nothing?


Looking at the PostGIS code, I'm pretty sure you're seeing an effect of the "is empty" function. Your input is in fact being parsed into an internal representation that reflects the input, a collection of empty things. But on output to WKB, the first test is "is this thing empty? if so emit an empty representation". So then we get this situation: is a geometry collection of empty things itself empty? Philosophy 101. In terms of most things we might do with it (calculate area or length, intersect it with things, really any operation at all) a collection of empty is just the same as a single empty. Mucking with the definition of "is empty" has a lot of knock-on effects all over the code base, so we haven't touched it much.

  • Thanks for the quick answer, Paul. The reason why I'm looking into this is because I've developing a library converts between GeoJSON, WKT, and WKB, and I'm trying to find some standards and rules (hence me experimenting with doing silly things like making collections of nothings). I would consider PostGIS and GEOS to be canonical implementations of geometry functions, and thus would serve as a good standard--but are these behaviors documented somewhere (in a spec, standard, or design doc)? – larsbutler Jul 11 '14 at 14:50
  • Regarding fidelity, the purist in me thinks that collections of nothing should be preserved: I think of it like an array of nulls, if that's not too strange of a comparison. Also, using ST_GeomFromEWKT, POINT EMPTY is represented in binary the same as MULTIPOINT EMPTY. Is that binary considered WKB, or something else? – larsbutler Jul 11 '14 at 14:52
  • The hex you see on the output is itself just another representation format ("extended well-known-binary") which itself has the limitations of WKB, so you're seeing the hack we adopted for POINT EMPTY in WKB. Internally we can and do represent POINT EMPTY as a distinct thing. – Paul Ramsey Jul 11 '14 at 15:05
  • I'll have to check into the parser and see why a collection of empties is not being handled, since naively I'd expect it to just work, but I'm sure there's something in there... it's hard to escape one's history. – Paul Ramsey Jul 11 '14 at 15:05
  • The most complete discussion of EMPTY is the one we wrote up when moving to 2.0 and more complete EMPTY handlings, trac.osgeo.org/postgis/wiki/DevWikiEmptyGeometry, and it doesn't say much about representation (what you'd care about), it talks more about behavior. – Paul Ramsey Jul 11 '14 at 15:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.