Artifacts and limitations of bufferLineSingleSided

[ylan]

Recently I implemented an algorithm that involves single-sided buffering of LineStrings and LinearRings. With testing I have encountered some limitations of the current implementation of the bufferLineSingleSided() function.

1) It does not accept LinearRings nor does it detect closeness of LineStrings. This may result in missing line segments in the buffered output, since it does not buffer the bit between the end and start point of the LineString. The advantage over buffering the LineString as a polygon (which sometimes gives the right result) is that this method can also give you an 'interior' buffer

2) Certain concavities in the LineString may create unwanted disconnected LineStrings in the buffer output. To illustrate this see the screenshot above (where green is the input and red is the single-sided buffer with a radius of 3). The artifacts appear in the top right.

A hex-encoded WKB of the corresponding input LineString is attached.

[ylan]

dump of hex encoded wkb

[strk]

Was this with trunk or 3.3 branch ?

[ylan]

This was using trunk revision 3664.

[strk]

I only find r3664 in the 3.3 branch. Could you try with current trunk as of r3673 ?

[ylan]

I'm willing to try it with the current trunk (r3675). Unfortunately it fails to build on my system now. It breaks at:

Scanning dependencies of target geos_c [ 83%] Building CXX object capi/CMakeFiles/geos_c.dir/geos_c.cpp.o /Volumes/macData/build/geos-svn/capi/geos_c.cpp:118: error: expected constructor, destructor, or type conversion before ‘*’ token

[strk]

You probably forgot to run ./configure again after updating (geos_c.h is generated from geos_c.h.in at configure time and contains the definition of GEOSInterruptCallback that line 118 is referencing)

[ylan]

You're right. I forgot to do that. Thanks for the hint.

As for the single side buffering: the problem still exists in r3675.

[robe]

Are you still having issue with this? Looks fine to me with my latest GEOS 3.4. under PostGIS 2.1.

SELECT ST_OffsetCurve(wkb,3);
original in center
SELECT ST_OffsetCurve(wkb, -3);

See attached openjump image

[robe]

no one has responded and I'm not seeing an issue with latest trunk so closing this.