[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
trac at osgeo.org
Thu Aug 10 11:18:30 PDT 2023
#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 pramsey):
So, the offending piece of code is this one
{{{
/* call is valid on multi* geoms only */
if (type==POINTTYPE || type==LINETYPE ||
type==CIRCSTRINGTYPE ||
type==COMPOUNDTYPE || type==POLYGONTYPE ||
type==CURVEPOLYTYPE || type==TRIANGLETYPE)
}}}
Both `COMPOUNDTYPE` and `CURVEPOLYTYPE` are, structurally, multi-
geometries, so it would be easy to cast them to `COLLECTION` hand them
off... then a CURVEPOLYGON would be handled like a nested
GEOMETRYCOLLECTION... the rings would each be a COMPOUND and each of those
would in turn be a set of CURVESTRING and/or LINESTRING.
This seems... not entirely bad? And it does match the ST_Dump behaviour?
--
Ticket URL: <https://trac.osgeo.org/postgis/ticket/5361#comment:5>
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.
More information about the postgis-tickets
mailing list