[postgis-devel] ST_MaximumInscribedCircle madness

[Rémi Cura]

Thank you everybody for your quick responses!
I know first hand how making a geometric algorithm robust to precision is
challenging,
I appreciate your efforts :-)

Remi

Le jeu. 20 avr. 2023 à 21:18, Regina Obe <lr at pcorp.us> a écrit :

> I have ticketed - https://github.com/libgeos/geos/issues/875
>
>
>
>
>
> *From:* postgis-devel [mailto:postgis-devel-bounces at lists.osgeo.org] *On
> Behalf Of *Martin Davis
> *Sent:* Thursday, April 20, 2023 8:45 PM
> *To:* PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
> *Subject:* Re: [postgis-devel] ST_MaximumInscribedCircle madness
>
>
>
> There's only one main loop, so an interrupt check can go there:
>
>
>
>
> https://github.com/libgeos/geos/blob/main/src/algorithm/construct/MaximumInscribedCircle.cpp#L187
>
>
>
> On Thu, Apr 20, 2023 at 5:33 PM Paul Ramsey <pramsey at cleverelephant.ca>
> wrote:
>
> One thing we can do is find a reasonable place in the loop to put an
> interrupt check. Where does it spend its time when it’s in this state?
>
>
>
> On Apr 20, 2023, at 5:31 PM, Martin Davis <mtnclimb at gmail.com> wrote:
>
>
>
> That geometry is indeed a simple rectangle, but it's very, very, very
> narrow.   This is causing the interative algorithm used in
> MaximmumInscribedCircle to essentially hunt forever trying to find a point
> which lies inside the polygon.
>
>
>
> Of course it would be nice to detect this situation and terminate faster,
> either with a point which lies actually lies outside the rectangle, or some
> other return value.  This will require some thought.
>
>
>
> On Thu, Apr 20, 2023 at 2:38 PM Rémi Cura <remi.cura at gmail.com> wrote:
>
> Hello dear Postgis devs!
>
> I have a strange case to submit to you.
>
> In a nutshell, trying to compute
>
> ```SQL
> SELECT ST_MaximumInscribedCircle( 'POLYGON ((59.3 100.00000000000001, 99.7
> 100.00000000000001, 99.7 100, 59.3 100, 59.3 100.00000000000001))') ;
> ```
>
> causes it to run for many minutes until it eventually errors.
>
> Worst, running this kind of computing on 12M geoms in parallel x6 created
> a postgres **segfault** and crashed my server (16 cores, 64GB).
>
> (many more geoms are making this function unhappy).
>
>
> /!\ Once this query starts, it can't be stopped by
> `pg_cancel_backend(pid)` or even `pg_terminate_backend(pid)`
>
> --> This is pretty dangerous in my opinion.
>
>
>
>
>
> The geometry is simple, it is a rectangle.
>
> I obtained it through other geometry operations
>
> It must be some kind of precision issue, I'm wondering if there is some
> kind of infinite loop going on or something.
>
>
>
> My full code is something like that:
>
> ```SQL
> SELECT env, diff, ST_MaximumInscribedCircle(diff)
> FROM CAST ('some_polygon'as text ) as g
>     , ST_Envelope(g) as env
>     , ST_MakeEnvelope(0,0,100,100) as bound
>     , ST_Difference(env, bound) as diff;
> ```
>
>
>
> Not creating a bug ticket as I don't know if I'm simply abusing the
> function / using it in a way it should not.
>
>
>
>
>
> POSTGIS="3.1.7 aafe1ff" [EXTENSION] PGSQL="140" GEOS="3.9.1-CAPI-1.14.2"
> PROJ="8.0.1" GDAL="GDAL 3.4.3, released 2022/04/22" LIBXML="2.9.1"
> LIBJSON="0.15" LIBPROTOBUF="1.3.2" WAGYU="0.5.0 (Internal)" RASTER
>
>
>
> PostgreSQL 14.7 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 7.3.1
> 20180712 (Red Hat 7.3.1-12), 64-bit
>
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20230425/d2c23b65/attachment.htm>