ST_Multi on curved polygon gives ERROR: Unknown geometry type: 0

[robe]

What steps will reproduce the problem?

1. SELECT ST_AsText(ST_Multi(ST_LineToCurve(ST_Buffer(ST_MakePoint(i,j),2))))

FROM generate_series(1,2) AS i CROSS JOIN generate_series(3,4) AS j

What is the expected output? On 1.3.3 install it gives 'CURVEPOLYGON(CIRCULARSTRING(3 3,2.4142135623731 1.58578643762691,1 1,-0.414213562373101 4.41421356237309,3 3))' 'CURVEPOLYGON(CIRCULARSTRING(3 4,2.4142135623731 2.58578643762691,1 2,-0.414213562373101 5.41421356237309,3 4))' 'CURVEPOLYGON(CIRCULARSTRING(4 3,3.4142135623731 1.58578643762691,2 1,0.585786437626899 4.41421356237309,4 3))' 'CURVEPOLYGON(CIRCULARSTRING(4 4,3.4142135623731 2.58578643762691,2 2,0.585786437626899 5.41421356237309,4 4))'

What do you see instead? ERROR: Unknown geometry type: 0

This was uncovered during torture testing on 1.3.5SVN. Haven't verified the issue exists in 1.4 but didn't give error in 1.3.3.

[mcayland]

Ah I see the problem here - it's related to the fact that the code in LWGEOM_force_multi assumes that it can convert a base geometry to its equivalent MULTI type just by adding 3 to the geometry type identifier. And of course this doesn't hold for the CURVEPOLYGON type. I've no idea why this didn't fail in 1.3.3, although I suspect its old behaviour was just random luck.

Adding a fix is fairly simple, although I'm not exactly sure what the behaviour should do. Anyone know what ST_Multi() on a CURVEPOLYGON should return?

ATB,

Mark.

[robe]

I think the reason it didn't fail in 1.3.3 is before the logic was if type > … then it is a MULTI, so it always treated that as a Multigeometry and didn't do anything with it (which probably broke other functions) which used the same silly logic.

Perhaps we should just leave this one to think about more. And just raise it as something that was working that is now broken for now. I doubt it is a common use case even among people that use circular strings.

[mcayland]

I see what happened here: when I introduced the new lwgeom_contains_subgeoms() function, I misunderstood what the logic was doing in LWGEOM_force_multi. The mistake I made was assuming that all non-collection types can be converted to MULTI; whereas in fact the only types that can be converted to MULTI are the standard POINT, LINESTRING and POLYGON since these are the only MULTI types that exist!

I've committed a patch to clarify the logic and your example above now works (i.e. it maintains the same behaviour in 1.3.3). I guess if people think that this behaviour is wrong we could discuss it further, but at the moment it's not particularly clear exactly what it should be.

ATB,

Mark.

[robe]

Thanks that worked for me and I was able to put it back into torture script. I thought it was that that was causing a later service crash in ST_Collect on CurvedPolygon. I'm investigating that one to see if it was an issue in 1.3.3.

[mcayland]

No, this was introduced as part of the curve fixes for 1.3.4 (I think I noted this in the commit message, but not in the comment above).

ATB,

Mark.