Opened 6 years ago

Closed 4 years ago

#554 closed defect (worksforme)

Artifacts and limitations of bufferLineSingleSided

Reported by: ylan Owned by: geos-devel@…
Priority: major Milestone: 3.4.0
Component: Default Version: master
Severity: Unassigned Keywords:
Cc: ylan

Description

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

http://share.ylan.nl/GEOS_bufferLineSingleSided.png

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.

Attachments (2)

example.wkb (819 bytes) - added by ylan 6 years ago.
dump of hex encoded wkb
offset_curve_3.png (14.7 KB) - added by robe 4 years ago.

Download all attachments as: .zip

Change History (10)

Changed 6 years ago by ylan

Attachment: example.wkb added

dump of hex encoded wkb

comment:1 Changed 5 years ago by strk

Milestone: 3.3.53.3.6

Was this with trunk or 3.3 branch ?

comment:2 Changed 5 years ago by ylan

This was using trunk revision 3664.

comment:3 Changed 5 years ago by strk

Milestone: 3.3.63.4.0

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

comment:4 Changed 5 years ago by 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

comment:5 Changed 5 years ago by 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)

comment:6 Changed 5 years ago by 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.

comment:7 Changed 4 years ago by robe

Cc: ylan added

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

Changed 4 years ago by robe

Attachment: offset_curve_3.png added

comment:8 Changed 4 years ago by robe

Resolution: worksforme
Status: newclosed

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

Note: See TracTickets for help on using tickets.