<html><head><meta http-equiv="content-type" content="text/html; charset=us-ascii"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">This is a know issue, and goes all the way up into JTS<div><br></div><div><a href="https://github.com/locationtech/jts/issues/876">https://github.com/locationtech/jts/issues/876</a></div><div><br></div><div>P<br><div><br><blockquote type="cite"><div>On Mar 16, 2023, at 1:04 PM, Regina Obe <lr@pcorp.us> wrote:</div><br class="Apple-interchange-newline"><div><div><blockquote type="cite">Hello, there is a behaviour that I didn't expect with ST_Buffer.<br></blockquote><br><blockquote type="cite">Using ST_Buffer on any LINESTRING with a start point the same as the end<br>point, for on example this circle:<br></blockquote><br><blockquote type="cite">In Postgis version 2.5, the result was an area encircling the input<br></blockquote>circle,<br><blockquote type="cite">with a radius 7 meters bigger than the input. This is what I would expect.<br></blockquote><br><blockquote type="cite">However, in Postgis version 3.3, the result is a ring that appears to be 7<br>meters wide and does not include the input polygon. I think this behaviour<br>only happens when the radius passed to ST_Buffer is bigger than the radius<br>of the input LINESTRING.<br></blockquote><br>I see what you mean, and yes a positive buffer of a linestring should always<br>contain the original geometry.<br>I can't think of an instance when it shouldn't even if the buffer is longer<br>than the length.<br><br>SELECT ST_Intersects(ST_Buffer(geog, 7.0), geog) ,<br>ST_Distance(ST_Buffer(geog,7.0), geog)<br>FROM (SELECT 'SRID=4326;LINESTRING(<br> 15.209907 48.3882267,<br> 15.2098971 48.3882238,<br> 15.2098892 48.3882189,<br> 15.2098842 48.3882126,<br> 15.2098826 48.3882055,<br> 15.2098846 48.3881985,<br> 15.20989 48.3881923,<br> 15.2098982 48.3881877,<br> 15.2099082 48.3881851,<br> 15.209919 48.3881848,<br> 15.2099288 48.3881868,<br> 15.2099372 48.3881907,<br> 15.2099433 48.3881962,<br> 15.2099465 48.3882026,<br> 15.2099465 48.3882095,<br> 15.2099432 48.3882159,<br> 15.209937 48.3882214,<br> 15.2099281 48.3882254,<br> 15.2099177 48.3882272,<br> 15.209907 48.3882267<br>)'::geography AS geog) AS f;<br><br>Yields:<br>st_intersects | st_distance<br>---------------+-------------<br> f | 2.06699802<br>(1 row)<br>The above returns false and visually it is clear it doesn't contain the<br>input string.<br><br>This is running:<br><br>POSTGIS="3.3.2 3.3.2" [EXTENSION] PGSQL="150" GEOS="3.11.1-CAPI-1.17.1"<br>SFCGAL="SFCGAL 1.4.1, CGAL 5.3, BOOST 1.78.0" PROJ="7.2.1" GDAL="GDAL 3.4.3,<br>released 2022/04/22" LIBXML="2.9.9" LIBJSON="0.12" LIBPROTOBUF="1.2.1"<br>WAGYU="0.5.0 (Internal)" TOPOLOGY RASTER<br><br>Unfortunately I don't have a PostGIS 2.5 readily handy. Can you provider<br>the: <br><br>SELECT postgis_full_version();<br><br>Of both your PostGIS 2.5 and PostGIS 3.3. This could be a GEOS bug rather<br>than a PostGIS one.<br>Could also be a proj issue since ST_Buffer is one of those functions that<br>transforms to geometry before doing buffer.<br><br>Thanks,<br>Regina<br><br><br><br><br><br><br><br>_______________________________________________<br>postgis-users mailing list<br>postgis-users@lists.osgeo.org<br>https://lists.osgeo.org/mailman/listinfo/postgis-users<br></div></div></blockquote></div><br></div></body></html>