Concave Hull returning multi poly with polygons

[latot]

Hi, for some reason, in postgis 3.4 ST_ConcaveHull is returning multipolygons.

select ST_ConcaveHull(

ST_COLLECT(

array[

'POLYGON((0 0, 1 0, 1 1, 0 1, 0 0))'::geometry, 'POLYGON((10 10, 11 10, 11 11, 10 11, 10 10))'::geometry

]

), 0

);

MULTIPOLYGON(((0 0,1 0,1 1,0 1,0 0)),((10 10,11 10,11 11,10 11,10 10)))

Well, a collection of polygons is the same to have a multipolygon.

If there is a point or linestring on the data, it computes the polygons right again.

Thx

[robe]

I thought this was an issue with the old geos, but looking at a server I have running gives a multipolygon

POSTGIS="3.4.1 3.4.1" [EXTENSION] PGSQL="150" GEOS="3.12.1-CAPI-1.18.1" SFCGAL="SFCGAL 1.5.0, CGAL 5.6, BOOST 1.78.0" PROJ="8.2.1 NETWORK_ENABLED=OFF URL_ENDPOINT=https://cdn.proj.org USER_WRITABLE_DIRECTORY=C:\Users\paragon\AppData\Local/proj DATABASE_PATH=C:\Program Files\PostgreSQL\15\share\contrib\postgis-3.4\proj\proj.db" LIBXML="2.9.14" LIBJSON="0.12" LIBPROTOBUF="1.2.1" WAGYU="0.5.0 (Internal)"

However passing 0 for shrink percent I'm tempted to say should be illegal, so it's probably treating that as a no op. Maybe we should just prevent 0 from being passed in. For example if I do:

SELECT ST_AsText(ST_ConcaveHull(

    ST_COLLECT(

        array[

            'POLYGON((0 0, 1 0, 1 1, 0 1, 0 0))'::geometry, 'POLYGON((10 10, 11 10, 11 11, 10 11, 10 10))'::geometry

        ]

    ), 0.8

)); 

I get:

POLYGON((10 11,11 11,11 10,10 10,1 0,0 0,0 1,1 1,10 11))

and shows me visually what I would expect.

[latot]

mmm, I did not test the percent, but will not fix it, testing the same example, while the ratio is lower than ~0.51 we will have a multi poly, is not exclusive of 0 ratio… D:

[pramsey]

This is 100% a GEOS thing. I'm not Sure precisely how much I care, you could also decompose the polygons to their points (ST_Points) and run that against the concave hull function. Depends on what kind of result you are looking for, if you really want a *polygon* concave hull, rather than a point-wise one.

[mdavis]

This is due to the current behaviour of the ConcaveHullOfPolygons algorithm in JTS/GEOS. It allows the hull to be eroded past the point where the output is fully connected. In contrast, the ConcaveHull algorithm for points ensures that the output is a single connected polygon. I can't remember why this decision was made - perhaps it was just an oversight. It should be possible to require that the output is fully connected.