st_numgeometries(geom) returns NULL when geom is not multi

[giohappy]

Maybe I'm doing something worng but when I run the following query:

select ST_GeometryN(geom, generate_series(1,ST_NumGeometries(geom))

I receive a single, empty, result when geom is not a multi-geometry. I would expect it to returned the same, single, geometry in case it is not multi. I have a table with both multi and geom. In such case I have to force to multi with this:

select ST_GeometryN(multi(geom), generate_series(1,ST_NumGeometries(multi(geom)))

but it is a useless overhead...

Giovanni

[robe]

Giohappy,

I know it sounds stupid, but this is by design. The ST_Numgeometries is designed to only work with multi geometries. I think it was dictated by the OGC spec, though I would like it to as you say do the logic thing of returning 1 for single geometries.

The workaround is to wrap your geom in ST_Multi. That will put it into a multi geometry casing if it is not a multigeometry and do nothing if it is.

Alternatively just use ST_Dump instead. ST_Dump is faster anyway and will explode out even for very nested collections.

​http://www.postgis.org/documentation/manual-1.5/ST_Dump.html

[strk]

This is fixed in trunk actually (to be postgis 2.0.0).

[robe]

Great. I don't think we want it to be fixed in 1.5, since although its stupid behavior it was by design, and would be considered an API change to me since it would break expected stupid behavior.

[giohappy]

Ok, thanks. We also agree that it's a stupid behaviour :) giovanni

[yabo]

Such change is going to break a lot of existing code that relies on the NULL return for single geometries. The first that comes to mind is ST_DumpPoints. I also have production code relying on this behaviour.

AFAIK there is no other way to test if a geometry is MULTI or not, so there should be at least an ST_IsMulti introduced.

[yabo]

Looking into postgis trunk I see that DumpPoints was patched to replace the use of NumGeometries by :

IF (typ like 'ST_Multi%' OR typ = 'ST_GeometryCollection') THEN

Still, having a ST_IsMulti would be better I think.

[strk]

IsMulti is kind of confusing. Is a single-element collection a "multi" ? And is an empty collection a "Multi" ?

Maybe ST_IsCollection() would be clearer, whereas all the MULTI* types are subclasses of the GEOMETRYCOLLECTION (as per OGC SFS). Also, it might have the nice characteristic of being always true on the result of ST_Collect (to be verified).

[yabo]

ST_IsCollection seems fine. As long as it returns true for any MULTI* an GeometryCollection (basically, the test I quoted earlier).

[strk]

Created #549 for ST_IsCollection. Patch welcome.