Curve Thoughts

[Daniel Baston]

Treating CompoundCurve and CurvePolygon as unitary "feels" correct and is
also the direction I've proposed with GEOS:
https://github.com/libgeos/geos/pull/1046

FWIW, the OGR CompoundCurve is also not a GeometryCollection (diagram
linked in the GEOS PR) but it implements NumGeometries / GeometryN in a way
that's consistent with collections.

Dan

On Fri, Feb 16, 2024 at 7:30 PM Paul Ramsey <pramsey at cleverelephant.ca>
wrote:

> I have started down the rabbit hole. It results in some finely sliced
> distinctions entering the code base (what does lwgeom_is_collection
> actually mean? we need this new thing lwgeom_is_unitary, to patch over the
> gap between “built as an array of other geometries” and “represents a
> singular thing”. But so far, so good.
>
> P
>
> > On Feb 16, 2024, at 4:28 PM, Regina Obe <lr at pcorp.us> wrote:
> >
> >>
> >>> On Feb 16, 2024, at 2:29 PM, Regina Obe <lr at pcorp.us> wrote:
> >>>
> >>> I'm a little confused by this though
> >>>
> >>>
> >> https://gist.github.com/pramsey/cbf6db1edb8762854925f6b6ad6d6b35#prop
> >> osal-fo
> >>> r-curvepolygon
> >>>
> >>> if you are treating a curved polygon like below as a collection?
> >>>
> >>> CURVEPOLYGON(COMPOUNDCURVE(
> >>>   LINESTRING(2 2, 2.5 2.5),
> >>>   CIRCULARSTRING(2.5 2.5, 4.5 2.5, 3.5 3.5),
> >>>   LINESTRING(3.5 3.5, 2.5 4.5, 3 5, 2 2)),
> >>>   LINESTRING(4 4, 4 5, 5 4, 4 4)
> >>>   )
> >>
> >> No, I’m not. My proposal was in fact to treat CompoundCurve and
> >> CurvePolygon as unitary. It feels like the “right” answer, though you
> are right
> >> that it’s potentially quite a rat hole of changes, which is hard to
> estimate at this
> >> point.
> >>
> >> P
> >
> > Okay I'm a little confused, might be just the wording, you wrote just
> above that:
> >
> > "Both CompoundCurve and CurvePolygon are, strictly speaking, unitary
> objects, though structurally they are easy to represent as collections.
> Again, just going with collection would be an easier implementation path."
> >
> > So I assumed what followed was what the output would look like as a
> collection, cause why bother mentioning collection is easier and following
> with a unitary output.
> >
> > Maybe add a line, "This is how the output would look treating as unitary"
> >
> > But FWIW, yes "unitary" feels like the right answer and feels logically
> easier to think about.
> >
> > Ultimately a curvepolygon is nothing but a polygon with curves
> > A compoundcurve is nothing but a linestring with some curved parts and
> much like a linestring each part must start where the previous part ended.
> >
> > It feels right that when you linearize it, you get the same count of
> things as non-linearized ergo why you need NCurves when you need to count
> those curve / straight components.
> >
> > I suppose not that many people using curve support yet aside from
> visualization and to have a much lighter representation than linearized
> curves, that it probably won't duly impact
> > existing workflows, so the backward compatibility change is not a huge
> deal.
> >
> > It's just the question of is it worth it to open up this rabbit hole, or
> do the least amount of work to close as many  inconsistencies in function
> outputs as we can?
> >
> > Thanks,
> > Regina
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20240218/831e64ea/attachment.htm>