[postgis-devel] ST_Buffer - single sided option

[Paul Ramsey]

Yes, left/right seems reasonable to me.
It's not an east/west thing though, it's a line direction thing, so
"left in the direction of digitization". I haven't experimented what
that would mean for a polygon... in particular, if you asked for a
right-side buffer on a CW ring, with a negative buffer distance...
what do you get? The right/left side and positive/negative distance
would appear to be interacting somewhat.
P.

On Fri, Jan 19, 2018 at 1:23 AM, Darafei "Komяpa" Praliaskouski
<me at komzpa.net> wrote:
> Hi,
>
> 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
> first attempt.
>
> I'll quote again a property I expect to hold true without mentioning "left"
> and "right":
>>> 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
>> https://geos.osgeo.org/doxygen/classgeos_1_1operation_1_1buffer_1_1BufferParameters.html#adc2afac5dacc613a39a72542bdb8bf21).
>> 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
>>
>> Stephen
>>
>> On Thu, Jan 18, 2018 at 10:23 AM, Darafei "Komяpa" Praliaskouski
>> <me at komzpa.net> wrote:
>>>
>>> Hi,
>>>
>>> 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
>>> `single_side`/`single_sided`?
>>>  - 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:
>>>> https://trac.osgeo.org/postgis/ticket/3989
>>>>
>>>> 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
>>>> feedback.
>>>>
>>>> I can put it up on Github as well if that would help.
>>>>
>>>> Many thanks
>>>>
>>>> Stephen
>>>> _______________________________________________
>>>> postgis-devel mailing list
>>>> postgis-devel at lists.osgeo.org
>>>> https://lists.osgeo.org/mailman/listinfo/postgis-devel
>>>
>>>
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel at lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/postgis-devel
>>
>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/postgis-devel
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel