[postgis-devel] issues with line_substring() and 4d lines

[strk at refractions.net]

I've given interpolation a shot, providing a general routine
to handle that (in 4 dimensions).

I've made both line_substring() and line_interpolate_point()
use it to do Z and M interpolation and provided some regress
tests for them.

Note that when 'start' and 'end' parameter have the same value 
the call is equivalent to line_interpolate_point() with the
exception that the latter avoids some overhead when the
'location' parameter is either 0 or 1...

Maybe we should completely drop line_interpolate_point() code
and replace the function definition with an 'SQL' version
invoking line_substring()... 

What do you think ?

--strk;

On Wed, Jan 18, 2006 at 09:35:27PM -0500, Christoph Spoerri wrote:
> strk,
> 
> in case you would like some code that does the interpolation, please check out 
> the LRS functions I sent to the list a few weeks ago. I implemented the 
> function so that they perform interpolation.
> 
> Let me know if I can help out in order to get the functionality into the next 
> version/release.
> 
> cheers,
> Christoph
> 
> On Wednesday 18 January 2006 05:20, strk at refractions.net wrote:
> > Thank you. Fixed in CVS.
> > I don't think we'll implement interpolation before next
> > release, but that'd be interesting.
> >
> > --strk;
> >
> > On Wed, Jan 18, 2006 at 08:06:28AM +0100, Alex Mayrhofer wrote:
> > > Hi,
> > >
> > > it seems to me as if there is a bug in line_substring() when performing
> > > the function on 4D lines:
> > >
> > > sketch=# select
> > > asewkt(line_substring(geomfromewkt('SRID=4326;LINESTRING(0 0 0 0, 1 1 1
> > > 1, 2 2 2 2, 3 3 3 3, 4 4 4 4)'), 0.5, 0.8));
> > >
> > >                       asewkt
> > > ---------------------------------------------------
> > >  SRID=4326;LINESTRING(2 2 0 0,3 3 2 2,3.2 3.2 0 0)
> > > (1 row)
> > >
> > > Please note the third output value - there is a problem with the Z and M
> > > value (i'd assume them to be 0 as well) [it looks like a copy of the
> > > previous points corrdinates).
> > >
> > > I can reproduce similar issues with more complex geometries as well:
> > >
> > > SRID=4326;LINESTRING(16.3116663381532 48.1343234522231 0 0,16.311761
> > > 48.134512 16.311517 48.134026,16.31199 48.135002 16.311761
> > > 48.134512,16.311828 48.135112 16.31199 48.135002,16.311463 48.135228
> > > 16.311828 48.135112,16.311485 48.135325 16.311463 48.135228,16.311978
> > > 48.135789 16.311485 48.135325,16.312465 48.136218 16.311978
> > > 48.135789,16.312534 48.136492 16.312465 48.136218, ...
> > >
> > > (original Z and M contain altitude and ctime, so those output values are
> > > for sure out of range of the input values, and seem to originate from X
> > > and Y values).
> > >
> > > Additionally, a question: are there any plans to extend the various
> > > linear referencing functions to also interpolate Z (and optionally M)
> > > values?
> > >
> > > thanks,
> > >
> > > Alex
> > > ---
> > > http://nona.net/features/map/
> > > _______________________________________________
> > > postgis-devel mailing list
> > > postgis-devel at postgis.refractions.net
> > > http://postgis.refractions.net/mailman/listinfo/postgis-devel
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel

-- 

 /"\    ASCII Ribbon Campaign
 \ /    Respect for low technology.
  X     Keep e-mail messages readable by any computer system.
 / \    Keep it ASCII.