Curve Thoughts

[Paul Ramsey]

So, the first cut, which improves the “saneness” of geometryn, interiorringn and adds in curven and numcurves for compound geometries is here

https://github.com/pramsey/postgis/tree/master-curves

The next piece would be changing up ST_Dump to respect the unitary nature of the compound/curvepoly objects. But maybe we don’t want to do that? Maybe ST_Dump means something else, like dump down to the point/line/polygon level. It kind of depends on what we think people are getting out of ST_Dump. 

Any thoughts on the semantics of ST_Dump?

(Also ST_DumpRings, ST_DumpSegments, ST_DumpPoints)

P

> On Feb 16, 2024, at 4: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
>> 
>