[postgis-devel] ST_Buffer - single sided option

[Paul Ramsey]

Aha. :) I was tricked by the open ticket
https://trac.osgeo.org/postgis/ticket/3989
Thanks Dan!
P

On Mon, Feb 26, 2018 at 9:43 AM, Daniel Baston <dbaston at gmail.com> wrote:
> Hi Paul,
>
> I merged in Stephen's patch for this, which uses the "side=left/right"
> syntax. He made some nice examples for the docs:
>
> https://postgis.net/docs/manual-dev/ST_Buffer.html
>
> The "sign" and "side" are two ways to refer to the same thing, i.e., a
> negative left buffer is the same as a positive right buffer:
>
> https://trac.osgeo.org/postgis/browser/trunk/postgis/lwgeom_geos.c#L966
>
> Dan
>
> On Mon, Feb 26, 2018 at 12:37 PM, Paul Ramsey <pramsey at cleverelephant.ca>
> wrote:
>>
>> 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
>> _______________________________________________
>> 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