[postgis-devel] ST_LineToCurve output type

[Sandro Santilli]

On Tue, Aug 13, 2013 at 09:43:16PM +0200, Sandro Santilli wrote:
> On Tue, Aug 13, 2013 at 12:36:02PM -0700, Paul Ramsey wrote:
> > On Tuesday, August 13, 2013 at 12:32 PM, Sandro Santilli wrote:
> > > I noticed that ST_LineToCurve returns linear-type geometries when it doesn't
> > > detect any curve in input. Given curved types can legitimately represent lines
> > > (compoundcurve only containing linestring elements) wouldn't it be more
> > > appropriate to always return curves ? It would make a nice invariant, IMHO.
> > > 
> > > Any reason NOT to do that ?
> > Because it's for un-stroking arcs, quite specifically, as your recent restriction on the kinds of inputs it would accept emphasizes. If the input is not an unstroked arc, we shouldn't muck with it. 
> > 
> > Take a compoundcurve. It's got arcy things in it, it's got linear things in it. Run curvetoline on it. Now it's just liney things. Now run linetocurve on it. It should now be a mixture again of liney things and curvey things.
> > 
> > Take a linestring. It's just liney things. Run curvetoline on it. It's still just liney things. Run linetocurve on it. It's still just liney things.
> > 
> > I think the current behavior makes sense.
> 
> Uhm, I actually kind of agree about it.
> But then again, take a compoundcurve that only has liney things,
> run CurveToLine, run LineToCurve and you end up with a linestring
> when you started from a compoundcurve.
> 
> I guess this is similar to the "multi" status of some inputs 
> lost during overlay operations. That's what we added ST_Multi for,
> should we have an ST_Curve to do a similar thing ? Or an ST_ForceCurve
> kind of casting function ?

By the way, didn't we have an Homogenize function exposed to SQL ?
Having the homogenizer it would be simple to go from curve to line
(a curve with no curved elements can become a line).

--strk;