[postgis-devel] Making SFCGAL mandatory

[Regina Obe]

> -----Original Message-----
> From: postgis-devel [mailto:postgis-devel-bounces at lists.osgeo.org] On Behalf
> Of Sandro Santilli
> Sent: Thursday, November 15, 2018 5:25 AM
> To: PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
> Subject: Re: [postgis-devel] Making SFCGAL mandatory
> 
> On Thu, Nov 15, 2018 at 01:08:54PM +0300, Darafei "Kom?pa" Praliaskouski
> wrote:
> 
> > >
> > > Probably. I don't remember exactly why we chose to use GUC.
> > > Functions in their own schema like sfcgal.ST_Intersects() could have
> > > been a solution as well (?)
> >
> > Can we change that for PostGIS 3.0, so that instead of
> > postgis.backend=sfcgal one will set search_path=postgis_sfcgal,public?
> 
> +1
> 
> --strk;
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel
[Regina Obe] 
What?  NO  -1

That is a super breaking change.  We'd have to remove the postgis schema qualfications in SFCGAL since we wouldn't know where postgis is installed.  We've already got issues with postgis.topology and postgis_tiger_geocoder because of this.
Let's not compound the issue.

The reason we introduced the backend was because we had fantasies of SFCGAL functions overtaking GEOS.  That has not happened yet, and may never will.

In reality the only functions that fall into this boat where the backend even comes into play outline in the pretty little chart here

https://postgis.net/docs/manual-2.5/PostGIS_Special_Functions_Index.html#PostGIS_TypeFunctionMatrix  - those ones with white cubes -- that's our overlap.

Let's consider some of these:

ST_Intersects -- I never understood why we'd want to use SFCGAL for this as the intersects in SFCGAL is much slower.  I think it was so the 3D behaves consistently so only useful if you want a 2D intersects for a 3D geometry or need a intersects for TINS (accept possibly for 2D TINS -- who on earth has 2D TINS?) - it's way slower.  With your proposed schema search_path craziness I'd be forced to schema qualify WHICH ST_Intersects I want anyway to prevent it from using the slower SFCGAL one I DON'T WANT or schema qualify all my SFCGAL function uses. 

ST_Union - again WHY - why would I want to use SFCGAL ST_Union for a 2D geometry (except for 2D TINS).  

ST_3DDistance -- okay yah I'd need this for solids -- you've got me there, but I still think we would have done better to call this ST_CGAL3DDistance or something.

ST_3DIntersects - this is a good case where it really matters in a useful way.  I'd much prefer calling it a different name (as Paul suggested) cause they really aren't the same and I wouldn't be guessing which one I'm using,  , but has the benefit of being able to handle TINS and also doing true SOLID intersects check.  Ours is just surface test at best as it treats each polygon patch as if it were just a 3D polygon and I don't think handles TINS.
Often times though I prefer using the built-in PostGIS one cause it's 100 times faster (though it's less correct), so I'd still need to schema qualify which one to use, which makes the whole search_path idea NOT USEFUL.  

ST_3DIntersection which Paul mentioned -- only SFGCAL implements this so it's always SFCGAL being used in this case regardless what backend you set.  Sure GEOS may someday but that hasn't happened.

What on earth makes you think that just because I'm using an SFCGAL function, I'd want to use the ST_Intersects/ST_3DIntersects of SFCGAL?

e.g in case of ST_StraightSkeleton -- which is only implemented by SFCGAL, that's really useful for 2D geometries, but I always use the PostGIS ST_Intersects if I need it, and I DON'T want to have to go around schema qualifying my use just to get the right one.


Thanks,
Regina