ST_MinimumBoundingCircle creates invalid geometries

[cswingle]

Certain combinations of PostGIS 2.3.3 and dependent libraries cause ST_MinimumBoundingCircle to create invalid geometries.

For example on an Ubuntu Xenial, AMD64 system (with ubuntugis-unstable):

POSTGIS="2.3.3 r15473" 
GEOS="3.5.1-CAPI-1.9.1 r4246" 
PROJ="Rel. 4.9.2, 08 September 2015" 
GDAL="GDAL 1.11.3, released 2015/09/16" 
LIBXML="2.9.3" 
LIBJSON="0.11.99" RASTER

SELECT ST_IsValid(ST_MinimumBoundingCircle(ST_GeomFromText(
    'MULTIPOINT(-150.646548 69.6052122,
                -150.641227 69.578776,
                -150.641227 69.578776,
                -150.659938 69.575257)')));
NOTICE:  IllegalArgumentException: Points of LinearRing do not form a
closed linestring
 st_isvalid
 ------------
  f

The same SQL is successful on several other identical versions of PostGIS, but with different libraries. These are two example systems where it works (Debian stretch and Debian jessie, AMD64):

POSTGIS="2.3.3 r15473" 
GEOS="3.5.1-CAPI-1.9.1 r4246" 
PROJ="Rel. 4.9.3, 15 August 2016" 
GDAL="GDAL 2.1.2, released 2016/10/24" 
LIBXML="2.9.4" 
LIBJSON="0.12.1" RASTER

POSTGIS="2.3.3 r15473" 
GEOS="3.4.2-CAPI-1.8.2 r3921" 
PROJ="Rel. 4.8.0, 6 March 2012" 
GDAL="GDAL 1.10.1, released 2013/08/26" 
LIBXML="2.9.1" 
LIBJSON="0.11.99" RASTER

Since it's the same version of PostGIS each time, it seems likely that it's another library causing the issue but I don't know enough about these interactions to identify a culprit or a solution for my Xenial system.

[robe]

Works on my end. Is it possible maybe you didn't upgrade scripts during upgrade. By doing

ALTER EXTENSION postgis UPDATE;

ST_MinimumBoundingCircle is an plpgsql function and I think we made recent updates to it, so perhaps the ones where you are having issue have out of date scripts.

Given that you have various versions of GEOS all working, I would rule out GEOS as the culprit and even your PROJ have various flavors working, but ST_MinimumBoundingCircle doesn't use proj anyway.

If you run this it will show any mismatch:

SELECT postgis_full_version();

mine reads

POSTGIS="2.3.3 r15473" GEOS="3.6.1-CAPI-1.10.1 r4317" PROJ="Rel. 4.9.1, 04 March 2015" GDAL="GDAL 2.2.1, released 2017/06/23" LIBXML="2.7.8" LIBJSON="0.12" RASTER

Also output

SELECT postgis_liblwgeom_version();

mine returns:

2.3.3 r15473

[dbaston]

Do the results of ST_MinimumBoundingRadius differ between the two systems? Could you please provide those results?

[cswingle]

Yes, the results also differ for ST_MinimumBoundingRadius:

On the good system:

SELECT postgis_liblwgeom_version();
2.3.3 r15473

SELECT ST_MinimumBoundingRadius(ST_GeomFromText(
    'MULTIPOINT(-150.646548 69.6052122,
                -150.641227 69.578776,
                -150.641227 69.578776,
                -150.659938 69.575257)'));
(0101000000888931CEE5D462C0BAA40902C5655140,0.0164071662296832)

and the failing one:

SELECT postgis_liblwgeom_version();
2.3.3 r15473

SELECT ST_MinimumBoundingRadius(ST_GeomFromText(              
    'MULTIPOINT(-150.646548 69.6052122,
                -150.641227 69.578776,
                -150.641227 69.578776,
                -150.659938 69.575257)'));
(0101000000000000000000F8FF000000000000F8FF,NaN)

I had already updated PostGIS on the failing system. To confirm, I tried again:

ALTER EXTENSION postgis UPDATE;
NOTICE:  version "2.3.3" of extension "postgis" is already installed

[dbaston]

Very helpful, thanks. The computed radius of NaN is pretty suspect!

This behavior isn't related to the dependent libraries, but it could conceivably vary from machine to machine based on the compiler used, etc.

I'm guessing this has something to do with a the small number of coordinates and presence of a duplicate coordinate.

As a workaround, I'm almost certain you'll see correct values if you wrap your inputs in ST_UnaryUnion.

[cswingle]

Thanks much for your suggestion to use ST_UnaryUnion. That does indeed resolve the error for all the rows in my query.

[robe]

dbaston,

I'm going to mark this one as a wontfix since it seems platform specific. Or do you think ST_UnaryUnion can be put in place without any performance loss?

If so maybe we can milestone it for 2.4.0 and do it before release. Even after I do the beta release it's fine, since it's technically a bug fix.

Feel free to unmark as wontfix if you think there is something we can do about it without causing more damage than good.

[dbaston]

Well, it happens to show up on a particular platform (and not an unusual one), but it's a symptom of a bug in the algorithm somewhere. Once the cause is found, it should be fixed back to 2.3.

[cswingle]

If there's something more I can do to help figure it out, let me know. It's a common system (Ubuntu Xenial), but with the ubuntugis-unstable PPA.

[cswingle]

I just spun up a Xenial virtual server with the ubuntugis-unstable PPA and couldn't replicate the issue. I think the problem may be that at one time I built a custom GDAL which is still in /usr/local/gis and has a linker entry in /etc/ld.so.conf.d. The system GDAL is GDAL 2.2.1, released 2017/06/23, but PostGIS is seeing the custom-built GDAL 1.11.3, released 2015/09/16. I no longer need the custom GDAL since the packaged versions have long since surpassed it, but I'm leery of blowing it away for fear of it breaking PostGIS on a production system.

[dbaston]

Appreciate you trying to replicate it. If you feel like experimenting, you could try rearranging the order of the points in the input to see which order(s) cause it to fail. And of course you can browse the source at ​https://github.com/postgis/postgis/blob/svn-trunk/liblwgeom/lwboundingcircle.c if you're into that sort of thing.

[robe]

cswingle,

PostGIS extension is made up of 2 libs postgis-2.3 (for geometry /geography) and rtpostgis-2.3 (for raster).

It's only the rtpostigs-2.3 that depends on GDAL so I seriously doubt that is the culprit.

[robe]

I can't replicate this on my PostGIS 2.5.0beta1 and GEOS 3.6.3. Dismissing as worksforme.