Curve Thoughts

[Regina Obe]

> 
> > 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