Buffer - Observation

[flightsurvey]

This is not an issue per se, but an observation and I'm raising on behalf of a customer as I do not have an adequate enough understanding of how this module works.

There are screen captures of two scenarios below. The first shows a buffer (in orange) set at +25m and the second shows a buffer set at -25m. The first smooths out the buffer polygon (and I can just about understand why) whilst the second makes the buffer much the same shape as the object polygon. Is this in line with what everyone expects to happen?

+25 metre buffer:

-25 metre buffer:

It does beg the question that if I set the object polygon to be the same size as the second buffer and then apply a +25 metre buffer then what would I expect to see? A buffer with the same proportions or one that is smoothed out?

To be honest, I find both results to be acceptable from an operational point of view but I still think it's worth raising the point.

But otherwise, thank you very much for such a useful utility.

Cheers.

[DenisCarriere]

Thanks for sharing 👍

Those outcomes are expected, the smoothing edges is for normal for positive buffers.

There has been some discussions (#639) about having different joining strategies (miter & flat).

Those screen shots look good! Good use of high resolution imagery + TurfJS.

[stebogit]

As just an alternative, if useful, I'd suggest the use of @turf/transform-scale, which would scale the polygon keeping the original shape.
In this case you would need to pass the scaling factor instead of a length parameter:

var scaledPoly = turf.transformScale(poly, factor);

factor = 1.24:

factor = 0.82:

[DenisCarriere]

Oh nice! @turf/transform-scale is another great option for this

[rowanwins]

Hey @stebogit

A thought on this, is there any way that we could get transformScale to accept something other than a factor, eg it would be great to pass in a regular turf distance like kilometers...

[stebogit]

👍 @rowanwins we should be able to calculate the factor internally based on a bbox on the geojson input I guess, but let me think about it

[stebogit]

@rowanwins I think we need to define how to apply a distance as factor. I can think about two approaches: we can apply it to the bbox, or add it to the distance of each point from the origin.
The actual factor used for the scaling would be the ratio between bboxes widths or distances from origin.

Example:

const scaled = turf.transformScale(polygon, 10, null, false, 'miles');

The left picture is actually misleading because the two polygons could still be "centered" (if the chosen origin is the centroid), but I wanted to highlight where the distance factor would be applied.

I'm not sure if the result is what you would expect, however we can definitely add this feature.

We can add an optional units parameter that, if defined as a string, implies the factor has to be considered as a distance of that unit.

Any other idea?
cc: @DenisCarriere

[rowanwins]

Hmm yeah maybe it's not such a smart idea, might be wisest to keep that functionality in the buffer module....

[DenisCarriere]

@stebogit Can't we just expand the origin parameter to include the center-of-mass & center?

[rowanwins]

That's alright I think I've got it sorted @DenisCarriere & @stebogit . I have a fully functional polygon buffer module with 0 dependencies (other than turf deps). I'm just adding the linestring buffer before I put in an initial pull request for your review (perhaps tonight...). Currently 5 times faster than jsts, gone from 3,000 ops/second to 18,000. Will support holes, inverse buffers (eg with a negative value) etc. I think I can even get it support endcap strategies!

[DenisCarriere]

@rowanwins 👍 Awesome! 🎉 Looking forward to it

[stebogit]

Can't we just expand the origin parameter to include the center-of-mass & center?

@DenisCarriere the centroid is currently the default origin for scale 👍

Great @rowanwins!

[DenisCarriere]

Agreed, but couldn't we also add center-of-mass? wouldn't that make the output different (compared to centroid/center)?

[stebogit]

Sorry didn't mean to close this... 😅

@DenisCarriere I remember we defined centroid as default origin following @morganherlocker suggestion. The user can anyway pass any point as origin.

However, here the issue is not really the origin, but how you would apply a distance parameter to then be able to calculate the scaling factor.

I'd actually agree with @rowanwins here, that maybe it's not the best way of think about @turf/transform-scale, in terms of distance increase I mean. @turf/buffer is definitely the best approach in this case.

[DenisCarriere]

Ooh yea! that's true... The user can just pass his own point 👍 Gotcha

[DenisCarriere]

@turf/buffer is definitely the best approach in this case.

👍 Yes this issue topic seems more of a buffer operation.