Opened 12 years ago

Closed 12 years ago

Last modified 12 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 Changed 12 years ago by robe


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 Changed 12 years ago by strk

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

comment:3 Changed 12 years ago by robe

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 Changed 12 years ago by giohappy

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

comment:5 Changed 12 years ago by 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.

comment:6 Changed 12 years ago by 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.

comment:7 Changed 12 years ago by 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).

comment:8 Changed 12 years ago by yabo

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

comment:9 Changed 12 years ago by strk

Created #549 for ST_IsCollection. Patch welcome.

Note: See TracTickets for help on using tickets.