[postgis-tickets] [PostGIS] #5361: Compound Curve inconsistent behavior with ST_GeometryN, ST_NumGeometries, and ST_Dump

[PostGIS]

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

 I suspect trying to get the others to do less is more likely to break
 people's workflow than having ST_GeometryN do more or maybe we should do
 nothing :)

 Out of curiosity I tried this on a SQL Server 2017 server.


 {{{
 WITH a AS (SELECT Geometry::STGeomFromText(
 'COMPOUNDCURVE(
 (2 2, 2.5 2.5),
 CIRCULARSTRING(2.5 2.5, 4.5 2.5, 3.5 3.5),
 (3.5 3.5, 2.5 4.5, 3 5)
 )',0) AS geom )

 SELECT a.geom.STGeometryN(2), a.geom.STNumGeometries(),
 a.geom.STNumCurves(), a.geom.STCurveN(2).STAsText()
 FROM a;
 }}}

 and it returned


 {{{
 NULL, 1, 4 , CIRCULARSTRING (2.5 2.5, 4.5 2.5, 3.5 3.5)
 }}}


 which in my mind looks like the correct way to handle this. But is it
 worth it?

 What I'm mad about is we don't have an ST_NumCurves and ST_CurveN
 function.  How did we live so long without these?

 I trashed my Oracle server so not sure what answer that would give. Maybe
 we just leave it alone since no one has complained except the IRC guy.  If
 they do complain we could introduced a ST_CurveN  and ST_NumCurves
 functions that counts the components in the curve.
-- 
Ticket URL: <https://trac.osgeo.org/postgis/ticket/5361#comment:2>
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.