Nice submission overall.
A warning though: the spline interpolant is not necessarily monotone, particularly at the end-points. As a result, in my tests it was common to get major discontinuities in "Nsign" at the boundaries.
You might consider adding a pchip() option to avoid this (pchip is guaranteed monotone).
These functions have proven quite helpful for me, Juernjakob! I would make one change: For most applications, the normalized s is awkward and unintuitive. For river flow applications it makes little sense to describe data points as being one-half of one river unit downstream. If data start out in meters, why not keep the data in meters? In every case I've needed to follow xy2sn with distanceAlongFlow=S*L. Then I often think I'm done with the L variable, only to realize that I should have kept it to transform back into the xy coordinate system.
In this situation, I have tried the following incorrect way of getting back to x,y:
The above solution would only be correct if the maximum value in distanceAlongFlow is located at the endpoint of the centerline. If you find yourself in a similar situation, the correct solution can be obtained by
Hi, Juernjakob, this program is very useful for handling river data. The problem is that the efficiency of this program need to be improved. I tried it for just 150,000 points, and it is not finished for more than half an hour. You know, for most of field applications, data sets with more than one million data points is very common. So, it will be more useful, if the efficiency of this program could be improved in future.
27 Feb 2013
Added check for a bug in "distance2curve.m"
17 Dec 2013
Dramatically increased performance by using a piecewise linear approximation for the smoothed centerline.
17 Aug 2015
The s-coordinate is no longer normalised, but uses distance units. This is consistent with Merwade's description of the method. (Thanks to Chad Greene for raising this issue)