ST_CurveN/ST_NumCurves

[Paul Ramsey]

So, I figured I'd just whip these off this afternoon, but "ha ha",
jokes on me. The question of what these things do is definitely
unsettled.

If you crack open SQL/MM Part 3, you'll find the following definition
of ST_NumCurves

  CREATE METHOD ST_NumCurves()
      RETURNS INTEGER
      FOR ST_CompoundCurve
      RETURN
         CASE
            WHEN SELF.ST_IsEmpty() = 1 THEN
  NULL ELSE
  CARDINALITY(SELF.ST_PrivateCurves) END

Note first, only ST_CompoundCurve is an argument. Note also that what
is being counted are the members of the compound: the number of
linestrings and circularstrings that make it up.

Check with Microsoft SQL Server, however, and you get a different story.

https://learn.microsoft.com/en-us/sql/t-sql/spatial-geometry/stnumcurves-geometry-data-type

Here the function takes any of LineString, CircularString, and
CompoundCurve. And the number of "curves" is the number of arcs in a
circular string, or the number of segments in a linestring, or the sum
of those things for a compoundcurve.

I *think* we want the SQL/MM version, limited though it is. However,
even that model has some open questions.

For example, if you ask PostGIS what is ST_NumGeometries('POINT(0
0)'), you will not get NULL or an error as SQL/MM might ask you to
return (since you aren't passing a collection in as a parameter), you
get 1, which a human would probably agree is an acceptable answer.

So for ST_NumCurves... that implies that, say, a LineString might be
said to have one curve. As would a CircularString.  And what about a
CurvePolygon? Would the number of curves be the sum of all the curves
used in the rings?

SELECT ST_NumInteriorRings('MULTIPOLYGON(((0 0, 1 0, 1 1, 0 0)), ((0
0, 1 0, 1 1, 0 0)))'::geometry);

This SQL/MM function returns NULL right now, because the function is
restricted to Polygon inputs only. ST_NRings on the other hand (a
PostGIS function) returns 2.

Thoughts?