[postgis-tickets] [PostGIS] #5361: Compound Curve inconsistent behavior with ST_GeometryN, ST_NumGeometries, and ST_Dump, add support for SQL MM ST_NumCurves and ST_CurveN

[PostGIS]

#5361: Compound Curve inconsistent behavior with ST_GeometryN, ST_NumGeometries,
and ST_Dump, add support for SQL MM ST_NumCurves and ST_CurveN
----------------------+---------------------------
  Reporter:  robe     |      Owner:  pramsey
      Type:  defect   |     Status:  new
  Priority:  low      |  Milestone:  PostGIS 3.5.0
 Component:  postgis  |    Version:  master
Resolution:           |   Keywords:
----------------------+---------------------------
Comment (by robe):

 Can I have a ST_NumCurves and ST_CurveN too.

 I think at the very least ST_NumGeometries and ST_GeometryN should at
 least agree with each other which is what your proposed change would fix
 at least.

 If ST_NumGeometries says there are 3 geometries, then I should be able to
 do ST_GeometryN(geom, 3) and get something back. That does seem like it
 would cause less friction than changing the behavior to 1 geometry.

 Then again, how many people would be using curves to care how that changes
 unless everyone gets into the habit now of SVGing their curves now that we
 support that.

 That said, I feel SQL Server is more the expected behavior and their
 having a ST_NumCurves, ST_CurveN to handle the subelements.

 I'm afraid to ask what it does with PolyhedralSurfaces and TINS.  I'm
 pretty sure ST_Dump expands those to polygons and triangles. In theory one
 can argue are those really any different from multipolygons?  To me they
 are.

 What I was thinking of was an extract argument  expand_complex=true

 SO SELECT ST_NumGeometries(geom) would do as it does now

 SELECT ST_GeometryN(geom)  -- would actually agree with ST_NumGeometries


 But if I did  SELECT ST_NumGeometries(geom, expand_complex => false);

  SELECT ST_GeometryN(geom, expand_complex => false);

 My curved stuff and TIN stuff and PolyhedralSurface stuff would be treated
 as one unit.

 So that way it's backward compatible except for the case where it was
 broken anyway.

 We could add the same arg to ST_Dump(geom, expand_complex => false)

 cause yes I have on occasion wanted to expand my TINS and
 polyhedralsurfaces and curved stuff into the subelements, but many times I
 want to treat them as a single unit.
-- 
Ticket URL: <https://trac.osgeo.org/postgis/ticket/5361#comment:6>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.