[postgis-devel] ST_Buffer - single sided option
Darafei "Komяpa" Praliaskouski
me at komzpa.net
Fri Jan 19 01:23:21 PST 2018
I like the idea of changing 1/-1 to left/right, it's more humane.
How about side=left/right/both for less presses of shift key? :)
As a person who mixes left and right I would also like have a setting that
doesn't mention "left" and "right" at all.
It's visually tricky sometimes, to convert the screen's "east" to "right"
for a line that goes "southwards/down", and then write that into query from
I'll quote again a property I expect to hold true without mentioning "left"
>> I expect ST_Buffer(ST_Boundary(ST_ForceRHR(polygon)), 10, 'single_side')
to be buffered "outside".
Or at least a highlight in docs that will tell me whether it's left or
right each time I forget :)
пт, 19 янв. 2018 г. в 3:30, Stephen Knox <stephenknox73 at gmail.com>:
> Hi Darafei,
> Thanks for that good feedback.
> Actually I think thinking it through I wonder if it would be better to
> have the option as single_side=left or single_side=right as I think that is
> much more intuitive. All the tests I've done on geometries indicate that
> geos honours the distance parameter as expected (positive is left hand side
> of the line and negative right - see
> The only issue is by default it gives right hand buffers round joins and
> left hand buffers mitre joins, but this can be overridden.
> Really this seems to be of greatest use for linestrings, as the buffer
> function already had a negative distance parameter for polygons, and
> whether single_side is true or not does not make any difference. With
> points again it ignores the parameter and undertakes a normal buffer, which
> is the only sensible thing to do.
> I'll work on that basis and add in the code, tests and docs for the
> revised function and also submit a pull request from Github.
> Thanks again
> On Thu, Jan 18, 2018 at 10:23 AM, Darafei "Komяpa" Praliaskouski <
> me at komzpa.net> wrote:
>> Thoughts that I have:
>> - this is a cool thing that I've needed multiple times. I worked around
>> its absence by fiddling with ST_MakeLine(ST_Collect(line,
>> ST_OffsetCurve(line, 1))) and then trying to make result valid, which
>> sometimes worked;
>> - how do I remember which way is it being offset? I expect
>> ST_Buffer(ST_Boundary(ST_ForceRHR(polygon)), 10, 'single_side') to be
>> buffered "outside". Does it hold true?
>> - if there are no better ideas on ST_Buffer signature I'd say your
>> option is good enough for me;
>> - there's no error reporting mentioning `single_side` as valid option;
>> - can `single_side=1` also work for `single_sided=1` and just
>> - what does it do for line and for point?
>> - does it work on EMPTY, LINESTRING(0 0, 0 0), MULTILINESTRING, and
>> self-intersecting one?
>> - how do I reverse the direction of buffering? I understand there's
>> negative buffer parameter, does it work? I see you parse parameter to be
>> single_side=1/0, maybe -1 will also make sense?
>> - out of curiosity, will ST_Buffer(geom,0,'single_side') fix invalid
>> geometries? :)
>> As someone responsible for github in PostGIS, I encourage you to put it
>> to GitHub as a PR: that'll get you test coverage report, travis CI
>> greenlight, a way to comment on your patch inline, and usual PR merge time
>> on it recently improved. :)
>> чт, 18 янв. 2018 г. в 12:56, Stephen Knox <stephenknox73 at gmail.com>:
>>> Hi List,
>>> I noticed that PostGIS didn't implement the single-sided buffer
>>> functionality of Geos (NB. not the Offset Curve functionality, but a
>>> polygon), so have submitted a patch to implement that:
>>> I have refrained from adding tests and documentation until I get some
>>> agreement that the function signature is acceptable, as I am a new
>>> contributor, and I think the ST_Buffer signature is already quit "unusual"
>>> in that it implements text parameters.
>>> I was hoping that post the recent patch releases, a more experienced
>>> contributor might be able to look at my (small) patch and give some
>>> I can put it up on Github as well if that would help.
>>> Many thanks
>>> postgis-devel mailing list
>>> postgis-devel at lists.osgeo.org
>> postgis-devel mailing list
>> postgis-devel at lists.osgeo.org
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the postgis-devel