ST_Dimension returns 0 for empty GeometryCollection

[esparano]

The documentation says that ST_Dimension should return 0 for Points and NULL for empty geometries. However, there appears to be a bug in the code where ST_Dimension return 0 for empty collections.

I would suggest changing line 1033 of lwgeom.c from:

int maxdim = 0, i;

to:

int maxdim = -1, i;

[pramsey]

The documentation seems to be out of date, as "null on empty" behaviour has been commented out…

postgis25=# select st_dimension('POINT EMPTY');
 st_dimension 
--------------
            0
(1 row)

postgis25=# select st_dimension('LINESTRING EMPTY');
 st_dimension 
--------------
            1
(1 row)

postgis25=# select st_dimension('POLYGON EMPTY');
 st_dimension 
--------------
            2
(1 row)

postgis25=# select st_dimension('GEOMETRYCOLLECTION EMPTY');
 st_dimension 
--------------
            0
(1 row)

[pramsey]

#1441 is where the behaviour was changed.

[pramsey]

In 16663:

Harmonize doco with existing behaviour, closes #4127

[esparano]

I have to strongly disagree with changing the docs versus changing the behavior of the code to match the docs. The dimension of a Point is 0 because it is, mathematically, a 0-dimensional object. However, the dimension of an empty geometry is not actually 0. It's undefined. It makes more sense to return -1, like the function returns for NULL.

[esparano]

Could I get some input on this? Reopening temporarily while we discuss this.

[robe]

Here is the way I see it

ST_Dimension is a concept of a geometry's geometric type and is defined to be the maximum dimension of any geometry in the set.

So that said

POINT EMPTY → 0

LINESTRING EMPTY → 1

MULTIPOLYGON EMPTY → 2

SELECT ST_Dimension(ST_Collect('POLYGON EMPTY'::geometry, 'LINESTRING EMPTY'::geometry)) → 2

So the only question left is what to do about GEOMETRYCOLLECTION EMPTY. Does an empty geometrycollection imply we should consider it being the highest dimension of emptiness or the lowest dimension of emptiness?

I frankly don't care - doesn't seem to be worth changing the code to address a questionably ambiguous thing and making it return -1 is liable to break someone's code somewhere, so would have to wait til PostGIS 3.0 since it is a policy change.

That said, I'm reclosing this bug. If you want to discuss further, about why this is all wrong, use our dev mailing list for that:

​https://lists.osgeo.org/mailman/listinfo/postgis-devel