Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#548 closed defect (wontfix)

st_numgeometries(geom) returns NULL when geom is not multi

Reported by: giohappy Owned by: pramsey
Priority: medium Milestone: PostGIS 1.5.2
Component: postgis Version: 1.5.X
Keywords: Cc:


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…


Change History (9)

comment:1 by robe, 14 years ago


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.

comment:2 by strk, 14 years ago

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

comment:3 by robe, 14 years ago

Resolution: wontfix
Status: newclosed

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.

comment:4 by giohappy, 14 years ago

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

comment:5 by yabo, 14 years ago

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.

comment:6 by yabo, 14 years ago

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.

comment:7 by strk, 14 years ago

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).

comment:8 by yabo, 14 years ago

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

comment:9 by strk, 14 years ago

Created #549 for ST_IsCollection. Patch welcome.

Note: See TracTickets for help on using tickets.